7 ms·
For a long time I thought the JS hate was just a friendly pop jab. From working with backend folks I’ve realized it comes from at least a somewhat patronizing v
by goldenManatee 6y ago
For a long time I thought the JS hate was just a friendly pop jab. From working with backend folks I’ve realized it comes from at least a somewhat patronizing view that JS should feel more like backend languages; except it’s power, and real dev audience, is in browsers, where it was shaped and tortured by the browser wars, not to mention it was created in almost as many days as Genesis says the world was built.
- antonvs 6y agoSo, there are excuses for Javascript's terribleness, but that doesn't stop it from being objectively terrible.
- leptons 6y agoAnd that's your opinion. I find javascript quite enjoyable and easy to use, without producing errors. YMMV.
- MereInterest 6y agoI'd love to have a way to take a `Date` object and set it as the value of a `datetime-local` input. Sure feels like that should be straightforward to do, without requiring any weird conversions like it does.
- mr_toad 6y agoYou might be interested in http://tc39.es/proposal-temporal/docs/index.html http://tc39.es/proposal-temporal/docs/index.html
- MereInterest 6y agoWow. `zonedDateTimeISO` looks like exactly what I was hoping for. I'm kind of surprised that there isn't anything analogous to `strftime`, though.
- sergeykish 6y agoJavaScript has good parts, I write it a lot. But it is ignorant to close eyes on its warts 1 + '2' 1 - '2' Number.MAX_SAFE_INTEGER + 2 and entire WAT series, stems from "don't raise" ethos. JavaScript exposes constructor instead of prototype that messed up a lot, in Ruby terms Object.alias_method :__proto__, :class Object = Object.instance_method(:initialize) Class = Class.instance_method(:initialize) Class.__proto__.alias_method :prototype, :owner new = ->(constructor) { constructor.owner.new } Person = Class.prototype.new do def initialize end end.instance_method(:initialize) def Person.foo 'foo' end puts Person.foo john = new.call Person def john.bar 'bar' end puts john.bar def (Person.prototype).baz 'baz' end puts john.__proto__.baz Does anyone wants to adopt this feature in their language?
- hajile 6y agoOperator overloading can lead to ambiguities in dynamic languages. Ruby, python, and any number of other languages have it much worse because they can be overloaded any way you want while JS overloads are (currently at least) set in stone by the language. If you could only choose one number type, would it be floats or ints? Crockford would say decimal, but the rest of use using commodity hardware would choose floats every time. It's not the language implement's fault someone doesn't understand IEEE 854. This max safe integer issue exists in ALL languages that use IEEE 854. In any case, BigInt is already in browsers and will be added to the spec shortly.
- sergeykish 6y agoPerl and Lua have separate arithmetic and concatenation operators 1 + "2" #3 1 - "2" #-1 1 . "2" | 1 .. "2" #"12" 1 . "-2" | 1 .. "-2" #"1-2" Python and Ruby throw exception, use explicit type conversion and string interpolation 1 + '2' Traceback (most recent call last): TypeError (String can't be coerced into Integer) 1 + '2'.to_i #3 "1#{'2'}" #"12" Hardly any language is perfect, I have not encounter much of operator overload in ruby (nokogiri?) but I believe C++ got it bad. One number type in Lua: > 0 | 0xffffffff 4294967295 > 0 | 0xffffffffffffffff -1 > 0 | 0x7fffffffffffffff 9223372036854775807 limited but better than JavaScript: 0 | 0xffffffff //-1 BigInt is an improvement 0n | 0xffffffffn //4294967295n 0xffffffffffffffffn 18446744073709551615n it is strict 1n - "2" 1 + 1n Uncaught TypeError: Cannot mix BigInt and other types, use explicit conversions works nice with string interpolation: `${1n}` "1" Numbers is a sane example. One can argue it was for good. How about `{} + []`? I believe I can disable this part in JavaScript engine and no one would notice. And misleading `object[key]` where it calls toString, sure I have not tried that in a decade but it is stupid. UTF-16: ""[1] # there were emoji //"�" You've said nothing about constructor oriented programming. Unique feature, I have not heard any other language adopted it yet. The post you've replied contents sketch for Ruby. Actually I've got it wrong — every JavaScript function is a closure (Ruby method is not closure) and Prototype method was a class method (not instance method), fixed but ugly: def function(&block) Class.prototype.new.tap do |c| c.define_method(:initialize, block) end.instance_method(:initialize) end def function_(object, name, &block) object.class_eval do define_method(name, &block) end end Person = function { |name| @name = name } function_(Person.prototype, :name_) { @name } john = new.call Person, 'john' puts john.__proto__ == Person.prototype puts john.name_ def function__(object, name, &block) object.singleton_class.class_eval do define_method(name, &block) end end function__(john, :name__) { @name } puts john.name__ By the way, you can say "Yes, I know JavaScript has some problems". It is not a secret, everyone knows.
- eecc 6y agoSure, until you parachute into a code base where several generations of contractors added features that communicate over a shared global object. This is bad per-se, but becomes worse when your language allows one to add fields on the fly and you end up with this container full of similar fields because eventually nobody knows exactly what’s in the object any more...
- leptons 6y agoAnd that seems pretty simple to fix. "The same level of awareness that created a problem cannot be used to fix the problem" - and maybe that's why they hired you, to fix these problems. I've been that guy before. What was really fun was the codebase I had to fix that used mexican slang words as variable names, and I only speak English. So much fun. But I sucked it up, accepted the challenge, and I improved it. It really doesn't take a super-genius to code javascript simply, efficiently, and without errors. Funny that a lot of programmers that think they're very smart are the ones that either shit on javascript, or make a lot of stupid errors with it, or both.
- hajile 6y agoI've seen similar abuses with global maps in other languages (essentially the same). This is an architecture fault rather than a language fault. As you say, that is a problem with any language and project with a revolving door of developers. Perhaps those companies should learn their lesson and hire at least one or two good, permanent senior devs to keep things on track. Like always, the human factor outweighs almost everything else.
- tlrobinson 6y agoThat’s not what “objective” means.
- antonvs 6y ago"When I use a word, it means just what I choose it to mean —neither more nor less."
- bloodorange 6y agoIt's not often that one comes across a quote from one of the greatest works of art: https://www.goodreads.com/quotes/12608-when-i-use-a-word-humpty-dumpty-said-in-rather https://www.goodreads.com/quotes/12608-when-i-use-a-word-hum... That whole conversation is quite interesting and perhaps this part can also be thought of as alluding to "prescriptivism versus descriptivism".
- antonvs 6y agoI think it goes beyond prescriptivism/descriptivism. Descriptivism refers generally to describing how a community uses language, so the most common usages end up being the primary definitions. Once documented, these tend to become prescriptive. In that context, a single author who uses a word in an unusual way would likely not have any impact on the descriptive or prescriptive definitions of that word, unless of course their usage becomes common. Humpty was arguing for the benefits of using words in unusual ways, which potentially violates both prescriptivism and descriptivism. Impressionistic use of words is one example of this, where the words used might convey a certain feeling, perhaps via their connotations, even though their literal definitions may not be exactly appropriate. This kind of usage is generally found in literature where language is being used as an artistic tool rather than a prosaic tool of communication. tl;dr: my HN comments is a art
- likeclockwork 6y agoSad to see the word "objective" become the next bullshit intensifier because people can't separate their own subjective opinions from the realm of verifiable fact. "Terribleness" isn't an objective property.
- antonvs 6y agoYou can compare Javascript to other languages and note that many of its notorious problems have no rational justification, and are unnecessary. That's what I call objectively terrible.
- likeclockwork 6y agoYeah, that's not objective. Sorry.
- deleted 6y ago[deleted]
- antonvs 6y agoWhat do you think "objective" means? The comparative approach I mentioned can be used to eliminate personal feelings about such issues - not in all cases (types might be an example), but certainly in some. Many users of Javascript, including myself, recognize that it has many weaknesses. There's even a book that acknowledges this in its title: "Javascript: The Good Parts." Denying this seems to be denying objective reality. You may be confusing "objective" with "universal," thinking that I'm claiming some unsituated universal truth. But that's not the case. Any statement is only ever true within some context - the language that defines it, the semantics of the statement, the premises that it assumes. In this case, there is a shared context that crosses programming languages, that allows us in at least some cases to draw objective conclusion about programming language features. "The bad parts" implied by Crockford's title includes many such features. We can examine them and conclude that while they might have some historical rationale, that they are not good features for a programming language to have. In many cases this conclusion is possible because there's simply no good justification - the title of this post is an example. Having all numbers be floating point has many negative consequences and no significant positive ones - the only reason for it is historical. Such features end up having consequences, such as on the design of hardware like ARM chips. That is an objectively terrible outcome. You can of course quibble with such a statement, based on a rigid application of a simplistic set of definitions. But you'd do better to try to understand the truth conveyed by such a statement.
- moksly 6y agoHuh? Python and powershell are all over the backend, and it’s hard to argue against JavaScript while you’re using those. At least in my opinion. I think it has more to do with the amount of people who are bad at JavaScript but are still forced to sometimes work with it because it’s the most unavoidable programming language. But who knows, people tend to complain about everything.