Missing a new kind of programing

[RoGeorge]

As a non-software developer, the type of programing languages looks like this to me, from simple to complex:

- 1. Machine level, where one puts numbers into a machine's memory,  then the machine interpret those numbers as instructions or data.  Nobody does this any more.

- 2. Assembly level, where one can write text mnemonics to be translated one to one into machine level, by a helping program called assembler.  Mnemonics are easier to use than putting numbers in a memory.

- 3. Higher level programming languages, where one can use certain English words as keywords of the given programming language.  The keywords are broken down into mnemonics by a compiler interpreted, depending the language.



At this point I'm tempting to split point 3. into
- 3.a. Procedural programming
- 3.b. Object oriented programming
- 3.c. Functional programming (I have never tried this yet)



However, from the perspective of a non software-dev, I do not care at all about programming languages, or programming paradigms, or other things like that.  I only care about solving the problem I need to solve, but with the help of a computer.  I'll put this as

- 5. Natural language description of how to solve the given problem



To give an example, it's very easy to use level 5, the natural language, and write something like:

Water-meter logger program:
- place a webcam to watch the water-meter under the sink
- at every minute take a snapshot of the water-meter
- use image recognition to identify the numbers captured in each photo
- turn the OCR digits into a number
- attach the timestamp to the reading and log that in a file

In natural language (level 5) it looks trivial, but to convert this into a program (level 3), it's not trivial, in the sense that translating from level 5 to 3 will need a lot of tedious work of handling all the details, and then it will need a lot of programming skills to implement, test and debug it all for a reliable level 3 program.  When something is tedious or repetitive, it also means it can be handled in an automated way, by a computer.

There is a need for a level 4 that right now is missing, something to help with the automated translation between the natural language (level 5) and the programming level (level 3).

For now, instead of a level 4 language, we have armies of software devs, but it looks like all this translation from level 5 to 3 should be possible to be done in an automated way, just like the other automated translations between higher and lower levels of detail.

From what I see, there is a current attempt to skip a level 4 "language" entirely by using machine learning.  The pitfall about this is ML produces fuzzy results, they need piles of data and in the end they can still mistake too often.



- Are there any other attempts for a language in between the natural language (level 5) and the programming language (level 3)?
- If not, what to use, or how to solve the translation from natural language once and for all (without externalizing the task to somebody else)?

[tszaboo]

If you have all the underlying programs or subroutines, you can program this with BASH or BAT, and pipe the output of one program to another. Or use any scripting language to do that. The only issue is that you need to translate this to something that the computer understands. And that should be fine. If we create a natural computer language, it will be ambiguous. And open possibilities of not working properly, because the user will say:
"Yo, Computer do a picture with the webby and doodle up what the numbers on that means, you know what I'm sayin"

[ejeffrey]

I don't really thing your hierarchy of program level is particularly illuminating.

The thing that makes higher level languages higher level is not that they use more english words as keywords.  It is that they allow expressing higher level concepts directly.  For instance:

"decrement register cx and jump to the start of the loop block unless c is zero"

is still very low level akin to assembly langauge even though it is written in english.

Code: [Select]

for (idx=0; idx<N; idx++) {
}

Is (very) slightly higher level despite having more syntax and less natural-language like.  Registers are abstracted by variables and the structure of the loop body is supported by the language natively

Code: [Select]

foreach idx in [0..N-1];

Is higher level yet: the loop increment and comparison operators are no longer explicit/arbitrary code, but invoke the concept of an iterator: this implies some sort of range object that encapsulates the "get next element" and "I'm done" behaviors, and the foreach syntax can then use any iterator to perform a loop.

Higher level language constructs allow applying operations directly on containers instead of using a loop, such as numpy ndarray operations that are automatically broadcast to match size.  In this sense, shell programming (bash / csh / zsh) is very high level because it allows composing operations on entire files or data streams.  Another way to go higher level is with object oriented programming where you can apply a generic operation such as "convert to string" to an object or a collection of objects and it is done in a data dependent fashion.

So your proposed level 5 program can be looked at in different ways. I would tend to ignore the natural language part of that, I don't think that is actually important.  You have outlined 5 basic procedural steps.  If those steps themselves have existing implementations, then you can already write code like this today.

What I think you are getting at is that you don't want to go and locate existing implementations of "configure the camera driver", "take a snapshot with the camera", "run OCR", and "log to file" but you want the compiler to figure that out and fill in the details.  That is, of course, exceedingly hard, and it is hard whether you write the program in natural language or not.  You are asking the computer to fill in the details from context and prior experience -- exactly what expert systems try to do with ML.  I don't really understand what you think it should be doing *other* than ML for this task?  Can you give an example of how programming with a proposed L4 language would work without being equivalent to ML?  I can't see how the result would be anything but "fuzzy" given the ambiguity of the input?

[dferyance]

Where there is some mechanical types of tasks in programming, the vast majority of it is not mechanical. Mathematicians have been studying computation before electronic computers exist.

Natural language: computer, determine if the collatz conjecture is true.
Natural language: computer, given a list of cities and the distances between each pair of cities, what is the shortest possible route that visits each city exactly once and returns to the origin city?

Or how about:
Natural language: Give me a video editing program that is better than Adobe
Natural language: Give me a slack competitor that is easier to use

Most of programming is either engineering or math. No one has figured out how to automate this. While ML is incredible, ML doesn't do this either.

[Nominal Animal]

You want to work at the level of ideas.

Problem is, ideas are just the end result.  All the art is in the implementation and logic.  You want the end result, but not learn the art, because you don't think there is anything worth your effort there.

"Do what I want" is not a program.  It is a desire.  Even "Webcam, take a picture" is a nontrivial command, if you have multiple webcams connected to the same computer.  And even with a single webcam, what resolution should the webcam use?  What compression settings?  Brightness, contrast?  Should 50Hz/60Hz mains flicker filtering be enabled?  Where should the image be saved?

Or should 640k of RAM the defaults suffice for everybody?

It saddens me that the true art, the beauty and art of crafting the structure and logic one can rely on, regardless of exact programming language or paradigm used, is so relegated to "useless stuff a computer should be able to handle" status.  Seriously.

Also explains why most "programmers" today know nothing about software engineering, and are simply monkeys throwing spaghetti at the wall to see what sticks, leaving the end users to deal with the resulting mess.  As long as it looks shiny and "artistic", they're happy.

Here, have a banana on me.

[SiliconWizard]

Agree with the above.

Taking your example:

Code: [Select]

Water-meter logger program:
- place a webcam to watch the water-meter under the sink
- at every minute take a snapshot of the water-meter
- use image recognition to identify the numbers captured in each photo
- turn the OCR digits into a number
- attach the timestamp to the reading and log that in a file

First issue there is that actually none of the points above even unambiguously means the same thing to two different people. Let alone to a machine.

The basic issue is that most of what seems "obvious" to each of us actually is only for each of us. Conveying even simple ideas to others without any ambiguity is hard enough, but imagining to be able to do just that to a machine and get the results we "want"? That's just unrealistic.

That said, that doesn't prevent some from trying. These days, of course, AI is on the top of the list for that. But that kind of workflow, even if it eventually half works, is likely going to be a very frustrating experience.

[Siwastaja]

The lack of "4" has been recognized and resulted in some disasters, such as UML.

In my opinion, any level that can be simply machine converted into "level 3", is unnecessary. If it seems necessary, there are a few possible root causes that could be fixed without introducing "level 4":
1) Developers of "level 3" are incompetent; or writers of "level 5" spec are incompetent; or both. In any of these cases, adding another level does not help the slightest.
2) Communication between "level 5" and "level 3" fails. Add another layer of abstraction and already bad communication completely stops.
3) "level 5" specification is so messed up it can't be implemented on "level 3". Adding "level 4" does not solve this,
4) Programming language/paradigms chosen on "level 3" are really too low level for the task, making it appear that "level 4" is needed. In reality, level 3 tools must be good enough to be usable for the team to translate "level 5" into code. (I don't think this happens very often although people are tempted to think in terms like "C is too low level to be usable on nearly any project".)
5) "Level 5" specification is too hand-wavy and abstract.
6) "Level 5" specification is too detailed and implementation-oriented and hard to translate into "level 3" code because the assumptions of how programming paradigms work are incorrect.

This isn't an easy problem but I'm almost sure adding another layer is rarely the right thing to do. Programmers ("level 3") must be trusted to understand the actual problem and work towards a good product, not just do mechanical translation; OTOH, specification ("level 5") must be perfectly understandable to said programmers, yet leave them enough room for implementation details. If you try to make the spec "directly translatable" to code, then you are just inventing yet another high-level language. It's not the purpose of high-level spec.

[Just_another_Dave]

The lack of "4" has been recognized and resulted in some disasters, such as UML.

In my opinion, any level that can be simply machine converted into "level 3", is unnecessary. If it seems necessary, there are a few possible root causes that could be fixed without introducing "level 4":
1) Developers of "level 3" are incompetent; or writers of "level 5" spec are incompetent; or both. In any of these cases, adding another level does not help the slightest.
2) Communication between "level 5" and "level 3" fails. Add another layer of abstraction and already bad communication completely stops.
3) "level 5" specification is so messed up it can't be implemented on "level 3". Adding "level 4" does not solve this,
4) Programming language/paradigms chosen on "level 3" are really too low level for the task, making it appear that "level 4" is needed. In reality, level 3 tools must be good enough to be usable for the team to translate "level 5" into code. (I don't think this happens very often although people are tempted to think in terms like "C is too low level to be usable on nearly any project".)
5) "Level 5" specification is too hand-wavy and abstract.
6) "Level 5" specification is too detailed and implementation-oriented and hard to translate into "level 3" code because the assumptions of how programming paradigms work are incorrect.

This isn't an easy problem but I'm almost sure adding another layer is rarely the right thing to do. Programmers ("level 3") must be trusted to understand the actual problem and work towards a good product, not just do mechanical translation; OTOH, specification ("level 5") must be perfectly understandable to said programmers, yet leave them enough room for implementation details. If you try to make the spec "directly translatable" to code, then you are just inventing yet another high-level language. It's not the purpose of high-level spec.

UML is complex enough to have a significant probability of not being enough well understood by the specification writer or the programmer. I think that may be caused by its objective of being a general purpose specification standard, which leads to the need of many different diagram types. However, domain specific specification standards like Grafcet are more useful in my experience.

The same thing happens with graphical programming languages. They’re useful for describing signal processing algorithms or communications at a high level (for example, Simulink), but using them for relatively low level programming (as programming the insides of functions) can lead to a mess too quickly

[golden_labels]

What if there is no level 4? Not “is not implemented”, but it is impossible for it to exist? There is no gap to fill between level 3 and level 5, if level 5 is not even in the sequence.

The presented picture suggests a progression, with “level 5” being merely a continuation of that series. But I don’t think it’s like that. What you have marked from 1 to 3 differs in how detailed the description is, but each of those levels is dealing with the same qualities. It’s all information about how different elements of a computing platform should operate together, in technical meaning, to obtain the result. “Level 5” on the other hand is conceptually different. It has little to do with computing. Instead, it describes a human-perceived outcome.  The relevant sequence preceding “level 5” are not computer languages, but levels of progressively stricter natural language, going down to purely mathematical, abstract expressions.

What you are asking for is not a new level of detail, but a translator between two different domains. It’s not a translation between different ways of expressing the same thing, but finding mappings between different concepts. This is why that is being done by humans and not simple processors: such a translation requires fair bit of comprehension of both domains, along with intelligence and experience to find the proper solution. DSLs are providing primitive translation, but that’s because they already encapsulate expert knowledge placed there by a human. And recent AI-based solutions are trying to replicate humans’ task.

That is not different than problems you face in electronics. Imagine I asked you to design me a circuit that boosts bass. That request is not a high level description of an electronic system: in electronics you do not have the idea of bass sound. You first need to map that to the domain of signal processing, where you model the problem in the relevant terms. But that is still an abstract description, as electronic circuits do not work with signals either. So you must make another leap, throwing a bunch of electronic components together to achieve the equivalent effect. The sequence, which you have proposed, would in this case be moving between getting an equalizer IC, using a few op-amps and passives, or soldering together transistors and winding your own capacitors. The original question of boosting bass is by no means just a continuation of that sequence.

[rstofer]

If you have all the underlying programs or subroutines, you can program this with BASH or BAT, and pipe the output of one program to another. Or use any scripting language to do that. The only issue is that you need to translate this to something that the computer understands. And that should be fine. If we create a natural computer language, it will be ambiguous. And open possibilities of not working properly, because the user will say:
"Yo, Computer do a picture with the webby and doodle up what the numbers on that means, you know what I'm sayin"

Or even something simple like "time flies".  Which word is the noun and which is the verb? 

The English language is ambiguous.  I suspect the other spoken languages are as well.

[DiTBho]

"Programs must be written for people to read, and only incidentally for machines to execute.
but, talk is cheap. Show me the code"

( )

[Doctorandus_P]

Time flies like an arrow.
Fruit flies like a banana.

[jpanhalt]

@RoGeorge

Are you looking for a graphical programming language? ( https://en.wikipedia.org/wiki/Visual_programming_language ).  Flowcode is one, but there are others.

I have never used any of them.  When something is complex, I may do a flowchart, then convert that to Assembly.  Over the years, one accumulates their own libraries to make the conversion easier.

[NorthGuy]

Water-meter logger program:
- place a webcam to watch the water-meter under the sink
- at every minute take a snapshot of the water-meter
- use image recognition to identify the numbers captured in each photo
- turn the OCR digits into a number
- attach the timestamp to the reading and log that in a file

If you show this to an engineer he'll immediately tell you that you'd be better off installing your own computer-readable meter in series and use it for monitoring. This is because the engineer can think. The compiler cannot.

[RoGeorge]

Are you looking for a graphical programming language?

Not really, I consider graphical programming to be at the same level as text compilers (same for libraries, or dedicated software).  Preferably would be to exist something of a much higher abstraction level, so to get rid of managing all the details a programming language is requiring now.

[Just_another_Dave]

@RoGeorge

Are you looking for a graphical programming language? ( https://en.wikipedia.org/wiki/Visual_programming_language ).  Flowcode is one, but there are others.

I have never used any of them.  When something is complex, I may do a flowchart, then convert that to Assembly.  Over the years, one accumulates their own libraries to make the conversion easier.

For high level signal processing programs graphical programming languages can be useful, as they are quite similar to a schematic, but for implementing low level routines they can be a nightmare to debug. In particular, Simulink is useful for programming regulators, but it is quite expensive

[hli]

The problem is, that even your 5th level (natural programming) is still _programming_. Which means it needs at least:

• decision support (IF/ELSE)
• loops (at least something like WHILE)
• storing data (variables or values of some kind)
• arithmetic
• input / output
• and for larger programs support for abstractions / structuring the logic (e.g. sub-routines)

I would say that most programming languages just differ in the last part - how they allow / support you how to structure your logic. Apart from that it does not really matter how you present that to the user - there will be the complexity of your actual problem, and you cannot make that go away.
One can simplify by reducing the capabilities presented to the user, e.g.

• removing control structures / structure support, and you get something like Excel
• provide only simple flows (e.g. business process notation)
• specialize to specific problem areas (e.g. statistics, such as R)

Using natural language adds the problem of not being specific enough - most of what you express in regular speach can have multiple meanings.