5 ms·

I feel like what we are getting wrong is throwing the baby out with the bathwater... repeatedly. Engineers love to engineer things. Why do people invent new l

by cbanek 10y ago

I feel like what we are getting wrong is throwing the baby out with the bathwater... repeatedly. Engineers love to engineer things. Why do people invent new languages? Sometimes it's a company trying to do something new, or something hard in a different language. Other times, it's someone who enjoys languages making a new language, thinking they've finally solved all the "hard problems," where "hard problems" is defined as problems they actually care about. If you're not making a programming language, you're probably making a DSL or something on top of another programming language, so now you have the fun and quirks of two languages. Instead, what if we had just a few programming languages, and made them more expressive? We'd avoid problems with language incompatibilities, libraries, and other general impedance mismatches. I chalk this up to a few of factors: 1) Your syntatic sugar is probably not as sweet as you think it is. Many times, people claim something is easier to read or work with when it is merely easier for them, and different for others. This causes confusion for people who aren't used to that syntax. Please stop trying to make boring code look interesting. Boring code is the easiest to work with and fix. 2) Languages are hard, and working on a language is a lot harder than most people think. Once your "brilliant idea for a new language feature" actually gets implemented, the more it does, the more likely it is to screw something up. To quote Scottie: "The more they overthink the plumbing, the easier it is to stop up the drain." 3) Because of #1 and #2, language development for major languages like python and C++ are slow. People hate slow, and so they'd rather build something special for themselves, or try some new language, because it's more fantastical. If this is a project for fun, go for it. But if this is for a business, people always constantly think some new tool is the silver bullet. What actually happens is you end up hunting bugs up and down your stack, lack robust programming tools, and end up keeping up with breaking changes rather than using that new margarita machine.

pjc50 10y ago
There aren't really all that many popular languages, and adoption is a huge hurdle. I don't think we have too much of a problem of wheel reinvention or syntatic sugar. Rust, for example, is trying genunine innovation in semantics. You also have to face the problem that, once a feature is shipped in a programming language, you can (almost) never remove it. This is why Python2->Python3 is taking so long: it's backwards-incompatible.
- cbanek 10y ago
  Adoption is a big problem, but I also think we overrate how awesome it would be to have everything in the latest language. A lot of times, you just don't need to. You simply need it to continue running. People also adopt new languages and then have more of the same exact problem, and more quickly. As for Rust, the problem becomes how do you interoperate with all the other things that aren't as "innovative." Really this means that there's a lot more work that needs to be done, either to port, adopt, or rework lower levels. This is exactly what I was saying in that "languages are hard." Also, not being a Rust programmer, what can I do in Rust that I can't do in any other programming language? In the end, languages are about getting stuff done: expressing a program. If you're making a language that can do all those things, and I can make a library in an existing language that can do the same job, it seems the library is winning by a lot. The library is the abstraction and the API provides the semantics.
  - kmill 10y ago
    > what can I do in $LANGUAGE that I can't do in any other programming language? In the end, languages are about getting stuff done: expressing a program. Everything can be tapped out with paperclips on the data bus in the end. What separates different languages is how easy it is to discover the program which implements certain functionality. This is sort of like the absurdity in a rational agent always knowing what is best for them: it disregards computational complexity. I haven't programmed in Rust, but from what I've heard is that the linear logic helps guide you away from programs which would involve use-after-free or multiple-mutation errors. The parametric type system also guides you away from certain subtle type errors other languages tend to let you get away with. Potentially, having a language which limits your search away from well-known but hard-to-avoid programming errors helps you write the correct program sooner. So long as your notion of "correct" is correct. An important tradeoff is between (1) compile-time checks which give confidence that a program implements its specification and (2) malleability in the face of a changing specification. With too many checks, it becomes hard to change the program (though with enough checks you can have some sense of what some changes break). Without enough malleability, the code rots. I'm curious how Rust is here. With enough of a budget, you can just throw more people at fixing defects the compiler didn't check for.
adrusi 10y ago
Instead, what if we had just a few programming languages, and made them more expressive? Because one of the most valuable things a language can do is remove unnecessary components to make a coherent small set of abstractions. That's incompatible with designing a language to support everyone's favorite feature.
- cbanek 10y ago
  I agree with the spirit of what you say, but there's a lot of finer points in here. There's what the language can do (syntax wise), what the standard library can do, and what 3rd party libraries can do. I agree less syntax is better. The syntax is probably the hardest part, since it is the base. A lot of standard libraries are where the meat is though, and when these are lacking, problems quickly arise. Example: C++ before the STL (yeah, dating myself here.) If you have good syntax and good standard libraries, then you should be able to make good 3rd party libraries. "Language features" I typically lump into the bundle of syntatic sugar. The only time this doesn't come into effect is when you simply can't accomplish the job any other way. Overall, I agree, we should have as few as possible "language features."

by cbanek 10y ago

pjc50 10y ago

There aren't really all that many popular languages, and adoption is a huge hurdle. I don't think we have too much of a problem of wheel reinvention or syntatic sugar. Rust, for example, is trying genunine innovation in semantics. You also have to face the problem that, once a feature is shipped in a programming language, you can (almost) never remove it. This is why Python2->Python3 is taking so long: it's backwards-incompatible.

cbanek 10y ago
Adoption is a big problem, but I also think we overrate how awesome it would be to have everything in the latest language. A lot of times, you just don't need to. You simply need it to continue running. People also adopt new languages and then have more of the same exact problem, and more quickly. As for Rust, the problem becomes how do you interoperate with all the other things that aren't as "innovative." Really this means that there's a lot more work that needs to be done, either to port, adopt, or rework lower levels. This is exactly what I was saying in that "languages are hard." Also, not being a Rust programmer, what can I do in Rust that I can't do in any other programming language? In the end, languages are about getting stuff done: expressing a program. If you're making a language that can do all those things, and I can make a library in an existing language that can do the same job, it seems the library is winning by a lot. The library is the abstraction and the API provides the semantics.
- kmill 10y ago
  > what can I do in $LANGUAGE that I can't do in any other programming language? In the end, languages are about getting stuff done: expressing a program. Everything can be tapped out with paperclips on the data bus in the end. What separates different languages is how easy it is to discover the program which implements certain functionality. This is sort of like the absurdity in a rational agent always knowing what is best for them: it disregards computational complexity. I haven't programmed in Rust, but from what I've heard is that the linear logic helps guide you away from programs which would involve use-after-free or multiple-mutation errors. The parametric type system also guides you away from certain subtle type errors other languages tend to let you get away with. Potentially, having a language which limits your search away from well-known but hard-to-avoid programming errors helps you write the correct program sooner. So long as your notion of "correct" is correct. An important tradeoff is between (1) compile-time checks which give confidence that a program implements its specification and (2) malleability in the face of a changing specification. With too many checks, it becomes hard to change the program (though with enough checks you can have some sense of what some changes break). Without enough malleability, the code rots. I'm curious how Rust is here. With enough of a budget, you can just throw more people at fixing defects the compiler didn't check for.

adrusi 10y ago

Instead, what if we had just a few programming languages, and made them more expressive? Because one of the most valuable things a language can do is remove unnecessary components to make a coherent small set of abstractions. That's incompatible with designing a language to support everyone's favorite feature.

cbanek 10y ago
I agree with the spirit of what you say, but there's a lot of finer points in here. There's what the language can do (syntax wise), what the standard library can do, and what 3rd party libraries can do. I agree less syntax is better. The syntax is probably the hardest part, since it is the base. A lot of standard libraries are where the meat is though, and when these are lacking, problems quickly arise. Example: C++ before the STL (yeah, dating myself here.) If you have good syntax and good standard libraries, then you should be able to make good 3rd party libraries. "Language features" I typically lump into the bundle of syntatic sugar. The only time this doesn't come into effect is when you simply can't accomplish the job any other way. Overall, I agree, we should have as few as possible "language features."