Why is that wrong? A language can be multi-paradigm while the “official” documents are written in a specific style. Like human languages, they evolve with their use (or fork into another language completely), while the high literature is the last one to change.

Together with that, I agree that one should read the high literature before inventing a new writing style.

I'm a big believer in 'when in Rome', not just in languages but life.

If you don't like language X, don't take a job writing language X.

On the other hand, sometimes it really makes sense to strike out and define a new, higher standard for code style and paradigm in a given language, or at least to improve somewhat on the style and paradigm that's handed to you.

JavaScript used to be a messy language "not fit for professional use" (see popular JS books from the year 2000 :shudder:), but it turns out most of the problem was how people were using it.

JS code being written today looks like an entirely different language compared to early idiomatic "JavaScripts" one could use to make pages "more dynamic".

JavaScript today wouldn't be recognizable to a JavaScript developer 6 years ago, especially when using class syntax, destructing, and async/await, among many other syntax additions.

Javascript the language has actually changed in those six years.

Common Lisp, OTOH, has not... But styles of CL do change as do libraries, making your statement as applied to CL much more plausible.

JavaScript was never a messy language, it was the different browsers that created a horrible situation for using JavaScript in web pages.

That's something I don't really understand. The language is a garbage-collected C-like. If you don't abuse objects/this/.call, plain Javascript is very readable. What made it a "write-only imperative scripting language"?

If you look at the "JavaScripts" that were floating around at the time (try looking up dynamicdrive.com from around the year 2003) I think you'll understand what I mean.

> read the high literature

The elite language in Rome was Greek.

Actually, they lacked 0, so they could not even terminate their C strings properly.

Wanting to explore that space as a hobby is not wrong, but insisting on it at work when it's clearly not typical or well-supported is pretty wrong in my opinion.

If it drove them to write in another language, might that be a win? A code base full of non-idiomatic code, where devs think in the style of language A while using language B, isn’t a great place to hang out.

It absolutely would be, if our entire stack wasn't in Go.

One was a JS guru who literally threatened 'I can walk across the street and get another job, you know.' And we let him, and both of us are happier for it.

So I do agree, don't join a team writing a language you hate.

I think I would have left too. Go has its advantages to be sure, but if you can write highly expressive functional code in a language like JS, Go is like wading through a swamp.

Agreed. We're 100% Go in our back end, and in the process of hiring. We literally wrote in the job posting, "If you don't want to write Go, this job is not for you."

Well that's just silly. Why take a job using hammers and nails when you really like screws and screwdrivers, but hate hammers and nails?

I think the argument instead might have been, "Go is not designed for it, and kludging in a language paradigm that the language wasn't designed for is going to make for worse code."

The fact that these engineers didn't understand this, suggest to me that perhaps they were not very good engineers as such, even if they might have been skilled software programmers.

Hm, by that measure no one would write OOP in C++.

C++ is a pretty-much-everything language and that includes OOP.

What do you mean? The entire premise behind the design and creation of the C++ language was to add object oriented features to C.

Sorry mate, your argument doesn't make much sense. People can and do write OOP in C++, and just because it is multi-paradigm does not mean no one should write OOP.

It's like saying, because an artist is using watercolors for this painting, they should therefore never do pencil drawings on other projects.

> People can and do write OOP in C++,

if that's "textbook java oop" with runtime polymorphism then that should definitely be avoided and is pretty much considered an anti-pattern nowadays

I don’t disagree, but that’s an entirely different issue than your original argument, which was to suggest that C++ is not an object oriented language.