This thread on Hacker News terrifies me

[Nick Sabalausky (Abscissa)]

On 09/01/2018 03:47 PM, Everlast wrote:
> 
> It's because programming is done completely wrong. All we do is program 
> like it's 1952 all wrapped up in a nice box and bow tie. WE should have 
> tools and a compiler design that all work interconnected with complete 
> graphical interfaces that aren't based in the text gui world(an IDE is 
> just a fancy text editor). I'm talking about 3D code representation 
> using graphics so projects can be navigated  visually in a dynamic way 
> and many other things.
> 
> The current programming model is reaching diminishing returns. Programs 
> cannot get much more complicated because the environment in which they 
> are written cannot support them(complexity != size).
> 
> We have amazing tools available to do amazing things but programming is 
> still treated like punch cards, just on acid. I'd like to get totally 
> away from punch cards.
> 
> I total rewrite of all aspects of programming should be done(from 
> "object" files(no more, they are not needed, at least not in the form 
> they are), the IDE(it should be more like a video game(in the sense of 
> graphical use) and provide extensive information and debugging support 
> all at a finger tip away), from the tools, to the design of 
> applications, etc.
> 
> One day we will get there...
> 

GUI programming has been attempted a lot. (See Scratch for one of the 
latest, possibly most successful attempts). But there are real, 
practical reasons it's never made significant in-roads (yet).

There are really two main, but largely independent, aspects to what 
you're describing: Visual representation, and physical interface:

A. Visual representation:
-------------------------

By visual representation, I mean "some kind of text, or UML-ish 
diagrams, or 3D environment, etc".

What's important to keep in mind here is: The *fundamental concepts* 
involved in programming are inherently abstract, and thus equally 
applicable to whatever visual representation is used.

If you're going to make a diagram-based or VR-based programming tool, it 
will still be using the same fundamental concepts that are already 
established in text-based programming: Imperative loops, conditionals 
and variables. Functional/declarative immutability, purity and 
high-order funcs. Encapsulation. Pipelines (like ranges). Etc. And 
indeed, all GUI based programming tools have worked this way. Because 
how *else* are they going to work?

If what you're really looking for is something that replaces or 
transcends all of those existing, fundamental programming concepts, then 
what you're *really* looking for is a new fundamental programming 
concept, not a visual representation. And ance you DO invent a new 
fundamental programming concept, being abstract, it will again be 
applicable to a variety of possible visual representations.

That said, it is true some concepts may be more readily amenable to 
certain visual representations than others. But, at least for all the 
currently-known concepts, any combination of concept and representation 
can certainly be made to work.

B. Physical interface:
----------------------

By this I mean both actual input devices (keyboards, controllers, 
pointing devices) and also the mappings from their affordances (ie, what 
you can do with them: push button x, tilt stick's axis Y, point, move, 
rotate...) to specific actions taken on the visual representation 
(navigate, modify, etc.)

The mappings, of course, tend to be highly dependant on the visual 
representation (although, theoretically, they don't strictly HAVE to 
be). The devices themselves, less so: For example, many of us use a 
pointing device to help us navigate text. Meanwhile, 3D 
modelers/animators find it's MUCH more efficient to deal with their 3D 
models and environments by including heavy use of the keyboard in their 
workflow instead of *just* a mouse and/or wacom alone.

An important point here, is that using a keyboard has a tendency to be 
much more efficient for a much wider range of interactions than, say, a 
pointing device, like a mouse or touchscreen. There are some things a 
mouse or touchscreen is better at (ie, pointing and learning curve), but 
even on a touchscreen, pointing takes more time than pushing a button 
and is somewhat less composable with additional actions than, again, 
pushing/holding a key on a keyboard.

This means that while pointing, and indeed, direct manipulation in 
general, can be very beneficial in an interface, placing too much 
reliance on it will actually make the user LESS productive.

The result:
-----------

For programming to transcend the current text/language model, *without* 
harming either productivity or programming power (as all attempts so far 
have done), we will first need to invent entirely new high-level 
concepts which are simultaneously both simple/high-level enough AND 
powerful enough to obsolete most of the nitty-gritty lower-level 
concepts we programmers still need to deal with on a regular basis.

And once we do that, those new super-programming concepts (being the 
abstract concepts that they inherently are) will still be independent of 
visual representation. They might finally be sufficiently powerful AND 
simple that they *CAN* be used productively with graphical 
non-text-language representation...but they still will not *require* 
such a graphical representation.

That's why programming is still "stuck" in last century's text-based 
model: Because it's not actually stuck: It still has significant 
deal-winning benefits over newer developments. And that's because, even 
when "newer" does provide improvements, newer still isn't *inherently* 
superior on *all* counts. That's a fact of life that is easily, and 
frequently, forgotten in fast-moving domains.