121–130 of 152 posts
Forget JS! WebAssembly is coming and you can use nice languages with it, for example C#. and if you need compatibility with older browsers you can still compile WebAssembly to JS and send it to old browsers.
Earlier quoted context omitted.
I'm sorry but I think your pattern matching for "Argument from Authority" is misfiring here. Lisper wasn't saying, "I'm right because I'm me." He was saying, "Adjust your prior[1] for my statement given additional data about its source." [1] https://en.wikipedia.org/wiki/Prior_probability
Quoting directly: > Oh, and BTW, before you completely dismiss the idea that my suggestion might have merit, you might want to look me up. He wasn't saying "I'm right because I'm me." He was saying, "I'm me so don't assume I'm wrong." It's still an appeal to authority. Had his credentials been part of the first line, where he was confirming that he was serious about his previous post, then your interpretation would b…
Wow, you have quite the exacting standards.
Earlier quoted context omitted.
> If he is an authority on the subject, it should show through in his comments. The comment speculating on the "OTHERWISE" clause is the kind of brilliant off-beat thinking that challenges the level of understanding of the reader. The people scoffing at and downvoting it are, however smart and knowledgeable they may be, ignorant or foolish. If they thought it through they might learn something. It's a perfectly valid…
> brilliant off-beat thinking Those words must have new meaning since he was citing as an example a language that's existed since the 70s. Ternary booleans are far from a unique or novel concept. The main difference is that for most languages, including Javascript, that third value exists at the variable binding or expression level, not the value level. Other languages that don't allow nulls encode that third value i…
FWIW, I actually agree with this. There's no need to add a new value. It would be fine with me (within the context of Javascript's already horribly broken design) to use an existing value (null or undefined) as the third "boolean" value.
The part that really matters is that whatever null>=0 returns it should be different from either 1>=0 or -1>=0.
Earlier quoted context omitted.
Quoting directly: > Oh, and BTW, before you completely dismiss the idea that my suggestion might have merit, you might want to look me up. He wasn't saying "I'm right because I'm me." He was saying, "I'm me so don't assume I'm wrong." It's still an appeal to authority. Had his credentials been part of the first line, where he was confirming that he was serious about his previous post, then your interpretation would b…
> Had his credentials been part of the first line, where he was confirming that he was serious about his previous post, then your interpretation would be correct. Wow, you have quite the exacting standards.
If you call that exacting standards, so be it. I call it reading comprehension.
Earlier quoted context omitted.
> brilliant off-beat thinking Those words must have new meaning since he was citing as an example a language that's existed since the 70s. Ternary booleans are far from a unique or novel concept. The main difference is that for most languages, including Javascript, that third value exists at the variable binding or expression level, not the value level. Other languages that don't allow nulls encode that third value i…
> Adding a third value would mean that a boolean variable binding could now have 5 values, true, false, not_true_or_false, null or undefined. That's nonsensical and deserves to be called out. FWIW, I actually agree with this. There's no need to add a new value. It would be fine with me (within the context of Javascript's already horribly broken design) to use an existing value (null or undefined) as the third "boolea…
I was merely explaining why I downed your other comment. I don't care if you're a fresh bootcamp grad or the former lead on AdWords...your argument is equally compelling. I'm calling it out because I think it discourages people from engaging in conversations where they can learn. If you are who you say you are and have the experience I think you do and someone significantly more junior disagrees with you, it's an opportunity for you to explain your thinking in a way that helps them improve theirs going forward. Instead, you took an expedient and, IMHO, intellectually lazy route. It's a small thing, but it's all part of making our field more welcoming to newcomers. What JavaScript beginner is going to argue with the ex-AdWords lead? Beyond being an appeal to authority, your comment possibly shut down someone's positive learning experience.
And if it seems like I'm quibbling with you or being overly hard on what you've said, that part is definitely about who you are. I feel like those of us who've been in the industry a while (I'm a few years behind you, but I'm still nearing my 20th year doing this stuff) have an obligation to be better about technical discussions and work towards positive conflict, even if the other side seems intent on going negative. It's hard and I fail at doing it constantly, so I say this with the full realization that I'm often the proverbial 'pot' to your 'kettle'.
I think a lot of you are drawing overly broad conclusions from this, according to your predispositions. A good language feature should be intuitive, given a basic understanding of the feature, and this falls within that. A JavaScript programmer considering what the relative order of null and 0 is (and therefore how an inequality operator between them would behave) would intuitively conclude, "I don't know, 0 and null…
Those that obey general principles without exception. For example:
(0) “Abstraction clients must not rely on implementation details”: parametric polymorphism, abstract data types.
(1) “Case analyses must be exhaustive”: algebraic data types and pattern matching.
(2) “Make as few assumptions possible about the intended meaning of programs”: principal types.
Earlier quoted context omitted.
It's not so much dynamic typing, but a lack of typing. Dynamic typing means that type checks are made at runtime. e.g. in Ruby: irb> nil >= 0 NoMethodError: undefined method `>=' for nil:NilClass and Python 3: >>> None >= 0 TypeError: '>=' not supported between instances of 'NoneType' and 'int' Obviously JS (and Python 2!) get this wrong, but to be fair JS was designed in the 90s.
I agree with everything you said, except for the part where you said JavaScript was "designed".
Dynamic typing is a nightmare.
It's not so much dynamic typing, but a lack of typing. Dynamic typing means that type checks are made at runtime. e.g. in Ruby: irb> nil >= 0 NoMethodError: undefined method `>=' for nil:NilClass and Python 3: >>> None >= 0 TypeError: '>=' not supported between instances of 'NoneType' and 'int' Obviously JS (and Python 2!) get this wrong, but to be fair JS was designed in the 90s.