> If it were enough of a problem that the bad outweighed the good, people wouldn't use it, but yet they still do, so it's not enough of a problem.
The problem is that while this is true, in practice it's more like the mandate of heaven than laissez-faire economics. When political power structures are involved, and thus the status quo itself is reliant on the omnipresence of certain economic forces, there can never be a drawdown under normal market forces. There is an intentional, exerted force which unbalances the equation in favor of the monoliths. "Enough of a problem" ends up becoming violent social upheaval. In effect, you advocate for normalizing the driver to aim our societal bus off the cliff because "somebody hasn't grabbed the steering wheel yet, so it's clearly an acceptable course." Discounting the fact that the co-driver is pointing a machine gun at the back of the bus.
Adam Smith would be absolutely apalled that we let things get this bad. This isn't what he wrote about at all. The free market is about economic coordination, not letting massive entities do whatever they damn well please at the expense of a society's quality. This is neo-mercantilism, the exact kind of thing he was vehemently disgusted with.
I think a good metaphor for the situation is that the US is like a tank and regulations are like armour on that tank.
It can both be true that the US has too many regulations (the tank has too much armour) and that it's in the wrong spots (too much armour in the back and not on the front.)
America needs less regulations in some scenarios, and more regulations in others. It may very well end up that the net result of these combined changes is less overall regulation and also more effective regulation.
If you care about high quality products we can start with the OP article and how this system, which is most definitely not capitalism as intended, has directly entailed this nosedive of enshittification for absolutely superfluous and nonsensical reasons. The Soviets succumbed to the exact same mistake, I'm not sure why you would bring them up.
I presume you live in a capitalist society. That means you are free to start your own business and avoid enshittification and nonsense.
Me, I started a game business because nobody else made the game I wanted to play. I started a compiler business because I didn't like the available compilers. I designed a new programming language because the existing languages were not good enough.
I think perhaps it's my fault for how I worded that reply, but to clarify it has scarcely little to do with products at all. They don't matter. I sure hope you still can make your own tools to your hearts desire, but that's not going to fix anything and it never will. I'll emphasize I'm still confused at your first reply, which reads like a non-sequitur to me, and this second reply makes me think we're having wildly different conversations, so I think I'll just leave it at that.
> Adam Smith would be absolutely appalled that we let things get this bad. This isn't what he wrote about at all. The free market is about economic coordination, not letting massive entities do whatever they damn well please at the expense of a society's quality. This is neo-mercantilism, the exact kind of thing he was vehemently disgusted with.
One problem is that the ambient propaganda has changed the definition of capitalism to exactly the problematic one you describe, so that arguing for a more sensible balance of the kind that Smith and others described is taken as an attack on capitalism itself.
These days I'm reminded more and more often of Wimp Lo from Kung Pow! Enter the Fist: "We have purposely trained him wrong, as a joke." Except people have been trained wrong to make them better targets for farming their capital.
LuaJIT is amazing. I find it insane there are no Schemes that are able to match it as a tiny, embeddable scripting language with a JITer. GNU Guile is an absolute gargantuan monster in comparison.
I see this misconception a lot. Functional programming has nothing to do with mutability or immutability. Just like product types (or associative arrays) don't make for object oriented programming, the paradigm is about the patterns you use and the total structure of the program. In the case of functional programming, it's that your entire program is built around function composition and folds. This changes how you build your program on a fundamental level.
Additionally, functional programming does have a strong theory behind it. That of the lambda calculus. Everything is formalization and constructions built on top of that. We don't have a "hard line" to detect if a language is "functional" because it's not a language paradigm, but a property of the code itself. Grammar is orthogonal to this stuff. You can, however, make a pretty good guess by looking at the standard library of a language. There is no ambiguity that Idris or Haskell are a languages designed for functional programming, for example.
I think this stems from a problem that there are a lot of programmers, who through no fault of their own, have engaged with tools for functional programming, but skipped building things using the alien and weird stuff so in the end there's no actual learning of functional programming itself. Every new programming paradigm is a shift of your core perspective, they require you to relearn programming from the ground up. It shouldn't feel like "this is just ABC with XYZ", you are only truly beginning to learn when you are put back into your shoes as a middle schooler unlocking the power of nested conditionals. If you don't get that feeling, you're just learning a different language and not a programming paradigm.
> And even the best example of purity, SQL
Purity is not a claim of functional programming. Also SQL is not anywhere close to being a functional language, it's not only a non-programming language, but even if it were (and it can be with extensions) its paradigm is far more in line with logic programming.
> This changes how you build your program on a fundamental level.
I think this manifestation of cargo cult mentality should be put to rest. For each paradigm we heard the same story, but we still see programs in ${LANGUAGE_A} not even following idiomatic styles and looking instead like programs transcoded from ${LANGUAGE_B}. You do not change the way you build programs by rewriting projects in a specific language or even style. You just get the same people implementing the same programs according to the same mental model. The key factor is experience and familiarity, and you don't build any of that by marketing a particular programming style. Moreso when which framework of library was adopted by a project. The hard truth is that experience and familiarity derive from problems a developer faced and the solutions that worked, and quite bluntly after all these decades functional programming isn't living up to the hype created by it's fans. It's the curse of LISP all over again.
I'm not sure that your objection puts anything to rest, least of all a "cargo cult mentality". You re-assert exactly what I say just to disagree and miss the rest of the post. Codebases which are not written in a functional style are not functional programming, no matter the language being used. The overwhelming majority of programmers did not learn to program in a functional style, and without the long haul learning process of thinking about program construction in terms of function composition and application, they will program according to whatever they've always used. They can't program or use a mental framework that they don't know. Languages are languages. The syntax and grammar of a language has (virtually) no effect on a programming paradigm. There's nothing in the grammar stopping you from using Haskell as an imperative language. That's a knock-on effect of being a turing complete grammar, no more, no less.
Given these facts which are absolutely not up for debate, some statistical sample of codebases which are just some unstructured hodge-podge mudball in any given language isn't particularly meaningful. Somebody who spent 2 weeks reading Haskell tutorials in their off-time isn't going to be writing functional programs in Haskell. Hell, somebody who has been writing mudball Haskell programs for years isn't going to be writing functional programs.
> and quite bluntly after all these decades functional programming isn't living up to the hype created by it's fans
Perhaps your problem is that you are looking through such a lens that "hype" even registers on your radar. And that's why I'm sure you can't name a single weakpoint of functional programming off the top of your head besides the ever popular, ever erroneous complaint about "performance" by people who think functional programming is immutability, purity and function pointers. If all you care about is the social baggage with a working discipline and its tools, how can you possibly have anything but the most trivial, surface-level and, to put it bluntly, ignorant view of things? There is no substance to that nonsense, don't kid yourself. Until you change that you will never receive any signal, just noise. The heterogeneity of programming as a discipline will continue to frustrate you to no end.
"All over again"
Lisp is a tool explicitly designed for functional programming ;-)
To chime in to this discussion, I suppose there is a disagreement of what functional programming means exactly. For some it means Haskell or equivalent, for you it seems to be much laxer. Functional-programming evangelists tend to be on the stricter side, though.
When programming with “functional core with imperative shell”, is that functional programming overall?
In the projects I work, functional-style parts are commonly bookended by imperative parts both outwards and inwards. The inward parts are things like database calls, file I/O, OS state, or other remote service calls. The art lies in keeping as much code free from side-effects as possible, but it’s rarely only the “shell” that is imperative.
Regarding functional (de)composition and proper structuring, that was very much a thing in imperative programming from fairly early on. That’s not specific to a functional style.
I suspect that it depends on the context in which people first learn about it whether they associate it with functional programming or not.
And I think that a lot of the aversion to functional programming advocacy comes from advocates demonizing anything imperative, while in reality a mix of both is appropriate.
> Functional-programming evangelists tend to be on the stricter side, though.
> I think that a lot of the aversion to functional programming advocacy comes from advocates demonizing anything imperative
I find these types to often be more motivated by things like nicely designed grammars and powerful type systems more than functional programming itself. A convenient test is give someone over to a J codebase. If they principally learned in a functional environment, or otherwise mastered functional programming, they'll love it. If they just like having language features that aren't 50 years old, they'll want to tear their hair out.
I have seen academic-types that abhor the idea of a flip-flop. I'm not programming a blackboard, so I pay this no mind.
> When programming with “functional core with imperative shell”, is that functional programming overall?
The functional parts surely are. The imperative parts are probably not (since they have to be very granular). Why reduce it to a binary overall? A complex codebase is a highly entropic thing. How much does the functional core influence the non-functional shell? It probably varies, and would require a high dimensional manifold to accurately graph.
> Regarding functional (de)composition and proper structuring, that was very much a thing in imperative programming from fairly early on.
Imperative and functional aren't generally mutually exclusive in my eyes. You can use statements to structure programs in a functional manner. No problem.
Threaded code is relatively similar to functional programming, but it's also very dead unfortunately. Most people's introduction and exposure to it is exclusively through Forth toys. It was (and maybe still is?) a real assembly technique. You need better control over the callstack than you get out of most imperative languages these days.
Point-free style is a critical component of functional programming in my eyes. Far more important than purity. It's not exclusive to functional programming, but it's pretty much holding up half the sky. Without it, you get crap like recursively descending a list of function pointers and void* args. Not ergonomic.
I should also note that I would consider ENIAC's programming paradigm to be rather close to functional:
> I'm not sure that your objection puts anything to rest, least of all a "cargo cult mentality". You re-assert exactly what I say just to disagree and miss the rest of the post.
Not quite. I'm pointing out how your argument is based on a cargo cult mentality where throwing "functional programming" labels at practices is all that's needed to fix any and all problems. It is not. Functional programming has been a thing for decades and you still get software with the same rate of bugs and failures than your average codebase.
> Codebases which are not written in a functional style are not functional programming, no matter the language being used.
This is another predictable way on how the cargo cult mentality copes with the failures to live up to the extraordinary claims. You're pinning the blame of the bug-free cargo planes not landing on your makeshift functional programming airport because of how the cult of functional programming is being practiced wrong.
The truth of the matter is that programming paradigms are not panaceas, and developers still need to be mindful of software engineering best practices to minimize the risk of introducing problems.
> As an American, it came as a surprise to me that we do not, in fact, have broadly shared values about our system of governance.
It shouldn't, America is two very distinct nations. The shape and nature of those nations vary wildly in classical Baudrilliardian sidewinding progression, but it's rooted in the very early history of British North America. Two distinct primogenitor colonies and societies, Jamestown and Plymouth. Founded for different reasons, in different contexts, by different people. Understanding the disparity is key to understanding a great deal about America. This divide has always persisted. Jefferson was of Tidewater, Hamilton was of Yankeedom. Democrats vs Whigs. Dixie vs Yankeedom. This split persists in history, and is much the reason why America is ostensibly a two party system. Even if the regional divide is not as hard and fast as it once was, even if the matters in which they differ change radically over time, the divide itself will always persist. It's wrapped up in the pre-revolutionary context the country was founded on. America will always be two countries in a trenchcoat, two echoes of wildly different cultures set against each other for dominance. You should always be keen to remember that. The union isn't of 13 distinct colonies, but two distinct cultures always in tension. It's a fundamental structure within our larger cultural blueprint.
That's a great insight and one for which I thank you for pointing out as I learned something new thanks to you today.
My question is whether two different cultures can in fact coexist with each other for a single system of governance.
Like, Why do we focus so much on our differences as a species that we forget how much common we are on literally everything.
What is a solution to this problem that's kinda impacting the world right now. America moves in pendulum in a political cycle completely 180'ing but yet at the same time, I feel like no real change is being made against lobbying/corruption which sort of infiltrates the world too.
Bernie sanders and now maybe zohran are the two democrats who are genuinely tryna do something for america which I deeply respect tbh. Yet there wasn't really a way for one to vote for them directly y'know?
Are these differences of cultures really that distinct to basically split a country in half in everything except the borders?
Was there no way of integrating them without having them idk being the way that they are right now?
I think a good introductory text on the deep nature of the divide in America is We Have the War Upon Us by William J. Cooper.
It's mostly a book about the civil war, but it introduces some post-revolution pre-war history and names. That gives you more resources to dig up. You should read as much as you can and form your own opinions on that.
I'm relatively well versed in "the divide" so to speak. But I'm trying to understand what you mean by the Plymouth and Jamestown split as it relates to our modern country today.
It seems like both the spirit of Plymouth and Jamestown are inside the big tent of the Republican party today. But that doesn't sound like what you intended it to mean. Or maybe it is?
That's the part I'm curious about; who is Plymouth and who is Jamestown in 2025 in your eyes?
Plymouth is harder to identify. It's not just the Puritans at Plymouth, nor exclusively New England. It's merely everything that came with the second colonization. The Dutch are a foundational part of Yankeedom. In fact, New York should probably be considered more foundational than Plymouth. You would be right to identify Jamestown with the modern GOP. Traditionally it was represented by the Democratic party, but I assume you're familiar with that.
I should note these geists extend far beyond legitimate political guise.
Of course I understood there were vast cultural and political differences causing tension. I just also believed that we had a shared system of fundamental values enshrined in the constitution and when push came to shove, we would all rally behind it. That's what I thought American patriotism meant; I genuinely thought I could count on Red voters to rabidly defend the constitution.
> I just also believed that we had a shared system of fundamental values enshrined in the constitution and when push came to shove, we would all rally behind it.
The US had a Civil War in the 19th century over the fear of the southern states that the northern states would not only refuse to continue to be complicit in the institution of slavery, but eventually end it.
The seceding states wrote slavery, as well as protections of the property rights of slave-owners, into their constitution.
After the war came the scaling back of Lincoln's planned reconstruction, sharecropping and Jim Crow. There are people alive today who remember segregation.
Oh I hadn't heard of Ante before. This looks very close to the language I wanted out of Rust. Haskell's module system, row polymorphism, linear types, no sepples glyph soup. That's an instant bookmark save. Will be watching that space very closely.
Koka[1] jumps to mind as a language built around effect types. Without having used Flex or Koka, I'm not sure how their effect types actually differ from the normal monad gauntlet you get in pure languages.
You are the best kind of correct since "many" can refer to some large number that is also insignificant. The pro-European sentiment is vastly dominant, though, and that's what matters.
reply