I agree with you that all languages are, in the end, equivalent, that it’s all a trade-off between sets of primitives, and that probably assembly language *IS* a better language for some tasks.

Still, my point is: I feel that a huge amount of the problems we solve nowadays in software are being solved using a very inappropriate set of primitives, which make our software worse and our lives more miserable. We need to advance our understanding to be able to build better tools. To me, software development is in its infancy, and things will get better as we advance. Our tools are terribly inadequate, and I miss a set of primitives that I feel is lurking below the current level of abstraction.

I know the race has no end, and that the axis of HOW-WHAT is actually a continuum, but advancing on that axis has to be the driving force to healthier software development.

BTW at some point I’ll discuss how I think there is no real distinction between CODE and DATA, so you can guess I have no problem accepting that HOW and WHAT are not completely disjoint concepts!

The WHAT you want to achieve with a program is (in theory) the same in any language, but the HOW is defined in terms of the primitives that language offers. Assembly has addition, KSI does not. C’s operations can be applied to arbitrary variables of a primitive type, Assembly’s only (in many cases) to a limited set of registers. C++ lets you apply operations to custom types rather than only the primitive (numerical) ones. Erlang lets you distribute a bunch of operations among multiple processes / machines.

In your Assembly / C example, the addition of these two numbers is presented as a WHAT, but in reality it’s just one step of a HOW solution to a larger ‘WHAT’ problem. It is very possible that if you were solving that problem in Assembly, the steps to solving it might not have involved creating these two variables.

Higher level languages don’t really change the focus from the HOW to the WHAT. They just change your current set of primitives for another, hopefully more sophisticated super-set, so that your HOW steps are easier to write, easier to understand, easier to modify, easier to run in different platforms, or (in general) measure better in some metric associated with the effort of the programmer. This is why the quality of a programmer’s code is largely independent of the programming language being used.

It is important to understand that, along with the new set of primitives in a higher level language, you often lose some primitives from the lower level language. It was a classic situation back in the days that writing 32-bit fixed point functionality was easier in Assembly than in C; JavaScript may be higher level than C, but good luck performing 64-bit bitwise operations in JavaScript. In general, if performance of the resulting program is part of the problem specification, high-level language constructs may be an impediment rather than an advantage. See for example the move towards Data-Oriented paradigms and away from Object-Oriented techniques in high-performance console games. (see https://plus.google.com/u/0/115950681746193428612/posts for more on this)

tl;dr In general, a higher level language makes it easier for the programmer to specify HOW to solve a problem, but it does not let the programmer focus solely on WHAT the problem is.

The bandicoot project (that I have discovered thanks to a comment above) seems to be an implementation of this programming paradigm, but with a better syntax than the one presented in the paper.

I see the Twins Jare mentions, as well as the yak shaving, especially on throwaway programs. People can also easily over-engineer stuff to avoid boilerplating two or three instances of something similar happening in a program.

I’d rather see a repeat of something that’s downright idiomatic than a custom solution to a problem everyone just boilerplates all the time.

Additionally, putting numeric constants at the top is not always as useful as further down in the code next to where they’re used. It can make some errors harder to spot in certain layout situations. Don’t even get me started on putting numeric constants in h files far from the use for no reason other than someone read a software engineering book in the 90s and never read one in the intervening 12+ yeares. That’s just horrible to deal with when it involves layout code or something else where the constant values really do matter.

All that said, copypasta is *painful*, to quote Sean Kelly: Code is read more than it is written

oops, thats six paradigms

The reason I can walk into a hardware store and build myself a deck or renovate my bathroom or build myself a certain object is because of standardization. The toolsets and the parts have been standardized.

I don’t have to have the metallurgical knowledge on how to create high carbon steel, nor do I have to have the knowledge and the equipment to create a certain nut and bolt. All that has been taken care of me. All I have to do is use standard nuts and bolts, and standard tools and I can work and create a reasonable object with little “end user” knowledge.

In computing however, we still expect “the programmer” to do the equivalent of digging the iron ore, smelting it properly, Building a lathe, then turning that piece of metal to make themselves a bolt, and the process go on.

Let’s say a programmer was given the equivalent of putting together a simple fence. All you need is wood planks, some nails, and a hammer.

Programmers don’t use hammers, they start with the ridiculous equivalent of digging up iron ore, growing trees to build the handles and building smelters from scratch to melt the ore and make the hammer heads, then they’ll melt the rest of the stuff down to make the nails and THEN they’ll actually start the process of nailing pieces of wood together which they wouldn’t have standard pieces of (but having grown the right tree, cut it down, then make the 2×4 out of them)…

Now imagine every handyman walking around with his own bloody smelter, ore extraction machines, lathes, and you get the idea.

What you’re arguing is that this process (ore digging, smelting, lathe turning) needs to be standardized. (yes but for a very small minority!)

What you NEED to argue is that NOT EVERY PROGRAMMER NEED DO IT! Just like not every engineer or handyman concerns him/herself these days with the type of bolts,nuts, handles, weights and measures.

And therein lies the problem. Programmers LOVE to jerk off to complexity, and that’s their main issue. Instead of solving problems, they love to WALLOW in the problem solving process itself. They love to re-invent the same wheels over and over again! They love to imagine themselves all as McCarthy’s or Chuck Moors or Dijkstras and leave a shitstorm of unusable garbage toy languages in their wake.

The problem isn’t that we don’t have “the right language”, the problem is that we have way too fucking many, and it’s too easy to create more. That is a way of avoiding the problem which essentially is that of standardization of basic computing parts/idioms and interfaces between them. For most computing problems TCL or even Bash with the basic set of UNIXcommands all piped together should be enough. But is it? …