[nightski]

He is definitely right about the social aspect of software engineering. But I think he sells a lot of the tools short. For example, he brings up things like Monads, Lambda Calculus, and whatnot - but then immediately dismisses them as not affecting what one truly does.

But I think this really misses the point. In our industry it is really easy to disguise oneself as a professional (or even just someone who knows what they are doing), without really knowing much of anything. Meaning, our focus as an industry has been on making the simple things as simple as possible (i.e. scripting/dynamic languages, code generation, frameworks).

But what I see happening in the Haskell space for example (and even further in languages such as Agda) are attempts to distill things down to their elements. To find the true semantics behind a problem. This not only helps by producing cleaner and more readable code, but it also helps with communication.

I really do believe software is a scientific (and mathematical) exercise. The problem is most of industry does not treat it as such, and hence we end up in the mess we are in.

[rprospero]

While I love what Haskell has done for me as a programmer, I don't think that it's finding the true semantics behind our problems. I rather think that it's finding a different basis. To take an analogy, monads and lambda calculus are like Fourier series. For many classes of problems, they produce a cleaner, simpler understanding of the solution. I'd hate to try and solve a boundary value problem with just Taylor series. However, while expressing linear functions with Fourier series is possible, it's less clear than the Taylor series and you're more likely to mess it up.

In the same way, monads, arrows, and recursion are great ways of describing many classes of programs. Additionally, they help with communication when your problem is a monad or an arrow. However, certain classes of problems are better described under other paradigms than being forced into the functional one.

This comes back to Carmack's point. It's important to know Haskell, since it's distilled computation down to a set of elements which are useful for describing a large class of problems. Being able to communicate these solutions is important. However, other paradigms are less error prone and do communicate solutions more clearly on other classes of problems.

[nightski]

I agree, but do not boil down Haskell to Monads. The most interesting abstractions are the ones you write. The only contribution Haskell has here is a flexible type system. It does not give you anything for free per se.

Rather, what I am saying is I see a trend in the Haskell community where the developers strive to find the best semantics for a problem and not just stop at the first arrived at solution because it works.

See all the conversations on pipes vs. conduit if you want an example.

[ky3]

> But what I see happening in the Haskell space for example (and even further in languages such as Agda) are attempts to distill things down to their elements. To find the true semantics behind a problem. ... I really do believe software is a scientific (and mathematical) exercise. The problem is most of industry does not treat it as such, and hence we end up in the mess we are in.

These statements suggest a view of science and math I find particularly insidious -- please correct me if that's not your view.

It's the view that software engineering should really be computational physics. All we need to do is figure out the laws, set up the equations for a specific problem, pick the best algorithms for the job, and hit Enter.

It's not unlike how the ultimate watchmaker created the universe. And best of all, there's no "monkey programming" (how I hate that term) in computational physics.

Truly romantic, and hey, I think I've just persuaded myself it's not so insidious after all!

[freyrs3]

He does seem to have a mental block on Haskell being too "mathematical or abstract" which is something I see a lot of in imperative programmers and am not sure I fully understand.

> I would like to be able to enable even more restric­tive sub­sets of lan­guages and restrict pro­gram­mers even more because we make mis­takes con­stantly.

Which I think is perfectly in line with the rigid Haskell type system and philosophy of "making the compiler do 90% of the work". The constructs that Haskell provides are very down to earth ways of composing programs that ensure that side-effects aren't implicit and lead to more correct composition semantics.