In defense of complicated programming languages
viralinstruction.com
In defense of complicated programming languages
1–10 of 379 posts
Re: In defense of complicated programming languages
#2In case anyone hasn't seen this most excellent talk on this topic, I highly recommend: Guy Steele - Growing a Language (OOPSLA '98)
Re: In defense of complicated programming languages
#3A language with a short learning curve is like a toolbox that’s nearly empty. You quickly run out of ways it could help you. We should optimize for experts, because that’s where each of us is going to spend most of his career.
Re: In defense of complicated programming languages
#4A language with a short learning curve is like a toolbox that’s nearly empty. You quickly run out of ways it could help you. We should optimize for experts, because that’s where each of us is going to spend most of his career.
Is it possible to optimize too much for experts, and sacrifice learning curve too much?
Re: In defense of complicated programming languages
#5A language with a short learning curve is like a toolbox that’s nearly empty. You quickly run out of ways it could help you. We should optimize for experts, because that’s where each of us is going to spend most of his career.
Is it possible to optimize too much for experts, and sacrifice learning curve too much?
If you can’t retain any or the project is short-term, I suppose. Probably nobody could learn a new language just for a hackathon.
Re: In defense of complicated programming languages
#6A language with a short learning curve is like a toolbox that’s nearly empty. You quickly run out of ways it could help you. We should optimize for experts, because that’s where each of us is going to spend most of his career.
Is it possible to optimize too much for experts, and sacrifice learning curve too much?
C++ before 2011 springs to mind. From "Direction for ISO C++"[1]:
"C++ is expert-friendly, but it cannot be just expert-friendly without losing important streams of new talent. This was the case before C++11 and C++11 reversed that negative
trend."
[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p200...
Re: In defense of complicated programming languages
#7A language with a short learning curve is like a toolbox that’s nearly empty. You quickly run out of ways it could help you. We should optimize for experts, because that’s where each of us is going to spend most of his career.
Is it possible to optimize too much for experts, and sacrifice learning curve too much?
Languages don't get popular unless they are very easy to learn, so no language popular today almost surely is biased in favor of learning curve and against complexity. We probably need some big industrywide intervention to create the optimal level of complexity in languages as I doubt even C++ is too complex to be optimal if you consider that you work 40 years in a career. It would work by just having a couple of standard languages so developers don't need to learn so many languages, then they spend a lot of time learning those until they are fluent and then they don't have to learn anything new about programming languages for the rest of their lives, very efficient.
Re: In defense of complicated programming languages
#8A language with a short learning curve is like a toolbox that’s nearly empty. You quickly run out of ways it could help you. We should optimize for experts, because that’s where each of us is going to spend most of his career.
Is it possible to optimize too much for experts, and sacrifice learning curve too much?
Yes, as the creator of C++ has said [1] before.
Personally, I'd also distinguish between "complicated over time" and "complicated by default." For example, Clojure has a minimal syntax and instead uses a large vocabulary of terse primitive procedures. If you don't know the primitives, it's "complicated." A different example is Rust, which has many features expressed in syntax. If you haven't learned all of the syntax, it's "complicated." Compare these with C++, which began as a small set of extensions to a stronger-typed C, but has gradually grown into a family of sub-languages, each added for a particular purpose, and all interacting with each other (sometimes beautifully, other times horribly -- knowing the difference is "complicated").
Re: In defense of complicated programming languages
#9Earlier quoted context omitted.
Is it possible to optimize too much for experts, and sacrifice learning curve too much?
Languages don't get popular unless they are very easy to learn, so no language popular today almost surely is biased in favor of learning curve and against complexity. We probably need some big industrywide intervention to create the optimal level of complexity in languages as I doubt even C++ is too complex to be optimal if you consider that you work 40 years in a career. It would work by just having a couple of sta…
> It would work by just having a couple of standard languages so developers don't need to learn so many languages, then they spend a lot of time learning those until they are fluent and then they don't have to learn anything new about programming languages for the rest of their lives, very efficient.
Programming methodology continues to evolve and languages need to address it to stay relevant.
Re: In defense of complicated programming languages
#10A language with a short learning curve is like a toolbox that’s nearly empty. You quickly run out of ways it could help you. We should optimize for experts, because that’s where each of us is going to spend most of his career.
Is it possible to optimize too much for experts, and sacrifice learning curve too much?
I don't think so, if you assume that learning is a linear thing and at the end of it you improve as a dev.
But the problem is that learning isn't one curve, it's a bunch of them and most of them lead to dead ends or even turn backwards after a while.
If you bloat out a language, what happens is that some subset of devs (like, maybe 10%) write really great code and have all the tools they'll ever need to do so. And the other 90% learn a chaotic mix of good and bad practices from each other, without the ability to properly distinguish them, and eventually reach some local maxima amongst themselves of overcomplicated "average" code that's shittier than I imagine it would be if they just kept the language simple.