Accessibility (as in execution environments) trumps language features in my book, and JS is the most accessible language there is. But of course, it all boils down to what you're trying to solve and where your program will live.
Is your programming language unreasonable? (2015)
11–20 of 138 posts
Re: Is your programming language unreasonable? (2015)
#12I lost the line of reasoning (or perhaps the author did) at the second example.
If I have 2 InputStream objects, nevermind equality. It just doesn't apply here. I don't even want `a.Equals(b)` to be considered valid code in the first place. Having __any__ default behaviour here is a lot like the permissiveness that is bashed in example 1 (a trifecta of unexpected variable scoping rules, the ability to re-type variables merely by assigning an object of a different type to them, and the idea that a boolean will silently convert itself to a numeric value): There are a billion situations where you'd want to e.g. treat a boolean as a number, and in the vast majority of them, '0' is a fine value, but nevertheless, it leads to unpredictable code so let's not default. Let's require an explicit interaction from the code author to indicate they really want to do that, and, hopefully, we can make that 'explicit interaction' simple.
Apply the same logic to example 2 and the author draws the wrong conclusion.
Re: Is your programming language unreasonable? (2015)
#13> I don’t care what my language will let me do, I care more about what my language won’t let me do. I think this is the best summary of the article. In short, please protect me from my own stupidity and/or laziness.
I like how this could be taken as an endorsement or criticism of the article, depending on the hubris of the reader
Re: Is your programming language unreasonable? (2015)
#14Accessibility (as in execution environments) trumps language features in my book, and JS is the most accessible language there is. But of course, it all boils down to what you're trying to solve and where your program will live.
[deleted]
Re: Is your programming language unreasonable? (2015)
#15> " 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. " So this essentially means there can never be a NULL object assigned to anything... how is this possible? is it avoided by throwing exceptions instead of returning NULL?
Not only that, it implies that there must be a valid null-state for every type, which is also a bad idea.
Re: Is your programming language unreasonable? (2015)
#16Speakeasy, Lightouch, Jazz is a fifth-generation programming language. I find only small hurdlesv when showing it to programmers. My challenge now is mainly getting stable shelter so I can compile these notes and hand them off to people.
Re: Is your programming language unreasonable? (2015)
#17I lost the line of reasoning (or perhaps the author did) at the second example. If I have 2 InputStream objects, nevermind equality. It just doesn't apply here. I don't even want `a.Equals(b)` to be considered valid code in the first place. Having __any__ default behaviour here is a lot like the permissiveness that is bashed in example 1 (a trifecta of unexpected variable scoping rules, the ability to re-type variabl…
Note that F# has the `[]` attribute for exactly that sort of case.
Re: Is your programming language unreasonable? (2015)
#18I lost the line of reasoning (or perhaps the author did) at the second example. If I have 2 InputStream objects, nevermind equality. It just doesn't apply here. I don't even want `a.Equals(b)` to be considered valid code in the first place. Having __any__ default behaviour here is a lot like the permissiveness that is bashed in example 1 (a trifecta of unexpected variable scoping rules, the ability to re-type variabl…
I don't understand how you concluded that Example 2 implies that the author thinks that `a.Equals(b)` should work on InputStream objects.
Re: Is your programming language unreasonable? (2015)
#19Previous discussion (2015):
https://news.ycombinator.com/item?id=8998117
Re: Is your programming language unreasonable? (2015)
#20> " 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. " So this essentially means there can never be a NULL object assigned to anything... how is this possible? is it avoided by throwing exceptions instead of returning NULL?
Not only that, it implies that there must be a valid null-state for every type, which is also a bad idea.
No, it implies that there must be a generic two-valued datatype to wrap every state:
Just t | None
You can have your null case, and avoid the null-pointer exception, default keyword, chained ? null-check hellscape in which we currently reside.