jlesk

Thanks for the comment.

The benchmark might seem like apples-to-oranges, but they both do templating & routing, which is what is being tested.

I also address this on the benchmark page:

Why compare a language to a framework?

1) THT takes a “batteries included” approach by providing essential web framework features.

2) Some might be worried that running a transpiled language would be too slow to run in production, and Laravel is arguably the best example of a production-ready PHP framework.

Also, yes it is essentially a new language. I don't expect anyone to rewrite large PHP applications in it, but people might consider it for new projects.

Strangely enough, many countries also have cultural laws around what languages can be used for subtitles and audio tracks. For example, IIRC there is a country in SA that doesn't allow non-Spanish subtitles if the primary audio is in Spanish.

There are all kinds of permutations like that which can look like arbitrarily bad UI decisions if you don't know the greater context.

I really like the line art logo on the site, but it's 2.4 MB (avatar.png).

Might want to size it down and run it through TinyPNG. :)

If you're into this kind of thing, I made a similar Turtle clone with a simpler syntax:

http://prismaco.de/

But I also like the approach here of using Turtle as a way to introduce JavaScript syntax. :)

Double-arrows let you signify that the tag is different with no extra effort because it's just an extra tap where your finger is already positioned.

It also has a right directionality to imply that it has scope until the end of the line.

Triple-arrow is the same idea, but uses the convention that triple-characters are common for delineating multi-line blocks.

Hi, thanks for your feedback.

I can understand that it might not seem useful to you if you already have a stack you've invested in, or it just doesn't fit the kind of projects you are working on.

But I just wanted to respond to a few things. :)

A) Come from a javascript background

It targets all web developers, who are all generally familiar with JavaScript. It aims to be another tool, not a total replacement for all projects.

B) Want to deploy on cheap hosters where node isn't available?

Shared hosting is still a very popular way to run websites. And node is often overkill for basic CRUD sites.

C) Don't care about performance

There is a big difference between not needing to support 100+ requests per second and "not caring". :) Out of the box, PHP is fast enough for a lot of apps, and the overhead of THT is not enough to be noticeable at that scale.

don't mind the additional complexity of the transpiler

There are no build steps, so the extra complexity just involves running the initial setup script. After that, you drop in new files and update them like you would with PHP. Ideally, it won't feel more complex than any other framework.

Can this even leverage the enormous PHP ecosystem?

This is on the roadmap. Though there are still plenty of projects that don't use 3rd party libraries and could be built with THT as it is today.

I personally have never needed to use composer, etc. in my projects, but it's still something I am looking to support.

Thanks!

I've used Node for many years, but I do find it too complex for some of my projects.

Sometimes you just need a handful of dynamic pages that you want to put up on a shared host somewhere. PHP is great for that.

Douglas Crockford also has a good article on how to implement Pratt parsing in JavaScript:

https://crockford.com/javascript/tdop/tdop.html

I referenced it often when I implemented THT. (https://tht.help)

Netflix employee here. You can find out a lot about our culture from our culture page:

https://jobs.netflix.com/culture

It's not just marketing fluff. It really does a good job of reflecting what it's like to work there, and is taken seriously by everyone from the top down.

As I mentioned elsewhere in this thread, it's not a competitive environment, and I've experience very little politics and drama. Those things are explicitly counter to the culture.

As for long hours, while the work day can be pretty intense, the office is usually empty by 5-6pm.

Hope that helps.

As a Netflix employee, I wouldn't really describe our culture as cutthroat at all. My experience in 5 years has almost entirely devoid of politics.

For example, from our culture page: "We have no bell curves or rankings or quotas such as “cut the bottom 10% every year.” That would be detrimental to fostering collaboration, and is a simplistic, rules-based approach we would never support."

https://jobs.netflix.com/culture

Our culture can feel intimidating, especially if you have any degree of imposter syndrome, but with very few exceptions, my colleagues and managers have always been supportive and really great to work with.

Netflix employee here. We have a high performance culture, certainly, but it's not the singular focus. I have probably seen just as many people let go for their inability to work well with others as anything performance-related.

From our culture page:

"...there are no “brilliant jerks.” The cost to teamwork is just too high. Our view is that brilliant people are also capable of decent human interactions, and we insist upon that."

https://jobs.netflix.com/culture

This is why I introduced LockStrings as a key feature of THT (a language that compiles to PHP). It takes the opposite approach to Perl's taint mode. You mark string literals as safe -- everything else is untrusted.

Functions that do risky things (Database, System calls, etc.) only accept LockStrings and are responsible for escaping, so all you have to do is provide the placeholders.

https://tht.help/tutorials/language-tour#lock-strings

Most of the principles are always in tension to some degree, and come down to a design decision. In this case, the shorter, clearer term won out. The two terms are practically synonymous, so if you know what a "boolean" is, you probably know what a "flag" is.

In actual use, you rarely interact with the names anyway -- you use `true` and `false` as values like most other languages.

I've been a designer/programmer pretty much my entire career and currently work on a research-centric UX design team. So while I've been designing my own language (THT, a language that compiles to PHP, aiming to fix most of the issues with that language), I've been applying usability concepts to the design.

A few principles:

- Acknowledging that the user is probably familiar with other languages, so stay within those conventions when possible. This is inspired by Jakob Nielsen's maxim that web designers should acknowledge that their users send 99% of their time on other websites.

- Making the most common activities the easiest. Larry Wall refers to this as applying Huffman coding to the syntax itself.

- Safe defaults. Making dangerous operations less convenient than the safe path. PHP has pretty much the opposite behavior, where many of the default design choices lead to security issues.

- Cognitive Load. Minimizing visual noise and the number of micro-decisions the user has to make. i.e. There should be one (good) way to do it.

- Preferring shorter, clearer terms over technical jargon. e.g. I use the terms "Flag" instead of "Boolean" and "List" instead of "Array". One can get pedantic over the exact meanings of symbols, but during the actual act of programming, simpler terms can help reduce friction.

The project is at https://tht.help if anyone is curious.

Nice work so far. There seems to be growing interest in online roleplaying, but most of the current offerings are lacking right now.

I personally launched Fabletop.com a couple of months ago, but the approach is a bit different, focusing more on a robust chat system, and less on the battlemat.

Good luck to you guys!

Do you also own recievd.com? I'm sure a lot of people forget "I before E, except after C."

Normally I'd agree with you, for those exact reasons, and my first prototypes were all generally flat (also being a fan of the Ultima series.)

But when I tried the current isometric style on a whim, it managed to solve all of the problems I was trying to address. Probably because I use a hybrid approach: only the underlying battlemat tiles are isometric. The miniatures are flat, slightly-transparent stand-ups and always face the player.

All of the top-down approaches just look ugly to me. You're either looking at the top of people heads, or tokens of disembodied heads. This also gives it a pseudo-3d look, with a bit of clutter to add that homey tabletop atmosphere.

I learned a lot from playing D&D as well -- my interest in graphic/info design can be traced back to when I was designing my own charts and character sheets.

Related to D&D and startups, my current project is a web-based virtual tabletop for roleplaying, built on node. =)

http://tabletopquest.com

After doing it the longhand way for over 10 years, I will never go back to that after using Haml. It just feels like the right solution to the problem of dealing with lots of nested markup. It might not be obvious what a benefit it is until you try it. I actually use my own custom-rolled flavor of Haml that is less Ruby-like, and I think it maps a bit better to the stylesheet and javascript.

On the topic of javascript templates, I tried Jaml for a while because I really wanted to have templates that could be cached on the client-side, but the function-based approach was really cumbersome. I ended up creating a server-side pre-processor that converts Haml to vanilla javascript functions that just build the output using string concatenation. These are called at run-time by underscore's template function. Overall, I'm totally happy with it so far.

I use composers for my slices: copland, glass, tallis, bach

I use Cancel buttons for pop-up forms all the time. It usually just hides the containing div, so re-opening the form will show the data as it was entered previously. Making the Submit button 2-3x longer than the Cancel button helps mitigate the risk of accidentally hitting the wrong thing.

There were even fewer options when I wanted to go this route 2 years ago, so I just went with a standard payment processor (BMT Micro) and charge one-time payments for users to pre-pay for time. e.g. $19.99 for 3 months or $59.99 for a year.

If you want to get from zero to charging ASAP, this might be worth considering. You could probably be integrated in a day or so. They are mainly geared toward downloadable software vendors, but I just use the "serial code" field as an Activation Code that the user enters into their profile page.

BMT Micro's royalty rate is around 10%, have awesome customer service, and just added a recurring option. The main downside is limited control over the template. I would also look into FastSpring since they are newer and seem to have more flexibility with the store configuration.

I have users that spend nearly all of their free time on my site. One recently asked me to ban them so they could kick the habit. I asked him what part of the site was addictive and he said, "Basically everything."

One of the key things, I think, is having lots of little things to do that you can get immediate feedback from. e.g. Check the forum for new replies, rate new content, see what kind of response their content is getting, etc.

Kathy Sierra has a great article on this kind of thing: http://headrush.typepad.com/creating_passionate_users/2005/0...

Having strict moderation keeps the general quality high, which means it's usually worth checking back to see what's new. There are also multiple tracks of achievement, like hitting 500 comments, etc. so there is always a new badge within striking distance.

You don't even need to have permanent badges. I have a list on the front page of the people who have submitted the most ratings that day. You don't get anything from being on the list, but people try to get to the top anyway. People like seeing their own names.

Having a friendly community is also a big help, since it means that other users are a direct source of positive feedback. That's a bit harder to develop, though.

I've always enjoyed the fun/weird bits of the Perl community and wrote a fair bit of (intentionally) obfuscated Perl a few years back.

My personal best was this "zombie" code: http://www.joelesko.com/cgi-bin/obfu.pl?obfuID=5

I deal with this every day, since I run a community of opinionated teenage band geeks, which can be worse than any technical forum I've seen.

My approach is that if you want the community to grow in the right direction, you have to keep pruning the bad stuff. So my main tool has been ruthless deletion. There's no convoluted point system to distract from the conversation with endless tweaking, meta-discussion, and arguments about being downvoted.

There is also one big ban button for the mods -- no reputation or warning system. I just rely on their judgment. We have occasionally banned new members just for having terrible attitudes. Sometimes we try to talk it out first, but often it's not worth the time. Maybe this only applies to younger users, but I've found that you have to toss out the bad apples as early as possible, because their attitudes will spread.

As a result, I've been called a dictator a few times (justifiably), and there have been a few bruised egos, but everyone else raves about how great the community is. Right now there is a civil discussion about Opera vs Broadway, and a thread with over 100 posts giving kudos to one another about their accomplishments, which was started by a regular user, not me.

Many banned members apologize and beg to be let back in, but I have learned to say no, because they relapse. Some have even threatened me, but I would rather have those people complaining loudly about how much of a jerk I am, than to have my best members silently leave because the site has gone downhill (though some people will say that no matter what you do).

Anyway, maybe that approach won't work in a place like this, but I believe that if you have a strong opinion about how a community should behave, don't screw around trying to be "fair" or clever. Just pick a bunch of people that share the same opinion and let them aggressively prune the bad stuff.

I get some inspiration from package design: http://www.thedieline.com