I noticed an interesting pattern over the years where a lot of people are willing to spend inordinate amounts of time learning libraries and tools within the ecosystem they’re familiar with, but they tend to have little interest stepping out of it. I guess there’s a certain level of comfort you develop with a language and then you just don’t want to spend the time to learn others.
I really don’t understand how people work with Js. What blows my mind is that people choose to use it on the server voluntarily when there are so many better options available.
Yeah, none of these languages have gone mainstream unfortunately. That said, I’ve been lucky enough to be able to use ClojureScript for all my front end dev, and haven’t had to touch Js in years.
We really do, I find Js is useful cause it’s so ubiquitous, but the language itself is really awful. Being able to write your code in Lisp and crap out Js is really appealing.
The demo is a dialect of Clojure that compiles to Js called Squint. I find it really depressing that this type of workflow has existed since the 70s, but never made it to the mainstream.
I’m not the one sealioning into your threads to harass you 🤡
Seems like my home is actually living rent free in that head of yours. 😂
I find small services work fine for well defined and context free tasks. For example, say you have common tasks like handling user authorization, PDF generation, etc. Having a common service to handle that is a good idea. This sort of a service bus can be leveraged by different apps that can focus on their business logic, and leverage common functionality.
However, anything that’s part of a common workflow and has shared state is much better handled within a single application. Splitting things out into services creates a ton of overhead, and doesn’t actually address any problems since you have to be able to reason about the entirety of the workflow anyways. You end up having a much more difficult development process where you need a bunch of services running. Doing API calls means having to add endpoints, do authentication, etc. where within a single app you just do a function call. Debugging and tracing becomes a lot more difficult, and so on.
The amount of churn in Js ecosystem really is phenomenal. The worst part is that a lot of it is just churn for the sake of churn without any tangible benefit that you can see.
I imagine it would be the same dynamic, and you could have an emulation layer on the chip with its own instruction set for legacy code while providing direct access to the native instruction set.
I’m not familiar enough with how Habit and Ante represent memory allocation to say, but part of the problem right now is that there’s already a VM baked into the chip to provide the PDP-11 style emulation on top of it. Ideally, we’d want chips that expose their native behavior, and then craft languages to take advantage of it. Similarly to what we’re seeing happening with graphics chips.
I very much agree, this is just a crazy period we have to live through, but sanity will return.
This dynamic illustrates how capitalism goes through different stages. Early on, companies compete on quality trying to attract customers with better products, and you end up with quality things that work well, last a long time, and so on. However, eventually you get to the point where the same volumes of the product are no longer needed, and that’s when you start seeing things like planned obsolescence creep in because the logic of capitalism is that you have to keep selling and growing indefinitely.
Crazy how we’re basically losing the right to personal property under late stage capitalism.
Not just software anymore, increasingly physical products too thanks to the whole IoT nonsense where every appliance you buy has to connect to the manufacturer to work now.
could even be useful as a command line tool
That’s not what the article is saying though. It’s arguing that the memory model that imperative languages assume is not actually how modern chips work. What we end up with effectively is a VM on the chip that pretends to be a really fast PDP-11 style architecture. Writing assembly against this VM still has the same problem. Interestingly, the way modern chips are designed actually fits better with functional style that doesn’t rely on global state.
It was published a while back, but everything it talks about still very much applies today.
Amusingly, I find s-exp syntax is one of the easiest to read now because it’s so regular and predictable. Since all the logic has to be expressed using data structures, you can’t add a bunch of weird rules to the syntax. On top of that, the code acts as a diagram so you can see relationships visually by looking at the nesting.