Every now and then a great movie comes out. Then it gets its American remake. It's been proven you can put Al Pacino, Robert de Niro and Bruce Willis in any movie (with predictable results!). This is the book equivalent of an American remake for me.
Is Javascript the new pseudocode? Honestly I'd rather be forced to learn a new language to understand a book than to read the book adapted to JS.
I just wanted to take 2 minutes to thank you personally for that comment. Honestly its amazing to find another person on this planet who has the exact same reaction to this idea ! I was going to type out what you said pretty much word for word, and then I'm reading what you wrote & I'm like, hey, who's this person who has read my mind & how're they doing that ? For a minute it was like, completely mindblowing.
I think most of the comments below are entirely missing the point & thinking of this as JS hatred. Its more about...cultural degradation...Pedestrianization. sicp was holy grail. you looked up to it, you cherished it, it was something few people have partaken of & it was nice that way. then gradually that got diluted over time. berkeley did the python3 gig & that itself was icky but now this is a whole new low. sicp in js ?! jesus. what next ? are we going to sicp in qbasic ? why not a sicp do-over in Visual Basic so all them fogey 90s microsoft-for-life developers! developers! developers! on win95 code up COM DLL interpreters in Notepad++ ? where does the madness end ?
sicp & scheme. buttons & bows. mac & cheese. bread & butter. things that go together.
Now, sicp & js is...is..what is it ? mustard & jam ?
you know what would be real cool ? sicp in J !!! Now that's a marriage made in heaven. if i was a rich vc i would happily fork over a million for a sicp in J effort. the apl family has so much to offer! now that i recall, there was actually an effort called aprol http://www.cs.trinity.edu/~jhowland/aprol.paper.pdf
I think the target audience is people who don't like to learn, and I find that worrying in the context of programming.
It's not like code examples in a book are intentionally obfuscated. They are also not some atrocious pile of spaghetti code you may have to put up with at work. I think any foreign PL programming book is a joy to read next to working as a software maintainer. And while the original book aspires to be a general programming book (the title!), I think we should allow Scheme programmers to have their poster child book/success story.
I also have a modest, optimistic interest in Rust, and tinker with it from time to time, but I don't think everything should be converted to Rust. The language team is open about sacrificing readability for other values, like execution speed, memory safety, concurrency, correctness. But with Rust at least the occasional rewriting hype can be justified as "testing the limits of the new language" and "optimizing" - because the language is pretty damn efficient. With Javascript it's... what? Some kind of idealism about running all programs in a browser sandbox? And isn't it a bit ironic that an idealistic book about software architecture is rewritten in an ad-hoc language, with a minefield of bad features you're not supposed to use but you will encounter at work?
> I think the target audience is people who don't like to learn, and I find that worrying in the context of programming.
A strange comment to make about someone trying to tackle a text like this
> I also have a modest, optimistic interest in Rust, and tinker with it from time to time, but I don't think everything should be converted to Rust.
This is a great example of how your perspective differs from that of the intended audience. They don't want the book in JS because it's a language they're already picking up and want to tinker with. It's likely one of the only languages they are confident with. Maybe they just finished their CS degree or (gasp) a coding bootcamp and would like to understand more of the fundamentals before learning their second language. Especially one like LISP that represents an entirely separate branch of programming language design from JavaScript.
As someone who writes Clojure professionally, I certainly share your hope they would choose to pick up lisp eventually. Let's not hamper their development in the meantime by steering them away from resources like this that might assist their journey.
Agreed. I'm pretty sick of the anti-JS kneejerk rhetoric that happens here.
It adds zero value to any discussion. It's nothing more than a desperate attempt to gain some internet points.
It's a popular language and it has flaws, but that doesn't automatically make it worthy of the amount of hate it receives here. This type of discussion has more in common with /r/iamverysmart than it does with valuable discourse that HN used to be known for.
I do enjoy "Professor Frisby's Mostly Adequate Guide to Functional Programming", which uses JS examples extensively. Despite the fact my last job was mostly JS, I had to look up functions all the time and stretch my brain muscles. Modern JS is different than "keep it the same" JS. But... converting a book to a different programming language rubs me the wrong way. I miss an opportunity to see another language, too. It's not even some very arcane language. If it really was a knee-jerk reaction, I'd have said:
Adapting a book for another language doesn't really make you miss an opportunity, though, right? The original is still freely available for you to look at and see another language.
It's not an attempt to get internet points. It's an expression of frustration that one of the most important platforms of our time has first class support for only one language, and the only reason that language is used is because of its monopoly on the platform. Were it no for that monopoly it would rarely be used.
I'm just glad JS is as good as it is, considering it didn't have to be good. It could have been even worse and still would have succeeded due to its monopoly.
But WebAssembly was just made a new standard by W3, which, correct me if I'm wrong, will allow browsers to natively support literally any other language the developers choose.
Yes, but only if those languages do not interact with the platform (the platform being "webpages"). DOM manipulation requires JavaScript. So, it is still the case that JavaScript is the only language with first class support.
I like JavaScript despite some of its quirks and there are some annoying ones. However with the mindset to embrace JS I find it easier to work with than blindly hating it. It could be worse. You could be coding in Monkey for Garmin.
The meaning of the second paragraph was ambiguous. Aside from Javascript dislike, which I don't pretend to deny, I believe learning new things is mind-expanding.
When an intriguing movie - or book - comes out, it's often intriguing because it's quite different. When you convert it to a common language - or Hollywood - it becomes less different. Reading "Working With Legacy Code" forced me to absorb some C#, but it also allowed me an opportunity to compare it with Java, which I learned at university.
What I understand from this is that people didn't really value Python as a pseudocode language. It was just fashionable at the time. Now it's Javascript's time. I wonder what's going to be next? Golang has a chance.
I like JS. I use JS daily. JS is part of the workflow for nearly everyone I know who works with code. For me, ES6 is fantastic to use. Some of the better books on JS [I'm thinking specifically of Haverbeke's "Eloquent Javascript"] are general computing classics in their own right.
I used to be a snob about JS, due to the fact that in the 90s / early 2000s, it had major shortcomings and produced a lot of slow, crashy web pages. But when I learned modern JS, I realized that it is now a fully mature language equal to any other, and easily used in a huge variety of contexts [thanks in no small part to Node]
I have to use Javascript almost daily at work, I hate it.
Up until a year ago or so I hadn't really had to use it much, I'm finding it so bad I'm seriously looking at how I can get into an alternate career. Working with JS is a profoundly miserable experience.
Previously I was working on C# and SQL. I'm no fan of either of those, but at least with C# I can understand what the designers were thinking. Ideally I would be working in Clojure if it was up to me. Or Scala or F#.
Now it's Javascript as that is the code base our client uses. The client runs a number of production factories and have an internal web app that is mostly Javascript on the front end for monitoring these production lines.
It's made me angrily punch my desk and consider just quitting on the spot on a number of occasions.
I don't know how anyone tolerates using this day to day and doesn't want to jump off the roof. It's absolutely idiotic.
JS is a terrible language. The amount of pitfalls, language features you must avoid, and obscure paradigms you must follow to make JS usable is mind-boggling. Just because you can use JS well doesn't mean it's a good language.
While I certainly wouldn't call JS "great", I actually do genuinely like a lot of parts of it. I like the Lispey style of embedding data structures (hashmaps and arrays) directly into the language, and I like that it has somewhat popularized some functional techniques and made them mainstream.
While callbacks aren't a great way of doing continuation-passing, at least we can credit JS with making continuation-passing mainstream.
In combination with the fact that JS actually does work pretty well on both frontend and backend, it is a language I use semi-regularly for prototyping, given its flexibility. Granted, if I decide to make a "real" version of the project, I'll probably do it with a more functional language, but I think JS doesn't suck too bad.
I love it and think it's a great language. It has bad parts, but they are easy to avoid, especially with a modern linter. So there you go. You're wrong. At least one experienced developer who has coded in many languages thinks JavaScript is a great language.
Basically, you install the `typescript` package which gives you `tsc`. Then you configure Node to run your program with `tsc` through your package.json.
But I’m happy for you that you like ES6. You all own the language now, so enjoy it. Us ES5 folks are going to have to rewind and fork so we can have a community again.
I do. I love vanilla JS especially. The way it interacts with the DOM and the way JSON works makes more sense to me than most other languages, and this is coming from a python user and newly lisp user.
Not everyone has the same brain as you. People enjoy things you don't understand.
It's useful and practical and has a lot of work put into it so it can't really be called bad, but it doesn't really stack up to what native languages can provide at the high end, and never will (even if it can get pretty darn close).
Though I acknowledge its immense utility, I feel like JS always tends to go for "good enough" solutions rather than "best in class" solutions. That is its own kind of quality, but there's good reason to dislike JS for people who focus on those particular qualities in a language.
For sure, if you have a shot at making a world class system you probably don’t want JS.
But I’ve never been in a job where we had a shot at building a world class system. Maybe I just have bad luck, but at each place I have worked the problems in the codebase are obvious and the impediments are institutional not technical.
There are hundreds of problems I could list in our current codebase that are causing slowdowns, bugs, etc. None of them are because of the programming language. They are places where someone put a square peg in a round hole, where someone copied a bug over and over because they assumed the existing code was correct, where someone used a fancy feature of the programming language that made the program worse.
None of that goes away if we start using Rust.
So yes, I agree with you if you are within striking distance of making a perfect application use a nearly perfect language.
I’ve just never been in that job. I’ve always been in the “let’s fix some of this low hanging fruit, and make sensible use of the tools we have” job.
The problem is that if the system was world class then it might actually be ok if it was in js. Most codebases are a bit of a mess, like you say, and js just makes it much harder to figure out what is going on. It's not just a dynamic language, it seems to encourage a gratuitously dynamic style. So you have to figure out everything in the debugger. That is if you can even determine where to set a breakpoint!
Yeah, I actually agree with you especially for ES6. Because it requires you to transpile, and because promises/async/await break the control flow model, it is extremely difficult, often impossible to place breakpoints. With await in particular, you can forget to await a promise and then your app just stops working, mysteriously, and there’s no way to find out what’s happening except to one by one disable parts of the app until the situation becomes clear.
Transpilation as a norm means it’s kind of 50/50 whether the source code you encounter while debugging will even be readable.
Actually what I see most often, professionally, is that JavaScript developers stop believing they can inspect their application at all, and when something is wrong immediately just try to guess what’s happening. Then see if their imagined fix helps, if not try again. Basically guess and check. Which is a fine technique but it’s pretty bad if that’s your only way to debug problems.
I am able to code in ES5 sometimes on independent projects (without Webpack) and it’s a joy. The debugger works everywhere, in a consistent way. I have callbacks everywhere so asynchronous code is simple to trace and easy to understand. It’s great.
I am working slowly towards a fork of NPM/Node ecosystem that starts over before ES6. I think early JavaScript is actually a wonderful, fast, elegant language.
I would say that ES6 is so bad in terms of debuggability that you almost have to use TypeScript to make coding in ES6 bearable.
The other aspect of what you’re saying: that you have no static analysis tools so you HAVE to debug, is spot on. I think to build a great JS application you have to put an equal amount of effort into designing the test harness. Basically all the time you would have spent wrangling the type system you have to put into the tests.
And you can’t just half- ass the tests. They need to really accurately mirror your business needs, and really model the relationship between your app and your tests, in order to provide an equivalent static analysis value to what a type system would give you.
However one final point, which is that the fact that ES5 is so impoverished in terms of control flow and data modeling, I think actually helps solve all of these problems. If you limit yourselves to basically just functions and literals, you are forced to write really strong clean interfaces. I find myself being able to focus almost entirely on separation of concerns. Because I’m not dealing with fancy language features, and because I literally can’t afford to build giant complex modules and applications, it forces me to build small, simple modules that have very clear responsibilities.
That might seem like a limitation to many, but I actually find it helps me to avoid headaches before they happen.
Do you find yourself accidentally doing that often? A few of the things from the "Wat" video fall into that category. "Things no one would have ever thought to try, yet a dynamic language will fully allow". If you want to point out valid concerns with JS, the double-equal implicit coercion is a far more frightening "gotcha".
Not lexically, no, but dynamically, sure, all the time. JS lets me receive an arbitrary value in a variable `foo`, and "add" it to another arbitrary value in a variable `bar`, without having any opportunity to specify what semantics I mean by "add." Fixing the semantics of the operation is the whole point of specifying it!
Personally, I favor languages that go "almost too far" in the opposite direction, e.g. Elixir. In Elixir, operator[] (a.k.a. the Access protocol) is generic across several types, but the semantics are very strictly constrained; not only does the access have to "mean" getting some kind of element from a container, but it's also only defined where it has a fixed O(1) time-complexity.
This sort of design being conventional in Elixir, means that you can usually predict, just from the lexical environment (a.k.a. "the code on the screen") what the runtime behavior will be of said code—which includes being able to "read off" a time/space complexity for the code—without needing to check how each ADT involved has implemented its generics, let alone having to check for implicit type coercions.
Few people do that outside of code obfuscation contests, but the point is JS has heaps of gotchas like that, each waiting to bite you. How about:
x = 5;
(no var declaration). Extremely easy to do by accident. Lots of these will be left for backwards compatibility. In JS errors often go silent and I developed a strong dislike for any language that does that, including Vimscript and Lua (and I do like Vim).
I'd agree that global declaration is far more egregious. A sibling comment recommends a linter, and I'd probably agree. It's sad that it was ever allowed as one that is copying and pasting code to another location can easily cause this case to happen.
Eh, I actually like JS but I have definitely forgotten to add a "var" or "let" a few times, or sometimes I will do it correctly, get a bit overzealous with cutting, and accidentally remove the initial var declaration.
I'm not saying that it breaks the language, but it definitely is irritating, especially if you're not using a linter.
Whilst I do find it irritating, I don't mind about the scope default so much, but I've certainly run into it (forgetting to specify) a lot.
Mostly because JS is not the only language that I'll be working with at a time, and if I'm dancing between three or four and they have similar syntax, then mistakes creep in.
Javascript is such a good language that, even after two decades of fixes, it's only good when you use a different language - specifically created to address JS's many problems - that compiles to it.
> develop on every platform natively (React Native)
If "native" means bundling a runtime and having your program pass serialized messages to a different thread where the actual native platform code lives, the same can be said for any language. You just need to build the wrappers for the native API – which is a lot of work but could be done for QBASIC running in DOSBox just as well as for JS running on V8.
To dang and the other moderators, can you think of a way to auto-penalize effectively contentless/empty anti-Javascript comments?
Imagine this kind of comment for any other language, C, Python, Ruby, Rust, Scheme whatever. It would be downvoted to death. And yet people still make & upvote these comments about JS despite JS being the most popular language, run on the most devices & having a massive community of people fixing its warts and modernizing JS.
There are still valid critiques of JS but they have nothing to do with Al Pacino or Bruce Willis. Please spare us, or if you want to criticize Javascript, learn something about Javascript in 2019 & criticize that.
Is Javascript the new pseudocode? Honestly I'd rather be forced to learn a new language to understand a book than to read the book adapted to JS.