O7

Mine’s a variation on Yog-Sothoth from the Cthulhu Mythos.

Not a bad idea really, I guess this way you can get the functionality right away. Merging it in, or adding similar functionality as an option in the official UI would be nice going forward.

🤣

👏

I doubt it there’s anything more to it, just drank too much lib koolaid.

libs are the same everywhere

And this is why tech companies love hiring young people who haven’t yet developed a sense of self-respect or learned yo value their time.

I personally find ((f) 1) easier to read. You just go inside out, evaluate f, then pass 1 as the argument to the output of f. There’s no ambiguity regarding order of evaluation there.

I’ve directly addressed your points, and I get the impression that you’re the one who’s ignoring my points here. The reality is that blocking operations in js are handled using async calls, and reasoning about async code is inherently more difficult than sync code. Platforms that provide proper threading allow developers to write sync style code and handle blocking by using threads that are managed by the runtime. While you have workers in Js, it’s pretty clear that they’re not meant to be used in the same way, nor do people use them this way in practice.

I literally just explained this to you in a prior comment. Let’s say you have a web server that’s accepting connections. You have one thread that grabs the connection and spawns a thread from a pool of workers threads to handle it. Then it goes back to listening for connections. This is how things work on platforms like the JVM. The runtime manages the execution of the threads. This is similar to the way the OS handles scheduling processes. When you’d doing async by hand you’re basically handrolling your own scheduler each time.

What stops you from using worker threads is lack of ergonomics. Just the fact that each worker has to live in a separate file creates friction. In a sane language you can just do new Thread().start() and you’re done. In Js it’s a Rube Goldberg machine as always. When you look at at actual code people write in Js, you see async code everywhere. So, maybe you can answer why you think that is, and why people aren’t using worker threads to write sync style code they’d write in other languages.

Js is single threaded from user perspective. You have no access to the threading runtime as a user and cannot spawn a thread in Js to do some background work. Workers are a recent addition, but using them is quite different from what I’m talking about.

And being stuck in a while loop is precisely why people have to use callbacks and why all the APIs are async. This is literally the problem. If you’re dealing with any non trivial load, you are forced to use async mechanics.

Sure, you end up passing higher order functions around, and my point is that complexity obviously goes up. There’s a reason callback hell is a well known thing in Js land. Meanwhile, Js is single threaded from user perspective. The fact that there is a background rendering thread in client side js is completely tangential to the discussion.

Finally, the problem with callbacks is generally seen in server-side Js runtimes. A great example is if you have an HTTP handler that needs to get data from a db. In a language with user accessible threads you just make a db operation synchronously and return the result. In Js, you have to do a callback. The reason you can do the operation synchronously when you have threads is due to the fact that HTTP handler thread can accept a request and then dispatch a new thread to handle it while waiting for other requests.

I’m not arguing that avoiding deep nesting is a good idea, or that techniques foe doing that don’t exist. I’m just pointing out that Js style programming naturally leads you to nesting things because of the nature of callbacks. Notice how your example isn’t using callbacks.

Problem is that Js kind of encourages this being single threaded and using callbacks for anything blocking. To be fair, the new async syntax sugar helps in modern Js, but nesting a bunch of callbacks or promises was basically the way you did stuff for the longest time.

Looks like a typical Js/Ts codebase to me. :)

Weirdly, I’ve seen plenty of people who appear to genuinely like Js and Ts.

It’s making fun of people who say that lisp is ugly and confusing. There’s nothing to refute there either since the claim is nonsensical as anybody who’s actually used lisp knows.

The comic doesn’t say anything about Lisp doing it terribly either. It’s saying that people who complain about parens are dealing with far worse in mainstream languages.

Having worked with Clojure for over a decade now, I find it far easier to refactor than most other languages I’ve touched.