Experience tells us that it’s the boring menial jobs that get automated first.

Most “boring menial” jobs are still around. There are still clerks, truck drivers, etc.

If you find yourself doing copy and paste programming, watch out: your buddy computer can do it too. The work on generating UI has already started, see for instance, pix2code.

GUI generators have been around for decades.

So I’m sorry to say that, but those programmers who specialize in HTML and JavaScript will have to retrain themselves.

I’m guessing he’s never done HTML or JavaScript.

You might think that programmers are expensive–the salaries of programmers are quite respectable in comparison to other industries. But if this were true, a lot more effort would go into improving programmers’ productivity, in particular in creating better tools.

A lot of effort does go into creating better tools.

I’m sorry to say that, but C and C++ programmers will have to go. These are the languages whose only raison d’être is to squeeze maximum performance from hardware. We’ll probably always be interested in performance, but there are other ways of improving it. We are familiar with optimizing compilers that virtually eliminated the job of an assembly language programmer. They use optimizers that are based on algorithmic principles–that is methods which are understandable to humans. But there is a whole new generation of AI waiting in the aisles, which can be trained to optimize code written in higher level languages.

Imagine a system, which would take this definition of quicksort written in Haskell:

That “quicksort” is notoriously inefficient. I guess our Magic AI Smart Compiler will somehow make it faster than C, but then why wouldn’t the MASC make the C even better?

(And for that matter, why use quicksort at all? Just say sort(list), done.)

[Explanation of quicksort] You can’t get any simpler than that.

Nonsense. I can get much simpler than that:

Sort(list) ≜ ε x Permutations(list):
∀i, j ∈ 1..Len(list): i ≤ j ⇒ x[i] ≤ x[j]

That’s the formal definition of a sort. I didn’t even need to specify the algorithm! Now the MASC can use quicksort, mergesort, radix sort, whatever’s most efficient!

This is what a human optimizer would do. But how much harder is this task than, say, playing a game of go against a grandmaster?

Much?

I can’t help but see parallels with Ancient Greece. The Ancient Greeks made tremendous breakthroughs in philosophy and mathematics–just think about Plato, Socrates, Euclid, or Pythagoras–but they had no technology to speak of. Hero of Alexandria invented a steam engine, but it was never put to work.

They had tons of technology! They made major advances in mechanics, metallurgy, architecture, city planning, medicine… technology doesn’t start with the steam engine.

As long as the dumb AI is unable to guess our wishes, there will be a need to specify them using a precise language. We already have such language, it’s called math. The advantage of math is that it was invented for humans, not for machines. It solves the basic problem of formalizing our thought process, so it can be reliably transmitted and verified.

Modern math is utterly inadequate to express most of our requirements. Try to formally express the requirement “this sort function should be parallelizable and minimize memory use for the average case”.

The definition of quicksort in Haskell is very mathematical. It can be easily verified using induction, because it’s recursive, and it operates on a recursive data structure: a list.

Again, his version of sorting was much more low-level than “math”, because he actually wrote an implementation of sorting and did not specify what sorting actually is.

In mathematics, a monad is defined as a monoid in the category of endofunctors.

The recursive function tells us a linear, one-dimensional, story. It appeals to our story-telling ability. The [11 line] functor-driven approach appeals to our visual cortex. There is an up and down, and left and right in the tree. Not only that, we can think of the algorithm in terms of movement, or animation. We are first “growing” the tree from the seed and then “traversing” it to gather the fruit from the branches. These are some powerful metaphors.

What? Those metaphors aren’t mathematical at all and don’t give us the precise understanding that he spent the blog post arguing for.

I’m often asked by programmers: How is learning category theory going to help me in my everyday programming? […] Category theory is the insurance policy against the drying out of your current watering hole.

There is more to math than category theory.

Programmers think category theory is way more important to math than it actually is. All of the mathematicians I’ve talked to think it’s a useful tool that has a lot of applicability in some domains, but they’re not nearly as zealous about it as programmers are. There’s lots of other important math, too. Like probability! I bet that for 95% of programmers out there probability will be more directly useful to know than category theory would be.

In mathematics, a monad is defined as a monoid in the category of endofunctors.

For the record, this definition comes from A Brief, Incomplete, and Mostly Wrong History of Programming Languages, which was written to make fun of Haskell. It’s not a great argument for how clear and precise mathematics is.

Actually, it comes from Categories for the Working Mathematician by Saunders Mac Lane, published in 1971.

I think what many people miss is that programming is a new type of math. Algorithms have existed for thousands of years, we just had a terrible way of defining them until now. People are creating new mathematical objects every day when they program, they just don’t realize it.

In other words, mathematicians and programmers play in a mental world of their own making. What the software world lacks, and mathematics is really good at, is a social system to gather all the good ideas and teach them. Instead, in the software world, we have people bumbling about reinventing the same ideas over and over again.

I agree with most of what you wrote, but not with everything:

Modern math is utterly inadequate to express most of our requirements. Try to formally express the requirement “this sort function should be parallelizable and minimize memory use for the average case”.

That’s just because ‘parallelizable’ and ‘memory usage’ and ‘average case’ are not formally defined.

For the record, this definition comes from A Brief, Incomplete, and Mostly Wrong History of Programming Languages, which was written to make fun of Haskell. It’s not a great argument for how clear and precise mathematics is.

“A monoid in the category of endofunctors” is as clear and precise as statements come, mathematically speaking. It’s not clear for most people because most people (including me) are not familiar with monoids, categories, and endofunctors.

I’m not sure I’ve ever seen someone write up an architecture or design doc where category theory was the linchpin. Calculus? Sure. Statistics? Almost every time.

I’m a bit baffled by this article, I’m not sure I understand who’s big rant against Haskell is it’s not future-proof enough? Most folks rail against Haskell as being not current-proof enough.

Quicksort is an in-place algorithm. Until GHC can optimize all the heap allocations away, I refuse to acknowledge this three-liner as “quicksort”. Even if GHC could do it, it would be a stretch.

Let’s face it, for all we know tomorrow’s most recession proof profession maybe Martian habitat window cleaner, because no matter how smart we make the window cleaning robots, they keep being blown over by the wind, and it’s just cheaper to pay a guy a few bucks to do it.

While we may have an inkling to what professions will die out, we really do not know what new jobs will be created, because that depends on what new technologies will be invented and take off, which is very hard to predict. There are tons of routine tasks that are hard to automate because in the end the worker needs to make judgement calls and we’d rather have a human doing it.

The author seems to have barely enough knowledge of programming and IT to be able to name-drop stuff, that’s about it.

So much nonsense that I’d expect it to come from someone completely outside the field but I guess knowing the world “quicksort” doesn’t make you an expert either.

The author is well known in the Haskell/functional programming community, most of all for his ability to explain category theory concepts clearly to beginners.

But compared to Fong or Spivak, he is not a very good teacher, in my opinion. I have watched the recent “Programming with Categories” series with interest, and been consistently disappointed in both his reliance on Haskell’s semantics to justify mathematical concepts. I’m not a fan of his book either; I’d recommend Spivak’s book instead.

Isn’t a functional strongly typed program easier to generate? A lot of constraints are encoded in the types for a program generator to exploit. This isn’t the case with fluffy “could you move that button two pixels up?” kind of front-end development the author dismissed as automatizable.

Wow this is a bad take.

Most “boring menial” jobs are still around. There are still clerks, truck drivers, etc.

GUI generators have been around for decades.

I’m guessing he’s never done HTML or JavaScript.

A lot of effort

doesgo into creating better tools.I, too, believe that AIs are actual magic.

(This argument is so played out that Sufficiently Smart Compiler was an injoke… on the C2 wiki.)

That “quicksort” is notoriously inefficient. I guess our Magic AI Smart Compiler will somehow make it faster than C, but then why wouldn’t the MASC make the C

even better?(And for that matter, why use quicksort at all? Just say

`sort(list)`

, done.)Nonsense. I can get

muchsimpler than that:That’s the formal definition of a sort. I didn’t even need to specify the algorithm! Now the MASC can use quicksort, mergesort, radix sort, whatever’s most efficient!

Much?

They had tons of technology! They made major advances in mechanics, metallurgy, architecture, city planning, medicine… technology doesn’t start with the steam engine.

Modern math is utterly inadequate to express most of our requirements. Try to formally express the requirement “this sort function should be parallelizable and minimize memory use for the average case”.

Again, his version of sorting was much more low-level than “math”, because he actually wrote an implementation of sorting and did not specify what sorting actually

is.For the record, this definition comes from A Brief, Incomplete, and Mostly Wrong History of Programming Languages, which was written to

make fun ofHaskell. It’s not a great argument for how clear and precise mathematics is.What? Those metaphors aren’t mathematical at all and don’t give us the precise understanding that he spent the blog post arguing for.

There is more to math than category theory.Programmers think category theory is

waymore important to math than it actually is. All of the mathematicians I’ve talked to think it’s a useful tool that has a lot of applicability in some domains, but they’re not nearly as zealous about it as programmers are. There’s lots of other important math, too. Like probability! I bet that for 95% of programmers out there probability will be moredirectly usefulto know than category theory would be.Actually, it comes from

Categories for the Working Mathematicianby Saunders Mac Lane, published in 1971.It’s still mostly known from the satirical essay (well worth reading by the way: http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html).

My personal take is that if someone is using that quote they’re being ironic.

I think what many people miss is that programming is a new type of math. Algorithms have existed for thousands of years, we just had a terrible way of defining them until now. People are creating new mathematical objects every day when they program, they just don’t realize it.

In other words, mathematicians and programmers play in a mental world of their own making. What the software world lacks, and mathematics is really good at, is a social system to gather all the good ideas and teach them. Instead, in the software world, we have people bumbling about reinventing the same ideas over and over again.

I agree with most of what you wrote, but not with everything:

That’s just because ‘parallelizable’ and ‘memory usage’ and ‘average case’ are not formally defined.

“A monoid in the category of endofunctors” is as clear and precise as statements come, mathematically speaking. It’s not clear for most people because most people (including me) are not familiar with monoids, categories, and endofunctors.

I’m not sure I’ve ever seen someone write up an architecture or design doc where category theory was the linchpin. Calculus? Sure. Statistics? Almost every time.

I’m a bit baffled by this article, I’m not sure I understand who’s big rant against Haskell is it’s not future-proof enough? Most folks rail against Haskell as being not current-proof enough.

Quicksort is an

in-placealgorithm. Until GHC can optimize all the heap allocations away, I refuse to acknowledge this three-liner as “quicksort”. Even if GHC could do it, it would be a stretch.Let’s face it, for all we know tomorrow’s most recession proof profession maybe Martian habitat window cleaner, because no matter how smart we make the window cleaning robots, they keep being blown over by the wind, and it’s just cheaper to pay a guy a few bucks to do it.

While we may have an inkling to what professions will die out, we really do not know what new jobs will be created, because that depends on what new technologies will be invented and take off, which is very hard to predict. There are tons of routine tasks that are hard to automate because in the end the worker needs to make judgement calls and we’d rather have a human doing it.

The author seems to have barely enough knowledge of programming and IT to be able to name-drop stuff, that’s about it.

So much nonsense that I’d expect it to come from someone completely outside the field but I guess knowing the world “quicksort” doesn’t make you an expert either.

The author is well known in the Haskell/functional programming community, most of all for his ability to explain category theory concepts clearly to beginners.

That doesn’t say much for the Haskell/functional programming community, then.

But compared to Fong or Spivak, he is not a very good teacher, in my opinion. I have watched the recent “Programming with Categories” series with interest, and been consistently disappointed in both his reliance on Haskell’s semantics to justify mathematical concepts. I’m not a fan of his book either; I’d recommend Spivak’s book instead.

If by “barely enough knowledge of IT” you mean, he’s not running an AD, a mail server, or maybe does not know how DNS works, he most likely does not.

But programming? That is something he does know. He does most of it with Haskell, which at least implies a certain level of dexterity.

Software Engineering? Maybe not, but to answer that, you’d have to have worked with him on a big software project.

Isn’t a functional strongly typed program easier to generate? A lot of constraints are encoded in the types for a program generator to exploit. This isn’t the case with fluffy “could you move that button two pixels up?” kind of front-end development the author dismissed as automatizable.