IMO, you can have both. It’s not either/or. You need the complexity of full solutions, you just don’t want to ingest all of the complexity in one big gulp. UNIX’ hierarchical file systems overcame the complexity issues of DOS’ flat file system. Lisp overcame the complexity issues of very long lists (lists are defined recursively). Hardware people learned early on that PIC - relative addressing - was a better way to express branching. Much of what we see in modern PLs inhibits layering, eg. inheritance with method overriding, functions that name other functions, etc., etc.

There was an alan kay quote something along the lines of “simplicity” can arise from slightly more sophisticated building blocks.

I see a lot of replies to this article advocating for absolute simplicity - simpler building blocks, and less code etc.

But we don’t have many great examples of good building blocks in mainstream application development. Designing good building blocks is very hard, so many people reject them all together.

I think this is a marketing issue, better building blocks obviously exist given the examples Paul gave.

But FoC projects need to effectively show how your new building blocks are 1 - simple to understand, implement & use, & 2 - implications on existing hard problems and how classes of complexity just disappear from the POV of the new building blocks.

Most people just see a structural editor and think “that must be super complex” and don’t see the beautiful simple underlying abstraction & implications on simpler plugin development & tooling.

The idea of snapping building blocks together is easier when only one simple type is used.

LEGO == “round peg” into “round hole”.

The UNIX idea of a simple inter-command type - characters delimited by newlines - is already too complicated (!). Workarounds to handle binary data instead of 7-bit ASCII bytes were invented, and, then, came Unicode.

It is possible to build up more complex types using layers of types.

Types in networks are layered this way. Types in PLs are not layered in the same manner. IMO, the concepts espoused in something like the OSI 7-layer model need to be applied to programming.

My feeling at this time, is that a software Message for coupling software components is (1) a Tag and (2) Data. One can complexify on the way up and simplify on the way down. Type checking and type stripping can be done by software components, but, the components need to be isolated from one another, e.g. free from hidden and visible dependencies (aka “0D”, anti-CALL/RETURN). The premature-optimization crowd can be mollified by allowing some components to be optimized out at “compile time”.

We have all of the tools, we just don’t bother to organize this way. In the same way that we wrote spaghetti code when everything looked like a GOTO.

Speaking of spaghetti... As tangled cords prove, simple doesn't not mean easy or natural.

Is simplicity an objective property of a system that is just hard to define? Or is simplicity somehow wrapped up — at least partially — with our subjective experience of it and is that why we have a hard time agreeing on it?

The article picks up on this issue, but then concludes that if it is partially subjective, we still just have to agree on how to deal with it — but that is the problem, not the solution.

There is an aspect of legibility to a system where different people might fundamentally disagree and no agreement seems possible (Emacs vs. Vim, Lisp vs. Forth, tabs vs. spaces, etc.). It often looks like it’s just an agreement issue and one side (of course, usually the other) is somehow confused and can’t see the “truth”.

But what if that is a flawed perspective to begin with?

What if there are emergent properties that are only ever clearly defined by their current context and not fully generalizable?

Similar to how many organisms are well adapted to their environment, but it means different things for different organisms in different environments. If you drop a shark, a well adapted deadly predator at a fairly high spot in the aquatic food chain, into the middle of Sahara desert, it’ll be dead within seconds.

Maybe when a system appears simple to us, we are just like a shark in water. Everything looks just fine over here. But try to teach that to a camel in the desert…

My unproven and probably unprovable hypothesis is that much of complexity in software comes from believing that "software" is a useful category to think about, independent of context. From an engineering (as opposed to philosophical-mathematical) point of view, an embedded computer in a washing machine has pretty much nothing in common with a Web browser, and a climate simulation has nothing in common with Dungeons & Dragons.

Some excellent quotes:

I would describe good Haskell code as “brittle”, and I mean that as a compliment. People tend to casually use “brittle” to mean “prone to breakage”, but in materials science what “brittle” means is that something breaks without bending: when a brittle material reaches the limits of its strength, it fractures instead of deforming. Haskell is a language where abstractions do not “bend” (or permit invalid programs) but rather “break” (fail to compile) in the face of problems.

And another:

I once heard it said that Haskell lets you work with functions the way Perl lets you work with strings. Lots of Haskell idioms, like monads, are perfectly expressible in other languages: Haskell just makes them feel natural, while writing a monad in many other languages feels like you have to do lots of busy-work.

I wish the critique of Haskell was as good as the love expressed for it.

For my part, I just find that most attempts write Haskell programs ends up down theoretical rabbit holes.

Here's a tiny, silly example. For illustration purposes, I wanted to write take 25 (map (^2) [0..]) as:

do

  i <- [0..]

  let ii = i * i

  guard (i < 25)

  return ii

This is, of course, bad because it loops after producing the 25 squares. You keep pulling off i s and keep fining that they are not longer less than 25. It would be "neat" if we could replace guard with some sort of until . But what sort? Could get lost for hours.

Haskell is the formal systems lover's dream (unless they have already moved on to something more sophisticated, such as dependent types). All code defines a formal system, but Haskell programmers love to make formal systems that are about the code (types etc.) Formal systems are very precise, which is great when you can certain that they match your problem. If they don't match, or if you don't know, they are an endless source of frustration. Which means that Haskell is great language if and only if your problem has already been formlized, e.g. in mathematics.

At first I thought it was a joke, because maybe IMTA?

But, I saw this snippet from its README and was like, so everything ?

KamilaLisp allows for actor programming, concurrent programming, imperative programming, functional programming, array programming, pure functional programming, object-oriented programming, rudimentary logic programming, mathematical programming, backend development, numerical and scientific computation, scripting and system administration, symbolic computation (real and complex analysis), tacit (point-free) programming, concurrent programming and event-driven programming.

But...like...yeah.

Created by a 19 year old!?

right!? everything about this makes me feel totally inept.

but also in awe — I love how it empowers you to think for a problem space, so, rather than “solve this the APL way,” vs “solve this the functional way” or “solve this the OO way” you can ask “what way of the ways at hand makes most sense for this bit?” — I’m used to making those choices at the language-level, e.g. “given this problem, I reach for X language” but here I can hand a tacit function working on a matrix off to an object!? 👨‍🍳

Looks like someone is having fun.

Meh, my take is more like:

Developer tools seemed like a good industry to be in, and we had a good business selling shovels, but the VCs weren't getting rich enough, so then when we tried leasing shovels to them with a tether attached that would yank it out of their hands and collapse all the holes they'd previously dug with it if they ever stop paying us... and turns out people who specialize in building tools have options as to where they get their tools

One time fee for something that has to work in an ever changing environment, so be constantly adjusted and improved, or have any customer support, is never good business. Actually, it's completely unsustainable business. On the other hand, paying 1% of the cost of a work hour for something that improves productivity by 2% gives you massive 100% ROI. A complete no-brainer. With price of a software development hour being ~100$, monthly cost of say 160$ per month for a tool that improves your productivity by 2% is an exceptional deal. Rationally thinking. Now the problem is that not a lot of people are all that rational. In addition to the difficulty of defining and measuring productivity.