Why does programming suck?

Sure, some engineers (especially junior ones) enjoy reinventing the wheel more than using something that already exists to solve users' problems. We all like to trick ourselves into thinking we're unique snowflakes (this problem extends into our personal lives as well). But more often than not, when multiple popular standards emerge, it's because there are legitimate engineering tradeoffs that are being made.

JSON vs. XML? XML is far more capable but complex. JSON is far simpler but less capable. Sometimes when you're delivering value to customers, you need that extra complexity, so you use XML. Other times you don't need it so you use JSON. It has nothing to do with ego or politics. Multiple different JSON libraries? One may prioritize ease of use to get up and running, the other may prioritize strong typing for serialization speed. One may prioritize strict compliance with the spec, the other might prioritize speed above all else. JSON vs. a binary format? JSON is more readily compatible and easier to debug. Binary is faster but more complex to setup. It goes on and on.

Again, sometimes competing standards or libraries or languages emerge because of political or capitalistic concerns. But usually when you're talking about competing open standards, there are multiple because there are legitimate engineering tradeoffs being made because engineering is not a one-size-fits-all science. (Few sciences are, otherwise they wouldn't still have people working on them.)

When an open source project rejects a contribution, or five projects exist to solve the same problem, they're often making legitimate engineering tradeoffs that are in no way arbitrary, and any one project would suffer to try to be every thing to every person. The article in question doesn't even point out a single example of a set of standards or libraries that are entirely arbitrary in their differences or could be collapsed into one solution, which further highlights how this is a theoretical argument, not a practical one.

I suppose that while visual programming excels at conveying topology and structure, it can be weak at a low level due to the tedium involved. Traditional code is arguably better suited for low-level grunt work, at least for most people.

A hybrid solution might be best. For example: a message travels from one high-level visual entity to another, and you'd easily be able to drill down into the code comprising those entities, locating the exact lines responsible for emission or receipt.

We (who do we mean when we say "we", anyway?) don't have a direction, path or overall goal for life, society, the human race and so on. I don't even have a plan for what I'm going to have for lunch next Tuesday.

Programming is contingent and incremental because rationality is bounded and the future is uncertain. We don't know what will be successful in the next few years or how the world will want to use it or what it will be prepared to pay for.

We can build jewel-like systems that are perfectly adapted to their use case using technology to the utmost. This nearly always results in a stranded evolutionary dead-end. The BBC Domesday Project (live video database on an 8-bit micro using PAL laserdisc!) is my favourite example, but there are many.

http://oro.open.ac.uk/35805/8/UML%20in%20practice%208.pdf

"Even if UML is viewed as the ‘de facto’ standard, it is by no means universally adopted. The majority of those interviewed simply do not use UML, and those who do use it tend to do so selectively and often informally."

"They also highlight some of the fundamental tensions within UML, resonating with arguments [8], [25], [17] that UML’s intended strengths (i.e., generality, accommodating different levels of abstraction) are intimately associated with its observed weaknesses (e.g., latent complexity, issues of transformation and coordination between views) and arise from fundamental properties of UML (e.g. lack of formal semantics, separation of expressions of structure and behavior)."

Whatever we do next, we have a nice set of examples and case studies of "what can go wrong."

The specific software tools based on UML are especially good examples of the problems.

However, programming may be lambda calculus at a theoretical level, but execution is a turing machine. All these little real world things that can be abstracted away in abstractions(!!), have to be unabstracted to meet a bunch of very real NAND gates somewhere, limited memory, resources etc.

Thats one reason it "sucks", but thats why its engineering and not math. Maybe one day computers will just be so powerful that we can afford to treat memory as infinite, runtime as infinitesimal, and build all the abstractions we want for free - then programming will be done :)

In this fun world, when i want to build something ill just draw a bunch of squiggly boxes and describe an alarmingly underspecified thingy i want done. Then the program will automatically figure out all possible inputs, quickly perform a "32 questions" kind of thing and resolve any ambiguity, then produce code. Managers will once again be confused why "adding this textbox is so hard", but this time they will be right - i will just tell lambda to go make a textbox.