4 ms·

> 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. Every

by 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.

cbanek 10y ago
> how easy it is to discover the program which implements certain functionality. Agree. But that is a composition of both language syntax/features and libraries. For example, I could write my own HTTP library in sockets in C++, or I could use cURL. I don't need a new language for that. I think your tradeoff is actually a false dichotomy. The compile time checks do give you confidence that the program implements what you think you implemented (not exactly the spec), but it is really how you design your code that allows malleability for changes. Obviously a good design makes it easy to change, and a bad design makes it hard to change. Some languages that lack these things, like Go, can make it hard. But usually it is the newer languages that I find lack these features. While some languages are more "malleable" than others, maybe with generics / templates / parametric types, I would say it is your code and how you write it, no matter what language it is in, that matters the most to your malleability. > With enough of a budget, you can just throw more people at fixing defects the compiler didn't check for. You still have to throw people at the code, because compilers aren't meant to find defects, they are there to build your code, and while some of your defects prevent that from happening, compiling isn't even close to correctness. Even if your compiler checked everything, it would only check what you coded, not what the spec says.
- kmill 10y ago
  > But that is a composition of both language syntax/features and libraries I agree with that, but I also think of a language as being syntax, libraries, and idioms together. Libraries give words, and the base language gives the ability to coin new ones. This is something Stephen Wolfram was advertising with his rebranding of Mathematica as the Wolfram Language, since while a pattern matching execution engine is useful symbolic calculations, it is nothing compared to the body of algorithms and data already curated and ready for use. > I could use cURL Arguably, the cURL is itself a specialized language for interacting with different file protocols, designed so that sort of task is easy. It's an embedded DSL in C. > I think your tradeoff is actually a false dichotomy. I didn't mean for it to be a dichotomy, just that if you have too much of one quality then you tend to have less of the other since doing both well is hard. I was thinking about how in my experience programs in languages with lots of formalities tend to ossify and become hard to change. > but it is really how you design your code that allows malleability for changes. That is true, and that's why I'd rather have the language make the local concerns easy and malleable so I can spend more time thinking about the global design. > compilers aren't meant to find defects, they are there to build your code That is one way to view a compiler, though I appreciate how hard it is to get NullPointerException-like-defects in Haskell. I also didn't actually mean "check" for defects, I meant making it so that defects can't happen due to some language feature which precludes them. Typo-like defects, not necessarily whether the program provably matches the spec. (And spec checking tends to make the language less malleable to spec changes...) I'm sure you'd agree that it is nice we don't have to allocate addresses by hand for variables anymore, and with it dealing with the class of errors of miscoding the address of a variable, or the difficulty of updating a program when the variable positions change. (I'm much too young to have been there for this early history, but I have compiled small programs by hand for hobby projects or educational value.) Most compiled languages don't let you use a variable which has not been declared (and at least C emits a warning) --- this can be thought of as a language feature which addresses variable address defects.
sullyj3 10y ago
> This is sort of like the absurdity in a rational agent always knowing what is best for them: it disregards computational complexity. Somewhat off-topic, but have you seen this? Seems interesting: https://intelligence.org/2016/09/12/new-paper-logical-induction/ https://intelligence.org/2016/09/12/new-paper-logical-induct...
- kmill 10y ago
  Yeah, it does seem interesting (and I've seen Tsvi around the Berkeley math department). Maybe someday I'll spend the time to understand it! When I said the thing about complexity, I was thinking about intuitionism. For an intuitionist, the only things which can be said to be true are the things you can believe with your faculties. This is where the "intuitionists don't believe in the law of the excluded middle" comes from --- just because you can see that something can't not be true doesn't mean you see it is --- or something like that. I wonder if this logical induction is a sort of Bayesian intuitionism, extending logical faculties with probabilistic ones. And, random thought, I wonder if there is a Turing-complete programming language you can design where you can prove something can be written in it, but actually finding that program is not decidable. Then, while it's true anything can be written in any language, this one would be provably infeasible to do so.

by kmill 10y ago

cbanek 10y ago

> how easy it is to discover the program which implements certain functionality. Agree. But that is a composition of both language syntax/features and libraries. For example, I could write my own HTTP library in sockets in C++, or I could use cURL. I don't need a new language for that. I think your tradeoff is actually a false dichotomy. The compile time checks do give you confidence that the program implements what you think you implemented (not exactly the spec), but it is really how you design your code that allows malleability for changes. Obviously a good design makes it easy to change, and a bad design makes it hard to change. Some languages that lack these things, like Go, can make it hard. But usually it is the newer languages that I find lack these features. While some languages are more "malleable" than others, maybe with generics / templates / parametric types, I would say it is your code and how you write it, no matter what language it is in, that matters the most to your malleability. > With enough of a budget, you can just throw more people at fixing defects the compiler didn't check for. You still have to throw people at the code, because compilers aren't meant to find defects, they are there to build your code, and while some of your defects prevent that from happening, compiling isn't even close to correctness. Even if your compiler checked everything, it would only check what you coded, not what the spec says.

kmill 10y ago
> But that is a composition of both language syntax/features and libraries I agree with that, but I also think of a language as being syntax, libraries, and idioms together. Libraries give words, and the base language gives the ability to coin new ones. This is something Stephen Wolfram was advertising with his rebranding of Mathematica as the Wolfram Language, since while a pattern matching execution engine is useful symbolic calculations, it is nothing compared to the body of algorithms and data already curated and ready for use. > I could use cURL Arguably, the cURL is itself a specialized language for interacting with different file protocols, designed so that sort of task is easy. It's an embedded DSL in C. > I think your tradeoff is actually a false dichotomy. I didn't mean for it to be a dichotomy, just that if you have too much of one quality then you tend to have less of the other since doing both well is hard. I was thinking about how in my experience programs in languages with lots of formalities tend to ossify and become hard to change. > but it is really how you design your code that allows malleability for changes. That is true, and that's why I'd rather have the language make the local concerns easy and malleable so I can spend more time thinking about the global design. > compilers aren't meant to find defects, they are there to build your code That is one way to view a compiler, though I appreciate how hard it is to get NullPointerException-like-defects in Haskell. I also didn't actually mean "check" for defects, I meant making it so that defects can't happen due to some language feature which precludes them. Typo-like defects, not necessarily whether the program provably matches the spec. (And spec checking tends to make the language less malleable to spec changes...) I'm sure you'd agree that it is nice we don't have to allocate addresses by hand for variables anymore, and with it dealing with the class of errors of miscoding the address of a variable, or the difficulty of updating a program when the variable positions change. (I'm much too young to have been there for this early history, but I have compiled small programs by hand for hobby projects or educational value.) Most compiled languages don't let you use a variable which has not been declared (and at least C emits a warning) --- this can be thought of as a language feature which addresses variable address defects.

sullyj3 10y ago

> This is sort of like the absurdity in a rational agent always knowing what is best for them: it disregards computational complexity. Somewhat off-topic, but have you seen this? Seems interesting: https://intelligence.org/2016/09/12/new-paper-logical-induction/ https://intelligence.org/2016/09/12/new-paper-logical-induct...

kmill 10y ago
Yeah, it does seem interesting (and I've seen Tsvi around the Berkeley math department). Maybe someday I'll spend the time to understand it! When I said the thing about complexity, I was thinking about intuitionism. For an intuitionist, the only things which can be said to be true are the things you can believe with your faculties. This is where the "intuitionists don't believe in the law of the excluded middle" comes from --- just because you can see that something can't not be true doesn't mean you see it is --- or something like that. I wonder if this logical induction is a sort of Bayesian intuitionism, extending logical faculties with probabilistic ones. And, random thought, I wonder if there is a Turing-complete programming language you can design where you can prove something can be written in it, but actually finding that program is not decidable. Then, while it's true anything can be written in any language, this one would be provably infeasible to do so.