3 ms·

> In general, being successful and popular had little to do with how well a PL is designed. Perhaps, but it is fairly easy to design a product for a small, sel

by pron 2y ago

> In general, being successful and popular had little to do with how well a PL is designed. Perhaps, but it is fairly easy to design a product for a small, self-selecting group of fans who find the aesthetics appealing and so declare the design good for their taste. Unless a language becomes heavily used in codebases that are maintained for years by a large variety of programmers, it's hard to tell how well it is actually designed as a mass-appeal product. Two of the three languages you mentioned weren't able to attain nearly the same success as Java for as long a duration. I'd give C a similar success score because what it lacks in popularity it still makes up for in longevity, being almost twice as old. There are good reasons for why C is still as popular as it is. For example, in its domain -- which requires compilation to exotic architectures -- "good design" entails being able to easily implement efficient compilers.

int_19h 2y ago
Of course, when you compare languages, you have to compare them to contemporary ones that also target the same niche. In case of C, that would be e.g. Modula-2. The consequences of the industry making an expedient but wrong choice then - 45 years ago! - are still with us: C++ only just got proper modules, and even then most C++ code written today is still mostly using #include... And to be clear, I'm not advocating for aesthetics here. It's not like C# is a model of purity, either; but I would say that their choices over the years have been more pragmatic overall from the perspective of someone who needs to write readable, good quality code without jumping through too many hoops or getting lost in the verbiage.
- kaba0 2y ago
  > C# [..] but I would say that their choices over the years have been more pragmatic overall from the perspective of someone who needs to write readable, good quality code without jumping through too many hoops or getting lost in the verbiage. I personally don’t agree with that, C# is very “impulsive” at adding new features, which sounds cool in isolation, but makes the language significantly more complex to understand, and has non-intuitive interactions with other features. I think C# is quick at going the C++ way, and there is no return from there if we guarantee compatibility. I much prefer Java’s approach, where yeah, at times one might lack some syntactic sugar/nicety (often greatly overcome by IDE/tooling’s advancements), but over time they do add important ones, but only commit to features that have been earnestly tried and sustainable.
  - pron 2y ago
    > I think C# is quick at going the C++ way, and there is no return from there To be fair to Microsoft, they have favoured rich, complex languages for a long time now. They were probably the biggest champions of C++ and TypeScript also doesn't seem to be going down a particularly minimalistic route (an understatement). They're fans of rich languages, and while such languages are not my cup of tea, they do have a large audience (although I think it's a large minority audience).
- pron 2y ago
  Modula-2 wasn't really a contemporary of C's. By the time it was released, C had already taken over the world. Plus, it's yet another case of something that looks good but has never really been tested. While not quite Modula-2, in the early oughts I was working on a large project that was half written in C++ and half in Ada. We're talking millions of lines of code in both languages here. The Ada code looked nice but we were cursing when we had to work with it for two reasons: we had to consult thick Ada manuals to grapple with language intricacies, and compilation times were frustratingly slow. With C++ we could spend more time thinking about the algorithms as there was less "language lawyering", and we could run more tests (ironically, C++ now suffers from both of these problems). Perhaps that's why to this day I prefer smaller languages with short compilation times (I like Clojure but dislike Scala; I like Zig but dislike Rust). My point is that when people say that one language is technically superior to another, what they really mean is that it's superior in the technical aspects that they themselves value more than the aspects where the other language is technically superior. This is all fine, except that these personal preferences aren't distributed equally. This is a little like the Betamax vs. VHS debate. Sure, Betamax had a superior picture quality that some valued, but VHS had a superior recording time, which others valued but that latter group was bigger. As for C# -- strong disagree there. I think they're making the classic mistake of trying to solve every problem in the language and soon, resulting in a pretty haphazard collection of features, quite a few of them are anti-features, making up a pretty complicated language. For example, they have both properties and records, while in Java we figured that by adding records we'll both direct people toward a more data-oriented form of programming and at the same time make the problem of writing setters so much less annoying to the point it shouldn't be addressed by the language (while properties have the opposite effect of encouraging mutation). They've painted themselves into a very tight corner with async/await (the same with P/Invoke, which constrained their runtime's design making it harder to add user-mode threads), and I think they've made a big security mistake with interpolation -- something we're trying to avoid with a substantially different design. Also, while richer languages do have a lot of fans, all else being equal more people seem to prefer languages with fewer features. Our hypothesis is that it's better to spend a few years thinking how to avoid adding a language feature (like async/await or properties) than to spend a few months adding it. Also, every feature you add constrains you a little in the future (and every language makes this tradeoff early when it's trying to acquire users, but once it's established you need to be more careful). That's why we try to keep the abstraction level high at the expense of a quicker and tighter fit to a particular environment. This delays some things, but we believe it keeps us more flexible to adapt to future changes. It's like having an adaptation budget that you don't want to fully spend on your current environment (I think P/Invoke and properties are such examples of overfitting that pays well in the short term and make you less adaptable in the long term). The complexity budget is another you want to conserve. Add a language feature to make every problem easier, and over time you find yourself not only constrained, but with a pretty complex language that few want to learn.

by pron 2y ago

int_19h 2y ago

Of course, when you compare languages, you have to compare them to contemporary ones that also target the same niche. In case of C, that would be e.g. Modula-2. The consequences of the industry making an expedient but wrong choice then - 45 years ago! - are still with us: C++ only just got proper modules, and even then most C++ code written today is still mostly using #include... And to be clear, I'm not advocating for aesthetics here. It's not like C# is a model of purity, either; but I would say that their choices over the years have been more pragmatic overall from the perspective of someone who needs to write readable, good quality code without jumping through too many hoops or getting lost in the verbiage.

kaba0 2y ago
> C# [..] but I would say that their choices over the years have been more pragmatic overall from the perspective of someone who needs to write readable, good quality code without jumping through too many hoops or getting lost in the verbiage. I personally don’t agree with that, C# is very “impulsive” at adding new features, which sounds cool in isolation, but makes the language significantly more complex to understand, and has non-intuitive interactions with other features. I think C# is quick at going the C++ way, and there is no return from there if we guarantee compatibility. I much prefer Java’s approach, where yeah, at times one might lack some syntactic sugar/nicety (often greatly overcome by IDE/tooling’s advancements), but over time they do add important ones, but only commit to features that have been earnestly tried and sustainable.
- pron 2y ago
  > I think C# is quick at going the C++ way, and there is no return from there To be fair to Microsoft, they have favoured rich, complex languages for a long time now. They were probably the biggest champions of C++ and TypeScript also doesn't seem to be going down a particularly minimalistic route (an understatement). They're fans of rich languages, and while such languages are not my cup of tea, they do have a large audience (although I think it's a large minority audience).
pron 2y ago
Modula-2 wasn't really a contemporary of C's. By the time it was released, C had already taken over the world. Plus, it's yet another case of something that looks good but has never really been tested. While not quite Modula-2, in the early oughts I was working on a large project that was half written in C++ and half in Ada. We're talking millions of lines of code in both languages here. The Ada code looked nice but we were cursing when we had to work with it for two reasons: we had to consult thick Ada manuals to grapple with language intricacies, and compilation times were frustratingly slow. With C++ we could spend more time thinking about the algorithms as there was less "language lawyering", and we could run more tests (ironically, C++ now suffers from both of these problems). Perhaps that's why to this day I prefer smaller languages with short compilation times (I like Clojure but dislike Scala; I like Zig but dislike Rust). My point is that when people say that one language is technically superior to another, what they really mean is that it's superior in the technical aspects that they themselves value more than the aspects where the other language is technically superior. This is all fine, except that these personal preferences aren't distributed equally. This is a little like the Betamax vs. VHS debate. Sure, Betamax had a superior picture quality that some valued, but VHS had a superior recording time, which others valued but that latter group was bigger. As for C# -- strong disagree there. I think they're making the classic mistake of trying to solve every problem in the language and soon, resulting in a pretty haphazard collection of features, quite a few of them are anti-features, making up a pretty complicated language. For example, they have both properties and records, while in Java we figured that by adding records we'll both direct people toward a more data-oriented form of programming and at the same time make the problem of writing setters so much less annoying to the point it shouldn't be addressed by the language (while properties have the opposite effect of encouraging mutation). They've painted themselves into a very tight corner with async/await (the same with P/Invoke, which constrained their runtime's design making it harder to add user-mode threads), and I think they've made a big security mistake with interpolation -- something we're trying to avoid with a substantially different design. Also, while richer languages do have a lot of fans, all else being equal more people seem to prefer languages with fewer features. Our hypothesis is that it's better to spend a few years thinking how to avoid adding a language feature (like async/await or properties) than to spend a few months adding it. Also, every feature you add constrains you a little in the future (and every language makes this tradeoff early when it's trying to acquire users, but once it's established you need to be more careful). That's why we try to keep the abstraction level high at the expense of a quicker and tighter fit to a particular environment. This delays some things, but we believe it keeps us more flexible to adapt to future changes. It's like having an adaptation budget that you don't want to fully spend on your current environment (I think P/Invoke and properties are such examples of overfitting that pays well in the short term and make you less adaptable in the long term). The complexity budget is another you want to conserve. Add a language feature to make every problem easier, and over time you find yourself not only constrained, but with a pretty complex language that few want to learn.