For those unfamiliar, Gary Bernhardt is the same guy who did the famous "Wat" talk on JavaScript:
if (a) b;
if (a) { b; c; }
{b; c}
{b}
{}
if (a) b;
However, semicolon insertion is only triggered when there's a newline at a position where there would otherwise be a syntax error. Here, neither is the case: blocks don't have to be terminated by semicolon (so no syntax error), and there's no newline in the source code!
All his opinions should be discarded.
I've probably seen twenty people call this "wrong", which frustrates me. It's not wrong. It was a stringified object! I didn't say "stringified" because it wasn't relevant to the question of whether the object was in an array!
There are other things in Wat that are genuinely wrong, though, like the fencepost error about "16 commas", which mistake will haunt me forever.
And that is not the only thing that is misleading, as you clealy said that {} was an object. Yes, the syntax in js is weird as it looks like an object, but it isn't. Again, a better shell would not let you do this.
I do agree the {} + [] example has always felt a bit unfair to me (for the reason that {} is a block), but whatever, it's a light-hearted talk.
Speaking of which, why does WAT do different things on node.js?
Only in old versions of Internet Explorer.
Wrapping the same input in parenthesis (eg, '({} + [])') yields different results.
edit: nevermind, I clicked the download link. But I'm still wondering why the video's unplayable on the site.
Javascript is great once used in a "good" way. It's flexible & it's almost everywhere. Spending all your time complaining about how "bad" Javascript is kindof pointless. If you use Javascript, learn how to use it well.
Master sushi chefs don't sit there complaining how bad knives are because the knives need to be constantly sharpened.
If you are cooking spaghetti, learn how to strain the noodles, instead of using silly examples assuming people are incompetent at learning a tool.
Sushi knives don't decide to cut you because the rice came from a different origin. And I'd guess that most craftsmen, outside of a ritual and tradition would love for their tools to have less disadvantages.
If you want to draw an analogy to spaghetti (?), it'd be like complaining that the only kind of spaghetti you can buy locally cooks only at a specific temperature, and even a bit more turns it to mush. And the reason is because the local government passed a bylaw with only a few hours of consultation that ended up banning imports of better kinds of spaghetti.
While it might be "pointless" to spend all your time complaining, there's certainly value in asking "wat" and pointing out absurdity.
Hmm, "the guy next to me goes 'pfft, this is bullsh*t'".
> it's about our nature as humans
Well, it's about our current generation of Americans (maybe Westerners). This complaining seems like unnecessary stress to me. I understand, because I used to do it.
I'm not convinced that this behavior is specific to Americans or Westerners; it may just be that we're most attuned to our own ways of expressing it. I'm also not convinced that it's a general property of the species, though; it would be arrogant for me to claim that kind of fundamental knowledge of how the human mind works. That kind of arrogance is the bread and butter of Hacker News, of course, so this is now necessarily a bad HN comment. ;)
I should've said something more like "it's about the way that we all act towards technology".
I don't think that was the point of the video (some amount of gratitude for the things we have) -- but then maybe I'm misunderstanding your point.
And we both understood the point of the video. The fact that there is much to be grateful for does not mean that we shouldn't improve on what needs improving. But for heaven's sake, if you're not going to improve on it, stop whining about it and be grateful for the amazing things it does enable.
I have to admit, a language has never stopped me personally. But it most assuredly has hurt me when trying to program with other people, who do not have a direct psychic hotline into my brain that tells them what preconditions must hold before my code will work properly, and what things they can and can not do with a certain library, and most importantly, why they can and can not do those things. Languages that allow me to encode more of those things into the program itself, instead of the ambient documentation-that-nobody-ever-reads-even-when-I've-put-tons-of-work-into-it, work better.
And as my memory isn't all that great, it turns out that if I'm away from my own code for long enough, I become one of those people who don't have a direct hotline to my-brain-in-the-past.
Programming is hard. It's an ongoing process of mastery. This is true with any programming language. There is no silver bullet.
> Languages that allow me to encode more of those things into the program itself
There are plenty of tools that almost every language provides for you. It's an architectural concern to ensure that there is as little mapping between the domain and the code.
I personally find Javascript to be flexible, which allows me to architect my software in a way that is communicative of the domain, without many restrictions.
> I become one of those people who don't have a direct hotline to my-brain-in-the-past
A story is a great way to communicate information. Automated functional (black box) testing is also good. Also, try to reduce the mapping between the domain and the software. Ideally, the software (naming) should have a 1-1 map to the domain.
Also, keep the structures flat, as this idiom tends to reduce complexity.
Keep consistent & iterate on architectural idioms between projects.
These are some ways to improve communicability of the codebase & to have insight into the business domain logic.
Ah, you see, there's the problem... this wasn't business logic. To put it in Haskell terms, I had code that was not in IO, but I couldn't actually encode that restriction in the language.
Most of your post amounts to "program better", which is vacuous advice. We've spent decades telling each other to "program better". We've proved to my satisfaction that's not enough. Have you used languages not from the same tradition as Javascript? It is possible, even likely, that you are not aware of the options that are available out there, even today.
What is "this"?
> Most of your post amounts to "program better", which is vacuous advice
No it's not. It's certainly better than dwelling on some edge case shortcomings and limiting your growth by blaming the tools.
No tool is perfect. Learn to use it better. Master it. Improve it. If you want to use a different tool, then use a different tool. There's no need to spread negativity.
There has been plenty of progress in Javascript idioms & programming idioms in the past few decades. You can accomplish many things with Javascript and the environment will only continue to improve. Programmers will continue to get better from the ecosystem & practices that have been learned over time.
Even your mighty Haskell is not perfect. Time to accept non-perfection & evolve :-)
> Have you used languages not from the same tradition as Javascript?
Yes, I have. I also draw inspiration from other languages & environments.
> It is possible, even likely, that you are not aware of the options that are available out there, even today.
Yes, I'm aware. When they prove themselves, I'll consider using them. In the meantime (and always), I'm happily mastering my craft free of unnecessary angst.
> But for heaven's sake, if you're not going to improve on it, stop whining about it and be grateful for the amazing things it does enable.
Sometimes you're not in a position to even be able to change something, even if you wanted to. The ideas you have in mind for a technology might fly in the face of how the community around that technology, or the guardians/maintainers of it, thinks of it - introducing these changes might break too much stuff that is dependent on it, the changes might fly in the face of the culture around that technology.
So if you have some technology that you think - subjectively, or even somewhat objectively if you have conviction enough - and you can not do anything about it, you only have two choices. Embrace it and try to work with it despite its flaws, or to abandon ship.
But if you want to abandon ship, you probably want to find a safe harbor, eventually. ie a place where you can develop or utilize some other technology. But that place might be sparsely populated, because everyone else is working with that other technology. So what do you do? You suggest that others jump ship. :)
Assuming that there is actually some kind of objective merit to complain about a specific technology, it might be wise to complain to others about that technology. That way they can hopefully use that info to make an informed choice, and perhaps abandon their current technology for another technology. In time, you might even get enough people to come over to this other technology that that community is big enough to support that technology as a valid alternative to the "bad" technology. But what if everyone just stfu'ed about what their "negative" thoughts are on a technology? Would that other technology be able to get enough "acolytes" in order to be a viable alternative? Probably not, because everyone was too "positive" and polite to point out how that technology might be better than the old technology.
Would JS even be so controversial if it wasn't for that it is so entrenched in Web development? Is that not a great example of how important mindshare can be?
In the mean time, one can learn to appreciate & use javascript strengths. It can be quite fun, liberating, & useful. Anecdotally, I have not run into these crazy issues, and I program in javascript everyday. I also have a large app and the framework I built is custom.
I liken this to using C++, Unix, & bash as a base. Yes, you could say these tools suck and spend time creating, marketing, & community-building for a new tool. Or you can iterate & improve upon these existing tools. There's no wrong answer. What do you want to accomplish?
> Sushi knives don't decide to cut you because the rice came from a different origin.
That analogy seems like a stretch. Care to explain? Javascript works with different locales. There are many international websites that use javascript.
Also, javascript does not "decide" to create a bug in your program. You create that bug by misusing the tool. You will get further if you take some responsibility and improve your practice.
> And I'd guess that most craftsmen, outside of a ritual and tradition would love for their tools to have less disadvantages.
I agree with that. Usually the improvements are iterative. One could use a laser cutter (which does not need sharpening) to cut sushi, but that would also burn it. Here's a good talk (Clojure: Programming with Hand Tools).
https://www.youtube.com/watch?v=ShEez0JkOFw&safe=active
Ritual & tradition is a social tool to propagate knowledge, idioms, & practices across generations. It makes sense to challenge ritual & tradition to they improve over time. It does not make sense to whine about it without doing anything.
> it'd be like complaining that the only kind of spaghetti you can buy locally cooks only at a specific temperature, and even a bit more turns it to mush
Not getting your analogy. This seems like a stretch, similar to the person who cannot strain the spaghetti noodles on the video. Care to explain?
And your examples make sense, javascript doesn't (in some cases) so it's very appropriate to complain.
In that case, it's appropriate to complain about gravity & being restricted to the speed of light?
No, it's better to learn about and use these properties to your advantage.
That changes everything
I'm sure you have the skills required to, say, write a preprocessor for whatever language you are using, and add some special constructs in it. Missing feature? Done in a few days. So…
If the laws of physics suck, suck it up.
If your tools suck, change them.
Yes I am. The property that they share is they will not be changed or avoided in the near future.
Another property is that despite certain limitations, you can still accomplish many things. If you focus on these limitations, you will accomplish less.
> If the laws of physics suck, suck it up.
Not in all cases. Physics is just a model of our understanding of physical existence. Einstein demonstrated that.
> If your tools suck, change them.
I guess if it's worth it to spend that much effort, then go ahead. Just know that the frequent examples of javascript's "problems" are easily surmountable, that is if you don't dwell on these "problems". Javascript has some great attributes to it.
Indeed, it does not "suck". That's like saying the human body sucks because we have this ridiculous tail bone and wisdom teeth. No accounting for taste, I suppose.
I choose to focus on that and progress in mastery of my craft. If you want to complain and/or change your tools, go ahead. I don't judge you.
You vastly overestimate the effort it takes to change your tools. When I was talking of a few days to add a feature to a language, that was a conservative estimate. With proper knowledge it's more like hours. And I'm not even assuming access to the implementation of the language. Source-to-source transformations are generally more than enough.
Heck, I have done it to Haskell and Lua. And it wasn't a simple language feature, it was Parsing Expression Grammars (the full business). I used no special tools. I just bootstrapped from MetaII (I wrote the first version by hand, then wrote about 30 compilers to the nearly final version). (For Haskell, I took a more direct route by using the Parsec library.)
Granted, writing a full compiler to asm.js is a fairly large undertaking. But fixing bits and pieces of the language is easy. Real easy.
> Not in all cases. Physics is just a model of our understanding of physical existence.
Oh, come on, don't play dumb. You know I was talking about the way the universe really works, not the way we think it works.
> I choose to focus on that and progress in mastery of my craft. If you want to complain and/or change your tools, go ahead. I don't judge you.
I'm not sure what you're saying. It sounds like you want to focus on particular programming languages. This would be a mistake, pure and simple. You want to master the underlying principles of programming languages. It can let you pick up the next big thing in a few days. It can let you perceive design flaws (such as dynamic scoping). It can let you manipulate your tools, instead of just using them.
Your way leads to obsolescence.
---
My advice to you: if you haven't already, go learn a language from a paradigm you don't know. I suggest Haskell. Also write an interpreter for a toy language. Trust me, that's time well spent. For instance, knowing Ocaml made me a better C++ programmer.
> You vastly overestimate the effort it takes to change your tools.
Cool! If you don't mind the asset overhead, having to recreate the existing javascript ecosystem, & the abstraction mapping, & the other unknown unknowns, then it's all good. Are there any well-known production sites that use such techniques? I don't doubt there will be, but are such techniques "ready for prime time"?
I personally have not experienced enough pain to be motivated to all that.
> Oh, come on, don't play dumb. You know I was talking about the way the universe really works, not the way we think it works.
The thing about existence is we don't know about it in it's entirety. Even if we know the rules, there are many mysteries to explore. It's wonderful :-)
> It sounds like you want to focus on particular programming languages. This would be a mistake, pure and simple. You want to master the underlying principles of programming languages.
I am mastering the underlying principles of programming languages.
I want to focus on getting better, faster, & smarter. For the web, it's nice to have everything in one language. Lot's of sharing of logic. Keeping DRY. Being efficient with time. Smaller team sizes. More stuff getting done.
Maybe compiling to javascript will help for other languages.
I'm a fan of dynamic languages. There's more than one way to master the craft. Asserting your one true way is a failure of imagination.
> Your way leads to obsolescence.
I doubt it. You vastly underestimate my ability to adapt & evolve ;-)
> My advice to you: if you haven't already, go learn a language from a paradigm you don't know. I suggest Haskell.
Maybe one day. In the mean time, I'm focusing on becoming a more fully rounded thinker. That means subjects outside of programming. Learning yet another language has diminishing returns.
I'm humble enough to not give you unsolicited advice, which would only serve my ego.
Ooh, and I agree. OCaml, Erlang, & Lisp are fun languages. Javascript is also fun.