Paul Graham has written some great essays over time, and most of them hold up surprisingly well as they age. Take this article, “Five Questions About Language Design“. Written in May 2001. That’s over 12 years ago from today as I read it, and many of his predictions have come to pass (the dominance of web applications, the rise in popularity of niche programming languages), and most of his logic is still sound, and still insightful.
Two particular points I found interesting, and would be interesting to the Haxe community I spend most of my time in:
4. A Language Has to Be Good for Writing Throwaway Programs.
You know what a throwaway program is: something you write quickly for some limited task. I think if you looked around you’d find that a lot of big, serious programs started as throwaway programs. I would not be surprised if most programs started as throwaway programs. And so if you want to make a language that’s good for writing software in general, it has to be good for writing throwaway programs, because that is the larval stage of most software.
I think Haxe is beginning to show it’s strength here in gaming. People are using it for Ludlam Dare (write a game in a single weekend), and then later the game scales up to be a full-featured, multi-platform, often commercial game. Haxe is good for a quick win (especially when targetting flash), but then you have the options to target so many other platforms as your vision for your game/app expands.
I’d love to see ufront get this good. I have so many things I would like to use as an app, but which I don’t feel justify an ongoing subscription to an online company. Many of them could get an MVP (minimal viable product) out in a weekend, if the framework was good enough. And it’s getting good enough, but still a little way to go :)
And then this:
2. Speed Comes from Profilers.
Language designers, or at least language implementors, like to write compilers that generate fast code. But I don’t think this is what makes languages fast for users. Knuth pointed out long ago that speed only matters in a few critical bottlenecks. And anyone who’s tried it knows that you can’t guess where these bottlenecks are. Profilers are the answer.
Language designers are solving the wrong problem. Users don’t need benchmarks to run fast. What they need is a language that can show them what parts of their own programs need to be rewritten. That’s where speed comes from in practice. So maybe it would be a net win if language implementors took half the time they would have spent doing compiler optimizations and spent it writing a good profiler instead.
Nice insight. I sometimes worry that the code I’m writing will be slow. It’s hard to know if optimisations are worth it, especially if it may compromise code readability etc. A better solution would be to focus on making profiling easy. On the JS target you can easily use the browser tools to show profiling information. Another option is to bake it into your Haxe code, something that the “massivecover” lets you do. Wiring that support from massivecover into ufront or other frameworks, and generating pretty reports, would be a very cool way to encourage people to write fast apps.