8 ms·

David Parnas in 1985: Throughout my career in computing I have heard people claim that the solution to the software problem is automatic programming. All that

David Parnas in 1985: Throughout my career in computing I have heard people claim that the solution to the software problem is automatic programming. All that one has to do is write the specifications for the software, and the computer will find a program [...] The oldest paper known to me that discusses automatic programming was written in the 1940s by Saul Gorn when he was working at the Aberdeen Proving Ground. This paper, entitled “Is Automatic Programming Feasible?” was classified for a while. It answered the question positively. At that time, programs were fed into computers on paper tapes. The programmer worked the punch directly and actually looked at the holes in the tape. I have seen programmers “patch” programs by literally patching the paper tape. The automatic programming system considered by Gorn in that paper was an assembler in today’s terminology. All that one would have to do with his automatic programming system would be to write a code such as CLA, and the computer would automatically punch the proper holes in the tape. In this way, the programmer’s task would be performed automatically by the computer. In later years the phrase was used to refer to program generation from languages such as IT, FORTRAN, and ALGOL. In each case, the programmer entered a specification of what he wanted, and the computer produced the program in the language of the machine. In short, automatic programming always has been a euphemism for programming with a higher-level language than was then available to the programmer. Research in automatic programming is simply research in the implementation of higher-level programming languages. http://web.stanford.edu/class/cs99r/readings/parnas1.pdf http://web.stanford.edu/class/cs99r/readings/parnas1.pdf

commandlinefan 6y ago
> automatic programming always has been a euphemism for programming with a higher-level language than was then available to the programmer And it seems to me that progress is going in the opposite direction than "they" want. Every time you move up the abstraction stack, you're surrendering some decision-making to the lower levels. If the underlying technologies guess right every time, you have no need to understand what they're doing. The first time they guess wrong, you have to spend a lot of time understanding not only how the lower layers work, and not only why they did the "wrong" thing in this one instance, but how to fiddle correctly with the layer you're operating at to get the lower layers to behave properly. You can work quickly with the high-level abstractions only as long as you understand the lower levels reasonably well. Optimal machine learning requires a good understanding of memory cache hierarchies, parallel instructions and complexity theory - not to mention the statistics and calculus that it's formed on. And "optimal" isn't some trivial "save a few seconds" but often "return an answer within the lifetime of the universe".
- jimbokun 6y ago
  Leaky Abstractions: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
- jdefr89 6y ago
  Security is also something to be mindful of. A lot of my work as a professional vulnerability researcher is just using my low-level knowledge to circumvent higher level abstractions people usually ignore. The abstractions aren't seeming to slow down and I fear soon only a few will be able to peak into most or all of level needed to provide reasonable security. Whenever I see a system built with "Automated" technologies, I usually start there to find flaws. In order to truly utilize high level abstractions it is useful to actually understand what provides them.
  - commandlinefan 6y ago
    I feel like I was lucky to have started learning computers when I did in the late 80's. There weren't nearly so many "time saving" abstractions back then, so if you wanted to see anything happen, you had to have a good understanding of what was going on under the hood. Although it was at times frustrating back then to put so much effort into something as simple as drawing a circle on a screen, I'm fortunate that I was forced to spend so much time internalizing the details - I don't know if I would have the patience to learn it all if I was starting right now if I could see that shortcuts existed.
    - dahhakd 6y ago
      It really depends on the specific person. I started programming in 2006 at 21yo and I don't feel like I missed anything at all. Spent a lot of time reading and researching things anyway. Higher abstractions doesn't necessarily mean lower complexity.
  - deleted 6y ago
    [deleted]
- zby 6y ago
jimbokun 6y ago
> All that one has to do is write the specifications for the software ...and we call that specification a computer program.
- xythian 6y ago
  I see where you're going here. It might help if we construct a specific syntax and grammar for writing specifications for software. It'll be helpful for all of us if we can make our specifications as clear and efficient as possible. We could even call this combination of a syntax and grammar a programming language. Just imagine a world when we have these programming languages to help us encode the specifications for our software. Wild! :)
  - agustif 6y ago
    User stories
    - RobertKerans 6y ago
      ...and so, we reach Cucumber, the apex of programming
- ghayes 6y ago
  I like to think of the square root of x function: r such that r * r = x That’s a specification that gives you no knowledge how to solve the problem. You can definitely have precise specifications that do not directly correlate to machine instructions.
  - a1369209993 6y ago
    And: print "Hello, World!" gives no knowledge how to put text on the screen. Conversely, there's no reason a standard library couldn't include: fn (*) :: Num -> Num -> Num fn (a * b) = [machine code goes here] un (_ * d) n = n/d un (d * _) n = n/d un (_ * _) n = sqrt(n) or similar.
  - earleybird 6y ago
closeparen 6y ago
A sister team at my company is quite proud of its rules engine that allows non-programmers to quickly implement business policies using its DSL in a web UI. With the years and postmortems gone by it has grown half-assed attempts at version control, code review, unit testing, deployment pipelines, etc. Now it’s very obviously just a shitty, hobbled software development environment. It’s used primarily because the team that owns it is aggressive about blocking design reviews for “duplication of effort” if you propose to use normal software development tools anywhere near its domain.
- musingsole 6y ago
  I was almost bitten by a project like this, despite ample protests the whole way long that "configuration" was just becoming a "crappy programming language". All too often I still have to deal with someone who thinks because logic hinges on a value in a JSON file, they've magically abstracted away the concern of what it is that the code should be doing.
  - mmmm2 6y ago
    It reminds me of Ant configuration files. They have loops and if else: <for list="a,b,c,d,e" param="letter"> <sequential> <echo>Letter @{letter}</echo> </sequential> </for> I call it The Devil's Lisp :).
    - Pokepokalypse 6y ago
      oh, then you'll love terraform.
      - closeparen 6y ago
        At least what you're writing down in Terraform is not actually a procedure.
    - dahhakd 6y ago
      Man, I'm not from the Java world, but these days I had to deal with it for a project and had to mess with ant builds, which I have never dealt with before. I was totally baffled. I just do not understand why would anyone subject themselfs to such levels of pain.
brundolf 6y ago
This is a good insight. So, clearly, higher-level languages have been an enormous success. But "no-code", as we mean the term today, has still (mostly) been a failure. So then what do we actually mean by "no-code" these days? I think "no-code", today, has the unspoken implication of "graphical". Okay, so why are "graphical coding" systems (languages?) mostly unsuccessful? There are some clear exceptions like Unreal Engine's Blueprints and certain WYSIWYG web editors like Squarespace, but the great majority of programming is still done in what comes down to, at the end of the day, text files. There may be more and more elaborate editors built atop these text files, but the "bones" of the code is always available, and never too far out of reach. My pet theory is that this last bit is the differentiator. In a totally graphical programming environment, the programmer never has to be exposed to the underlying format directly. This perhaps encourages proprietary stacks, where the GUI is all that's known and the substance of the "code" itself may never even be made available to those who seek it out. Maybe this arrangement keeps these "languages" siloed, and therefore keeps them from gaining real traction. It's hard for a thriving ecosystem to evolve around a closed format. Competing tools, editors, compilers, open transfer via regular files, translation, etc are all stifled. You end up totally dependent on one company for all of your needs. For some projects the value-proposition still works out; for most it doesn't. If so, here's my proposal: instead of focusing on all-in-one no-code environments, focus on creating graphical tooling for existing languages. Or even, creating new (text-based!) programming languages that are designed from the get-go with advanced (graphical?) tooling in mind, while still having that real, open, core source-of-truth underneath it. We've seen echoes of this already: Rust's features would make it nearly unusable without its (excellent) user-friendly tooling. Design apps like Sketch can output React source code. Pure-functional languages like Clojure really thrive with an editor that has inline-eval. I think if "no-code" is ever going to catch on for real, it needs to be less afraid of code. On the other hand: is the value-add really the graphical interface, or is it the "height" of the language? In the latter case, maybe it's more important that we explore even-higher-level languages, and set aside the graphical part as a distraction. Or, maybe we combine the two goals: create higher-level-languages that also lend themselves to graphical UIs, but are still grounded in formalized text underneath.
- megameter 6y ago
  The common denomination in textual coding is text itself: There were historically some differences by locale, encoding, and line ending, but we have managed to converge on a sufficiently encompassing standard with UTF-8 text that the rest can reasonably-if-imperfectly be dealt with by the text processing code, and this is the source of friction: our text editors and terminal emulators are great - so great, that it's hard to get out of the path dependency involved in utilizing them. It isn't just the interactive cursor, or copy-paste, or search-and-replace, or even regular expressions...it's decades of accumulated solutions that can handle every concievable text problem. Every time we go to some other way of describing a document we lose all that text editing infrastructure, which is such a huge setback that no alternate solution has yet hit a widespread critical mass, only specific niches in specific domains. Which doesn't make text good, it makes it worse-is-better! As I see it, the probable way forward would not be in language design, but in formats and editors. Breaking through the dependency will be a slow process.
YeGoblynQueenne 6y ago
The above describes what is today called program synthesis, i.e. generating a program from a complete specification. There is a parallel discipline, of inductive programming, or pgoram induction, which is the generation of programs from incomplete specifications, which usuall means examples (specifically, positive and negative examples of the inputs and outputs of the target program). Together, program synthesis and program induction, comprise the automatic programming field, which has advanced a little bit since the 1980's, I dare say. Inductive progamming is very much a branch of machine learning and that's the reason most haven't heard of it (i.e. it's machine learning that is not deep learning). The main approaches are Inductive Functional Programming (IFP) and Inductive Logic Programming (ILP, which I study for my PhD). IFP systems learn programs in functional programming languages, like Haskell, and ILP systems learn progarms in logic programming languages like Prolog. And that is why neither is used in industry. That is to say, both approaches work just fine - but they're not going to be adopted anytime soon (if I may be a bit of a pessimist) because most programmers lack the background to understand them and they can't be replaced by a large dataset. A quick introduction to Inductive Programming is on the wikipedia articles: https://en.wikipedia.org/wiki/Inductive_programming https://en.wikipedia.org/wiki/Inductive_programming I suggest to follow the links to the article's sources and to search for IFP and ILP systems separately. Two prominent representatives are Magic Haskeller (IFP) and Aleph (ILP): http://nautilus.cs.miyazaki-u.ac.jp/~skata/MagicHaskeller.html http://nautilus.cs.miyazaki-u.ac.jp/~skata/MagicHaskeller.ht... https://www.cs.ox.ac.uk/activities/programinduction/Aleph/aleph.html https://www.cs.ox.ac.uk/activities/programinduction/Aleph/al... More can be found on the inductive-programming.org website: https://www.inductive-programming.org/ip-systems.html https://www.inductive-programming.org/ip-systems.html
- overkalix 6y ago
  .
  - Ma8ee 6y ago
    Tap on the time of the comment to see it in isolation. From there you can favourite it instead of cluttering the thread.
- 6y ago
m463 6y ago
That's an interesting perspective - the same discussion when code was assembler and paper tape. I suspect that "code" will just keep on getting higher and higher level. This means that humans will be able to express themselves and have an outlet to automate this. Maybe the real question will be at what point will people say the specification "is not code". and what will it be? English? Mathematical notation? doxygen? A notebook? Latin?
- kordlessagain 6y ago
  Code are not models and models are not code!
readams 6y ago
A key distinction here is whether you could write your no-code system using your no-code system. If you no-code system is self-hosting, then you've made a higher-level programming language. Otherwise, it's a tool that lives on some dimension other than "programming language".
blackrock 6y ago
Admittedly, Assembler is much easier than machine code. And machine code is much easier than paper tapes. Also, this must be where “patching” code came from. Earlier in my career, I never understood the reference when they said they released a new patch.

commandlinefan 6y ago

> automatic programming always has been a euphemism for programming with a higher-level language than was then available to the programmer And it seems to me that progress is going in the opposite direction than "they" want. Every time you move up the abstraction stack, you're surrendering some decision-making to the lower levels. If the underlying technologies guess right every time, you have no need to understand what they're doing. The first time they guess wrong, you have to spend a lot of time understanding not only how the lower layers work, and not only why they did the "wrong" thing in this one instance, but how to fiddle correctly with the layer you're operating at to get the lower layers to behave properly. You can work quickly with the high-level abstractions only as long as you understand the lower levels reasonably well. Optimal machine learning requires a good understanding of memory cache hierarchies, parallel instructions and complexity theory - not to mention the statistics and calculus that it's formed on. And "optimal" isn't some trivial "save a few seconds" but often "return an answer within the lifetime of the universe".

jimbokun 6y ago
Leaky Abstractions: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
jdefr89 6y ago
Security is also something to be mindful of. A lot of my work as a professional vulnerability researcher is just using my low-level knowledge to circumvent higher level abstractions people usually ignore. The abstractions aren't seeming to slow down and I fear soon only a few will be able to peak into most or all of level needed to provide reasonable security. Whenever I see a system built with "Automated" technologies, I usually start there to find flaws. In order to truly utilize high level abstractions it is useful to actually understand what provides them.
- commandlinefan 6y ago
  I feel like I was lucky to have started learning computers when I did in the late 80's. There weren't nearly so many "time saving" abstractions back then, so if you wanted to see anything happen, you had to have a good understanding of what was going on under the hood. Although it was at times frustrating back then to put so much effort into something as simple as drawing a circle on a screen, I'm fortunate that I was forced to spend so much time internalizing the details - I don't know if I would have the patience to learn it all if I was starting right now if I could see that shortcuts existed.
  - dahhakd 6y ago
    It really depends on the specific person. I started programming in 2006 at 21yo and I don't feel like I missed anything at all. Spent a lot of time reading and researching things anyway. Higher abstractions doesn't necessarily mean lower complexity.
- deleted 6y ago
  [deleted]
zby 6y ago

jimbokun 6y ago

> All that one has to do is write the specifications for the software ...and we call that specification a computer program.

xythian 6y ago
I see where you're going here. It might help if we construct a specific syntax and grammar for writing specifications for software. It'll be helpful for all of us if we can make our specifications as clear and efficient as possible. We could even call this combination of a syntax and grammar a programming language. Just imagine a world when we have these programming languages to help us encode the specifications for our software. Wild! :)
- agustif 6y ago
  User stories
  - RobertKerans 6y ago
    ...and so, we reach Cucumber, the apex of programming
ghayes 6y ago
I like to think of the square root of x function: r such that r * r = x That’s a specification that gives you no knowledge how to solve the problem. You can definitely have precise specifications that do not directly correlate to machine instructions.
- a1369209993 6y ago
  And: print "Hello, World!" gives no knowledge how to put text on the screen. Conversely, there's no reason a standard library couldn't include: fn (*) :: Num -> Num -> Num fn (a * b) = [machine code goes here] un (_ * d) n = n/d un (d * _) n = n/d un (_ * _) n = sqrt(n) or similar.
- earleybird 6y ago

closeparen 6y ago

A sister team at my company is quite proud of its rules engine that allows non-programmers to quickly implement business policies using its DSL in a web UI. With the years and postmortems gone by it has grown half-assed attempts at version control, code review, unit testing, deployment pipelines, etc. Now it’s very obviously just a shitty, hobbled software development environment. It’s used primarily because the team that owns it is aggressive about blocking design reviews for “duplication of effort” if you propose to use normal software development tools anywhere near its domain.

musingsole 6y ago
I was almost bitten by a project like this, despite ample protests the whole way long that "configuration" was just becoming a "crappy programming language". All too often I still have to deal with someone who thinks because logic hinges on a value in a JSON file, they've magically abstracted away the concern of what it is that the code should be doing.
- mmmm2 6y ago
  It reminds me of Ant configuration files. They have loops and if else: <for list="a,b,c,d,e" param="letter"> <sequential> <echo>Letter @{letter}</echo> </sequential> </for> I call it The Devil's Lisp :).
  - Pokepokalypse 6y ago
    oh, then you'll love terraform.
    - closeparen 6y ago
      At least what you're writing down in Terraform is not actually a procedure.
  - dahhakd 6y ago
    Man, I'm not from the Java world, but these days I had to deal with it for a project and had to mess with ant builds, which I have never dealt with before. I was totally baffled. I just do not understand why would anyone subject themselfs to such levels of pain.

brundolf 6y ago

This is a good insight. So, clearly, higher-level languages have been an enormous success. But "no-code", as we mean the term today, has still (mostly) been a failure. So then what do we actually mean by "no-code" these days? I think "no-code", today, has the unspoken implication of "graphical". Okay, so why are "graphical coding" systems (languages?) mostly unsuccessful? There are some clear exceptions like Unreal Engine's Blueprints and certain WYSIWYG web editors like Squarespace, but the great majority of programming is still done in what comes down to, at the end of the day, text files. There may be more and more elaborate editors built atop these text files, but the "bones" of the code is always available, and never too far out of reach. My pet theory is that this last bit is the differentiator. In a totally graphical programming environment, the programmer never has to be exposed to the underlying format directly. This perhaps encourages proprietary stacks, where the GUI is all that's known and the substance of the "code" itself may never even be made available to those who seek it out. Maybe this arrangement keeps these "languages" siloed, and therefore keeps them from gaining real traction. It's hard for a thriving ecosystem to evolve around a closed format. Competing tools, editors, compilers, open transfer via regular files, translation, etc are all stifled. You end up totally dependent on one company for all of your needs. For some projects the value-proposition still works out; for most it doesn't. If so, here's my proposal: instead of focusing on all-in-one no-code environments, focus on creating graphical tooling for existing languages. Or even, creating new (text-based!) programming languages that are designed from the get-go with advanced (graphical?) tooling in mind, while still having that real, open, core source-of-truth underneath it. We've seen echoes of this already: Rust's features would make it nearly unusable without its (excellent) user-friendly tooling. Design apps like Sketch can output React source code. Pure-functional languages like Clojure really thrive with an editor that has inline-eval. I think if "no-code" is ever going to catch on for real, it needs to be less afraid of code. On the other hand: is the value-add really the graphical interface, or is it the "height" of the language? In the latter case, maybe it's more important that we explore even-higher-level languages, and set aside the graphical part as a distraction. Or, maybe we combine the two goals: create higher-level-languages that also lend themselves to graphical UIs, but are still grounded in formalized text underneath.

megameter 6y ago
The common denomination in textual coding is text itself: There were historically some differences by locale, encoding, and line ending, but we have managed to converge on a sufficiently encompassing standard with UTF-8 text that the rest can reasonably-if-imperfectly be dealt with by the text processing code, and this is the source of friction: our text editors and terminal emulators are great - so great, that it's hard to get out of the path dependency involved in utilizing them. It isn't just the interactive cursor, or copy-paste, or search-and-replace, or even regular expressions...it's decades of accumulated solutions that can handle every concievable text problem. Every time we go to some other way of describing a document we lose all that text editing infrastructure, which is such a huge setback that no alternate solution has yet hit a widespread critical mass, only specific niches in specific domains. Which doesn't make text good, it makes it worse-is-better! As I see it, the probable way forward would not be in language design, but in formats and editors. Breaking through the dependency will be a slow process.

YeGoblynQueenne 6y ago

The above describes what is today called program synthesis, i.e. generating a program from a complete specification. There is a parallel discipline, of inductive programming, or pgoram induction, which is the generation of programs from incomplete specifications, which usuall means examples (specifically, positive and negative examples of the inputs and outputs of the target program). Together, program synthesis and program induction, comprise the automatic programming field, which has advanced a little bit since the 1980's, I dare say. Inductive progamming is very much a branch of machine learning and that's the reason most haven't heard of it (i.e. it's machine learning that is not deep learning). The main approaches are Inductive Functional Programming (IFP) and Inductive Logic Programming (ILP, which I study for my PhD). IFP systems learn programs in functional programming languages, like Haskell, and ILP systems learn progarms in logic programming languages like Prolog. And that is why neither is used in industry. That is to say, both approaches work just fine - but they're not going to be adopted anytime soon (if I may be a bit of a pessimist) because most programmers lack the background to understand them and they can't be replaced by a large dataset. A quick introduction to Inductive Programming is on the wikipedia articles: https://en.wikipedia.org/wiki/Inductive_programming https://en.wikipedia.org/wiki/Inductive_programming I suggest to follow the links to the article's sources and to search for IFP and ILP systems separately. Two prominent representatives are Magic Haskeller (IFP) and Aleph (ILP): http://nautilus.cs.miyazaki-u.ac.jp/~skata/MagicHaskeller.html http://nautilus.cs.miyazaki-u.ac.jp/~skata/MagicHaskeller.ht... https://www.cs.ox.ac.uk/activities/programinduction/Aleph/aleph.html https://www.cs.ox.ac.uk/activities/programinduction/Aleph/al... More can be found on the inductive-programming.org website: https://www.inductive-programming.org/ip-systems.html https://www.inductive-programming.org/ip-systems.html

overkalix 6y ago
.
- Ma8ee 6y ago
  Tap on the time of the comment to see it in isolation. From there you can favourite it instead of cluttering the thread.
6y ago

m463 6y ago

That's an interesting perspective - the same discussion when code was assembler and paper tape. I suspect that "code" will just keep on getting higher and higher level. This means that humans will be able to express themselves and have an outlet to automate this. Maybe the real question will be at what point will people say the specification "is not code". and what will it be? English? Mathematical notation? doxygen? A notebook? Latin?

kordlessagain 6y ago
Code are not models and models are not code!

readams 6y ago

A key distinction here is whether you could write your no-code system using your no-code system. If you no-code system is self-hosting, then you've made a higher-level programming language. Otherwise, it's a tool that lives on some dimension other than "programming language".

blackrock 6y ago

Admittedly, Assembler is much easier than machine code. And machine code is much easier than paper tapes. Also, this must be where “patching” code came from. Earlier in my career, I never understood the reference when they said they released a new patch.