5 ms·

What makes JS more "hackable"? Someone find that cartoon about the gaunt-looking guy and the laid-back kid when the girl asks them to hold her coffee and link

What makes JS more "hackable"? Someone find that cartoon about the gaunt-looking guy and the laid-back kid when the girl asks them to hold her coffee and link it [edit: http://i.imgur.com/76Wtthy.jpg http://i.imgur.com/76Wtthy.jpg ]. ...Because it gets the hell out of they way and holds your coffee for you and doesn't slap it out of your hand and throw a tantrum because it was actually a medium coffee...and it gives you the simplest no-BS object/array literals you can get...IMO opinion everyone wailing and beating their chest bemoaning the fact that JS got where it is fails to understand that it got there because it the "UX" of coding JS is just a lot more pleasant - and you can treat it as a compile target and do your work in a more type-obsessed thing like Typescript if that's your cup of tea without imposing on the underlying "hackability" of the language.

itsnotlupus 10y ago
Typescript is sufficiently close to JavaScript that it doesn't really feel like it's treating JS as some invisibly underlying assembly-like layer. In practice, you can use as much or as little typing as you want, and the compiler will occasionally tell you "I think you're doing something dangerous here", but even then you're only one <any> away from ignoring its generally good advice (or more sanely, you would annotate the ambiguous bits a bit better so typescript understands you really meant to do that.) But otherwise, all the usual js hacks still very much apply. Anyway, that's why typescript is my cup of tea|coffee.
bbcbasic 10y ago
Hmm not convinced. Is it pleasant UX that you can put petrol in your diesel car because the nozzle fits? Would it be pleasant UX to have your bank let someone withdraw money from your account without ID? Bleach bottle with no safety cap? Also the laid back kid of JS will throw a tantrum if the coffee is not a coffee. He'll throw the tantrum at your customer though (at runtime), not your developer (at compiler time). Which arguably is a good UX for coding but not the bottom line.
- tracker1 10y ago
  Considering the variety of fuel sources a diesel engine can use (oil, deisel, etc), I'd say it is pretty useful... ;-) Yeah, and good luck dealing with that remote API that now gives you an extra field in the JSON or XML, and your compiled client in a few thousand workstations needs to be updated and redeployed because of said fit.
  - bbcbasic 10y ago
    > Yeah, and good luck dealing with that remote API that now gives you an extra field in the JSON or XML Java C# and every other decent typed language has good serialization and deserialization support. The extra field poses no problem.
    - tracker1 10y ago
      I've had to consume Java generated wsdl in C#, having response types of "Object" from the Java side, meaning the .Net side has no properties on the responses from those methods, I'd have to disagree...
      - bbcbasic 10y ago
        Nothing to do with static vs dynamic typing. Just get Java and C# to talk in another protocol. How about JSON or vanilla XML
- dccoolgai 10y ago
  It would be pleasant if your engine didn't care whether you put gas or diesel in it and just ran. I think that's the point made in the cartoon. I like that the kid just holds the cup and pours it when I tell him to. If I wanted him to pour coffee and gave him a cup of beer, I'm ok saying that's my fault. I'd still rather have the kid. Having a guy that only accepts "Large cups of coffee" is necessary at lower levels (c), but keep it out of my scripting language.
  - 10y ago
zeveb 10y ago
> it gives you the simplest no-BS object/array literals you can get I really don't think that: { "foo": "bar", "baz": ["quux", 1, true] } is simpler than: ((foo bar) (baz (quux 1 true))) Quite the opposite, really.
- dccoolgai 10y ago
  That does look nice. Is that, LISP? To my eye, they look roughly equivalent, though - and a lot of what I consider the "No-BS object system" occurs after the literal is declared - adding and manipulating properties, etc.
  - zeveb 10y ago
    > Is that, LISP? Well, S-expressions, which can be used for Lisp code, but can also just be used for plain data. > a lot of what I consider the "No-BS object system" occurs after the literal is declared - adding and manipulating properties, etc. Yeah, it's definitely convenient to use, even more so than Python's objects. I prefer a stronger type system for my own software though.
- akubera 10y ago
  Question: Can s-expression list-of-lists really be used to represent an unordered map when it comes to operations like equality? Or rather, does one simply use expectations/context to compare this object to, say [["foo", "bar"], ["baz", ["quuz", 1, true]]] making it a non-issue?
  - zeveb 10y ago
    > Question: Can s-expression list-of-lists really be used to represent an unordered map when it comes to operations like equality? With the right predicates, anything is possible grin I think that context unavoidable: one can't just read a JSON value into a generic data structure, or even into a typed structure: one has to apply the types of one's business logic (e.g. 'user-id' must not only be a string, but a string beginning with either 'E' or 'C'). In that context (pun intended), then it makes sense for equality comparisons to be at the business-object layer, not at the freshly-deserialised JSON object layer.

itsnotlupus 10y ago

Typescript is sufficiently close to JavaScript that it doesn't really feel like it's treating JS as some invisibly underlying assembly-like layer. In practice, you can use as much or as little typing as you want, and the compiler will occasionally tell you "I think you're doing something dangerous here", but even then you're only one <any> away from ignoring its generally good advice (or more sanely, you would annotate the ambiguous bits a bit better so typescript understands you really meant to do that.) But otherwise, all the usual js hacks still very much apply. Anyway, that's why typescript is my cup of tea|coffee.

bbcbasic 10y ago

Hmm not convinced. Is it pleasant UX that you can put petrol in your diesel car because the nozzle fits? Would it be pleasant UX to have your bank let someone withdraw money from your account without ID? Bleach bottle with no safety cap? Also the laid back kid of JS will throw a tantrum if the coffee is not a coffee. He'll throw the tantrum at your customer though (at runtime), not your developer (at compiler time). Which arguably is a good UX for coding but not the bottom line.

tracker1 10y ago
Considering the variety of fuel sources a diesel engine can use (oil, deisel, etc), I'd say it is pretty useful... ;-) Yeah, and good luck dealing with that remote API that now gives you an extra field in the JSON or XML, and your compiled client in a few thousand workstations needs to be updated and redeployed because of said fit.
- bbcbasic 10y ago
  > Yeah, and good luck dealing with that remote API that now gives you an extra field in the JSON or XML Java C# and every other decent typed language has good serialization and deserialization support. The extra field poses no problem.
  - tracker1 10y ago
    I've had to consume Java generated wsdl in C#, having response types of "Object" from the Java side, meaning the .Net side has no properties on the responses from those methods, I'd have to disagree...
    - bbcbasic 10y ago
      Nothing to do with static vs dynamic typing. Just get Java and C# to talk in another protocol. How about JSON or vanilla XML
dccoolgai 10y ago
It would be pleasant if your engine didn't care whether you put gas or diesel in it and just ran. I think that's the point made in the cartoon. I like that the kid just holds the cup and pours it when I tell him to. If I wanted him to pour coffee and gave him a cup of beer, I'm ok saying that's my fault. I'd still rather have the kid. Having a guy that only accepts "Large cups of coffee" is necessary at lower levels (c), but keep it out of my scripting language.
- 10y ago

zeveb 10y ago

> it gives you the simplest no-BS object/array literals you can get I really don't think that: { "foo": "bar", "baz": ["quux", 1, true] } is simpler than: ((foo bar) (baz (quux 1 true))) Quite the opposite, really.

dccoolgai 10y ago
That does look nice. Is that, LISP? To my eye, they look roughly equivalent, though - and a lot of what I consider the "No-BS object system" occurs after the literal is declared - adding and manipulating properties, etc.
- zeveb 10y ago
  > Is that, LISP? Well, S-expressions, which can be used for Lisp code, but can also just be used for plain data. > a lot of what I consider the "No-BS object system" occurs after the literal is declared - adding and manipulating properties, etc. Yeah, it's definitely convenient to use, even more so than Python's objects. I prefer a stronger type system for my own software though.
akubera 10y ago
Question: Can s-expression list-of-lists really be used to represent an unordered map when it comes to operations like equality? Or rather, does one simply use expectations/context to compare this object to, say [["foo", "bar"], ["baz", ["quuz", 1, true]]] making it a non-issue?
- zeveb 10y ago
  > Question: Can s-expression list-of-lists really be used to represent an unordered map when it comes to operations like equality? With the right predicates, anything is possible grin I think that context unavoidable: one can't just read a JSON value into a generic data structure, or even into a typed structure: one has to apply the types of one's business logic (e.g. 'user-id' must not only be a string, but a string beginning with either 'E' or 'C'). In that context (pun intended), then it makes sense for equality comparisons to be at the business-object layer, not at the freshly-deserialised JSON object layer.