4 ms·
> 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
by 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>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. What passive aggresiveness and/or disrespect? The repeat is used to communicate disagreement with a specific thing attributed to what I said. Since it was attributed twice, with no regard to the arguments I made, it was mostly necessary. If anything is "passive agressive" is this sudden ad-hominen and armchair psychology attempt. I only responded to the abstract issue under discussion, didn't made any judgements on the participants. Can we keep it at that level?
- coldtea 12y ago>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. And my point is that I'm not doing that, I'm not picking features based on personal preference (my actual preferences are different), but to describe how a language can encompass the whole range of applications (be the right tool for most jobs, as much as possible). This wasn't about "my dream language" (that would be something like Smalltalk) but about whether a language can cover all/most bases or we're forever doomed to use a babel tower of "right tools for the right job". And the "cover all bases" thing I tried to tackle from a technical features standpoint. At this conceptual level of the argument I don't even care much if programmers will like the end result. >That's a No True Scotsman-like argument No, it's just a statistical observation. 90% of programmers do use this languages. I don't say the rest are not programmers or not true programmers -- just that we can cover the majority of programmers doing professional work with a language in that vein. >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! Now, that's disrespect and passive agressiveness! I never said it's just me that "has all that figured out". In fact lots of people say the same thing, inside every language community there's a trying to fix the same pain points to make each language more universal. Lots of Python people for example wanted to make it GIL-less / capable of good async operation / faster / typed / etc. All this is for handling different kinds of scenarios that it currently does not. People using JS asked for more speed, then for server side/native interfacing (Node et co), then for "programming at large" features (ES6) etc, types, things like asm.js to get native memory management, etc. So, what I wrote was that having a language extend to almost all jobs is not impossible, and gave a laundry list of features (taken from observations such as the above), that could accomplish that.