[jbrennan]

I feel like you could do even better if you approached a language design from the other side, instead of focussing on the lower-level aspects to instead be thinking of higher level aspects. If I were designing a programming language, I would start with what the development environment would look like, what tools do I want to build to support development in the language, etc., and then build the language to support that.

It seems so often languages are built, and then the tools are an afterthought, things like debugging, visualizing program flow, code assist, whatever it may be. What if program flow (that is, what's going on inside the program) were in mind from the start, instead of something you try and add later.

Just my thoughts. Is this a feasible way to design a language?

[MattJ100]

Depends what your goal is. Your approach is to optimize for developer productivity. Mike's is to optimize for machine productivity.

The question is whether it is possible to do both at once, hence Mike's point about the ideal language needing to find the right high-level abstractions (machine-efficient and developer-intuitive). What we currently have is somewhere in-between, but more towards the machine-efficient side. It's quite easy to produce inefficient code, without realising it, in today's high-level languages.

[jbrennan]

>Your approach is to optimize for developer productivity. Mike's is to optimize for machine productivity.

Yeah that's a valid point. And it's probably just my lack of experience in language design or just general naïveté. It seems like for most devices (modern smartphones, tablets, traditional computers) are fast enough that we'd be better served focusing on developer productivity in newer languages. Sure, they'll never compete with C in terms of efficiency.

Besides, I can still easily create terribly inefficient code in C ;)

[justincormack]

Devices maybe but servers less so, if you can get a 100x performance increase from going g from say PHP to LuaJIT then you can save a lot of money without a productivity loss.

[jbrennan]

Definitely. But you're also not going to stand to gain as much from writing some of the tools I'm talking about, anyway.

There will definitely always been places where software efficiency trumps programmer efficiency, but for a lot of cases, it doesn't. It's still important, just not always the most important.

[mamcx]

I think the same. I have dream to build one myself, but lack the expertise and the time for it. However, I think on it very similar to how build a "normal" app: The end-user, thinking in the most tedious work (like debugging, pass data & transformation, etc) then think in how could be it write. In fact I look at my past projects and try to remember what were the parts that waste more time...

But is certainly harder than think: How make recursion?