Who is programming even for? #

Programmers, is the obvious answer. That is probably more true today than it has been in the past.

Why is that?

It takes a lot of different skills to produce commercially viable software: domain expertise, marketing, user experience design, graphical design and programming. In a professional context, you usually have groups of people who've specialized in one of these skills, working together. However, only one of these groups is actually building anything: the programmer.

The way these groups collaborate is by telling the programmer how something should work, and then having the programmer implement it. Is this really the ideal way to make software?

Shouldn't domain experts be able to define domain logic directly? Shouldn't designers be able to draw a UI in a visual tool, and have that be the actual UI? Should programmers really be involved in every single step of defining a working program?

It's tempting to think that programming is a skill so advanced that only a subset of the population is able to perform it. I've come to believe, however, that this is mostly the result of our programmer-targeted tools.

For that, I blame open source.

Specialization through charity #

Don't get me wrong. The reason why we can develop software with any efficiency at all is due to open source projects.

Builders with a passion for their craft, build their own tools. Due to a lack of interest or capability to monetize their tools, they made them freely available to everyone.

Free software of good quality has immense value, but also a cost. It's very hard to compete with free software, and free software built by developers tends to target other developers as their main audience.

As a consequence, software development has grown more code-centric over time.

GUI Builders #

The first time I saw an IDE, I was looking over the shoulder of my brother while he was building a password manager in Visual Basic. Visual Studio, the IDE, had a drag-and-drop GUI for creating the actual GUI of the application, and made it very easy to connect events (like click) from the UI to code.

Do I, personally, dream of having access to a GUI builder? No. I have no problem visualizing a GUI based on the code in front of me, and prefer the convenience of having everything be code. But at work, where a designer has already crafted a beautiful GUI, it seems entirely wasteful to have me re-implement that GUI in code.

Why can't their design simply be something I connect to and react according to the events it sends? Would that not be much more efficient, and better utilize the strengths of the team?

Visual programming #

To control my smart appliances at home, I use a hub from Homey. Homey has a built-in visual programming language called Homey Advanced Flows. Actions and events are represented by boxes, and you can connect one to the other by connecting lines between them.

This is simple and effective.

Debugging is a matter of following the flow through the lines. Parallelism happens when a box has multiple outgoing connections. It's easy to see, at a glance, what a specific flow does and how it does it.

Would I, personally, want this at work? No. I'm much more efficient when my hands don't leave the keyboard and I don't have any difficulty in visualizing the flow in my head. I also suspect that there are a bunch of things that are harder to define visually compared to text, like a hashmap or a sorting algorithm.

That said, for code that I only touch once or twice a year, a visual representation of the code is faster to understand at a glance. It would be nice if code could have more than just a text representation, where you could pick your visualization based on what you need.

And just like I should be able to consume the GUI created by an expert designer, shouldn't I also be able to consume, or embed myself into, a flow diagram created by a domain expert? Wouldn't that save everyone a great deal of time and effort? Wouldn't it also make the logic much more accessible to non-programmers?

We shouldn't constrain ourselves to code #

You cannot create an entire application through a GUI builder, nor through a DSL for expressing domain logic. That doesn't mean we should define every part of an application with code.

When I attended the Norwegian equivalent of high-school, I had to decide which math course to take: 1my or 1mx. I chose 1mx, as I heard it was the most advanced course and because I enjoyed the challenge. Both courses had the same teacher, and for most of the semester we actually ended up solving the same problems. The 1my students had a tendency to solve problems visually, by drawing charts and diagrams. 1mx students stuck with numbers and symbols, solving the same problems but without visualizations.

Not everyone can solve problems with numbers and symbols alone. That doesn't mean they can't solve complicated problems.

We should strive to let domain experts define domain logic in a tool suitable for them. We should let designers define GUIs graphically. We should make it possible for domain logic, GUIs and low-level code to interoperate, if and when it makes sense.

I accidentally explored this a tiny bit through my work on Gløgg.

Hopefully someone smarter than me can explore it further.