In Clojure equality checks are done by value as the default, and all the data is represented using a set of common data structures.
Logging tends to happen as a side effect that’s completely outside the whole class hierarchy.
Functional programming tends to get conflated with static typing and immutability, but it’s a much broader paradigm than that. I find it really depends on the specific language. It’s very easy to do local mutation in Clojure for example. There are constructs like transient specifically designed for doing that. There are also languages like Janet that are functional, but use mutable constructs by default and can embed in C with very low footprint.
I generally get annoyed with software being slow to startup and hogging resources as well, but that’s a separate discussion. The JVM is designed primarily for servers where you have long running processes, and startup time isn’t really a big concern. So, it’s not the best illustration. A CL app written using something like clog will be very snappy.
Joe Armstrong made a good point a while back as well. He pointed out that it’s better to focus on making the compiler smarter so that it can do the optimize performance, and optimize languages for human readability. I very much agree with that sentiment. We can see an example of that being done with GraalVM which can compile JVM bytecode into optimized native apps that have very fast startup time and use far less resources than the JVM. At the moment it’s not comprehensive, but you can make GUI apps with it, and they’ll even run on RPi.
Sure yeah, I’ve done lots of UI programming with Clojure. It works great. I’ve also made small games. Why do you think it would be more difficult than with imperative style?
Typically this is true, but it’s certainly possible to get comparable performance with functional style. Carp, which I linked above, basically uses the same approach to memory management as Rust. It doesn’t rely on GC.
I also find that for most cases it really doesn’t matter all that much unless you’re in a specific domain like writing drivers, making a game engine, etc. Computers are plenty fast nowadays, and ergonomics tend to be more important than raw performance.
That’s not actually true, modern architecture works much closer to the way functional languages work https://queue.acm.org/detail.cfm?id=3212479
It does, hence why it breaks the paradigm.
Rust solves a specific problem, and it’s good at letting you write correct programs with low resource usage. It’s definitely a huge improvement on C and C++.
That said, I find a language like Clojure is far more productive because it’s more expressive, and development is done interactively. With Clojure, you start up your program, connect the editor to it, and evaluate code as you go seeing changes live. Once you’ve worked this way, it’s really hard to go back to having to compile your whole program each time you want to see what it’s doing. It’s like having a conversation with the compiler. It makes it very easy to experiment with different ways to solve a problem, and it gives a lot of confidence because you always see exactly what the code is doing. Clojure also interops with JVM and Js runtimes, so those entire ecosystems are available for use.
Incidentally, there’s a Lisp style language that embraces a lot of Rust principles. https://github.com/carp-lang/Carp
The. real question is whether this problem needs to be modelled using classes in the first place. The alternative is to just have a set of composable functions that take a piece of data and return a modified version that can be passed to a different function.
As a rule, exceptions should indeed be used for behaviors that are outside normal execution flow. For example, you might throw an exception if a file you’re trying to access doesn’t exist, or a network call fails, etc.
There’s plenty of real world code written in functional languages. Also, this idea that FP is somehow more complex is complete nonsense. Lisp family are some of the easiest languages to learn.
Been working in Clojure for over a decade now, and would never never go back to using imperative/OOP at this point.
Indeed, and I’d argue most of actual useful industry exists outside the west at this point.
UBI is the wrong solution in general in my opinion. The proper approach is to have universal basic services. People should have access to all the basic needs provided unconditionally. I think it will be interesting to see how China will handle automation as it will definitively show whether it is moving towards communism or not. In a capitalist society, rapid automation would mean mass unemployment and economic strife. However, in a socialist society automation can simply translate into having a shorter work week.
If you read the article, you’ll see that these are being used in combination with traditional automation. The advantage of humanoid robots is versatility and ability to work in spaces designed for humans. As a side note, I always find it amusing how people always assume that nobody bothered to think of these obvious arguments before going ahead and building these robots.
This indeed would be a big problem in a capitalist society where people have to work for the sake of working.
yeah, I’m pretty sure that as a westerner you have zero agency over either government in practice
The worst part about LLMs is that people ascribe some sort of intelligence or agency to them simply because the output they produce looks coherent. People need to understand that these are nothing more than Markov chains on steroids.