6 ms·

> Is that some law of nature, or merely a consequence in how we've designed languages thus far? It's a game of tradeoffs, same as everything else in nature, is

by Udo 12y ago

> Is that some law of nature, or merely a consequence in how we've designed languages thus far? It's a game of tradeoffs, same as everything else in nature, isn't it? I would rarely say that a given language's design or implementation is universally flawed, instead it's the result that comes out of a set of premises and decisions. Yes, some of them may be objectively bad, but mostly they are just decisions made to solve specific problems. In a way the whole point of my post was that languages don't primarily exist on a one-dimensional spectrum of "good" to "bad". They're optimized for different things. The assumption that given a list of possible decisions during language design you just have to select the right one every time is based on the fallacious premise that right and wrong are the actual choices you get. > A well designed type-infered statically typed language [...] ...and those are already some key decisions you made that reflect what's important to you personally. Every time you choose one of these properties, you open doors and close others behind you. While you may personally believe these are the minimum requirements which every "good" language absolutely must have, you should also recognize that you are doing exactly the same thing as every single language designer in history.

rtpg 12y ago
>It's a game of tradeoffs I find that less and less true. The canonical example for me are abstract data types. They're pretty much free on a runtime level, enable clean code, and allow for more static checking. Basically a superpowered version of enums. I can't see any argument against having it in the language unless the express goal is to have no syntax (lisp).
- Udo 12y ago
  Again, that's a personal preference, not a statement of fact. There is a cost associated with different type systems, and that cost can vary with the problem you are trying to solve. It's not that I argue against the benefits of having such a system in place, but you should be aware of the fact that this too might not represent the end-all-be-all for all programmers. One of the basic mistakes made here seems to be the notion "if programmers only _knew_ about the one true way of doing it, they'd all use the same language and tools, namely: mine".
  - coldtea 12y ago
    Again, this is not about personal preference. In the real world, 90% of programmers use either C#, Java, C/C++, JS or Python/Ruby/Perl in their jobs. We could restrict ourselves to this set of languages and syntax style, and design a super-set language that does everything, gets rid of their historical warts, and can go from scripting to HPC. Stuff like using significant whitespace or not, are BS bikeshedding, which we can bypass. The thing is, were it matters (speed, expressivity, availability of REPL and IDE, large SDK) nothing but money prevents us from making such a language... Is there anything preventing a top notch team working for 10 years and come with one ready, including all the trims and works, JIT, AOT native compiler, ports to 2-3 architectures, batteries et al? Sure, some people would still like their Java or their Lisp or whatever. But there's not some logical impossibility preventing us from creating a language that's better for 90% of the tasks than what's our there. In a sense, that's what MS did with C# -- but they stopped too soon because they have their own agenda. So it was Windows only, in the CLR with no supported AOT option, etc.
    - Udo 12y ago
      > Again, this is not about personal preference. There is no need for passive aggressiveness. I get that aping the exact phrase used in a parent comment is used to communicate disrespect, and it's duly noted, but all things being equal I would prefer not to go down that route. My argument here is that people designing languages have made choices based on their personal preference as well. It's not really appropriate to take one specific set of features you like and declare it to be the objective winner. > In the real world, 90% of programmers use either C#, Java, C/C++, JS or Python/Ruby/Perl in their jobs. That's a No True Scotsman-like argument. Also, what's the meaning of the three different types of separators you used there? But for the sake of convergence, yes, let's assume every important real-world language is in that list. I'm still not sure what to say about this without repeating myself, except for: go and do it. You say it's a matter of investment, but on the other hand consider the benefits if someone pulled it off. If you really do believe you are the person who has this all figured out, please go ahead and implement this. Heck, make it a Kickstarter project or something, I'm in!
coldtea 12y ago
>It's a game of tradeoffs, same as everything else in nature, isn't it? My question is if tradeoffs are inherent in programming language design (some mathematical inevitability) or due to lack of resources and other "real world" concerns that can be overcome given enough care and money. I'm not convinced by anything that I've seen that we don't just have the latter. E.g. one could say in 1995 "JS is an awful language for development, and it's unsuitable for anything that needs to be fast. It's an inevitable tradeoff, use the right language for that etc". And then the big corps got interested in optimizing JS, and we can now write full 3D games, and even video encoding in it, and we have asm.js and the like that take the performance of JS 2-3x worse than C for most things, as opposed to 100 times worse back in the day. And we got node in the server side, and tons of libs etc. And with ES6/7 we get tons of language improvements. Even the "fundamental" issues with JS, like bizarro type coercion, global by default, no integer types etc, could be corrected, it's just compatibility concerns that makes us not fix them, not some inherent impossibility of getting a great language without those issues. Heck, we could even introduce optional gradual typing for JS, if it wasn't for those backward compatibility concerns, and even AOT compilers to native code. Those things maybe wouldn't make JS perfect and useful for everything, but it would make it an order of magnitude better than what it is. And if we started from scratch, without all those compatibility constraints at all, we could get a new language pretty close to perfect with enough money and a great team. >...and those are already some key decisions you made that reflect what's important to you personally. Every time you choose one of these properties, you open doors and close others behind you. What door exactly closes? In the "mathematic necessity" way, not the "some people only like dynamic typing" way. Because the thing under discussion was wether a language good for everything (or close to it) could be produced. I chose those attributes not because I like them personally, but with this end goal in mind. Namely: 1) Without static types, you can't get the last mile of performance and safety checks, for using it for high performance apps and systems programming. They also help having a better IDE experience (autocomplete, suggestions etc) for those who like that. 2) If the types are not infered the language will feel too verbose and weighty to people wanting to use it for quick scripts and the like. >you should also recognize that you are doing exactly the same thing as every single language designer in history. Well, I don't have any beef with any language designer in history. My basic problem with current languages is not that they made some choices, but that they didn't make some additional work they could PILE ON TOP of the previous choices and get much better.

by Udo 12y ago

rtpg 12y ago

>It's a game of tradeoffs I find that less and less true. The canonical example for me are abstract data types. They're pretty much free on a runtime level, enable clean code, and allow for more static checking. Basically a superpowered version of enums. I can't see any argument against having it in the language unless the express goal is to have no syntax (lisp).

Udo 12y ago
Again, that's a personal preference, not a statement of fact. There is a cost associated with different type systems, and that cost can vary with the problem you are trying to solve. It's not that I argue against the benefits of having such a system in place, but you should be aware of the fact that this too might not represent the end-all-be-all for all programmers. One of the basic mistakes made here seems to be the notion "if programmers only _knew_ about the one true way of doing it, they'd all use the same language and tools, namely: mine".
- coldtea 12y ago
  Again, this is not about personal preference. In the real world, 90% of programmers use either C#, Java, C/C++, JS or Python/Ruby/Perl in their jobs. We could restrict ourselves to this set of languages and syntax style, and design a super-set language that does everything, gets rid of their historical warts, and can go from scripting to HPC. Stuff like using significant whitespace or not, are BS bikeshedding, which we can bypass. The thing is, were it matters (speed, expressivity, availability of REPL and IDE, large SDK) nothing but money prevents us from making such a language... Is there anything preventing a top notch team working for 10 years and come with one ready, including all the trims and works, JIT, AOT native compiler, ports to 2-3 architectures, batteries et al? Sure, some people would still like their Java or their Lisp or whatever. But there's not some logical impossibility preventing us from creating a language that's better for 90% of the tasks than what's our there. In a sense, that's what MS did with C# -- but they stopped too soon because they have their own agenda. So it was Windows only, in the CLR with no supported AOT option, etc.
  - Udo 12y ago
    > Again, this is not about personal preference. There is no need for passive aggressiveness. I get that aping the exact phrase used in a parent comment is used to communicate disrespect, and it's duly noted, but all things being equal I would prefer not to go down that route. My argument here is that people designing languages have made choices based on their personal preference as well. It's not really appropriate to take one specific set of features you like and declare it to be the objective winner. > In the real world, 90% of programmers use either C#, Java, C/C++, JS or Python/Ruby/Perl in their jobs. That's a No True Scotsman-like argument. Also, what's the meaning of the three different types of separators you used there? But for the sake of convergence, yes, let's assume every important real-world language is in that list. I'm still not sure what to say about this without repeating myself, except for: go and do it. You say it's a matter of investment, but on the other hand consider the benefits if someone pulled it off. If you really do believe you are the person who has this all figured out, please go ahead and implement this. Heck, make it a Kickstarter project or something, I'm in!

coldtea 12y ago

>It's a game of tradeoffs, same as everything else in nature, isn't it? My question is if tradeoffs are inherent in programming language design (some mathematical inevitability) or due to lack of resources and other "real world" concerns that can be overcome given enough care and money. I'm not convinced by anything that I've seen that we don't just have the latter. E.g. one could say in 1995 "JS is an awful language for development, and it's unsuitable for anything that needs to be fast. It's an inevitable tradeoff, use the right language for that etc". And then the big corps got interested in optimizing JS, and we can now write full 3D games, and even video encoding in it, and we have asm.js and the like that take the performance of JS 2-3x worse than C for most things, as opposed to 100 times worse back in the day. And we got node in the server side, and tons of libs etc. And with ES6/7 we get tons of language improvements. Even the "fundamental" issues with JS, like bizarro type coercion, global by default, no integer types etc, could be corrected, it's just compatibility concerns that makes us not fix them, not some inherent impossibility of getting a great language without those issues. Heck, we could even introduce optional gradual typing for JS, if it wasn't for those backward compatibility concerns, and even AOT compilers to native code. Those things maybe wouldn't make JS perfect and useful for everything, but it would make it an order of magnitude better than what it is. And if we started from scratch, without all those compatibility constraints at all, we could get a new language pretty close to perfect with enough money and a great team. >...and those are already some key decisions you made that reflect what's important to you personally. Every time you choose one of these properties, you open doors and close others behind you. What door exactly closes? In the "mathematic necessity" way, not the "some people only like dynamic typing" way. Because the thing under discussion was wether a language good for everything (or close to it) could be produced. I chose those attributes not because I like them personally, but with this end goal in mind. Namely: 1) Without static types, you can't get the last mile of performance and safety checks, for using it for high performance apps and systems programming. They also help having a better IDE experience (autocomplete, suggestions etc) for those who like that. 2) If the types are not infered the language will feel too verbose and weighty to people wanting to use it for quick scripts and the like. >you should also recognize that you are doing exactly the same thing as every single language designer in history. Well, I don't have any beef with any language designer in history. My basic problem with current languages is not that they made some choices, but that they didn't make some additional work they could PILE ON TOP of the previous choices and get much better.