Ah, gotcha. A slashdot post is not really sufficient to introduce the topic. Typically you use immutable data structures, which are often built over a mechanism called a "path copy". Basically, your app state is stored in a data structure, and when state is updated, you create a new data structure representing the new state, using purely functional code. People often think this is slow, but it's very fast, often faster than mutable code, except in very hot loops. The bit where you update the reference to the current state (change the reference from the old state to the new state) is a side effect, and is handled in different languages/frameworks in different ways. In some languages your code returns data that represents the state change (e.g. state monad) and the runtime handles the side effects, so you have no direct handle on the side effects. In other languages, there are stateful abstractions, like an "atom", that effectively separate the concept of a "value" from the concept of an "identity" (like the current state).

More generally, you separate side effects (including state) from the purely functional parts of the code. E.g. instead of writing a routine that prunes log files by date, you write a routine that reads dates (this is a side effect), one that reads the current time (also a side effect), and one that deletes files (also a side effect). Then you write a purely functional routine that takes a list of dates and returns a list of files to delete.

The overall goal is to get all your business logic into purely functional routines like this, because it hugely simplifies development, and reasoning about code. E.g. it's very easy write tests, because you don't have to mock anything. The code with side effects becomes extremely simple, so testing those becomes easier, too.

It's a huge topic, and I highly recommend looking for more info on youtube, and elsewhere.

Not sure what your concern is, but there are very many real-world examples to choose from. Look into any functional programming language for web server and database examples. A few specific ones that might be worth a look are the datomic database, the clojurescript "om" framework, the react "redux" state management framework, and more generally the notion of "single atom state".

The point is that there's nothing else like the M1 on the market. If you use linux but want M1 performance, porting is the only option.

Ok, so you've proven you don't know what the terms "institutionalized racism" and "affirmative action" mean. There is a wide body of literature about race in the US which will describe these terms, what they mean, and how they are measured. You can look them up and read them, so that the next time you comment on an article about race your ignorance will be less comprehensive.

But regarding your twenty years in Oklahoma and Texas, I grew up in that part of the country. There are a few possibilities. If you're a transplant, they may not use the n-word around you because in their minds you're still an outsider, even after twenty years. Or, maybe you're a person of color yourself, so you're an outsider. Or, in those twenty years you never left your house. Or, it's so normalized you no longer hear it. Or, you're lying.

In any case, while you can't avoid people who use the n-word in those parts of the country, they aren't a majority. That doesn't mean racism isn't common. For example, a multi-racial couple that I knew made the mistake of attending an all-white church, and their car was keyed during the service. Most of the congregation would never use the n-word, but they quietly looked away when this sort of thing happened, and they *certainly* didn't see anything, if asked. This is the predominant cultural attitude in large portions of the US, which you are willfully misrepresenting.

Nope. You're probably overlooking some key points, one being that California is very large, another being that the land in California is far more rich than the midwest. Having a lot of cultivated land doesn't mean much if that land is very marginal, producing low yields.

There's a widespread belief in IT that test code and UI are easier than other coding tasks.

It's completely false. Both are harder than other coding tasks. Your senior devs tell you to assign these projects to junior devs because they don't want to do them. They don't want to do them because they're much harder than other coding tasks.

It's win-win for the senior devs: they get easier work, and when the junior devs struggle, it makes the senior devs look even better. "oh, man, they can't even write a test suite. Well, I guess I should get the big bonus this year."

Put your best devs on test and UI. Put your junior devs on the simple stuff: backend work.

It's freaking horrible for US residents, as well. I just want to buy a service, I don't want to try to work through the calculus of how well the driver performed, how much I value it, how much the driver deserves, and how much social aggression I'll face if the driver thinks they've been shorted. I just need a ride. I don't need a passive-aggressive douche pressuring me to tip well on my way to the airport.

Completely disagree. I worked over a decade in the valley, and have now worked for several years in academia. The amount of bureaucratic nonsense I have to deal with now is a few orders of magnitude smaller than what went on in the corporate world. My first six months in academia were more productive than my last six years in the private sector.

Academia does not have the cash required to sustain a large bureaucracy. It's simply not there. Technologies that, in the corporate world, would be managed by a team of thirty people, in academia are managed by one person, because that's all they can afford. Things that took months, or years, now take hours, or days. It could not be more starkly different.

You have no idea what you are talking about.

I can't believe anyone is taking this seriously. Every valley company claims to hire only the best. It's marketing bs that upper management sells to themselves, and to gullible new hires. They've been doing this for decades.

Lisp programmers don't engage in "parenthesis counting". They read it by indent, like python, and the editor does the counting.

I'm working in both lisp and python at the moment, and it makes me dislike python more every day. Invariably, the allegedly readable, convenient syntax hurts more than it helps.

There's complexity that comes with the problem domain. Then there's "incidental" complexity that comes with your choice of tools. For example, languages without garbage collection have more incidental complexity than languages with garbage collection: without GC, you spend a lot of time manually solving the problem of managing memory resources.

OO introduces a lot of incidental complexity. That's the point. It's clear, since he mentions some function programming languages, that he believes FP introduces less incidental complexity. I think that's exactly right.

You're wrong about the alternatives. JVM based languages have the same libraries as java available, by definition. Check out clojure. A good place to start is the Rich Hickey videos on infoq.com.

Oh, man! I was just recently trying to remember the name of that column. Thank you!

Another relic in my head is the memory of a computer camp I attended at about that time (subject: lisp). Another camper had written a bunch of TRS-80 games with "klutz" themes. E.g. a version of "Asteroids" where, after hurtling toward your ship, the asteroids made a neat path around the ship, before continuing on their path. Or, a version of "Space Invaders" with a single alien that filled the whole screen. And so-forth. They were brilliant. Unfortunately, I didn't stay in touch with the author.

I've used TRS-DOS, DOSPLUS, and others.

What the hell is TRS-80 DOS?

Damn kids.