[reikonomusha]

Hello! Disclaimer: I haven’t read the full publication yet and I’ve only skimmed it.

A lot of programming languages that are coming out these days talk about simplicity, lowering “cognitive load”, increasing expressiveness, being nimble/lightweight/easy/whatever, and—this one stated by you—reducing “accidental complexity”. When I looked at your grammar and some examples, I saw atomic building blocks that don’t lead to any less complexity than what I’d get if I strung together similar building blocks in Lisp or Python or ML.

To me, “accidental complexity” doesn’t seem like a very well defined concept. I might say such a term in a meeting room arguing to upper management that we need to pay off tech debt. Or I might blog using such a term to talk vaguely philosophically about software engineering. But I don’t think I’d find myself using it in a formal context to argue the merits (or lack thereof) of a technology. I admit that this may be due to my ignorance of a term of art.

The introduction to your publication is even more bold: “Regularized programming” (and hence Bosque) will (supposedly) unleash a revolution on programming the same way structured programming did the paradigms before it, ushering a “golden age” of programming and the like.

Focusing on the term “accidental complexity”, can you elaborate what that means? What is an example of accidental complexity and how does it naturally come about with the current crop of languages. And how—in the large—does this programming language avoid it (or help the programmer avoid it)?

Edit: I see in your publication, upon the mention of “accidental”, you cite “Frederick P. Brooks, Jr. 1987. No Silver Bullet Essence and Accidents of Software Engineering. Computer 20 (1987), 10–19.” But in reading this [0], Brooks says:

> The complexity of software is an essential property, not an accidental one.

He only speaks of certain difficulties as being “accidental”, and past ways in which we’ve improved the impedance of such difficulties.

[0] http://www.cs.nott.ac.uk/~pszcah/G51ISS/Documents/NoSilverBu...

[mrkmarron]

I would say accidental complexity comes from mostly historical reasons. Two sources discussed in the report are reference equality and looping. These make a ton of sense if you are implementing a language with a compiler that targets an x86 processor. They map naturally to the features of the hardware but make other tasks impractical, e.g. compilation to a FPGA or verifying a SemVer dependency update doesn’t break your application.

Section 5 of the paper explores some scenarios that, once this “accidental complexity” has been removed, become much more feasible. These types of experiences are currently aspirational, and much work remains, but the hope is to demonstrate the practicality and value of these concepts.

[thechao]

This is the exact goal of the removal of “incidental algorithms”, as described in a number of papers/talks by Sean Parent, Mat Marcus, Jaakko Järvi, et al. They mostly explore this in the setting of GUI behavior implementation.

[azhenley]

I wish PL researchers would actually run studies to measure cognitive load and usability metrics while using their language compared to some other language.

I would do it if the right PhD student came along!

[awild]

I have never investigated this, but I feel that PL pragamtics and PL-feel is relatively under researched.

I talked about this with colleagues a few years back, but we had very distinctly different feelings about what we were doing when writing C vs C#: C often feels more like writing text that will be translated to code while C# already feels like you are manipulating code. It makes no sense when I write this out but that's phemenology for ya.

[vnorilo]

This is interesting. I "feel" this in Visual Studio, as the DE is more tightly I(ntegrated). Do you still feel like this in the context of a plugin-less plain editor?

[seanmcdirmid]

Running any study with real humans is very expensive. We can measure simple things empirically (eg reaction time), but trying to measure something such has “cognitive load” is probably impossible, and what is a usability metric? Do those already exist for PL or so they need to be invented somehow?

We (PL researchers) think about this a lot, but so far no one has come up with any good answers on how to empirically measure PL usability for an entire PL (vs chipping off small features to evaluate). At best, we can run qualitative studies with little in the way of rigor.

[jermaustin1]

> I would do it if the right PhD student came along!

Quit trying to lure unsuspecting CS grads into your van!

[coldtea]

>To me, “accidental complexity” doesn’t seem like a very well defined concept. I might say such a term in a meeting room arguing to upper management that we need to pay off tech debt. Or I might blog using such a term to talk vaguely philosophically about software engineering. But I don’t think I’d find myself using it in a formal context to argue the merits (or lack thereof) of a technology.

That sounds bizarro. Accidental complexity is pretty obvious to show in an example of a function or an application architecture or class.

It might be harder to define in abstract (except as e.g. "complexity not imposed inevitably by the functionality/problem domain"), but it's very easily observable in specific code examples.

[reikonomusha]

Can you show me some examples? I understand complexity, I also understand incidental complexity, but I’m not sure about it being accidental.

[willtim]

Google the "Out of the Tar Pit" paper by Moseley and Marks. After incidental complexity, Accidental complexity is the all remaining stuff. It's the complexity you wouldn't have to deal with in an ideal perfect world. For example: manual memory management, performance optimisations, JavaScript equality semantics, aspect-oriented programming, dependency injection frameworks or any other ad-hoc technology to work around issues further down in the stack.