You are viewing archived messages.
Go here to search the history.

Eli Mellen 2023-08-23 14:15:56

No one actually wants simplicity

The reason that modern web development is swamped with complexity is that no one really wants things to be simple. We just think we do, while our choices prove otherwise.

later, continuing…

The same is often true of complexity. The real test is the question “what are you willing to sacrifice to achieve simplicity?” If the answer is “nothing”, then you don’t actually love simplicity at all, it’s your lowest priority.

When I say “sacrifice”, I don’t mean that choosing simplicity will mean you are worse off overall – simplicity brings massive benefits. But it does mean that there will be some things that tempt you to believe you are missing out.

Looking beyond the inflammatory fun title, how do ya’ll think this relates to the future of coding? Is a reason that visual programming is often just around the corner because folks aren’t willing to shed some of the complexity (read also as “power” or “flexibility”) of existing programming systems?

Paul Tarvydas 2023-08-23 14:41:05

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.

Marcelle Rusu (they/them) 2023-08-23 14:50:45

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.

Paul Tarvydas 2023-08-23 15:23:50

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.

William Taysom 2023-08-24 04:35:33

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

Stefan Lesser 2023-08-24 06:12:51

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…

Konrad Hinsen 2023-08-24 06:33:13

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.

Konrad Hinsen 2023-08-25 07:10:56

A nice essay on programming languages, but with a message that is much more general:

It's about the tension between "make better technology", "use start-of-the-art technology", and "use boring (but stable and well understood) technology". Different goals, different tools.

Another example I have experienced a lot: mathematics and physics. Mathematicians work on new mathematics, mathematical physicists introduce state-of-the-art mathematics into physics, and all other physicists use 100-year-old mathematics from textbooks. And each group complains about the attitude of the two others.

📝 Leaving Haskell behind — Infinite Negative Utility

For almost a complete decade—starting with discovering Haskell in about 2009 and right up until switching to a job where I used primarily...

William Taysom 2023-08-26 04:54:42

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:


  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.

Konrad Hinsen 2023-08-26 18:04:03

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.

Eli Mellen 2023-08-25 12:15:30

Has anyone spent time with kamilalisp?

I've spent the last week or so exploring it, and it keeps blowing my mind.

Eli Mellen 2023-08-25 12:16:17

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.

Ivan Reese 2023-08-25 15:26:08

Created by a 19 year old!?

Eli Mellen 2023-08-25 15:26:30

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

Eli Mellen 2023-08-25 16:54:38

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!? 👨‍🍳

William Taysom 2023-08-26 04:56:39

Looks like someone is having fun.

Gregor 2023-08-26 11:15:02

📝 Andy Gocke on X

Developer tools seemed like a good industry to be in, "sell shovels in the gold rush" and all, but it turns out developers prefer to dig for gold with their teeth.

abeyer 2023-08-26 20:55:37

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

Jarno Montonen 2023-08-27 07:38:03

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.

Nils Berg 2023-08-26 20:58:46

wee, new stuff from Eskil Steenberg:

(not that new, he’s been working on things like this, and advocating for live debugger use for many years at this point. and yet, his stuff always seems fresh, and just…different)