3 ms·

That's a huge problem with programming languages: Designers can always add things, but removing stuff is hard. JavaScript is a great example of this. It still h

That's a huge problem with programming languages: Designers can always add things, but removing stuff is hard. JavaScript is a great example of this. It still has automatic semicolon insertion, variable hoisting, and a broken comparator (==). Practically everyone agrees these are bad things, but they can't be changed. Doing so would break backwards compatibility, and there's a huge ecosystem of JavaScript programs that would need to be updated. Also, language users often rebel when language designers make breaking changes. Python 3 tried to remove cruft, and look how slowly it's been adopted. Instead of adopting 3.x, people backported the features they wanted to 2.x. I would love it if C had less cruft, but when I say that I mean, "I want C with less cruft, but with the same huge ecosystem of documentation and libraries and tools and debuggers and profilers that crufty-C has."

taliesinb 14y ago
That's why I think the language Go is such a great development. The authors seem to have added only the minimum set of features that make the language workable for their initial needs. As a result, these features are largely orthogonal, and the rules are simple to state and learn -- even if they at first seem a bit odd (you have to cast all numeric types to each-other before they can interact). In contrast to Scala, another modern language I investigated recently, which seemed like quite a thicket of features.. some of which seemed just to be there to mediate the interaction of other features.
- deleted 14y ago
  [deleted]
its_so_on 14y ago
Let's talk about the solution here, since I'd like to know what it is! I'd like to hear what you guys have to say about it. ----------------- 1. Assumption: nobody is perfect and your programming language will have a gargantuan fault. since nobody is perfect, after the dust settles and you have a million users, your programming language will have a really gargantuan fault that is used hundreds of thousands of times throughout everyone's code. ----------------- 2. For this exercise let's make it extreme! Let's make this really extreme with something that's clearly braindead. Let's say in this language you have two comparisons for comparing integers, one for odd and one for even comparisons. (!!) =odd== which behaves like a normal comparison between two odd integers (5 =odd== 7 evaluates to false, and 5 =odd== 5 evaluates to true, but both 2 =odd== anything or anthing =odd== 8 is false, even 2 =odd== 2 or 8 =odd== 8) and =even== which is a normal comparison function between even integers and always false when either integer is odd, even if they have the same odd value. The normal way to do a comparison in this language is: (a % 2) ? a =odd== b : a =even== b ----------------- 3. aftermath Now, the language is at version 2.3 and there are HUNDREDS OF THOUSANDS of examples of the idiom (a % 2) ? a =odd== b : a =even== b throughout the codebase. It's a mess! Someone has the bright idea of cleaning up this cruft. Why not introduce ==, which compares an odd to an odd or an even and an even, returning true if the integer on the left equals the integer on the right, regardless of whether they're odd or even! ----------------- 4. how do you clean up? Great idea. Man, why didn't we think of this up-front. It's clearly much better. Well, nobody is perfect. It wasn't done this, better way, up front. NOBODY now argues that this way isn't better. But people have learned to live with this braindead feature. It's not just the one idiom either. Maybe you could search and replace (a % 2) ? a =odd== b : a =even== b with a new == -- but what do you do if someone uses =odd== or =even== outside that exact idiom? Maybe they have an arcane if-else clauses or functions that have bizarre logic and use these comparisons, which should not even exist. What do you do with it? Seriously. The dust has settled and you made a huge mistake. Now what do you do? - If you start over (3.0), it sounds like users will just backport your improvements. - If you introduce == WITHOUT breaking =odd== and =even==, people will keep writing code using =odd== and =even==, which is unreadable and wrong and a mess. - But if you DO break it, you break people's scripts and they will simply not upgrade past the point where it still works. If you find a security bug, you either have to backport it to the braindead tree or cut users off from it. And of course, in the real world, it's the == itself that is broken and doesn't behave the way it should, not these hypothetical braindead functions. so...what do you do?
klodolph 14y ago
Even languages that are explicitly designed to be minimal can be anything but. For example, Scheme. The call/cc function is a lot more complicated than it sounds, and it sounds complicated. People are talking about removing it from the "minimal" Scheme. (There are two versions of R7RS, the big version and the small version. If you think that call/cc is actually simple, then you haven't tried to write higher order library functions such as map.) And Scheme's syntax for numbers was invented by Cthulhu himself. (Python 3 was supposed to be adopted this slowly, last time I checked.)

taliesinb 14y ago

That's why I think the language Go is such a great development. The authors seem to have added only the minimum set of features that make the language workable for their initial needs. As a result, these features are largely orthogonal, and the rules are simple to state and learn -- even if they at first seem a bit odd (you have to cast all numeric types to each-other before they can interact). In contrast to Scala, another modern language I investigated recently, which seemed like quite a thicket of features.. some of which seemed just to be there to mediate the interaction of other features.

deleted 14y ago
[deleted]

its_so_on 14y ago

Let's talk about the solution here, since I'd like to know what it is! I'd like to hear what you guys have to say about it. ----------------- 1. Assumption: nobody is perfect and your programming language will have a gargantuan fault. since nobody is perfect, after the dust settles and you have a million users, your programming language will have a really gargantuan fault that is used hundreds of thousands of times throughout everyone's code. ----------------- 2. For this exercise let's make it extreme! Let's make this really extreme with something that's clearly braindead. Let's say in this language you have two comparisons for comparing integers, one for odd and one for even comparisons. (!!) =odd== which behaves like a normal comparison between two odd integers (5 =odd== 7 evaluates to false, and 5 =odd== 5 evaluates to true, but both 2 =odd== anything or anthing =odd== 8 is false, even 2 =odd== 2 or 8 =odd== 8) and =even== which is a normal comparison function between even integers and always false when either integer is odd, even if they have the same odd value. The normal way to do a comparison in this language is: (a % 2) ? a =odd== b : a =even== b ----------------- 3. aftermath Now, the language is at version 2.3 and there are HUNDREDS OF THOUSANDS of examples of the idiom (a % 2) ? a =odd== b : a =even== b throughout the codebase. It's a mess! Someone has the bright idea of cleaning up this cruft. Why not introduce ==, which compares an odd to an odd or an even and an even, returning true if the integer on the left equals the integer on the right, regardless of whether they're odd or even! ----------------- 4. how do you clean up? Great idea. Man, why didn't we think of this up-front. It's clearly much better. Well, nobody is perfect. It wasn't done this, better way, up front. NOBODY now argues that this way isn't better. But people have learned to live with this braindead feature. It's not just the one idiom either. Maybe you could search and replace (a % 2) ? a =odd== b : a =even== b with a new == -- but what do you do if someone uses =odd== or =even== outside that exact idiom? Maybe they have an arcane if-else clauses or functions that have bizarre logic and use these comparisons, which should not even exist. What do you do with it? Seriously. The dust has settled and you made a huge mistake. Now what do you do? - If you start over (3.0), it sounds like users will just backport your improvements. - If you introduce == WITHOUT breaking =odd== and =even==, people will keep writing code using =odd== and =even==, which is unreadable and wrong and a mess. - But if you DO break it, you break people's scripts and they will simply not upgrade past the point where it still works. If you find a security bug, you either have to backport it to the braindead tree or cut users off from it. And of course, in the real world, it's the == itself that is broken and doesn't behave the way it should, not these hypothetical braindead functions. so...what do you do?

klodolph 14y ago

Even languages that are explicitly designed to be minimal can be anything but. For example, Scheme. The call/cc function is a lot more complicated than it sounds, and it sounds complicated. People are talking about removing it from the "minimal" Scheme. (There are two versions of R7RS, the big version and the small version. If you think that call/cc is actually simple, then you haven't tried to write higher order library functions such as map.) And Scheme's syntax for numbers was invented by Cthulhu himself. (Python 3 was supposed to be adopted this slowly, last time I checked.)