5 ms·

This is horribly pragmatic, but a reason that can contribute to a langugauge's success and popularity comes from how easy it is for new users to "pick it up", "

by bleair 12y ago

This is horribly pragmatic, but a reason that can contribute to a langugauge's success and popularity comes from how easy it is for new users to "pick it up", "find libraries that they find useful" and build working prototypes for "itches they want to scratch". I'm making broad generalizations, but as examples, if you wanted to build a program to perform some numerical analysis or maybe build an analytical simulation you could pick fortran and you'd likely find libraries and examples to help you out. If you wanted to build a simple web page backed by a database you could grab php & some of its libraries and you would be quickly constructing web pages. With java you could find examples of tools / libraries for churning through databases and also plugging into various web application frameworks. If you wanted to write a PhD about computer languages you could use lisp :P. I've found great value in python personally because the examples were decent and more importantly it was easy to see how to build the programatic bridges into the other languages and libraries I wanted to use. I'd strongly argue that ruby and node.js popularity can be partially traced to seeing the "fun" and / or neat examples that are shown off in tutorials. They show how to leverage the constructs provided by each language's common libraries and the resulting programs are interesting / neat to some number of potential adopters. In the 90s when I looked at ada there wasn't much in terms of libraries that I could leverage to explore problems that interested me at the time. Again, not every language has to be ideally suited to writing video games or web pages to be useful. Ada the language might have outstanding academically interesting aspects. If it doesn't help me solve real world problems I care about though it's less likely I'll invest the time to learn about it.

wting 12y ago
I like to categorize many features that lower initial difficulty as "deferred technical debt." There are type system features that ensure a higher degree of correctness, but it's not fun debugging compiler errors when you're trying to get something working. For example, being forced to handle errors immediately via return codes or option types is not "fun". By comparison, exceptions act as a giant GOTO and no one blinks an eye. Dynamic typing is also another form of deferred technical debt. It is preferable to handle type errors at runtime or through testing instead of at compile time. People who claim very few bugs are a result of type errors typically do not have experience with ADTs or stronger type systems than Java / C++ / C.[0] > Most programmers think that getting run-time errors, and then using a debugger to find and fix those errors, is the normal way to program. They aren't aware that many of those errors can be detected by the compiler. And those that are aware, don't necessarily like that, because repairing bugs is challenging, and, well, sorta fun. I don't think this attitude has changed in the past 16 years. People prefer to debug a run time stack rather than deal with compile errors, perhaps even more so with the rise of dynamic languages. [0] Clojure community likes to argue that bugs arise from mutability more than type safety, but I don't have not experience to comment either way.
- waps 12y ago
  I disagree strongly with exception versus error codes. It sounds reasonable until you look at what real programmers (the kind that isn't perfect) will do and how it affects production code. Real life programmers don't know the stack up and down and haven't read the documentation for the stuff they use. They will not have thought through every possible error case. Sucks, but that's real life. So any solution that depends on either of those will simply fail. So there's 2 ways to have parts of your program signal errors to other parts. The question that matters is what will mediocre programmers do ? If you force em to give errors through return codes, they will flat-out ignore the errors. That means errors, and all meta-information about them (like which file it is that won't open, or which host doesn't respond, that sort of thing) disappears into a black hole. It MAY end up in some log file, or it may not. Crucially, sometimes it disappears into a logfile that is custom to the library being used (at least in C). Needless to say, you will have memory leaks when this happens, and you will have invalid state. It may also lead to crashes directly, if it doesn't it will lead to "delayed crashes" (like OOM), and all sorts of fun behavior (which is why some system engineers prefer direct crashes : it makes the point where the problem gets created easy to identify). If you give them exceptions they will not handle the exceptions, nor will they get try ... finally correct. This will lead to memory leaks and inconsistent data. And it may lead to program crashes, BUT crucially it will preserve the error that was originally detected, and log it in the main program, making fixing the error critical. Is this "deferred technical debt" ? I can understand your reasoning, but I think checked exceptions are a much, much better solution than return values. What I find especially irritating is the moronic attitude that testing somehow makes up for not having static types. I have never seen a program that has half the tests any statically typed language automatically executes. Not even once.
  - ryanobjc 12y ago
    Yeah I totally agree here. There is a lot of hand wringing about hiring 'the best programmers' etc, but the reality is everyone is human and humans make mistake. Lets make the systems resilient to mistakes that humans make - strange how this seemingly simple statement is actually quite controversial around here! In truly large systems, all of the above happens and more. This is why error handling in C is so problematic, and why we toss it with Java. That go is bringing it back, is a little worrysome. Then again, go might be a hackers language, and might ultimately end up being the repository of write-once programs that aren't maintained.
waveman2 12y ago
To put it another way "It's the ecosystem, stupid." Apologies to Bill "It's the economy, stupid" Clinton.
- PhantomGremlin 12y ago
  Poor James Carville. According to Wikipedia he was the one who coined that phrase. But Clinton gets credit for it, much like (IIRC) Edison got a lot of credit for the work of his minions.

by bleair 12y ago

wting 12y ago

I like to categorize many features that lower initial difficulty as "deferred technical debt." There are type system features that ensure a higher degree of correctness, but it's not fun debugging compiler errors when you're trying to get something working. For example, being forced to handle errors immediately via return codes or option types is not "fun". By comparison, exceptions act as a giant GOTO and no one blinks an eye. Dynamic typing is also another form of deferred technical debt. It is preferable to handle type errors at runtime or through testing instead of at compile time. People who claim very few bugs are a result of type errors typically do not have experience with ADTs or stronger type systems than Java / C++ / C.[0] > Most programmers think that getting run-time errors, and then using a debugger to find and fix those errors, is the normal way to program. They aren't aware that many of those errors can be detected by the compiler. And those that are aware, don't necessarily like that, because repairing bugs is challenging, and, well, sorta fun. I don't think this attitude has changed in the past 16 years. People prefer to debug a run time stack rather than deal with compile errors, perhaps even more so with the rise of dynamic languages. [0] Clojure community likes to argue that bugs arise from mutability more than type safety, but I don't have not experience to comment either way.

waps 12y ago
I disagree strongly with exception versus error codes. It sounds reasonable until you look at what real programmers (the kind that isn't perfect) will do and how it affects production code. Real life programmers don't know the stack up and down and haven't read the documentation for the stuff they use. They will not have thought through every possible error case. Sucks, but that's real life. So any solution that depends on either of those will simply fail. So there's 2 ways to have parts of your program signal errors to other parts. The question that matters is what will mediocre programmers do ? If you force em to give errors through return codes, they will flat-out ignore the errors. That means errors, and all meta-information about them (like which file it is that won't open, or which host doesn't respond, that sort of thing) disappears into a black hole. It MAY end up in some log file, or it may not. Crucially, sometimes it disappears into a logfile that is custom to the library being used (at least in C). Needless to say, you will have memory leaks when this happens, and you will have invalid state. It may also lead to crashes directly, if it doesn't it will lead to "delayed crashes" (like OOM), and all sorts of fun behavior (which is why some system engineers prefer direct crashes : it makes the point where the problem gets created easy to identify). If you give them exceptions they will not handle the exceptions, nor will they get try ... finally correct. This will lead to memory leaks and inconsistent data. And it may lead to program crashes, BUT crucially it will preserve the error that was originally detected, and log it in the main program, making fixing the error critical. Is this "deferred technical debt" ? I can understand your reasoning, but I think checked exceptions are a much, much better solution than return values. What I find especially irritating is the moronic attitude that testing somehow makes up for not having static types. I have never seen a program that has half the tests any statically typed language automatically executes. Not even once.
- ryanobjc 12y ago
  Yeah I totally agree here. There is a lot of hand wringing about hiring 'the best programmers' etc, but the reality is everyone is human and humans make mistake. Lets make the systems resilient to mistakes that humans make - strange how this seemingly simple statement is actually quite controversial around here! In truly large systems, all of the above happens and more. This is why error handling in C is so problematic, and why we toss it with Java. That go is bringing it back, is a little worrysome. Then again, go might be a hackers language, and might ultimately end up being the repository of write-once programs that aren't maintained.

waveman2 12y ago

To put it another way "It's the ecosystem, stupid." Apologies to Bill "It's the economy, stupid" Clinton.

PhantomGremlin 12y ago
Poor James Carville. According to Wikipedia he was the one who coined that phrase. But Clinton gets credit for it, much like (IIRC) Edison got a lot of credit for the work of his minions.