Wednesday, June 18, 2014

Obsession with mathematics

To put it bluntly, the discipline of programming languages has yet to get over its childish passion for mathematics and for purely theoretical and often highly ideological speculation, at the expense of historical research and collaboration with the other social sciences. PL researchers are all too often preoccupied with petty mathematical problems of interest only to themselves. This obsession with mathematics is an easy way of acquiring the appearance of scientificity without having to answer the far more complex questions posed by the world we live in.
I've replaced "economics" with "programming languages" in this quote from Phil Greenspun's blog. Seems appropriate, no?

9 comments:

Shrutarshi Basu said...

I'm actually in two minds about this. I can appreciate mathematical purity for it's own sake and I think there's something to be said for spending lots of time getting things right(ish) and then transplanting that into the real world. Anything related to Haskell comes to mind. At the same time, I do think that people with a solid understanding of PL (not necessarily PL researchers) do need to get out more. If we're ever going to rid ourselves of scourges like JavaScript and Node.js, we need people well versed into in the theoretical details of PLs to be out there building production languages, compilers and runtimes. Unfortunately, a lot of that is grunt hacking, dealing with platform inconsistencies, and building boring but essential standard libraries. Maybe if we required PL PhD students to do a "tour of duty" in some industry setting?

John Shutt said...

The quote will work, at least to some extent, with pretty much any preparadigm field in the modern context. Iirc, Kuhn's Structure of Scientific Revolutions talks about how researchers in a preparadigm field spent much of their time squabbling over foundational questions about their field and seeking the prestige of a paradigm field. Then when the field actually settles on a paradigm, the foundational questions no longer command attention and the characteristics of a paradigm field emerge without being forced. Myself, I reckon we're not ready to synthesize ourselves a paradigm because we don't really know what the foundational questions are yet.

Daniel Yokomizo said...

Most other disciplines (e.g. economics, physics) existed before mathematical formalism so, in a sense, when we see them overusing math is a way to gain legitimacy. This is very common in macroeconomics where they try to use math to describe equations that have no relation to our observations.

OTOH computer science came from mathematics and only later became something separate from it. Historically PLs began outside the hard mathematical side of CS (but even then we used some math to understand them) and "evolved" as an entirely programming discipline (which still is not entirely understood as a separate discipline from math and engineering by many), but that was by necessity not (necessarily) by intention. We lacked the tools to understand what we wanted from PL design.

dmbarbour said...

It's amusing that Wolfram language - which grew up from Mathematica - is one of the more worldly.

Harrison Ainsworth said...

If you look at code, most of the structure is not algorithmic, it is not anything very logical. It is about names and groupings and such -- *psychological* things -- it is really a kind of formalised documentation.

It is like Sraffa gesturing to Wittgenstein: all that white-space formatting, what is the logical structure of that? (http://en.wikipedia.org/wiki/Piero_Sraffa#Personal_connections)

Arcane Sentiment said...

ISTM engineering fields generally aren't paradigm-based. They have lots of heuristics, and some local paradigms for parts of the practice, but there's no central idea on which the entire field is built. Physics and chemistry and biology have paradigms because the phenomena they study have such consistent patterns (and the boundaries between fields are to some extent defined by those paradigms), but the engineering fields that manipulate them have no such consistent content, so they can't have powerful paradigms.

Programming might be different, because its tools and artifacts are mathematical and thus could be made consistent enough for a paradigm to have wide applicability. Paradigm-seeking in PLT could be charitably interpreted as advocating this rather than claiming to describe all possible ways of programming.

John Shutt said...

I think the use of the term "paradigm" to describe different styles of programming is mostly an attempt to acquire unearned prestige, together with delusions of grandeur — imagining the prestige is actually deserved. The usage may have started innocently enough, as a simple and reasonable application of a trendy term, but the ulterior motives seem rather ascendant now. I'm not at all sure a paradigm for computer science, in the Kuhnian sense, would be a mere style of programming; that may be much too superficial. We may not even be asking the right questions yet.

I'm dubious of the suggestion that engineering fields aren't paradigm, in the Kuhnian sense. I rather think they're all paradigm fields, advancing by what Kuhn calls "normal research".

Arcane Sentiment said...

The type theory movement, at least, are trying to make a Kuhnian paradigm, not just a programming style: they want to explain all possible languages (and all possible semantic properties!) in terms of type. This is why they say things like “dynamic typing is just a special case of static typing” — because that defends the universality of the model. Similarly, the von-Neumann-machine tradition explains (and implements!) all possible languages and behaviors in terms of mutable memory. (And Lispers explain everything in terms of objects and functions.)

Advocates of each model tend to prefer programming styles that are closer to their model (because they look simpler, and because their model contains the features they consider important), but many accept a wide variety of styles. What makes them paradigm-seeking is that they aim to explain everything, not just their own styles and tools.

patrickdlogan said...

How JavaScript came to be, and came to be widely adopted, now including nodejs, is one of the most complex, interesting, paradigmatic, and tragic stories of this young industry. And that is a story that has essentially nothing to do with math or science.