No single programming language, or programming paradigm, is the best choice for solving all problems. There's a reason most operating systems and device drivers are written in C, despite fifty years of null pointer and buffer overflow errors.

"Side-effect free" and "functional programming" are different concepts, and one does not imply the other. Many LISP dialects allow side-effects like setting a value in an array. And many languages with an imperative core allow programming in a functional style, taking Kotlin and Ruby as just two examples.

Furthermore, "no side effects" isn't actually what I want in a programming language. If it doesn't have any side effects, why am I running the code? Data needs to be saved, logs need to be written, remote APIs need to be called, payments need to be debited and credited, emails need to be sent. I don't want a programming language that makes it difficult to produce a side effect, I want a programming language that makes it easy to reason about all the side effects my program produces. Functional languages may or may not do a good job of that, just as some imperative languages are better or worse at that.

The solutions to the author's problem of "increasing complexity, longer product-development times, and greater fragility of production systems" are to separate components (e.g. via microservices) so that it's easy to reason about, test, deploy, and fix failures in an individual piece of the overall system. Given the choice of a million lines of C++ code split into 200 independent services or a million lines of Haskell in a monolithic binary I'll take the -crab juice- C++ any day.

> While natural gas may be cheaper, nuclear power hasn't been given credit for its carbon-free contribution to the grid and that has caused nuclear plants to struggle financially, Griffith added

A great way to address this would be to put a price on carbon emissions as proposed in the Economists' Statement (https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Feconstatement.org%2F) or the Energy Innovation and Carbon Dividends Act (https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fenergyinnovationact.org%2F). Nuclear, renewables, and fossil fuels could then compete on a more level playing field.

Rewind 20 years ago before there were music streaming services. It was still pretty hard for new recorded music to be successful. Is a "Classic Rock" station going to play an edgy new song? No, they're going to play Stairway To Heaven again, because everyone in their demographic loves that song, so they can sell ads targeting that demographic. There were radio stations focused on new music, but the dominant format was "Top 40," which still made it hard for a new artist to get noticed unless they could create a really big hit.

I would be amazed if new releases were getting anywhere close to a majority of plays. Wake Up Little Susie, Jailhouse Rock, and Johnny B. Goode are all 65 years old, but they're still great songs. Every new year of recorded music has even more recorded music to compete with for attention. Pick any year since 1973; Dark Side of the Moon outsold 99% of new albums released that year. 20 years ago there wasn't an effective way to measure total play count for a song, but I'll bet that most people played more old music on their CD/tape/record players than they played new music, because they still had all their old albums on the shelf, but only bought a few new albums per year.

A German company will be operating the data center, but Microsoft will still be writing and presumably operating the software.
Or are they making an Office 365 install like running Apache and any ol' ISP can run a copy?

In a world where any computer can talk to any other computer, the physical location of the small bits of wire and magnets holding your data isn't the most important thing to worry about.

I routinely launch computing jobs on thousands of Von Neumann machines.

A primary goal of any sort of cloud storage is high availability: when your own system is unavailable, you want to be pretty certain that you can get the cloud copy.

How many copies of your file would you need to store on random people's hard drives to feel confident that in three years (when you spill beer on your computer) all of those hard drives are still functional, haven't erased your data, and are connected to a computer which is connected to the Internet?

With enough copies of your data floating around, you can probably recover it. But would the cost of renting that many people's disks be reasonable, compared to backing it up to two or three cloud providers?

Excellent!
Anyone know when Fry's will accept these Emperor Norton bills I have?

Excellent!
Anyone know when Fry's will start accept these Emperor Norton bills I have?

Bitcoin by itself has no intrinsic value. It only has value because people decide it should.
Money is just shorthand for people doing stuff.
Without people, there's no economy. Money is just a useful fiction.

Step 0: Have a friend do a mock interview with you.
Tell your friend to pick a question like the ones you've been getting.
Solve it on a whiteboard.
In addition to getting some scenario practice, your friend can point out if you're coming across in an awkward way.

Step 1: Listen
Listening is more important than talking in good communication.
I interview a lot of software engineers. Sometimes candidates get so excited about an idea they have that I can't get a word in edge ways to point out they missed a requirement or to suggest there's an easier solution. They may leave the interview saying "I cranked out some great sorting code," but in my notes is written "Implemented bubble sort."
Before diving in to code, verify that the interviewer wants you to implement something. If they say "How would you sort the data," you might not need to implement a sort algorithm.

Step 2: Think Out Loud
If a solution to a problem occurs to you, say it so the interviewer knows where you are.
If they ask questions about your thought, follow their line.
If they just acknowledge what you said, analyze it for a minute and see if it's a good solution, or if there are interesting caveats.

You can learn a lot from Mozart because you can read all the notes he published.
You can listen to many interpretations of his works by different people.
We don't have the chance to read through 25-year-old Mac symphonies^W programs.
We aren't even writing for the same instruments.

Or they could, y'know, plant several varieties of orange trees to hedge against a narrow epidemic. Like, say, a parasite that his spinach really hard...

Because I'm trapped in an output monad. Or stuck in an infinite loop.

Gah! One of my other favorite professors from the University of Colorado is named Jim Martin. You had me very worried for a moment.

[previous post was accidentally anonymous]

I started CU at the tail end of Evi's career when she was, as she put it, "on sabbatical buying a boat." In five years in the classroom, I only got to hear one guest lecture from her. Yet through the passing interactions and from the smiles of respect every student gave her, I could tell Evi was a great person.

I remember an open meeting about improving things in the CS department. At one point, we decided to have a students-only brainstorming session for a while. "All the professors leave and come back in fifteen minutes. Except Evi, she can stay." That's the sign of someone with a lot of social capital.

Here's hoping a decade of sailing has taught Evi enough to get out of this jam. She's certainly taught many of us how to keep afloat in the cyber seas.