Programming languages are not technical


#1

I’ve been thinking a lot recently about how programming languages interface with humans. Programming languages only really exist because of our shortcomings as beings - we cannot think of highly complex apps in terms of register allocation - we need to forget about that so we concentrate on our problem.

It follows that we need many different languages. We need to support

  1. Different problem domains, and
  2. Different types of programmers

I watched the intro to the Go languages because I thought it would probably be useful for my career, and was horrified! If you happen to name a function a certain way, you implement an interface. Then I thought that actually, a different type of person to me would love this feature. It is just that I like symmetry, correctness and completeness and I value those things over development speed.

This isn’t an argument that Rust is better than Go, just that it appeals to me aesthetically. Maybe this bias is stopping me using the best tools for any job I am doing, maybe not. I don’t know, but I thought I’d share my ramblings.


#2

A few thoughts:

It follows that we need many different languages. We need to support

  • Different problem domains, and

Agreed, but this is not a controversial point. In fact, procedural macros exist to support this very use case, among others.

  • Different types of programmers

I disagree with this. The reason is already embedded in your argument: what looks or feels ergonomic / useful / comfortable is highly subjective, and almost no individual has good enough taste and experience to build an entire language well on their own (and that is disregarding other factors, e.g. the sheer amount of effort involved in designing and implementing a language clearly favors teams over individuals). In fact it’s one reason that every successful PL has an entire community surrounding it at the core. Given this, it seems pointless to develop with a subjective focus like that as it is setting the language up for failure by building on ideas that feel good rather than actually sound ones.

In addition, one good way to view code is as the expression of a solution to a problem. If this is the starting view point, then it makes perfect sense to only focus on the inherent complexity of the problem being solved, not the person looking at it. The idea here is that if a person cannot handle the inherent complexity involved, they have no business altering it either until they do. For example, you wouldn’t ask an average 10th grader to solve Fermat’s Last Theorem either, as they simply do not have the tools to even begin solving the issue. An established mathematician on the other hand, has no problems reading and comprehending the many mathematical formulae and deductions involved. (Not that a mathematician would necessarily solve FLT; it is a notoriously hard issue, but that’s besides the point).


#3

Thanks for replying to such a rambling post. I agree I don’t think that you should design a programming language to different tastes, but I do think that as a language user you are biased by taste. I think that the relationship between human and language is as, if not more, complex than the relationship between programming language and machine (aka. compiling). I think the aesthetic beauty of Rust is part of its success, rightly or wrongly, and that is food for thought. When designing a programming language that aspires to great usage you need to consider psychology as much as type theory.

Irrelevant aside: both my parents were Supervised by Andrew Wiles whilst at Cambridge. I believe it’s when they got to know each other. I’m grateful for this :smiley:


#4

“shortcomings of register allocation”; even worse lets blame the transistor.
The solution is really for the machines to write all executables so no need for those silly programmers.


#5

For now we need humans to convert real-world problems into technical solutions.

For now…