Can Programming Be Liberated, Period? (2008) [pdf]

The previous discussion from 2017 was on point: Most of programming is figuring out what you actually want and that problem is not going to be solved by computers any time soon. However, I think there is a sub-problem where computers can help. One of the biggest issues when writing large and long lived systems is that the code becomes more complicated than the original problem. Anybody whose worked on legacy systems before will be familiar with that issue: figuring out how to do what you want to do in the confines of the existing code is sometimes more difficult than analysing the original problem.

I tend to make my living on legacy code. In fact, I enjoy it more than green field projects because it's trickier. Also, because nobody else wants to touch that code, I have more freedom :-) And (if I'm honest) it's an easy escape from the occasional colleague who always insists that "it must be like X" because they lack experience to see things in terms other than X. When you get to the point of, "Well, we can't reasonably do X because of all our legacy problems. What's plan B?", there is a lot more room for compromise and the task becomes a lot more fun (IMHO).

But on greenfield projects, having a tool that helps you understand when you are making the code worse would be incredibly helpful. We've got some metrics (like cyclomatic complexity, class size, method size, etc, etc) but it's still pretty easy to write code with terrible consequences even when following linting rules.

This is where I can see the potential for AI and ML to help: a kind of permanent pair programming partner that can keep an eye on the big picture. For example, warning you when you have too many options in your API, or when your architecture is not isolated enough (or too isolated). It's a lot of fuzzy judgement calls, so it's hard to find specific rules to help you. I suspect there are some startups looking at this, but I admit that I haven't followed their progress at all.

I think the programming language design is not the problem. Python and others are easy enough. The problem is more with representing the thousands(more sometimes) of decisions that go into building a codebase. It is impossible for someone to just go in and understand a codebase. If there is a way to shorten the time to learn why every decision was taken, programming could be easily gamified.

From 2017: https://news.ycombinator.com/item?id=16008462

It is perfectly possible to program without a keyboard. That said it is a bit domain limited - block diagrams usually or picking from a list of functions.

Not having the how and what however is a bit of a receipe for disaster by asking something for nothing - undefined behaviors are bad. Programming depends upon clarifying your ideas - design does period. Even if you could teach it a phone interface it would still have to deal with standards to actually be a phone.

The precise "how" can be left to programs with machine learning or other optimizations like compilers of course but one needs a search space/technique for it to generate.

And there are pitfalls to keep in mind like spurious correlations,data poisoning to make a toy turtle be perceived as an AK-47, and model glitch exploitation. It will still give you what you ask for in the training functions - not what you really want. You may want a more efficient form of locomotion so it finds a perpetual motion device trick that needless to say won't work in the real world.

That happens with humans as well with perverse incentives and unclear requirements.

Side note; Harels Algorithmics is a wonderful book I recommend to anyone.

This is a bit similar to what I had been thinking for the past several weeks. My approach was a little bit different, and involved excel-like mechanisms with a bit of AI sprinkled on top, but this might be even better, though harder to do.

Title should mention the year, [2008].