The working solution is Marxism, that’s the antidote to capitalism and the ideologies that prop it up.

I agree with that, Liberalism as an ideology exists to justify capitalist relations and protect property rights. The mistake people make is in thinking that Liberalism is somehow progressive to begin with.

In practice, it’s like a coin with two very different sides. On one face, you’ve got political liberalism that’s all about individual freedoms, fair elections, and human rights. This is the feel-good stuff that’s used to market Liberalism and make it seem universally appealing.

But flip that coin over and you get economic liberalism, which is really just capitalism wearing a fancy philosophical mask. This side worships markets, treats private property as sacred, and assumes wealth accumulation is basically a human right. Since property rights are seen as the foundation of all other freedoms, the system effectively locks in wealth inequality by making redistribution seem like theft.

That’s why liberals lose their minds whenever governments impinge on the rights of the rich or regulate corporations. In their worldview, any limit on property rights is a threat to freedom itself.

I thought this was a great take on the whole thing

https://orgrad.wordpress.com/articles/liberalism-the-two-faced-tyranny-of-wealth/

why not?

I’ve never got the appeal of that sort of thing either.

The states is literally running a proxy war against Russia using Ukraine, but yeah we’ll just ignore that important context because it doesn’t fit with the narrative you’re peddling right?

It’s a really convenient narrative based on the fallacy of homogenizing Ukraine. Let’s take a look at a few slides from this lecture that Mearsheimer gave back in 2015 to get a bit of background on the subject. Mearsheimer is certainly not pro Russian in any sense, and a proponent of US global hegemony. First, here’s the demographic breakdown of Ukraine:

here’s how the election in 2004 went:

this is the 2010 election:

As we can clearly see from the voting patterns in both elections, the country is divided exactly across the current line of conflict. Furthermore, a survey conducted in 2015 further shows that there is a sharp division between people of eastern and western Ukraine on which economic bloc they would rather belong to:

Either you’re intentionally spreading misinformation here, or you’re far too ignorant to discuss the subject you’re attempting to debate here.

Why would you lie about something that’s well documented, this isn’t reddit.

Burgerland occupies Hawaii and part of Cuba just to name a couple of places, but sure it’s defending sovereignty of a nation where it overthrew the legitimate government in a violent coup. 🤡

the least propagnadized lemm.ee lib has logged on everybody

it’s just chauvinism

China should really send him a gift basket or something. He’s done such an amazing job convincing the ruling class in the US that China is collapsing. 🤣

What I’m saying is that most good static typing systems do not practically have such limitations, you’d be very hard pressed to find them and they’d be fairly illogical. Most static typing systems that are used in enterprise do have limitations because they are garbage.

Of course they do, it’s silly to claim otherwise. Some type systems are certainly more flexible than others, but each one necessarily restricts how you can express yourself. Not to mention the fact that advanced type systems introduce mental overhead of their own. The more flexible the type system is the more complex it is as a result. There was even famously a debugger for Scala type system illustrating just how absurd things can get. I’ve used plenty of typed languages including Haskell, so I understand perfectly well how modern static typing works.

Meanwhile, I’d argue that Typescript provides incredibly weak guarantees in practice, and the impact of transpiling on the workflow is not insignificant.

My experience is that immutability plays a far bigger role than static typing. The best pattern for ensuring correctness and maintainability is to break things up into small components that can be reasoned about independently. Any large project can be broken up into smaller parts, and that’s by far the best approach towards ensuring correctness that I’ve seen.

Again, that’s my experience working with many different languages for over two decades now. I’m not suggesting other people can’t have their own preferences.

That’s not what I’m saying. I think static typing introduces a certain set of trade offs that some people prefer. You restrict the set of statements that are possible to express to ones that can be checked by the type system, and as a result you get additional compile time guarantees. For example, Lemmy devs prefer this trade off and it has nothing to do with enterprise workflows.

I agree, the language alone isn’t a silver bullet. I’m not suggesting that it is. You still have to implement good workflow, do testing, code reviews, architecture design, and so on. All these things are language agnostic. What the language can do is reduce friction in your workflow, and nudge design in the right direction by making it easier to do the right thing. I largely see it as a quality of life improvement.

Also, I’m not saying that patterns like adapters don’t have their uses or that you might not use a similar approach in a functional language. My point was that these types of patterns tend to be more pervasive in mainstream languages.

Static typing itself is a trade off as well. It introduces mental overhead because you are restricted to a set of statements that can be expressed using a particular type system, and this can lead to code that’s written for the benefit of the type checker rather than a human reading it. Everything is a trade off in practice.

Finally, the choice of language ultimately depends on a particular team. Different people think in different ways, and have different experience. The best language is the one that majority of the team is comfortable using. Hence, I’m speaking here from my personal perspective of the way I enjoy doing development. This will necessarily vary from person to person.

This is absolutely true, however I don’t particularly value this feature because most engineers typically already cannot separate concerns very well in industry so IMO if I had this I would not want people to use it. Very much a “it works ship it” trap.

That’s been the opposite of my experience using Clojure professionally. You’re actually far more likely to refactor and clean things up when you have a fast feedback loop. Once you’ve figured out a solution, it’s very easy to break things up, and refactor, then just run the code again and make sure it still works. The more barriers you have there the more likely you are to just leave the code as is once you get it working.

This is where you lose me, you still have wrappers and adapters, they’re just not classes.

A good explanation of the problem here https://www.youtube.com/watch?v=aSEQfqNYNAc

When you’re dealing with types or classes they exist within the context they’re defined in. Whenever you go from one context to another, you have to effectively copy the data to a new container to use it. With Clojure, you have a single set of common data structures that are used throughout the language. Any data you get from a library or a component in an application can be used directly without any additional ceremony.

Yeah you can definitely have this kind of stuff in other languages.

It’s not even remotely comparable. Outside Lisps, I have not seen any environment where you can start up your app, connect the editor to it, and then develop new code in the context of a running application. I also find that language design very much impacts conventions and architecture. Clojure’s focus on immutability naturally leads to code that’s largely referentially transparent and where you can reason about parts of the application in isolation without having to consider side effects and global state. Meanwhile, focus on plain data avoids a lot of the complexity you see in OOP languages. Each object is basically a state machine with an ad hoc API on top of it. You end up having to deal with graph of these opaque stateful entities, which is incredibly difficult to reason about. On the other hand, data is inert and transparent. When you pass data around, you can always simply look at the input/output data and know what the function is doing. Transforming data also becomes trivial since you just use the same functions regardless of what data structure you’re operating on, this avoids many patterns like wrappers and adapters that you see in OO style. My experience with Clojure is that its semantics naturally lead to lean systems that are expressed in terms of data transformation pipelines.

Again, this is my personal experience. Obviously, plenty of people are working with mainstream languages and they’re fine with that. Personally, I just couldn’t go back to that now.

I found Clojure jobs were generally pretty interesting. One of my jobs was working at a hospital, and we were building software for patient care. So we got to go to the clinics within the hospital observe the workflow, builds tools for the users, and then see how it improved patient care day to day. It was an incredibly rewarding experience.

For me, the language matters a lot, and Clojure is the only language that I’ve used for many years that I’m still excited to write code in. Once you’ve worked with a workflow that’s fully interactive, it’s really hard to go back. I really enjoy having instant feedback on what the code is doing and being able to interrogate the app any time I’m not sure what’s happening. This leads to an iterative development process where you always have confidence that the code is doing exactly what you expect because you’re always exercising it, and experimentation become much easier. You can just try something see the result, and then adjust as you go.

Clojure jobs are definitely around, I got involved in the community early and wrote a few libraries that ended up getting some use. I also joined local Clojure meetup, and ended up making some connections with companies using it. I’ve also worked in a team lead position in a few places where I got to pick the tech stack and introduced Clojure. I didn’t find it was that hard to hire for it at all. While most people didn’t know Clojure up front, most people who applied were curious about programming in general and wanted to try new things.

It was basically way ahead of its time.