[nothiggs]

On the contrary. We should strive to correct all the "wats" that obviously exist in all these languages, but most of what I see is just complaints, most of them ignoring the amazing things that can be done with these technologies. Over 30 year I've been programming in more languages than I care to count, and I don't remember at any point having a specific language stop me from achieving my goal because it has some traps or design flaws. Always made sure to know about them and make use of the language's strong points instead of concentrating on the weak.

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.

[jerf]

"I don't remember at any point having a specific language stop me from achieving my goal because it has some traps or design flaws."

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.

[briantakita]

> 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

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.

[jerf]

"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.

[briantakita]

> Ah, you see, there's the problem... this wasn't business logic.

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.

[Dewie]

tl;dr: you can't necessarily change the troublesome technology, so you might have to leave. But in order to have a viable alternative to that "bad" technology, you need other people (case in point: mindshare of JS). In order to get more people to "your side", you might need to point out what is wrong with the original technology.

> 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?