Hacker News Reader

Comment by mikece | Hacker News Reader

I've been hearing about "no code" or "no programmer required" business solutions for over 20 years. Cynically, I encourage this thinking because my billable rate to untangle someone else's hot mess when urgent deadlines are looming goes up. Practically speaking, if the business problems being solved are complex you might be able to pull off a low-code solution but without knowledge and practice of the essential architectural patterns of software development a novice will paint themselves into a corner before they even know what they are doing, requiring an expert to come in an clean things up.

View on HN

Nearly 40 years for me; I remember reading about The Last One [1] back in 81.

[1] https://en.wikipedia.org/wiki/The_Last_One_(software)

The pipe dream is far older than that.

Around 1960 some people seriously claimed that within about 5 years there would be no more professional programmers because with this new language, everyone could write the software they need themselves, since it was so easy to use.

The language was COBOL.

Oh, and look, this one still seems to be around: http://www.makeyourownsoftware.com/

Thanks for sharing—that site is a real gem!

> Around 1960 some people seriously claimed that within about 5 years there would be no more professional programmers because with this new language, everyone could write the software they need themselves, since it was so easy to use.

Of course that prediction seems quaint now, but I posit that the prediction failed because they greatly underestimated the increase in demand of software as much as overestimated the expressiveness/productivity increase of COBOL (and later systems).

Heck, considering what a professional programmers job might have been like in the 50s, its not far fetched at all that such profession indeed has disappeared as modern programmers work at such a different level of abstraction

Yes, given that back then people were typically working in assembler (with frequently changing platforms, to boot) and writing relatively simple data processing applications, the claim is somewhat understandable.

But I think the main thing it failed to take into account is more how hard it is to translate business requirements into complete and unambiguous instructions.

The even bigger thing is how better tools and abstraction create more demand for code, as more can be done. The entire history of computers has seen software demand increase over time.

This reminds me of the Jevons paradox from economics. The story is that when steam engines became way more efficient, the demand for coal exploded. Even though each engine used much less energy, the total amount of energy consumed went through the roof.

Oh my god, I was convinced until the end that it was a top notch joke site... then I got to the credit card form.

There used to be an early ARPAnet mailing list called "INFO-COBOL@MC", that was actually for exchanging jokes and copyrighted Dave Barry articles (which was an officially prohibited abuse of the government sponsored ARPAnet). It was a great stealth name because nobody took COBOL seriously, and we would just laugh at people who posted COBOL questions.

Here are some old INFO-COBOL messages archived in the MIT-AI HUMOR directory:

http://its.svensson.org/HUMOR%3bINFO%20COBOL

Then there was The TTY of Geoffrey S. Goodfellow's spin-off, the specialized "DB-LOVERS" mailing list, just for dead baby jokes.

https://news.ycombinator.com/item?id=8418591

Speaking of COBOL jokes:

https://medium.com/@donhopkins/cobol-forever-1a49f7d28a39

That's pretty funny, thanks for sharing!

To be fair, afaik (second hand account), when COBOL appeared it drove a bunch of non-expert programmers into the field, mostly domain-driven people. It really was a new age of programming. (which then-experts didn't really see in a positive light)

Episode of Command Line Heroes by Red Hat about COBOL: https://www.redhat.com/en/command-line-heroes/season-3/the-i...

I think it's a little unfair to characterize COBOL as a failure in that regard. It tremendously increased the accessibility and use of programming and computing in general by way of consequence; it's been instrumental in allowing the programmer population to grow massively.

Granted, extraordinary superlative claims never materialize, but the intent, the vision is important ime. Especially in business settings.

Yes, in the 80's and 90's we called it CASE (Computer Aided Software Engineering). It was just as fascinating then and equally impractical now. Text turns out to be a great, compact way to convey ideas or instructions which is the heart of software development.

I don't think text is nearly as compact as people claim it to be.

I dabble in graphical programming languages from time-to-time, and one feature they all share is the editing environment for code makes entire categories of syntax error impossible; there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together." It's a level of integration between the space of all possible arrangements of elements and the set of arrangements that constitute valid programs that I see text-based IDEs approach, but struggle to catch up with. And I suspect part of the challenge is that as a tool for describing programs, sequential text has too much dimensionality; the set of strings of sequential text is much, much larger than the set of valid programs, and it's easy to put text sequences together that aren't valid.

> there is no way in the language's design to pass a string to a function that only accepts a number, for example, because the "blocks just don't fit together."

Which is easily achieved by the first typed language that comes to hand, no?

Not without an IDE. It's still extremely possible (in all text-based languages I'm familiar with) to write the program with a typecheck error; the typechecker will gleefully catch it for you. At typecheck time. Often (depending on my toolchain) minutes after I've written the offending code and mounds of code depending on it.

It's possible, with many languages, to write IDEs that will make this hard, but I've yet to find one that makes it impossible. Certainly not in the same way that, for example, Scratch will simply refuse to let the offending blocks click together. I certainly don't advocate transitioning from text languages to Scratch, but I think there's meat on the bones of asking the question "Why, when I'm editing code in text-based languages, am I even allowed to reference a variable that is demonstrably the wrong type? What benefit is that gaining me?" Because I think the answer in a lot of cases is "No real benefit; editing, typechecking, and compilation have just historically been disjoint concerns with no feedback channel because writing those is hard."

Are you suggesting that you can do visual development without anything more than a text editor?

Apples to apples would mean comparing your Scratch experience with a nice IDE for a typed language.

"It's possible, with many languages, to write IDEs that will make this hard, but I've yet to find one that makes it impossible."

I'm strong believer, even if that belief doesn't come up often, in structured editing[1] which sort of bridges the gap and makes writing invalid programs impossible, at least syntatically but I don't think adding type level checking is a big jump and I haven't kept up with research so that might already be there. Unfortunately I don't know any successful examples of that beyond research projects that I could point out. I remember hearing rumors that some of the LISP machines might have veered to that direction, but idk

Even more I don't believe in plain monospaced ASCII being the ultimate format for code. Luckily there I know one example that goes at least a bit further: Fortress[2], a language from Sun that had richer rendering format available (although the underlying form was still afaik textual). And of course APL is another example, albeit bit less easily approachable. Raku also has some cute tricks (of course it does) with unicode characters[3], but they are more really just tricks that radical revolution in design.

There are also lots of other interesting ideas on how to format and layout code in the research, just one random example is "code bubbles"/"debugger canvas"[4]

While I think all this and so much more has great potential, there is huge cultural entrenchment around simple text based programming that seems unlikely to be overcome any time soon. As for graphical programming, I think the common failure there is being often also heavily mouse-driven, while keyboard is really powerful input device.

[1] https://en.wikipedia.org/wiki/Structure_editor also known as projectional editor

[2] https://web.archive.org/web/20060819201513/http://research.s... has some examples, slide 33

[3] https://docs.raku.org/language/unicode_ascii for example "The atomic operators have U+269B ATOM SYMBOL incorporated into them. Their ASCII equivalents are ordinary subroutines, not operators". Obviously.

[4] https://www.microsoft.com/en-us/research/publication/debugge... paper has few screenshots

Re: "The atomic operators have U+269B ATOM SYMBOL incorporated into them. Their ASCII equivalents are ordinary subroutines, not operators". Obviously."

Except for the short-circuiting operators (such as || and &&) and the assignment operator, all operators in Raku are just subs with a special name. Adding your own operator to the language is as simple as adding a subroutine, e.g.:

    sub prefix:<√>($value) { sqrt($value) }
    say √9;   # 3

Do you have examples of delivering actual production applications with a graphical programming language in less time than developing the same thing with a traditional text based language?

I don't, and the gap is (IMHO) wide between where the ones I've used are and where they'd need to be to compete with text input. The main hindrance is UI; keyboard is a relatively high-bandwidth input (in terms of bytes-per-second of usable signal), and most of the graphical languages I've seen are heavily mouse-centric with not enough accelerator keys to close the gap. I can generate a lot of incorrect code-per-second with a keyboard, but I can also generate a lot of code-per-second period.

I'm hoping someone can close the gap and bring us a graphical language with a robust keyboard interface to navigate through it and edit it, with the advantage of strong edit-time validation excluding invalid programs. If someone can close the gap, it'd be a hell of a thing to see.

FWIW I would argue that Sketch (and other applications like it, plus Unity, etc) are most accurately described as graphical programming languages -- highly domain-specific ones.

Conveying ideas and instructions is also at the heart of architecture. Digital representations are embedded at every stage of a contemporary building design and construction pipeline. 98% of those representations are something else than text.

I strongly believe software application design is fundamentally closer to architectural design than the kind of work done in a purely textual realm — say, writing a novel or a research paper. But it's a really hard nut to crack.

I hope CASE today is like AI and neural nets were in early 2000s — a bit of a laughing stock, "something people in the 1980s wasted a lot of time on but nowadays everyone knows it doesn't work."

I'm actually quite fond of some "no/low code" tools but there is a threshold of complexity beyond which if you use them then terrible abominations will result that are far more complex then the equivalent code and actually require more technical expertise then 'code' - so you end up with components that only a skilled developer can maintain in a platform that developers will hate.

I’ve dealt with a few of these too, and the point at which you should just give up and switch to python/bash/anything always comes sooner than you think.

By the way, this is an anti-pattern known as a Turing tarpit: https://en.wikipedia.org/wiki/Turing_tarpit

The classic magnet for this: Microsoft Access. It's a fantastic force-multiplier until Dr. Jekyll turns into Mr. Hyde and begins grinding your business to a halt.

Absolutely true.

There are also a large number of projects - maybe majority? - that never reach that level of complexity; and the "no/low code" solution (like Excel, Access, etc.) enabled a non-engineer to solve a business problem without hiring any engineers.

That's where these kinds of systems shine, if done right; allow a "non-engineer" who has a logical mind / the engineering tao to create solutions without having to learn traditional development toolchain.

Reply on news.ycombinator.com