A programming language for humans.

A programming language for humans.

Eat Your Greens (EYG) is a statically typed functional programming language.<br>It is a better programming language, for some measure of better.<br>This post explains what I consider to be better and which features that requires adding or removing from the language.

End user programming disappointment

I started building a language during a 10 week wait for my visa to start a new job in Sweden.<br>I built EYG specifically after noticing a recurring pattern amongst technically minded, but not professional, developers.

The pattern was a cycle like the one below.

A technically minded person identifies a problem they feel they should be able to automate.

They choose a nocode or locode tool and get it working.

Quickly they get frustrated as growing complexity isn’t handled well by the tool.

At this point there are two choices:

Ask a developer for help, they immediately throw out the first solution saying it needs rewriting in a “real” language.

The original maker starts learning the “real” programming language themselves and progress slows while they do.

These tools and problems fall in the broad category of end user programming.<br>Some people prefer citizen developer because it captures the usecase of non professionals making useful contributions at work.<br>My favourite way to describe software not for mass consumption is home cooked.

Essentially creating software to solve a problem should be available to people who don’t make it their full time identity to be a developer.

Humans vs Developers

This section was nearly the title of this post.

Full time developers can spend more time keeping up with changing technology than others.<br>If only 10% of your job is writing software then reading about writing software isn’t happening.

Sympathy for the machine only exists in developers. They will happily explain why integer overflows need to happen.<br>The average human response to integer overflows is “WTF, that’s not how numbers work”.<br>We have BigInt and 99% of the time the WTF response is the correct one.

On average, developers are working on larger problems. This makes sense - some developers are working on software projects with hundreds of others, whereas end user software is probably less than one human’s fulltime attention.<br>This means developer tools underserve the smaller problems.

My hypothesis

Developers deal with two broad categories of work.

Describing the logic of the problem they are solving using language constructs like if, loop, var etc.

Working with computers to run those problems using constucts like $PATH, /var/tmp and AWS.

There are a lot of humans who can do the first work fine but don’t have the time to master the second category.<br>I call these humans “makers”.

Therefore any end user programming tool that tries to make programming easier, say by creating a visual language, is solving the wrong problem.

Excel is the darling of any end user programming conversation. “It’s actually the most popular programming language, don’t you know”.<br>An Excel macro remains textual programming, but removes all issues around deploying and running the macro.<br>Excel completely solves category 2.

EYG exists to remove category 2 problems (they are handled automatically by platforms or runtimes) and let makers focus on describing their problem.<br>It focuses on the home cooked end of the software spectrum.<br>EYG is a good choice for:

Glue Problems: “I need this spreadsheet to talk to this Discord bot.”

A Personal Dashboard: “I want to see my solar panel output and my calendar in one place on an old iPad.”

An Automation: “If my doorbell rings and I’m on a Zoom call, flash my desk lamp.”

Further evidence from Gleam

While in Sweden I worked with automation engineers.<br>They are technically literate people but they spend as much time thinking about electrical, mechanical and safety issues than they do about the software.

This is the software environment they work in.

Clearly they are real programmers.<br>Yet I watched several of them go through the same cycle as above when trying to build software in other domains, such as a website.

What has this got to do with Gleam?

Well I managed to convince a few of them to do the Gleam tour.<br>A statically typed functional language was a new paradigm for them and yet these engineers had no trouble learning Gleam.<br>In fact they mostly finished the tour and asked “now what”.<br>They were happy with the constructs of the language but didn’t know where to apply it and how to deploy it.

Gleam is a wonderful language that really neatly allows you to express your solution to domain problems (category 1).<br>But there are still pains around releases and deployment.<br>It’s clearly not at Excels level of convenience in smoothing out category 2 problems.

Why not work on Gleam

For a while my language was experiments that I hoped might make it back to Gleam.<br>However there are a few irredeemable differences due to different...