EYG: A Programming Language for Humans

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

I started building a language during a 10 week wait for my visa to start a new job in Sweden. 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.

These tools and problems fall in the broad category of end user programming. Some people prefer citizen developer because it captures the usecase of non professionals making useful contributions at work. 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.

This section was nearly the title of this post.

Full time developers can spend more time keeping up with changing technology than others. 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. The average human response to integer overflows is “WTF, that’s not how numbers work”. 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. This means developer tools underserve the smaller problems.

Developers deal with two broad categories of work.

There are a lot of humans who can do the first work fine but don’t have the time to master the second category. 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”. An Excel macro remains textual programming, but removes all issues around deploying and running the macro. 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. It focuses on the home cooked end of the software spectrum. EYG is a good choice for:

While in Sweden I worked with automation engineers. 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. 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.

Well I managed to convince a few of them to do the Gleam tour . A statically typed functional language was a new paradigm for them and yet these engineers had no trouble learning Gleam. In fact they mostly finished the tour and asked “now what”. 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). But there are still pains around releases and deployment. It’s clearly not at Excels level of convenience in smoothing out category 2 problems.

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

Gleam is nominally typed and EYG is structurally typed. Nominal typing is the best way for a professional to rigorously describe a domain. Structural typing is the best way for a computer to help a user without them requiring to think about the types ahead of time.

Gleam is for developers building applications. EYG is for makers building features.

There are many choices EYG makes to work well for the makers it wants to support. Below are the main areas where it differs from other languages.

At this point I think types are a good choice for everyone. The trend is from JavaScript to TypeScript (and on to Gleam). For EYG I chose a type system that never forces a user to define a type ahead of time and it is optional to run it. It focuses on making the type system a best in class helper rather more ceremony in the process of writing software.

After convincing those automation engineers to try Gleam the thing that caused the most issues was understanding dependency hell when updating. Gleam was still pre 1.0 so they happened more often than it does now. EYG steps around the dependency issue by defining dependencies inline where they are identified by the hash of the module’s contents.

Capturing side effects in the type system enables a runtime to provide more help to the maker. When writing a script for a webpage any dependency that calls the file system will show up as a helpful type error. I have plans to take this further; for example a platform might be able to provision a key value store only if your lambda function uses the key value effects.

My measure of better is how well the language enables makers to build reliable, sharable programs. This extends to configuration, scripts, automations, widgets etc.

This is my measure of better and of course there are others. If you are looking for the best language for a large team to build a new browser may I suggest Rust.