Hacker News Reader

> One reason is that most computer scientists actually lack the experience of having worked in large software companies and don't actually know a lot about how that works. It's something I realized while doing my Ph. D. in this area and I fixed it by leaving academia. I learned a lot since then

This was me exactly. I started a Ph. D. simultaneously with two other students and our supervisor had us working on separate aspects of a common overall problem, each of which required a lot of software development, in C, because we were chasing performance. The supervisor had an academic background and all of us had only just graduated. Needless to say this was a total disaster and we never even managed to complete our separate parts let alone integrate a usable system. I bailed out and got an M.Phil for my efforts, but on the basis of the experience managed to get the job that I wanted, so it wasn't a complete write-off.

As soon as I encountered some actual software engineers in a well structured research department, I realised how bad our approach in Uni had been. My job involved a similar problem area, and using better tools (Common Lisp on a Lisp machine) I managed to build in about six months what I had failed to do in three+ years in academia.

My thoughts on the feudal nature of the Ph.D system at my Uni are a whole separate post!

I would enjoy a summary of that separate post!

> But you don't need to know much about that to use a language.

On the other hand, without the formal underpinning there is an enormous risk you assume your intuitions are correct about stuff where it turns out there's just unyielding mathematics (or occasionally physics) that disagrees. The formal instruction would either outright tell you about that or at least give you the right lenses to see for yourself.

For example it's not at all rare to see programmers who think about floating point as just the Real Numbers, because they superficially resemble real numbers you've seen - but it's not, it's the modulo integers again but wearing a trench coat. Formally it's obvious we're not getting the Real Numbers, Almost All of which aren't even computable. But without that formal underpinning people have nasty surprises.

People's intuitions about concurrency and parallelism are all wrong too. Amdahl's law matches reality but doesn't match how people intuitively expect this to work out. The insight that makes Rust and several modern languages work (that you can't incur a data race if you don't have multiple references and mutation) is not at all intuitive.

It's a theoretical risk; you mitigate it by just having smart people that have a good analytical mindset that can learn. As it turns out, the most important thing you learn in university is the ability to acquire new skills; not any particular skills. That ability is not unique to computer science.

Another thing is that languages and tools that require a lot of formal background are a hard sell in industry because it means having to hire more scarce and expensive people. It's a reason that functional programming was a hard sell for a long time until languages got good enough that normal people could figure it out. Scala was an early example that did not quite get that right maybe. Too difficult for people without a CS degree and a good understanding of type systems. Indeed the whole language became a bit of a playground for type system nerds. It got a bad reputation for being hard and a bit over engineered.

Javascript and python, both of which now have some level of functional programming support, are much easier to pick up by other people. Which is why those languages are so popular. Any high school kid can work with this. I currently have a couple of summer interns in my team. These two languages are what they know.

> and don't actually know a lot about how that works. It's something I realized while doing my Ph. D. in this area and I fixed it by leaving academia. I learned a lot since then.

Well said.