Sorry, no, there was no smugness. I agree with your points here quite firmly. I guess my tone didn't carry.

Thanks for saying as much!

Good coders can be productive and write good code in any mainstream language, contrary to what is said in the famous "PHP: a fractal of bad design"[0].

That said JavaScript has a number of the same problems as PHP and pointing this out should be equally acceptable as pointing out issues with PHP[1], and while I'm impressed that it was created in three weeks and impressed with the JS community we shouldn't pretend it is a very well designed language. People being productive in JS is pretty much a result of an amazing ecosystem, not because of the language.

For a very simple example of what JavaScript could have been, look at Typescript: anything you can do in JS you can also do in TS. In fact, "porting" from JS to TS is as simple as changing the file extension.

Yet except for the need for transpiling TS is massively easier to work with and can eliminate whole classes of problems when used correctly.

Source: Have programmed and maintained others creations in JS and later TS.

[0]: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

[1]: I also have programmed my fair share of PHP code. It doesn't have to be bad. But I'll happily admit that it isn't the prettiest or most well designed language I know.

> pointing this out should be equally acceptable as pointing out issues with PHP

Not the best example, considering that PHP has done its time as whipping boy. I've never been a PHP dev and I did my share of trash-talk against PHP instead of learning about the aspects that I could learn from.

My problem isn't that it's "unacceptable" to point out issues - it's that people aren't doing so CONSTRUCTIVELY. Instead, it's about finding the lesser social class to dump on freely.

For example - I have serious concerns/doubts about typescript and how it props up a tool-enhanced crutch for programming-as-communication that ultimately leads to lower-quality code. You would likely disagree and would raise your concerns about JS without TS. We can have a lovely conversation comparing points and, while it's probable neither of us is convinced by the other, we both walk away with a better understanding of the perspectives of others and impacts of code choices.

OR we could imply that JS isn't a "proper" programming language, and thereby JS devs aren't "proper" programmers and we can pat them on the head and tell them to run along and play.

Back when I was doing a lot of Perl dev (before my Java days) I noticed that the weaker Perl devs would hate-on Python (and the reverse), while the stronger Perl/Python devs would hang out with the stronger Python/Perl and compare notes. It took me a while to figure out why that made sense. The two communities had a lot of explicitly different philosophies, yet were really able to learn from one another and occasionally both languages improved as a result.

If JS isn't someone's preferred approach, that's fine...but that doesn't mean they are "lesser". They're _different_, just like different problem domains are _different_. That doesn't make them immune from criticism either, but I'm far more interested in those looking to broaden their views rather than broaden the reach of their current viewpoint.

Thanks for being so calm. In hindsight I regret my comment.

Reading your comment now and rereading your comment I realize you were defending Javascript programmers, not the language. (I guess we'll have to disagree about JavaScript the language :-)

I agree we shouldn't attack programmers because of language choice. And I am happy that I pointed out that I am amazed by the JS community as it hopefully shows that I wasn't trying to attack anyone.

Thanks for clarifying - I hope I didn't come across too defensive. It's definitely become a sensitive spot when so many are dismissive, so I might lash out at those undeserving of it.

As for the language - JS definitely has its warts and its holes. It's not a language I love, but it IS a language I greatly enjoy developing for. Then again, I thought Perl was a great language (albeit with its own warts) so my views are fairly unconventional. Definitely though, I tend to think that languages fall into a more complex graph than just "better" and "worse", or even "better at X" and "worse at X".

I completely disagree. It is physically impossible to be more productive in a C++ project that takes 5 minutes to compile compared to almost any interpreted language with a debug cycle spanning seconds. It's that simple. The next issue is the ecosystem. Often the language itself is completely irrelevant if the ecosystem is good enough but here is the thing: ecosystems are tied to languages. Yes I can be productive in "crappy language X" if I recreate the superior ecosystem of "super language S". I am not a superhuman lifeform that has the power of hundreds of bright human brains (millions of bad ones aren't enough) and the corresponding two hundred hands required to interface with the computer.

No. I will just pick a good ecosystem and the language it was built around and be happy instead of proving that you can build a skyscraper out of feces by producing steel via nuclear fusion.

It's very possible, but instead of debugging you spend more time thinking so you're making fewer iterations.

That said, I really enjoy Common Lisp for being compiled (good performance versus interpreted) and the speed of compiling (compiling single functions at a time) so you get the same time-to-execution as your interpreted languages. Better, actually, if you change the function definition in place when you hit a condition.

EDIT: I hit submit before finishing my thoughts.

C++ isn't that bad. 5+ minute compile times can be tightened down if you have a good structure for your codebase. And if it remains at 5+ minutes, that's what unit testing is for (shouldn't need the whole build to execute) along with a build pipeline. Submit the change and get results after a few minutes. Distcc and other systems can also aid for the really large projects. Another factor to consider, to test that interpreted (presumably dynamically typed) program you have to have more tests than the C++ program needs. Static typing (even though I have issues with C++'s type system, it's still ok) covers a lot of the areas that you have to manually create tests for in dynamically typed languages

We do Erlang and C++ for CUDA programming where I am. It would be nearly impossible for us to write good code for what we do in, say PHP, or even Java.