4 ms·
> how easy it is to discover the program which implements certain functionality. Agree. But that is a composition of both language syntax/features and librari
by 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.