4 ms·

Ya'll can thumb your nose at JS all you want. Haters gonna hate. I'm starting to question whether this HN mindset is healthy. People get trapped in this vortex

Ya'll can thumb your nose at JS all you want. Haters gonna hate. I'm starting to question whether this HN mindset is healthy. People get trapped in this vortex of us constantly chanting about how horrible JS is, and totally ignoring all the incredible things we can do now. It's worth pushing back against this echo chamber and reminding people that you now have the power to grant wishes on command. Someone wishes X exists, and for most values of X, if it's technology and you can shove it into a web browser, you can make X appear out of thin air. Like, within two weeks. How incredible is that? And it's mostly due to JS, not in spite of it. Let's put it this way. Think of your favorite language. Favorite paradigm, whatever. All the shit you hate about JS, picture the exact opposite of that. Now imagine that the web was entirely built around that. Surprise: now everyone would hate exactly whatever you love. It would've grown all that hair and all those warts you currently despise about JS. It's what the world does. So when people knock on JS, it's getting much harder to take this stuff seriously. I've been a dev for over a decade and have been down a dozen rabbit holes, from C++ template metaprogramming to .NET nonsense to elisp verbosity to hardcore functional + immutable paradigms. Loved all of them, each in their own way. What we have now with JS is simply incredible from a raw "get shit done" perspective.

panic 9y ago
Here's an implementation of "deep equality" -- a relatively common operation on composite values -- in JS. It has millions of downloads in just the last week: https://github.com/substack/node-deep-equal/blob/master/index.js https://github.com/substack/node-deep-equal/blob/master/inde... It includes special cases for dates, takes O(n log n) time in the number of keys, and has suspicious comments like, "I've managed to break Object.keys through screwy arguments passing. Converting to array solves the problem." There are 15 open issues and 15 open pull requests. A sane language would have this operation built-in.
- sillysaurus3 9y ago
  And yet, this is a perfect example of "this does not matter." Pick a project. Think of a website you want to make. At no point during that are you going to be stonewalled by "Man, if only I wasn't forced to spend the last 4 hours debugging this weird deep equality issue. I could've gotten so much more done!" You can take that information and use it however you want. It's the truth. It's up to you to either reject the notion or integrate it into your mindset and abandon the tendency to cling to idealisms. Ivory tower development simply does not happen in reality, and I say this as someone who spent a couple years trying to build an ivory tower Lisp. I know it's not coming across at all, but I really identify with your mindset and acutely feel your pain. This was a major mental hurdle that I had to force myself to overcome. I'm saying, it's possible, and the only thing you have to do is to choose to do it. Let go. Realize that it doesn't matter. It's worth the benefits. You can do so much more. I was afraid that "letting go" would translate into "now I'm part of the problem too." But it turns out the opposite is true. It's very powerful that you have a background that most JS devs lack. Because they often rabbithole themselves into complexity, and you can come along and do something simple that no one else thought to stop and do. But you can do all of that while still embracing the wider ecosystem. It's not an either-or. You can help bring sanity to what would otherwise be a ball of hair. But the way to be in that position is to jump in and churn churn churn until you've used Vue and React+Redux and understand the concepts and tradeoffs.
  - shakna 9y ago
    > Pick a project. Think of a website you want to make. At no point during that are you going to be stonewalled by "Man, if only I wasn't forced to spend the last 4 hours debugging this weird deep equality issue. I could've gotten so much more done!" I have faced this on the job. About three abstraction layers deep in a Backbone app. It took me two days to trace the exact cause and find a way to implement a better check, that wouldn't make things respond in unexpected ways. > It's up to you to either reject the notion or integrate it into your mindset and abandon the tendency to cling to idealisms. JavaScript is terrible. It is not the product of academic research like Smalltalk or Haskell. I can accept it is the only tool available for the job, and continually look at all the solutions for that particular issue, and I will keep doing that. I can use JavaScript, and I can write it. Usually my code is simpler and faster, because it takes me much longer to write anything, because of how aware I am of the side-effects. My employers in the past have liked the results that has produced. But I will never enjoy writing it. It is a language that is difficult in ways that reveal it's sloppy roots, and spill it's implementation details. Much of the time JS feels like working with UB in C, except it is actually detailed to act that strangely, in the spec. Just an example that has always stuck with me, this is valid JS: [][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])() Pretending it's puss-filled core is wonderful is going to lead to nothing but burn out, but so is hating every procedure you write in it. It's a tool. It's sharp on both sides, which can lead to a lot of blood-letting if you aren't careful. But it is still the best carving tool we have on hand.
- Sacho 9y ago
  I would otherwise agree that JS's standard library is too small, but I don't think your example showcases it. Which languages offer this in their standard library? It's not in any of the languages I have used: C, C++, C#, Java, PHP, Python.. A better example would be the extremely poor Date object, which has only a couple format functions and can't even be created from a specified format. There's also a bunch of holes when manipulating data, filled by libraries like lodash(although the standard lib has improved significantly in this regard).
  - panic 9y ago
    Which languages offer this in their standard library? It's not in any of the languages I have used: C, C++, C#, Java, PHP, Python.. Off the top of my head, Haskell has "deriving Eq", and Scheme has "equal?". I'm pretty sure Python uses deep equality for tuples as well. Anyway, it's just one example of something I wanted to do in JS recently and ended up disappointed in the quality of the code I saw to do it.
  - sametmax 9y ago
    Python does: >>> {"foo": [1, 2, set([True])]} == {"foo": [1, 2, set([False])]} False >>> {"foo": [1, 2, set([True])]} == {"foo": [int('1'), 2, set([bool(1)])]} True
    - Sacho 9y ago
      You're right, I forgot about those and overstated my case.
      - always_good 9y ago
        I don't blame you. I think the only reason I ever do deep comparison is in unit tests, and every test/assertion library has a `deepEquals` assertion, so it's not something I regularly miss. There are better examples of deficiencies in Javascript's standard library, especially when targeting browsers, but Javascript has made massive strides lately like its native Set and Map datastructures. For example, Set doesn't come with the classic methods `.intersection()` / `.difference()` / `.union()` / etc. but it's just not a defining moment of my overall experience with Javascript. We're long past the days where you had to bring your own `Array#map`, but I don't know if all of these commenters are.
- orf 9y ago
  I'm all for bashing the insane world of Javascript, and think that the argument grandparent is is making is quite weak, but not many languages have deep-equality baked in. Sure, you can perhaps override some methods on an object, but given two arbitrary objects (like two dicts in Python), knowing if two are 'equal' is not easy and certainly not built in. That being said, JS doesn't make implementing this easy or simple at all.
  - sametmax 9y ago
    Actually it works in Python. And it's VERY handy, especially in unit tests. See my other comment.
  - robhu 9y ago
    This works in Ruby: irb(main):001:0> require 'set' => true irb(main):002:0> {'foo' => [1, 2, [true].to_set]} == {'foo' => [1, 2, [false].to_set]} => false irb(main):003:0> {'foo' => [1, 2, [true].to_set]} == {'foo' => ['1'.to_i, 2, [true].to_set]} => true
Flimm 9y ago
It's true that the most well-known languages are likely to attract the most criticism by virtue of being so well-known. It's true that Javascript and its ecosystem has improved. However, it's also true that there remains some warts to Javascript (for instance, modules are not there yet). It's not fair at all to say "all of these concerns are not concerns" just because you have grown to appreciate all the advantages that Javascript offers. That's being silly, sillysaurus3.
loup-vaillant 9y ago
> totally ignoring all the incredible things we can do now. Any Turing tar-pit can do incredible things. And when it has a monopoly on its own niche, of course incredible things happen.
- deleted 9y ago
  [deleted]

panic 9y ago

Here's an implementation of "deep equality" -- a relatively common operation on composite values -- in JS. It has millions of downloads in just the last week: https://github.com/substack/node-deep-equal/blob/master/index.js https://github.com/substack/node-deep-equal/blob/master/inde... It includes special cases for dates, takes O(n log n) time in the number of keys, and has suspicious comments like, "I've managed to break Object.keys through screwy arguments passing. Converting to array solves the problem." There are 15 open issues and 15 open pull requests. A sane language would have this operation built-in.

sillysaurus3 9y ago
And yet, this is a perfect example of "this does not matter." Pick a project. Think of a website you want to make. At no point during that are you going to be stonewalled by "Man, if only I wasn't forced to spend the last 4 hours debugging this weird deep equality issue. I could've gotten so much more done!" You can take that information and use it however you want. It's the truth. It's up to you to either reject the notion or integrate it into your mindset and abandon the tendency to cling to idealisms. Ivory tower development simply does not happen in reality, and I say this as someone who spent a couple years trying to build an ivory tower Lisp. I know it's not coming across at all, but I really identify with your mindset and acutely feel your pain. This was a major mental hurdle that I had to force myself to overcome. I'm saying, it's possible, and the only thing you have to do is to choose to do it. Let go. Realize that it doesn't matter. It's worth the benefits. You can do so much more. I was afraid that "letting go" would translate into "now I'm part of the problem too." But it turns out the opposite is true. It's very powerful that you have a background that most JS devs lack. Because they often rabbithole themselves into complexity, and you can come along and do something simple that no one else thought to stop and do. But you can do all of that while still embracing the wider ecosystem. It's not an either-or. You can help bring sanity to what would otherwise be a ball of hair. But the way to be in that position is to jump in and churn churn churn until you've used Vue and React+Redux and understand the concepts and tradeoffs.
- shakna 9y ago
  > Pick a project. Think of a website you want to make. At no point during that are you going to be stonewalled by "Man, if only I wasn't forced to spend the last 4 hours debugging this weird deep equality issue. I could've gotten so much more done!" I have faced this on the job. About three abstraction layers deep in a Backbone app. It took me two days to trace the exact cause and find a way to implement a better check, that wouldn't make things respond in unexpected ways. > It's up to you to either reject the notion or integrate it into your mindset and abandon the tendency to cling to idealisms. JavaScript is terrible. It is not the product of academic research like Smalltalk or Haskell. I can accept it is the only tool available for the job, and continually look at all the solutions for that particular issue, and I will keep doing that. I can use JavaScript, and I can write it. Usually my code is simpler and faster, because it takes me much longer to write anything, because of how aware I am of the side-effects. My employers in the past have liked the results that has produced. But I will never enjoy writing it. It is a language that is difficult in ways that reveal it's sloppy roots, and spill it's implementation details. Much of the time JS feels like working with UB in C, except it is actually detailed to act that strangely, in the spec. Just an example that has always stuck with me, this is valid JS: [][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])() Pretending it's puss-filled core is wonderful is going to lead to nothing but burn out, but so is hating every procedure you write in it. It's a tool. It's sharp on both sides, which can lead to a lot of blood-letting if you aren't careful. But it is still the best carving tool we have on hand.
Sacho 9y ago
I would otherwise agree that JS's standard library is too small, but I don't think your example showcases it. Which languages offer this in their standard library? It's not in any of the languages I have used: C, C++, C#, Java, PHP, Python.. A better example would be the extremely poor Date object, which has only a couple format functions and can't even be created from a specified format. There's also a bunch of holes when manipulating data, filled by libraries like lodash(although the standard lib has improved significantly in this regard).
- panic 9y ago
  Which languages offer this in their standard library? It's not in any of the languages I have used: C, C++, C#, Java, PHP, Python.. Off the top of my head, Haskell has "deriving Eq", and Scheme has "equal?". I'm pretty sure Python uses deep equality for tuples as well. Anyway, it's just one example of something I wanted to do in JS recently and ended up disappointed in the quality of the code I saw to do it.
- sametmax 9y ago
  Python does: >>> {"foo": [1, 2, set([True])]} == {"foo": [1, 2, set([False])]} False >>> {"foo": [1, 2, set([True])]} == {"foo": [int('1'), 2, set([bool(1)])]} True
  - Sacho 9y ago
    You're right, I forgot about those and overstated my case.
    - always_good 9y ago
      I don't blame you. I think the only reason I ever do deep comparison is in unit tests, and every test/assertion library has a `deepEquals` assertion, so it's not something I regularly miss. There are better examples of deficiencies in Javascript's standard library, especially when targeting browsers, but Javascript has made massive strides lately like its native Set and Map datastructures. For example, Set doesn't come with the classic methods `.intersection()` / `.difference()` / `.union()` / etc. but it's just not a defining moment of my overall experience with Javascript. We're long past the days where you had to bring your own `Array#map`, but I don't know if all of these commenters are.
orf 9y ago
I'm all for bashing the insane world of Javascript, and think that the argument grandparent is is making is quite weak, but not many languages have deep-equality baked in. Sure, you can perhaps override some methods on an object, but given two arbitrary objects (like two dicts in Python), knowing if two are 'equal' is not easy and certainly not built in. That being said, JS doesn't make implementing this easy or simple at all.
- sametmax 9y ago
  Actually it works in Python. And it's VERY handy, especially in unit tests. See my other comment.
- robhu 9y ago
  This works in Ruby: irb(main):001:0> require 'set' => true irb(main):002:0> {'foo' => [1, 2, [true].to_set]} == {'foo' => [1, 2, [false].to_set]} => false irb(main):003:0> {'foo' => [1, 2, [true].to_set]} == {'foo' => ['1'.to_i, 2, [true].to_set]} => true

Flimm 9y ago

It's true that the most well-known languages are likely to attract the most criticism by virtue of being so well-known. It's true that Javascript and its ecosystem has improved. However, it's also true that there remains some warts to Javascript (for instance, modules are not there yet). It's not fair at all to say "all of these concerns are not concerns" just because you have grown to appreciate all the advantages that Javascript offers. That's being silly, sillysaurus3.

loup-vaillant 9y ago

> totally ignoring all the incredible things we can do now. Any Turing tar-pit can do incredible things. And when it has a monopoly on its own niche, of course incredible things happen.

deleted 9y ago
[deleted]