[sjatkins]

Heretical or not you are dead wrong. Don't think so? Go program in Forth or Assembler instead of your current main language for a while and get back to me. There would have been no reason to invent any HLL or even assembler if you were correct. Put aside your ruby and try to do the same work in vanilla C and get back to me.

[wpietri]

I think you're taking his point too literally. Yes, you can find a pathological interpretation of his words and beat that up. But his point is that most of the arguments people have here over language choice are irrelevant, because whether you're using PHP or Python or Ruby or Scala or Go is not the bottleneck in the system.

Personally, I agree. I've never seen a bad team succeed because of a good language, and I've never seen a good team fail because of a bad one. We argue over languages not because it makes or breaks companies, but because that's the most obvious feature of our days. We form tribes around languages the way non-programmers do around sports teams, and as with sports teams, minor differences get blown up into major social divisions. It's our own version of the streetlight effect: https://en.wikipedia.org/wiki/Streetlight_effect

I'm all for people arguing about language features when they are actually designing languages. But as far as building businesses around software, I think "Language X is a secret weapon" is absurd. If a good team picks something they're happy working in, then the biggest problem with a project will almost never be the language they picked.

[TheOtherHobbes]

I think that's wrong for at least some contexts, because - for example - Python is so slow that it can literally become the bottleneck on any non-toy server. So unless you're running a one-person blog or don't carDjango should probably not be your first choice for a scalable production server.

People argue about languages because they all have different trade-offs for performance/efficiency, initial development time, developer cost, developer availability, and maintenance.

The differences are real, and they have real effects on the profitability and the prospects of success/failure of any project.

Management quality and culture do too, obviously. But you can assume that for a given level of management competence, different languages will still create different business outcomes.

[Adlai]

Forth is as high-level as you'd like it to be.

http://www.colorforth.com/POL.htm

[e12e]

Indeed, a strange one to pick. I'd even say that if portability isn't a concern, working with x86_64 assembly is quite pleasant. If you avoid the lure of premature optimization, and stick with either function oriented, or at least procedure oriented programming, without too many long jumps -- I think you could get on quite fine in assembly.

The biggest issue, might be one that (sadly too) many low-level languages share: with the move to UTF-8 as the only sane choice for text, there are no string/char datatypes any more. No reason one can't use procedures/functions to deal with strings in assembly, but it would require a bit more planning than in a language that have "native" UTF-8 support.

[ed: I think Kollibri OS proves both points: it's a working OS, but they've yet to port from 32bit to 64bit even though they upstream they forked from (Menuet OS) has a 64 bit version (that's not Free software/open source).

http://kolibrios.org/en/

Another "big" asm OS project is: https://github.com/ReturnInfinity/Pure64 ]

[sklogic]

Forth should not be in this list, it is a meta-language. It can be quickly turned into something equally or more powerful than you current Blub (pick any, does not matter).

[coldtea]

"Quickly" without writing tons of Forth code, not. And it still wouldn't match 200.000 npm packages or a million or so for Java.