My talk "Functional Programming: Failed Successfully" is now available!

atravers · June 25, 2024, 7:10am

Software engineering is not math, and it will never be.

Neither is civil or electrical engineering! But they very much rely on mathematics, and that is where software engineering will also have to go.

The industry generally doesn’t care about math and correctness as Haskellers do.

Hence the maxim “try rebooting the system”. Now just imagine if we had to “reboot” all our bridges, tunnels, apartment and office blocks, entire cities, energy grids, et al…

Hoping for the industry to suddenly start caring what Haskellers care about is wishful thinking.

Is it just Haskellers? I would have most Prologgers and and other declarative-language users also care. But just like Haskellers, most of them also realise that it “won’t happen overnight” - just like the transition humans made from building with mud and grass to stone and wood.

History shows that the industry is not interested in pure functional/mathematical utopia. This will not change […]

This aforementioned reference:

The [[pure]] attribute, JTC1.22.32 Programming Language Evolution Working Group

having (apparently) stalled since 2015 certainly attests to that! So “what’s the problem?”

(page 11-12 of 17)

7.2 Drawbacks

7.2.1 I/O and side effects restrictions¹⁰

As useful as pure functions seem to be, they also bring us some trouble. The most problematic drawbacks are in fact what makes pure functions useful in the first place. Without the ability to cause side effects, pure functions cannot read a file or prompt the user for an input which is sometimes quite useful. […]

7.2.2 Debugging¹¹

GCC has the ability to warn you about which functions are viable candidates for either pure or const attribute qualifying. This is mainly done through code optimization analysis. However, such analysis frequently misses pure functions [11]. This is the reason why it is up to the programmer to qualify the function or not. Imagine that we falsely qualify an impure function as pure. […]
In reality, this will probably result in an incoherent program execution which should be troublesome to debug: “… using this attribute incorrectly can lead to a nearly impossible to locate bug as actually seeing the redundant use of the function removed by the compiler requires looking at the assembly! Oh, and this type of bug will rarely show in a debug build since only highly optimized builds will have the bug.” [28].

…is that all? Interesting:

it isn’t just pure functions which have a problem with I/O:

(page 2 of 8)

Blue is a pure object-oriented language [2] with very clean syntax, a strong and statically checked type system and support for inheritance and genericity. However, it is not the Blue language which provides the support for delaying the use of I/O, but rather the environment.

[…] which allows the interactive creation of objects of any class and calling of the methods of these objects. It is this testing facility which allows the delay in teaching I/O.

I/O Considered Harmful (At Least for the First Few Weeks)
and as for trying to determine when some I/O actions can be used purely:

Using unsafePerformIO safely?

So it’s fortunate for us that Haskell already has such functions (having no visible side effects) by default: otherwise we would probably be still deciding whether or not to include them!

[…] it’s Haskellers who need to learn what software engineering is, not vice versa.

Apart from (maybe?) a few “Haskell natives” (Haskell ver. 1.0 being released in 1990), the majority of us already know what that so-called “software engineering” looks like. And presumably so did John Backus back in 1978…

But all this talk about pragmatism (or the lack thereof) has has me wondering about something for a little while now:

does anyone here remember:
- a physicist,
- a chemist,
- an astronomer,
- or other scientist,
- or an applied mathematician,
…asking a pure mathematician to be (more) pragmatic?
if so, what was the response by the pure mathematician?