[derefr]

No joke: I strongly believe that "real programmers" do indeed write in assembler. Not x86 assembler, mind you. Rather, "real programmers" first compose an abstract machine semantics for the solution domain, create an instantiation of those semantics in the form of a virtual machine on some host architecture, and then express the solution in an assembler language targeting the abstract machine semantics. (See, for example, the Prolog abstract machine semantics to represent the solution domain of expert systems.)

They might, if their problem is really hairy and requires large amounts of exploratory programming, create a high-level programming language (usually a macro-language) that allows easy access to the same abstract machine semantics, and then code in that. For well-defined "closed" problems (e.g. in-kernel packet filtering), this added baggage is usually unnecessary, but for more "engineering-oriented" problems, you might end up with something more like an Erlang than a Prolog.

Note that C itself follows this rule; the "C abstract machine" is a pretty good fit (though perhaps not perfect) to the solution domain of low-level systems programming.

[themoonbus]

I like to use python

[jacquesm]

The context appears to be low level programming.

[pekk]

Can you explain why this is a smarter way to build software?

[derefr]

Mostly that it's the simplest and oldest (and, in my opinion, the least "sandwiched in between five layers of indirection") version of a very common idea, that I'm not quite sure the name of. It's the idea behind DSLs, and Lisp-like languages. Most of Chuck Moore's writings on the potential behind Forth-like languages are also about this idea. The most modern instantiation of the idea, I believe, is "Behavior-Driven Development" with Cucumber et al. But it's all the same thing, in the end.

Generally, the idea is: first, you should define a language to directly express statements about your problem domain. Then, in one place, you can define the solution in terms of the problem domain. Completely separately to that, you can implement the mechanism by which a machine interprets and acts upon statements about the problem domain. Putting the two together results in a program that solves your problem. But either may be maintained separately.

The term "separation of concerns" has effectively always been about making sure that demands for change that come from separate "departments" don't end up touching the same line of code. This model excels in that: maintaining the specification of the solution is solely the province of the business, while maintaining the interpreter of that specification is solely the province of some engineers somewhere. As long as the interface between the two is stable—a stable ABI—improvements can be made to one or the other without the other group ever having to be aware.

A great example of this is the Inform 7 language. One group of people writes text adventures in this language, or enhancements and plugins for text-adventure development. A separate group of people maintains interactive-fiction interpreters that parse a given ISA. Neither group has to think about the other. The ecosystems of the IDE and the runtime are, in fact, completely divorced.

[_nedR]

My personal opinion: Because there are very few if any leaky abstractions waiting to blow up in your face. True WYSIWYG.