Bosque Programming Language

Re:Bosque Programming Language by coldtea on Wednesday April 17, 2019 @06:46AM (#19681363)

>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.

[ Parent | on HN ]

Re:Bosque Programming Language by reikonomusha on Wednesday April 17, 2019 @10:37AM (#19682931)

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

[ Parent | on HN ]

Re:Bosque Programming Language by willtim on Wednesday April 17, 2019 @12:40PM (#19684124)

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.

[ Parent | on HN ]