The problem with software trade schools, even though you may not require a pure maths focus, I still expect people who program professionally to be good at maths. I would expect most programmers to analyse algorithms in a formal manner if they have to. And the people capable of doing maths at that level are not the people that traditionally go to trade schools.

To make something fast or to make something scale you don't need a proof. You need a profiler.

To a certain degree, this is true. However, a profiler won't turn the DFT into the FFT.

The FFT only needs to be invented and optimized once, though, then everyone else can just link in libfftw or kissfft.

All those software tradespeople can do the jobs that require connecting pieces together. A tradesperson can be taught enough to know which algorithms to apply in which situations.

Computer scientists become academics inventing new algorithms, and analyzing and perfecting the ad hoc algorithms created by software tradespeople.

Aside: I wish the English language would just decide that "man" and "men", when used as part of a compound word like "tradesman", is gender neutral.

> The FFT only needs to be invented and optimized once, though, then everyone else can just link in libfftw or kissfft.

> All those software tradespeople can do the jobs that require connecting pieces together. A tradesperson can be taught enough to know which algorithms to apply in which situations.

Is that a circular argument? If we had enough people cranking out smart enough algorithms (like the automatic programming example upthread), would we need so many tradespeople?

A profiler is for micro optimisations. A profiler won't let you go from bubble to quick sort for example.

A profiler will tell you if sorting actually using a meaningful amount time in your application.

If you go ahead and blindly change your bubble sorts for quick sorts then at best you may be wasting time doing something that has no effect on performance, and at worst you may be making your program slower.

Quicksort is slower than bubble sort for nearly sorted input after all.

It does give you information on where the most time is being spent, but it doesn't tell you what to implement. Without adequate algorithm knowledge you might try a micro optimisation when it really needs a completely different algorithm.

With superficial knowledge you might stick to certain rules without really understanding them. That bubble sort example you gave is a perfect example.

You are operating under the assumption that the performance of an average piece of software is algorithmically limited, this is almost never the case. In average software the core performance characteristics are typically bound by far simpler issues, such as excessive database queries.

A profiler is not good at speed up an algorithm, but a profiler is THE tool you need to speed up a system, and most optimization in the wild is system optimization, not algorithm optimization.

This particular example is a perfect case study in how excessive focus on computer science can lead you astray in software engineering.

In my view, all performance optimisations need to be driven by hard data and a profiler is just one source of this kind of data.

Maybe not, but Google will:)

I know almost no programmers who analyst algorithms in a formal manner.

Most coding doesn't require it - certainly not the kind of thing that most large companies want coders for.

N.2 on your list does already exist in the real world, albeit as a graduate program. CMU offers Software Engineering (with very minimal CS involved) at both the main and SV campuses, perhaps even at others as well.