I'll stop there and let you expand the list if you want.
Turns out the whole computing world is built on top of this terrible tech which many people hate, yet somehow it's moving forward.
51–60 of 243 posts
I'll stop there and let you expand the list if you want.
Turns out the whole computing world is built on top of this terrible tech which many people hate, yet somehow it's moving forward.
Earlier quoted context omitted.
> And yes saying "oh but it is because it has dynamic types" doesn't excuse it It has nothing to do with dynamic types[0]. It has to do with > If compareFunction is not supplied, elements are sorted by converting them to strings and comparing strings in lexicographic[0] period end of the story. You might argue it's a shitty default, but please argue against reality, not what you (wrongly) believe it is. [0] this is t…
The correct answer is it has to do with weak types. > `If compareFunction is not supplied, elements are sorted by converting them to strings and comparing strings in lexicographic` period end of the story. As I said explaining the historical context or labeling the brokennes with something like "weak typing" doesn't excuse. It still stays broken. > You might argue it's a shitty default, but please argue against reali…
No, it does not. You could define the exact same default function in Java, Haskell (requiring that the sorted type be a Show instance) or Python (hell, getting the exact same behavior in Python could hardly be simpler: `ar.sort(key=str)`. There, I broke it. That is near literally how the ECMAScript spec very explicitly defines the default comparison function. The behavior of the sort function is not a consequence of weak typing).
> As I said explaining the historical context or labeling the brokennes with something like "weak typing" doesn't excuse.
Which you'd know is not what I'm doing, if you could be arsed to read instead of trying to substitute your imagination for objective reality.
> The point is, it is has fundamentally broken type system.
That might well be, but the default sort comparison function is not a demonstration of it. As opposed to the comparison table of 0 and null for instance:
> 0 0 0 == null
false
> 0 >= null
true
> 0 > null
falseIs Dart an alternative for those problems? Edit: I mean stuff like "callback hell", does it allow me to programm normally and still avoid blocking the loop?
If you're doing frontend dev, then you must use Javascript or a language which compiles to Javascript. I believe Dart currently has a mostly functional tool to compile Dart code to Javascript. As for callback hell, Dart has "Futures" which are basically Promises. If you like Promises, you could use Dart...or one of the many excellent Promise libraries for Javascript; the syntax is almost identical. (The linked articl…
A syntax would be something like the async/await support in C#. Or the async and let!, do! etc along with pipelines in F#.
Sadly I agree, you can just start with this: > [1,10,5,-15,-2,4].sort(); [-15,-2,1,10,4,5] And yes saying "oh but it is because it has weak types" doesn't excuse it, it is broken and that's that. Naming the brokeness with a label or showing why historically it is there, doesn't fix it. On the other hand they do have nice closure support, I do like some of that. But in large, the language makes me angry every time I h…
> [1,10,5,-15,-2,4].sort(function(a,b) {return a > b}) [ -15, -2, 1, 4, 5, 10 ] > [1,10,5,-15,-2,4].sort(function(a,b) {return ""+a > ""+b}) [ -15, -2, 1, 10, 4, 5 ] Perhaps .sort was initially designed to do something else, like sorting strings, rather than integers.
"JS has callable attributes, Hobjects are unusable for stable keys...object does not carry any type information, Null everywhere, since ojects are hashes" I find most of the problems listed are related with dynamic type system of JS. These all can be solved most easily by a statically typed language. Therefore the debate mostly is between static vs dynamic typing.
Personally, I disagree. I find JavaScript to be the most "write-able" language, and switching to Node + frontend JS as my main language (I've done Python, Ruby, PHP, Java and C++ as jobs) has been the best thing I've done in a long time. Express and Angular are amazing. Sure, it has a bunch of quirks. Sure, it's not good for everything (I do mostly relatively simple CRUD apps). Sure, in the browser, it gets slow when…
How do you handle Javascript ignoring wrong numbers of function arguments? Do you use a linter to catch this sort of thing? This part of Javascript sounds the most absolutely insane to me: Silencing an error like that is catastrophic.
(function(window, undefined) {...})(window);Personally, I disagree. I find JavaScript to be the most "write-able" language, and switching to Node + frontend JS as my main language (I've done Python, Ruby, PHP, Java and C++ as jobs) has been the best thing I've done in a long time. Express and Angular are amazing. Sure, it has a bunch of quirks. Sure, it's not good for everything (I do mostly relatively simple CRUD apps). Sure, in the browser, it gets slow when…
How do you handle Javascript ignoring wrong numbers of function arguments? Do you use a linter to catch this sort of thing? This part of Javascript sounds the most absolutely insane to me: Silencing an error like that is catastrophic.
Silencing an error would be a problem, but in JS, it's not an error, because there's no concept of "wrong numbers of function arguments" built into the language. That's not to say you can't inspect the number of arguments yourself and throw an error, if some situation warrants it. But you don't have to do this. It's a very flexible, dynamic language. In some ways this flexibility makes things easier and more expressive, in other ways it necessitates more manual checking (or slower debugging). There's no catastrophe, just design differences.
The problem is that you hardly have a choice nowadays. Python, JS and PHP are dynamic, Java is a great language but crappy concept (don't tell me it isn't slooo... ...ow). Ironically, the ugliest language I have ever coded in (ObjectiveC) has the best design decisions (IMHO). ARC instead of manual memory management or GC, strongly typed but still allows generic object pointer (id),...
Personally, I disagree. I find JavaScript to be the most "write-able" language, and switching to Node + frontend JS as my main language (I've done Python, Ruby, PHP, Java and C++ as jobs) has been the best thing I've done in a long time. Express and Angular are amazing. Sure, it has a bunch of quirks. Sure, it's not good for everything (I do mostly relatively simple CRUD apps). Sure, in the browser, it gets slow when…
I see this all the time. JS is slow because of the dom. No. JS is slow because JS is slow. Yes, I know V8 makes it faster than it used to be. Yes I know it is neck and neck for computation, but because of the way memory is handled it is slow for loading large dictionaries. But I could forgive all of that. JavaScript is not well designed for work in a team environment, nor is it well designed for Large Code Bases. But…
Performance was one of the selling points of Node.JS for me.
Despite most of the points in this post being debatable — there's one bit that caught my eye: "Being nice will not help it, and CoffeeScript is not radical enough." As the guy who started CoffeeScript, I agree. It's an intentionally very conservative approach. But there's more than one good way to skin the JavaScript cat. I think it would be fun to take another run at the same problem — attempt to find a minimal, rea…