9 ms·

Death of a Language Dilettante

122 points by doty 10y ago

EdwardCoffin 10y ago
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.
- lolc 10y ago
  I just tried Elm and I can assure you that bad programmers can write bad code in any language, good or bad.
  - EdwardCoffin 10y ago
    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 10y ago
      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.
  - MaulingMonkey 10y ago
    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.
- jdcarter 10y ago
  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.
- MaulingMonkey 10y ago
  > 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.)
- eikenberry 10y ago
  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.
jpt4 10y ago
Temper the soldier rather than steel, and a club becomes a sword. A fairer example might be to compare the Nix and Guix package manager codebases, which aim to implement the same model of declarative system wide dependency management. The former is written by a university team in C++ and Perl, the latter by GNUcolytes in Guile Scheme and a touch of C.
- andreasvc 10y ago
  Well, which do you say is better?
  - jolux 10y ago
    I'm wondering too ^-^
  - 1_player 10y ago
    None sadly, one will be relegated to the "just an academic curiosity" phase, the other one to obscurity. [1] 1: https://news.ycombinator.com/item?id=10005646 https://news.ycombinator.com/item?id=10005646
- kazinator 10y ago
  > Temper the soldier rather than steel, and a club becomes a sword. WTF, I haven't heard that one before. Did you make it up? When I google it, your above comment is the third hit, and the previous two aren't relevant.
  - jpt4 10y ago
    The exact phrase, yes, but I read "Temper the fighter, not the sword" here: [0]. The general observation that either the tool or the operator can be improved in an operator-tool system is semi-regularly invoked in discussions of new programming languages/EDC multi-tools/governance models within my conversational circles. [0] https://www.reddit.com/r/systema/comments/3lcn5q/systema_lineage_whats_up_with_that/ https://www.reddit.com/r/systema/comments/3lcn5q/systema_lin...
- 10y ago
andreasvc 10y ago
It seems to me that if everyone followed the kind of pragmatism that this post argues for, nothing new would ever be adopted.
- knieveltech 10y ago
  Only if the new thing legitimately and very clearly solved a real problem that presented a credible barrier to work. That's a very high bar to clear when creating a new programming language.
- angersock 10y ago
  That would be a feature not a bug. Every developer should be forced, I believe, to read Arthur C. Clarke's story Superiority ( https://en.wikipedia.org/wiki/Superiority_%28short_story%29 https://en.wikipedia.org/wiki/Superiority_%28short_story%29 ) and to reflect on its application to their profession. EDIT: Story can be found here... http://www.mayofamily.com/RLM/txt_Clarke_Superiority.html http://www.mayofamily.com/RLM/txt_Clarke_Superiority.html
  - B1FF_PSUVM 10y ago
    > Story can be found here Well worth a few minutes. Not that teaching it would help much, wisdom rolls off people's minds like water off a duck's back.
ScottBurson 10y ago
Even something as blatantly broken as the pre-ES6 scoping rules in JavaScript isn't the fundamental problem it's made out to be. It hasn't been stopping people from making great things with the language. No, it hasn't been stopping them, but I guarantee you it's been slowing them down, at least a little. If nothing else, it makes the language a little bit harder to learn than it needed to be. I'll wager it also causes actual bugs that people have to spend time tracking down. It's true that those bugs can be avoided by proper discipline, but the brain cells required for enforcing that discipline could have been used for something else. ETA: I agree with the author that a certain pragmatism is useful in selecting a language for a particular project, but I still think it's important to raise people's consciousness about warts in language designs. Doing so improves the odds that the next language someone designs to scratch their personal itch, but that happens to catch on for some reason, will have fewer such warts.
- angersock 10y ago
  Has it been slowing them down as much as debugging new frameworks and build pipelines? Is it harder to learn a smaller thing with some tricks than a larger thing with few tricks? Those are two questions I often ask myself when thinking about the evolution of the JS ecosystem.
- xiaoma 10y ago
  Over 90% of the first 100k LOC I wrote was ES5 JavaScript or CoffeeScript. I don't actually recall even a single instance when I was bitten by a bug related to lexical scope on the job. Maybe the problem is people expecting JavaScript to work like Java or some other block scoped language. Async bugs, on the other hand, were nightmarish at times.
  - x0x0 10y ago
    Did you write the same 100 klocs of code in a language with lexical scoping before coming to js?
    - xiaoma 10y ago
sdenton4 10y ago
My take away here is that it only pays to be a programming language dilettante if you are actually building a programming language, especially if it's a dedicated language for a new platform. Otherwise, you're mostly going to be subject to whatever's already mostly in use on your platform of choice, up to minor tweaks in that language over time.
agentgt 10y ago
I find there are roughly two categories of languages that are worthwhile (based on my opinion of course). 1. Easy to write/produce: Languages/Framework that are easy to write because they are highly expressive (Haskell/Scala) or are very opinionated (Rails). 2. Easy to read/maintain: Verbose languages with excellent tools... cough... Java/C#. As for reading code I don't know what it is about crappy verbose languages but I have yet to see Java/C# code that I couldn't figure out what was going on. Sure I have more experience with these languages and the tools (particularly code browsing with an IDE) make it so much easier... but so do most people. The reality is language dilettantes think writing code is painful (as mentioned in the first paragraph by the author) but the real bitch is maintaining. I feel like there must be some diminishing returns on making a language too expressive, implicit, and/or convenient but I don't have any real evidence to prove such.
- EdwardCoffin 10y ago
  > I feel like there must be some diminishing returns on making a language too expressive, implicit, and/or convenient but I don't have any real evidence to prove such. I think it is understood that the more expressive your language is, the more difficult it is to make tools for the language. For example, Common Lisp style (non-hygienic) macros are hard to support in a debugger (by which I mean, hard to allow the developer to step through their code as they wrote it, rather than stepping through the final expanded form). Dynamic dispatch makes it difficult for tools to provide who calls and which function does this call invoke (not impossible, with some forms of static typing, but more difficult in general).
  - agentgt 10y ago
    I think I agree with that idea. However I have also wondered if it is because more explicit/verbose languages take longer to physically write and thus the verbose pattern is sort of repeated through out. For example in Java it is typical to have ridiculously long spelled out variable/function names. While this is annoying to write it often makes maintenance slightly easier for a variety of hopefully obvious reasons. It seems with really expressive languages you get programmers who will use extremely short variable/function names (Haskell being the extreme). Of course this could be just cultural (e.g. Haskell academia). That is it seems when the language gets easy people get lazy :) (this is probably a false assumption). I'm not sure if its analogous but an extreme opposite of expressive language would be punch cards. My grandmother used to work on ancient computers and you would have to really think ahead what you wanted to do. Consequently lots and lots of documentation would be done.
hyperpallium 10y ago
Unfortunately, the real value of anything is almost entirely due to extrinsic factors. Air? Very valuable if you're underwater, on the moon etc. Which human language? The one spoken by the people you need to communicate with is most valuable. The first iPhone? Very valuable then; not today. But some people love intrinsic value. And it's what they create that ends up having real value. They would say that intrinsic value is the only "real" value. They aren't very practical.
- pron 10y ago
  > They would say that intrinsic value is the only "real" value. Thing is, this is a testable hypothesis (at least in theory): measure whether those "intrinsically valued" languages make a true impact on software cost. Often, it is the very same people who tout this intrinsic value who deliberately shy away from testing this hypothesis empirically. It's interesting that when Java's original designers analyzed customer needs vs. features offered by academic languages, they discovered that most value in those languages wasn't in the linguistic features but in the extra-linguistic features, so they deliberately put all the good stuff in the VM, and packaged it in a language designed to be as unthreatening and as familiar as possible. It was designed to be a wolf in sheep's clothing: It was clear from talking to customers that they all needed GC, JIT, dynamic linkage, threading, etc, but these things always came wrapped in languages that scared them. -- James Gosling[1] [1]: https://www.youtube.com/watch?v=Dq2WQuWVrgQ https://www.youtube.com/watch?v=Dq2WQuWVrgQ
  - hyperpallium 10y ago
    Thanks, I've just watched it (only up to your quote). I agree, but how did customers need JIT? I thought it was just to compensate for the inherent performance penalty of an extra layer, of a VM. BTW: Android java now uses ahead-of-time compilation (5.0 switched from JIT dalvik to AOT art). Just on the "wolf" part: not only was the language familiar (sheep's clothing), but features were removed. Not just for familiarity, they actually caused problems and so removing them was an improvement. e.g. removing operator overloading (which C++ had): apart from very fundamental maths (such as complex numbers and matrices), these caused a lot of problems. Probably because they were algebras designed by non-mathematicians. Removing them hurt matrix algebra etc, but was by far a net benefit. (BTW a nice thing about shader languages is matrices as first class values). Finally, taking this back to my GP comment on intrinsic vs extrinsic: I was thinking of the language as a "product" which would include the VM... but I think your approach is better. Along those lines, performance, bugginess, portability of the runtime etc are also non-linguistic features, strictly speaking. Actually testing that hypothesis is really difficult. I've only heard of a few attempts to measure productivity in different languages, and their experimental design is not very compelling. Of course, in practice, all those non-linguistic factors dominate. Yet, some of James' non-linguistic "wolf" features have linguistic counter-points: e.g. no memory management; threading. Therefore, they are examples of linguistic features with "intrinsic value". I'd also include references (instead of pointers), and array-bounds checking (um... is that last one a "linguistic" feature?) I think some language features have real value - though, as with java's inspirations, probably not the whole language, just particular features. [ But I meant by my statement, that these folks think intrinsic value is the only "real" value, that they dispute extrinsic value entirely! i.e. that ideas are eternal, valuable absolutely and despite context; and contingent fluctuations in supply and demand, progress of technology and install base etc are 100% meaningless. Like the truth of a theorem, regardless of its usefulness. ]
Zak 10y ago
This article isn't exactly wrong. Certainly, running on your target platform and having library support for the things you're trying to do are critical features for getting anything done, and a great language that lacks these things in the wrong tool for the job. That doesn't mean criticism of bad design choices in, say, Javascript is mistaken, or as the author describes it, "troubling". It just means you probably have to use Javascript anyway[0]. It also leaves out another reason for learning languages and using them for pet projects: it makes you a better programmer. The more good languages you know, and idioms from those languages, the more likely you are to recognize when an ad-hoc implementation of one of those idioms is the right solution to a problem in the language you're actually using. [0] Though possibly only as a compilation target.
clitmouse 10y ago
matlab? custom function was (or still is?) a one-function-one-file. i had bunch of function-files in a project directory. my mind was literally scattered. then i moved on to languages that allow binding function to variable. i had much less files. simpler. FP with anonymous function further frees my mind from naming variables so i have zero chance of mistyped function names. easier maintenance? sure those didn't stop me from getting work done; however, i prefer to not waste time on weaker programming languages, although coding on those languages did broaden my mind (yeah, now i know they suck)
deleted 10y ago
[deleted]
grifter2000 10y ago
tl;dr: "Language regardless; lazy, indecisive people often fail to complete complex tasks."
sgt101 10y ago
Kinda mean to Ruby. Also misses the point, it's not the job at hand that matters, it's the 10000 jobs that keeping the thing alive that matters.
- Chris2048 10y ago
  Maybe. but actually what's important is investment cost versus the ratio of supply vs demand. There are lots of Java jobs, yes, but there are also lots of Java programmers too. I'm a python dev (now) and while I have to search a little longer for jobs, I get good pay still, since I'm also rarer.
  - sgt101 10y ago
    I think that what is important is how easy code is to maintain and how easy it is to move from 60 modules to 6000 modules (and beyond). Running a big code base in PHP is very, very difficult (I have done this, it was not a good experience) running a big code base in Java is better (I have done this too, it wasn't that great but some of the information hiding and abstractions in Java seemed to help partition the issues from one another). I have never run a large code base over a number of years in Python, I expect it's rather like doing things in Java. I feel strongly that if I had to run a large Julia code base (in about 2 years when it goes gold) then things might be much improved and much less make work might arise.
    - tanlermin 10y ago
      What do you mean by "goes gold"? Like 1.0?
      - sgt101 10y ago
        Yeah - when they (the dev's) underwrite that they believe that their original intent is fulfilled - 1.0
xigency 10y ago
When doing serious development and hitting these issues, the workaround isn't to continue using a broken language. The workaround is to use a different language. The first question 'Does this language run on the target system that I need it to?' isn't a yes or no question. Take a look at this example - http://blog.fogcreek.com/the-origin-of-wasabi/ http://blog.fogcreek.com/the-origin-of-wasabi/ A language that compiles to PHP and ASP, what a relief. And for the contemporary result - http://blog.fogcreek.com/killing-off-wasabi-part-1/ http://blog.fogcreek.com/killing-off-wasabi-part-1/ When the platform catches up, then you can go back to mainstream development with a useful language.
- spdegabrielle 10y ago
  Sometimes you need to write a compiler.
lmm 10y ago
Give me Scala and a real-world problem vs someone using using PHP or Javascript and I will beat them on the initial write, and destroy them on the maintenance. I wouldn't use Scala professionally if I didn't believe this. In the short term practical concerns can be more important than PLT ones - in five years' time I'm sure Idris will be a better language than Scala, but for some tasks it isn't yet - apart from anything else, you need a strong library/tool ecosystem before a language is truly useful. But that's a temporary state of affairs. If you were making this kind of judgement 20 years ago, and chose a popular language like Perl or TCL or C++ over a theoretically-nice language like OCaml or Haskell, how would you be feeling about that decision today?
- guelo 10y ago
  > like Perl or TCL or C++ how about PHP or Javascript?
  - lmm 10y ago
    Same thing I think, though I don't think anyone would have tried to write a serious program in JavaScript 20 years ago.
- pron 10y ago
  Give me Java and a real-world problem vs someone using using Scala and I will beat them on the initial write, and destroy them on the maintenance. :) > in five years' time I'm sure Idris will be a better language than Scala Idris? In the entire history of computing there has been a single[1] complete non-trivial (though still rather small) real-world program (CompCert) written in a dependently typed language. Even though the program is small and the programmer (Xavier Leroy) one of the leading dependent-type-based-verification experts, the effort was big (and that's an understatement) and the termination proofs proved too hard/tedious for him, so he just used a simple counter for termination and had a runtime exception if it ran out. Idris is a very interesting experiment, I'll give you that. But I don't see how anyone can be sure that it would work (although you didn't say it can work, only that it would "be a better language than Scala", so I'm not sure what your success metrics are). [1]: Approximately, though I don't know of any other.

122 points by doty 10y ago

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.

lolc 10y ago
I just tried Elm and I can assure you that bad programmers can write bad code in any language, good or bad.
- EdwardCoffin 10y ago
  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 10y ago
    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.
- MaulingMonkey 10y ago
  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.
jdcarter 10y ago
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.
MaulingMonkey 10y ago
> 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.)
eikenberry 10y ago
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.

jpt4 10y ago

Temper the soldier rather than steel, and a club becomes a sword. A fairer example might be to compare the Nix and Guix package manager codebases, which aim to implement the same model of declarative system wide dependency management. The former is written by a university team in C++ and Perl, the latter by GNUcolytes in Guile Scheme and a touch of C.

andreasvc 10y ago
Well, which do you say is better?
- jolux 10y ago
  I'm wondering too ^-^
- 1_player 10y ago
  None sadly, one will be relegated to the "just an academic curiosity" phase, the other one to obscurity. [1] 1: https://news.ycombinator.com/item?id=10005646 https://news.ycombinator.com/item?id=10005646
kazinator 10y ago
> Temper the soldier rather than steel, and a club becomes a sword. WTF, I haven't heard that one before. Did you make it up? When I google it, your above comment is the third hit, and the previous two aren't relevant.
- jpt4 10y ago
  The exact phrase, yes, but I read "Temper the fighter, not the sword" here: [0]. The general observation that either the tool or the operator can be improved in an operator-tool system is semi-regularly invoked in discussions of new programming languages/EDC multi-tools/governance models within my conversational circles. [0] https://www.reddit.com/r/systema/comments/3lcn5q/systema_lineage_whats_up_with_that/ https://www.reddit.com/r/systema/comments/3lcn5q/systema_lin...
10y ago

andreasvc 10y ago

It seems to me that if everyone followed the kind of pragmatism that this post argues for, nothing new would ever be adopted.

knieveltech 10y ago
Only if the new thing legitimately and very clearly solved a real problem that presented a credible barrier to work. That's a very high bar to clear when creating a new programming language.
angersock 10y ago
That would be a feature not a bug. Every developer should be forced, I believe, to read Arthur C. Clarke's story Superiority ( https://en.wikipedia.org/wiki/Superiority_%28short_story%29 https://en.wikipedia.org/wiki/Superiority_%28short_story%29 ) and to reflect on its application to their profession. EDIT: Story can be found here... http://www.mayofamily.com/RLM/txt_Clarke_Superiority.html http://www.mayofamily.com/RLM/txt_Clarke_Superiority.html
- B1FF_PSUVM 10y ago
  > Story can be found here Well worth a few minutes. Not that teaching it would help much, wisdom rolls off people's minds like water off a duck's back.

ScottBurson 10y ago

Even something as blatantly broken as the pre-ES6 scoping rules in JavaScript isn't the fundamental problem it's made out to be. It hasn't been stopping people from making great things with the language. No, it hasn't been stopping them, but I guarantee you it's been slowing them down, at least a little. If nothing else, it makes the language a little bit harder to learn than it needed to be. I'll wager it also causes actual bugs that people have to spend time tracking down. It's true that those bugs can be avoided by proper discipline, but the brain cells required for enforcing that discipline could have been used for something else. ETA: I agree with the author that a certain pragmatism is useful in selecting a language for a particular project, but I still think it's important to raise people's consciousness about warts in language designs. Doing so improves the odds that the next language someone designs to scratch their personal itch, but that happens to catch on for some reason, will have fewer such warts.

angersock 10y ago
Has it been slowing them down as much as debugging new frameworks and build pipelines? Is it harder to learn a smaller thing with some tricks than a larger thing with few tricks? Those are two questions I often ask myself when thinking about the evolution of the JS ecosystem.
xiaoma 10y ago
Over 90% of the first 100k LOC I wrote was ES5 JavaScript or CoffeeScript. I don't actually recall even a single instance when I was bitten by a bug related to lexical scope on the job. Maybe the problem is people expecting JavaScript to work like Java or some other block scoped language. Async bugs, on the other hand, were nightmarish at times.
- x0x0 10y ago
  Did you write the same 100 klocs of code in a language with lexical scoping before coming to js?
  - xiaoma 10y ago

sdenton4 10y ago

My take away here is that it only pays to be a programming language dilettante if you are actually building a programming language, especially if it's a dedicated language for a new platform. Otherwise, you're mostly going to be subject to whatever's already mostly in use on your platform of choice, up to minor tweaks in that language over time.

agentgt 10y ago

I find there are roughly two categories of languages that are worthwhile (based on my opinion of course). 1. Easy to write/produce: Languages/Framework that are easy to write because they are highly expressive (Haskell/Scala) or are very opinionated (Rails). 2. Easy to read/maintain: Verbose languages with excellent tools... cough... Java/C#. As for reading code I don't know what it is about crappy verbose languages but I have yet to see Java/C# code that I couldn't figure out what was going on. Sure I have more experience with these languages and the tools (particularly code browsing with an IDE) make it so much easier... but so do most people. The reality is language dilettantes think writing code is painful (as mentioned in the first paragraph by the author) but the real bitch is maintaining. I feel like there must be some diminishing returns on making a language too expressive, implicit, and/or convenient but I don't have any real evidence to prove such.

EdwardCoffin 10y ago
> I feel like there must be some diminishing returns on making a language too expressive, implicit, and/or convenient but I don't have any real evidence to prove such. I think it is understood that the more expressive your language is, the more difficult it is to make tools for the language. For example, Common Lisp style (non-hygienic) macros are hard to support in a debugger (by which I mean, hard to allow the developer to step through their code as they wrote it, rather than stepping through the final expanded form). Dynamic dispatch makes it difficult for tools to provide who calls and which function does this call invoke (not impossible, with some forms of static typing, but more difficult in general).
- agentgt 10y ago
  I think I agree with that idea. However I have also wondered if it is because more explicit/verbose languages take longer to physically write and thus the verbose pattern is sort of repeated through out. For example in Java it is typical to have ridiculously long spelled out variable/function names. While this is annoying to write it often makes maintenance slightly easier for a variety of hopefully obvious reasons. It seems with really expressive languages you get programmers who will use extremely short variable/function names (Haskell being the extreme). Of course this could be just cultural (e.g. Haskell academia). That is it seems when the language gets easy people get lazy :) (this is probably a false assumption). I'm not sure if its analogous but an extreme opposite of expressive language would be punch cards. My grandmother used to work on ancient computers and you would have to really think ahead what you wanted to do. Consequently lots and lots of documentation would be done.

hyperpallium 10y ago

Unfortunately, the real value of anything is almost entirely due to extrinsic factors. Air? Very valuable if you're underwater, on the moon etc. Which human language? The one spoken by the people you need to communicate with is most valuable. The first iPhone? Very valuable then; not today. But some people love intrinsic value. And it's what they create that ends up having real value. They would say that intrinsic value is the only "real" value. They aren't very practical.

pron 10y ago
> They would say that intrinsic value is the only "real" value. Thing is, this is a testable hypothesis (at least in theory): measure whether those "intrinsically valued" languages make a true impact on software cost. Often, it is the very same people who tout this intrinsic value who deliberately shy away from testing this hypothesis empirically. It's interesting that when Java's original designers analyzed customer needs vs. features offered by academic languages, they discovered that most value in those languages wasn't in the linguistic features but in the extra-linguistic features, so they deliberately put all the good stuff in the VM, and packaged it in a language designed to be as unthreatening and as familiar as possible. It was designed to be a wolf in sheep's clothing: It was clear from talking to customers that they all needed GC, JIT, dynamic linkage, threading, etc, but these things always came wrapped in languages that scared them. -- James Gosling[1] [1]: https://www.youtube.com/watch?v=Dq2WQuWVrgQ https://www.youtube.com/watch?v=Dq2WQuWVrgQ
- hyperpallium 10y ago
  Thanks, I've just watched it (only up to your quote). I agree, but how did customers need JIT? I thought it was just to compensate for the inherent performance penalty of an extra layer, of a VM. BTW: Android java now uses ahead-of-time compilation (5.0 switched from JIT dalvik to AOT art). Just on the "wolf" part: not only was the language familiar (sheep's clothing), but features were removed. Not just for familiarity, they actually caused problems and so removing them was an improvement. e.g. removing operator overloading (which C++ had): apart from very fundamental maths (such as complex numbers and matrices), these caused a lot of problems. Probably because they were algebras designed by non-mathematicians. Removing them hurt matrix algebra etc, but was by far a net benefit. (BTW a nice thing about shader languages is matrices as first class values). Finally, taking this back to my GP comment on intrinsic vs extrinsic: I was thinking of the language as a "product" which would include the VM... but I think your approach is better. Along those lines, performance, bugginess, portability of the runtime etc are also non-linguistic features, strictly speaking. Actually testing that hypothesis is really difficult. I've only heard of a few attempts to measure productivity in different languages, and their experimental design is not very compelling. Of course, in practice, all those non-linguistic factors dominate. Yet, some of James' non-linguistic "wolf" features have linguistic counter-points: e.g. no memory management; threading. Therefore, they are examples of linguistic features with "intrinsic value". I'd also include references (instead of pointers), and array-bounds checking (um... is that last one a "linguistic" feature?) I think some language features have real value - though, as with java's inspirations, probably not the whole language, just particular features. [ But I meant by my statement, that these folks think intrinsic value is the only "real" value, that they dispute extrinsic value entirely! i.e. that ideas are eternal, valuable absolutely and despite context; and contingent fluctuations in supply and demand, progress of technology and install base etc are 100% meaningless. Like the truth of a theorem, regardless of its usefulness. ]

Zak 10y ago

This article isn't exactly wrong. Certainly, running on your target platform and having library support for the things you're trying to do are critical features for getting anything done, and a great language that lacks these things in the wrong tool for the job. That doesn't mean criticism of bad design choices in, say, Javascript is mistaken, or as the author describes it, "troubling". It just means you probably have to use Javascript anyway[0]. It also leaves out another reason for learning languages and using them for pet projects: it makes you a better programmer. The more good languages you know, and idioms from those languages, the more likely you are to recognize when an ad-hoc implementation of one of those idioms is the right solution to a problem in the language you're actually using. [0] Though possibly only as a compilation target.

clitmouse 10y ago

matlab? custom function was (or still is?) a one-function-one-file. i had bunch of function-files in a project directory. my mind was literally scattered. then i moved on to languages that allow binding function to variable. i had much less files. simpler. FP with anonymous function further frees my mind from naming variables so i have zero chance of mistyped function names. easier maintenance? sure those didn't stop me from getting work done; however, i prefer to not waste time on weaker programming languages, although coding on those languages did broaden my mind (yeah, now i know they suck)

deleted 10y ago

[deleted]

grifter2000 10y ago

tl;dr: "Language regardless; lazy, indecisive people often fail to complete complex tasks."

sgt101 10y ago

Kinda mean to Ruby. Also misses the point, it's not the job at hand that matters, it's the 10000 jobs that keeping the thing alive that matters.

Chris2048 10y ago
Maybe. but actually what's important is investment cost versus the ratio of supply vs demand. There are lots of Java jobs, yes, but there are also lots of Java programmers too. I'm a python dev (now) and while I have to search a little longer for jobs, I get good pay still, since I'm also rarer.
- sgt101 10y ago
  I think that what is important is how easy code is to maintain and how easy it is to move from 60 modules to 6000 modules (and beyond). Running a big code base in PHP is very, very difficult (I have done this, it was not a good experience) running a big code base in Java is better (I have done this too, it wasn't that great but some of the information hiding and abstractions in Java seemed to help partition the issues from one another). I have never run a large code base over a number of years in Python, I expect it's rather like doing things in Java. I feel strongly that if I had to run a large Julia code base (in about 2 years when it goes gold) then things might be much improved and much less make work might arise.
  - tanlermin 10y ago
    What do you mean by "goes gold"? Like 1.0?
    - sgt101 10y ago
      Yeah - when they (the dev's) underwrite that they believe that their original intent is fulfilled - 1.0

xigency 10y ago

When doing serious development and hitting these issues, the workaround isn't to continue using a broken language. The workaround is to use a different language. The first question 'Does this language run on the target system that I need it to?' isn't a yes or no question. Take a look at this example - http://blog.fogcreek.com/the-origin-of-wasabi/ http://blog.fogcreek.com/the-origin-of-wasabi/ A language that compiles to PHP and ASP, what a relief. And for the contemporary result - http://blog.fogcreek.com/killing-off-wasabi-part-1/ http://blog.fogcreek.com/killing-off-wasabi-part-1/ When the platform catches up, then you can go back to mainstream development with a useful language.

spdegabrielle 10y ago
Sometimes you need to write a compiler.

lmm 10y ago

Give me Scala and a real-world problem vs someone using using PHP or Javascript and I will beat them on the initial write, and destroy them on the maintenance. I wouldn't use Scala professionally if I didn't believe this. In the short term practical concerns can be more important than PLT ones - in five years' time I'm sure Idris will be a better language than Scala, but for some tasks it isn't yet - apart from anything else, you need a strong library/tool ecosystem before a language is truly useful. But that's a temporary state of affairs. If you were making this kind of judgement 20 years ago, and chose a popular language like Perl or TCL or C++ over a theoretically-nice language like OCaml or Haskell, how would you be feeling about that decision today?

guelo 10y ago
> like Perl or TCL or C++ how about PHP or Javascript?
- lmm 10y ago
  Same thing I think, though I don't think anyone would have tried to write a serious program in JavaScript 20 years ago.
pron 10y ago
Give me Java and a real-world problem vs someone using using Scala and I will beat them on the initial write, and destroy them on the maintenance. :) > in five years' time I'm sure Idris will be a better language than Scala Idris? In the entire history of computing there has been a single[1] complete non-trivial (though still rather small) real-world program (CompCert) written in a dependently typed language. Even though the program is small and the programmer (Xavier Leroy) one of the leading dependent-type-based-verification experts, the effort was big (and that's an understatement) and the termination proofs proved too hard/tedious for him, so he just used a simple counter for termination and had a runtime exception if it ran out. Idris is a very interesting experiment, I'll give you that. But I don't see how anyone can be sure that it would work (although you didn't say it can work, only that it would "be a better language than Scala", so I'm not sure what your success metrics are). [1]: Approximately, though I don't know of any other.