4 ms·

And that's your opinion. I find javascript quite enjoyable and easy to use, without producing errors. YMMV.

MereInterest 6y ago
I'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 ago
  You might be interested in http://tc39.es/proposal-temporal/docs/index.html http://tc39.es/proposal-temporal/docs/index.html
  - MereInterest 6y ago
    Wow. `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 ago
JavaScript 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 ago
  Operator 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 ago
    Perl 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 ago
Sure, 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 ago
  And 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 ago
  I'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.

I'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 ago
You might be interested in http://tc39.es/proposal-temporal/docs/index.html http://tc39.es/proposal-temporal/docs/index.html
- MereInterest 6y ago
  Wow. `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 ago

JavaScript 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 ago
Operator 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 ago
  Perl 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 ago

Sure, 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 ago
And 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 ago
I'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.