[EdwardCoffin]

There are a couple of implicit assumptions in the final paragraphs that I think should be made explicit. One was that we can evaluate these languages based on this experiment with a single programmer. Another was the not-clearly-defined term strong work ethic, by which I think he means someone who will strive to make the program work properly, not have horrible kludges, will avoid known problematic aspects of the language, etc.

The problem with these assumptions is that you don't run into situations like that often. You're far more likely to run into a team of people of mixed abilities, and with some languages, one or two of them will be able to inflict horrors on the whole codebase.

[MaulingMonkey]

> Another was the not-clearly-defined term strong work ethic, by which I think he means someone who will strive to make the program work properly, not have horrible kludges, will avoid known problematic aspects of the language, etc.

Indeed. Using a different definition of "strong work ethic", I've met programmers who had too strong a "work ethic" - using it as an excuse or crutch to scoff at improvements to code readability or maintainability. After all, if you just power through it with enough overtime, you can wade through even the worst codebases, so why bother cleaning it up? To make things easier? And you want to take a break to step back, think on the problems, and discuss options instead of just sitting down and coding more? Sounds like you're just looking for excuses to be lazy - put down the coffee and get back to work!

Needless to say, this can lead to a lot of firefighting and damaged morale.

Ivory tower academics can get too caught up on theory to practice effectively. On the other hand, that's probably still preferable to the COBOL-only programmer that doesn't understand why things have changed since the 1970s - after all, COBOL can do anything your newfangled languages can! Better than either: Give me a practical polyglot. Preferably one who hates whatever terrible language we're going to be using, with a laundry list of issues that language has to back up that hate. Why such a hater? Because that hate sounds like the impassioned voice of experience with these problems (and how to mitigate or avoid them, even if one of those options - switching languages - isn't on the table.)

[lolc]

I just tried Elm and I can assure you that bad programmers can write bad code in any language, good or bad.

[MaulingMonkey]

The problem is that in some languages, good programmers cannot help but write bad code, and will review bad code without catching all the bad.

[EdwardCoffin]

I'm not disagreeing with that, what I am saying is that some languages offer up a power to perpetrate real horrors that some other languages don't. For instance, much as I love Common Lisp, I'd hate to work in a group with people who don't know how to write macros but do so anyway. There are all sorts of things one can get up to in C or assembly that you can't get up to in Java (deliberately treating a chunk of memory as if it were a type other than it really is, for example). Some languages like Smalltalk don't have a way of enforcing privacy on APIs, unlike say Java, so on a large project you can find out that someone you don't even know has just started using your private APIs and you are now obligated to support them as if they were public APIs, restricting your own freedom to change internals. These are all problems I have run into.

[lolc]

To me "bad programmers can write bad code in any language" is a snarky critique on favoring laws over conventions. There is this hope that given strong laws (safeguards), collaborating with unreasonable people is easier. Then the discussion devolves into the use of dangerous features versus the need to work with unreasonable people.

In my view, the discussion should be about comfort. At what abstraction levels will we work? If you put in a lot of safeguards, you can work comfortably at a certain level. But if you want to move out of this band, be it to write some low-level glue-code, or some higher abstractions, you find the safeguards to be a barrier. If those safeguards are conventions, you can agree to break them, if they are laws, you must subvert them or not work at those levels.

I prefer conventions as much as I prefer working with reasonable people. And sometimes turning conventions into law has few downsides, like with the private keyword.

[eikenberry]

The 'single programmer' bit is the most damning IMO. It assumes that a programming language is objectively good or bad, when they are instead a medium for creation where the personal affinities of the creator is the most important factor.

[jdcarter]

Precisely: language/library/framework decisions affect the whole team. If you choose something weird, you'll quickly be cursed under your teammate's breaths--if not get screamed at to your face--because eventually they're going to need to work on your code, too.

That's not to say you can't bring new technologies into a company. I've done it several times. You just need to understand that it's a big undertaking to get an entire team to buy in and learn that new tech.

Of course for hobby projects, go hog wild. That's how I pick up new languages.