Problem of Expressive Programing Languages

By Xah Lee. Date: .

One problem with expressive programing language is that it becomes unsuitable for large team in a corporation. because when the syntax becomes super flexible and the semantics is very powerful, they create many ways to express the same algorithm, and that makes the source code hard to read, because everyone has a different style of coding. Example of such programing languages are Perl, Wolfram Language, JavaScript. In contrast, Java, Golang, Python, are rather inflexible, but in turn, their code is easier to read, almost all source code look the same.

JavaScript functional programing flexible coding style problem

one problem with functional programing in JavaScript and Wolfram Language is that, when there are a team of coders, the code becomes incomprehensible.

because, the function can be chained, function return functions, and the chaining function or method syntax is too convenient. So, everyone has a different coding style (here, the style refer to the semantic construct, not formatting). So, code become hard to understand.

lisp doesn't have this problem because the parenthesis prevents people chaining functions arbitrarily.

this is when python shines. First of all, it has a crippled lambda, so you can't have arbitrary functions inline or chain them. You have to define it by itself. Then, the language syntax prevents you from writing one-liners.

java, also works here. Because, the lang is so inflexible that you have to write everything out, each line can only do very little.

though, as a language designer, what can you say about this? what can you do?

isn't it ironic that if you create a language so powerful and flexible that it backfires? Something must be wrong with this logic? how to resolve this paradox?

in my way of thinking, whenever result of mathematical analysis conflict with human intuition or practice, it is human that needs to adopt. (For example, relativity, flat earth, concept of size, dimension, time. Habit. superstition. religion, etc.) but we must be very careful.

so here, if we verify by science truly that powerful language with flexible syntax indeed create a problem due to multitudes of incompatible programing style, then, the issue is about how to create or enforce a style. Because, math tells us that ensuring a unified style is a consideration by itself.

many language designers, cut corners. They think, O that's too flexible and create a multi-style problem, therefore my language will not have this syntax. That is confounding of issues. It will solve the problem near-term, not long-term. It's like the qwerty layout for typewriters. When typists types too fast and the key jams, the problem was solved by changing the layout so typists can't type fast.

comment at

Systematic Grammar