Because smarter people than I have answered this question:

> Programs must be written for people to read, and only incidentally for machines to execute. - Abelson

As to why that might be the case: when the bugs you wrote are found; the edge-cases you missed are discovered; or the vulnerabilities you didn’t know about it are unearthed, another person, sometimes future you, will have to read your intentions; try to interpret them; and address the above. When you code, you are telling a story and are in control of the narrative. When you paint a picture (I.e. graphical) you have less control over the narrative and interpretation.

Or at least that’s my hot-take.

Your comment is extremely thought-provoking, and I immediately find it true of myself, but artists are quite capable of telling stories in pictures in a way that compels an understanding that goes deeper than reference to text - might it not just be that you and I have less control over the narrative and interpretation than in text because that happens to be our preferred medium?

What imagery gives you is an intuitive sense of how you should, or how the artist did, feel about subject matter. Imagine at a glance knowing which parts the artist was proud of, which they considered an unglamorous but necessary hack, and what they considered ugliness that was forced upon them and unnecessary to the program as a whole, and viscerally "knowing" what areas are wrong?

I look forward to a future where we understand how to teach well enough that artist-programmer hybrids are more common-place.

I see what you mean, but I think that we are both correct - I agree entirely that stories in pictures can give both a deeper or quicker understanding of most topics - the issue is that they cannot clarify or directly state something. The best works of art are open to many interpretations - or we would never re-read imaginative literature, re-visit galleries we had been to previously, and so on.

On the other hand, for an instruction manual, there is little room for interpretation as the words only have so many definitions (though read "Authority and American Usage" by DFW to really open a can of worms), so we do not often re-read a manual for a process we know (though it could be argued we ought to). I also concede that for simple tasks entirely visual instruction manuals suffice, and to that end I will say that I've enjoyed writing simple things with Scratch (for example), but I would hesitate to write a program that needed to be maintained with a visual language.

To put a more fine point on it: For the top 1% of programmers it may be the case that they would work best in a visual language, but the maintenance and support of those applications by the bottom 99% would erase many of the gains (I am here assuming programming as a professional activity in support of an organization's goals, not, as it were, a strictly artistic personal activity). In a professional context - I am unfeeling about what my predecessors felt about any part of the code, I only need to know what their intentions were, and I need them to tell me so, as explicitly as possible.

*Edit: I think that there may be use in clarifying whether we are discussing professional programming or programming as a hobby - because I enjoy both, and while I enjoy learning and using some languages (cough Haskell, Lisp) for myself, I would be very hesitant to use them professionally due to the difficulty others have in maintaining/understanding them. (Food for thought: why do Java, Javascript, and Python absolutely dominate our field despite having "better" alternatives?)

All this aligns quite well with my initial gut response to

>Why is programming editing text?

Because it didn't come out right the first time.

Especially with regard to intentions and interpretations, this immediately draws a parallel in my mind to movies versus books. Movies can definitely have impactful illustrative power, but it's almost a given that the book will have been better. I think the reasons that this is the case are probably the same reasons why code is expressed better through written language than other mediums.

Previous related discussions that may contain insights:

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

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

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

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

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

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

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

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

With titles and dates:

Lamdu - towards the next generation IDE (peaker.github.io) Dec 25, 2013 https://news.ycombinator.com/item?id=6964369

Programmer Tooling Beyond Plain Text (joelburget.com) May 5, 2015 https://news.ycombinator.com/item?id=9495836

Prune: A Tree-Based, Home-Row-Oriented Code Editor (facebook.com) Aug 21, 2015 https://news.ycombinator.com/item?id=10099611

Why Don't We Have a General-Purpose Tree Editor? (2014) (pcmonk.me) Feb 6, 2017 https://news.ycombinator.com/item?id=13578256

Cirru – An editor for AST (cirru.org) Mar 2, 2017 https://news.ycombinator.com/item?id=13773813

Code as text is a problem (dohgramming.com) May 6, 2017 https://news.ycombinator.com/item?id=14278605

Frame-Based Editing [pdf] (kcl.ac.uk) June 22, 2017 https://news.ycombinator.com/item?id=14609215

Searching a Million Lines of Lisp (wilfred.me.uk) Sept 3, 2017 https://news.ycombinator.com/item?id=15160030

Did you do this manually?

Yep

how do you keep track of these things for future reference? Browser history or something more involved than that?

There’s also a public BigQuery dataset with all HN posts and comments from nearly all time you can write SQL queries against.

I Googled :P

oh thanks, some of them are indeed interesting

"we" tried that 15-20 years ago, and while there was a lot of hype around the so called 4th gen languages (https://en.wikipedia.org/wiki/Fourth-generation_programming_...).

It turned out, at least with that iteration of tools, that smaller programs were somewhat easier to write, but larger ones took about the same time, and (at least where i worked) people agreed that it was very hard to understand the flow of the program for new people, or even if you had to maintain something after an extended period of time.

Another problem is that you're somewhat limited to what the language designer envisioned, and if the IDE doesn't have a "building block" for what you're trying to do, you will spend a lot of time working around it.

We had maybe a couple hundred large "point and click programmed" programs, and they've all been replaced by something written in a traditional programming language. Maybe it's because it has already been "prototyped", but rewriting it in the traditional programming language has actually been faster than writing the original program Some of these programs have been untouched for 15 years, so i doubt anyone remembers much about how it was implemented to begin with.

Great area to think about. Now is probably the best time ever to try something in this space.

Rationale: The modern Apple-using programmer wants something to do with their touch bar, there are more meta keys than they can use, they are running a machine with huge graphics capabilities that are underutilized.

Some ideas: Full screen, keyboard-driven navigation (meta-arrow = codeblock, meta-arrow = window/file), meta keys for compile/test/git commit/diff. Combine tmux, vi/emacs, Visual Studio, FileMerge.

Try it and see. Don't listen to others. Sometimes rethinking things for the ground up is for the best. Worst case you learn. Supportive wisdom:

To be original you don't have to be first - you just have to be different and better. - Adam Grant

Experience doesn't matter. The rate of learning matters. First principles thinking matters. - Vinod Khosla

Light speed analysis: What is the best theoretical performance I could achieve with this design? What is the real information content being transferred and at what rate of change? What is the underlying latency and bandwidth between components? Could the approach ever achieve the performance goals or does it need a rethink? Understand the true performance characteristics of your building blocks rather than focusing on functional characteristics. - Terry Crowley

There's actually a long and interesting history of tools which abstract away the text editing involved in code. Microsoft in particular has consistently produced visual tools to build code - usually, but not always, specialized to some task.

Windows Forms editors, and similar HTML editors have been around at least since I was a kid (1993 for forms, later for HTML WYSIWYG editors); old versions of visual studio provided tools to let you lay out databases visually, and later on to link those up to related objects. Maybe they still do, I don't know.

Turing-complete visual code editors have also been implemented. Microsoft (again) had a couple - a "Visual Programming Language" (named as such, iirc) for their long-dead robotics framework and something else called "Workflow Foundation" (WF), which allowed you to lay out workflows with arbitrary code built into it. I only worked with WF, and it was pretty terrible.

A much better implementation is Scratch. It's generally relegated to education, because laying code out visually is actually pretty inefficient. It's great when you're getting started, but you'll soon find that the textual representation of a language is a lot denser. Put another way, what takes longer: typing `def` or moving your mouse to a menu and dragging a "function" object into place?

Regarding cross-compilation, that's a different problem, and one which has been solved in various directions. Ideally, one could compile this hypothetical language directly to machine- or bytecode.

I do see the appeal of doing this. If you come up with something you should post it here - I would love to see it.

The question presupposes that there is a rational _why_ behind the situation a large group of people have gotten themselves into over a period of incremental steps over decades.

It is heresy to say, but of course writing programs primarily as simple text files is ridiculous. It’s also ridiculous that we write web pages in HTML etc rather than using elegant WYSIWYG editors, and that we use LaTeX for designing visual artefacts.

It’s probably possible to explain “why” we got here, but not “why” it’s a good idea, because it isn’t.

I put it down to culture. Programmers are strongly opinionated and resistant to change (eg blub). We’re historically been selected from a narrow and strange demographic. Which is why few people agree with what seems obvious to an outsider, and why we don’t fix it.

Imagine if engineers built bridges or engines or satellites by writing XML rather than using CAD tools and modelling suites.

I seem to recall nice ideas around Smalltalk’s editor. It should be possibly to have a hybrid approach that can gradually transform programming from text editor into a mixture of maths and high level engineering design.

>Imagine if engineers built bridges or engines or satellites by writing XML rather than using CAD tools and modelling suites.

There’s actually a move inside engineering of physical objects towards code generated shapes. For better aerodynamics, lighter weight, etc. Your optimization code spits out a 3D file and you just go in and clean up artifacts.

code generated /= text. Most html web pages are still largely written _by hand_ in a text editor. The closest thing to this that exists now is OpenSCAD, a usability nightmare.

Now try to express the exact same ideas from your comment without using text.

There can be specialized tools that are useable but nothing beats text in the general case.

Check out the work they are doing on glamoroustoolkit:

http://gtoolkit.com

One view of things is that code is more Poetry than a lot of people give it credit for. The formatting of code and usage of whitespace is as much aesthetic / creative space as it is technical requirement (depending on the language of course; whitespace is more syntactically necessary in Python than say C, obviously).

I am sure there are classical poets that would happily engage in the tabs versus spaces debate, and even some of the other formatting debates in the code world. Concepts like rhythm and structure from the poetry world directly apply to code formatting, because they affect how we as people read the code. Programmers just don't often think to use the same terms for such isomorphic concepts. Yet it also speaks to how so many code formatting arguments get to be so heated: it can be deeply, personal, subjective, aesthetic.

(When we are squashing personal freedom/creativity in our "mandated" formats or automated formatters should we sometimes wonder that maybe we are losing our chance at finding the programming equivalents of great poets that might stun, delight, or otherwise bring emotion to us with their code? We have things like the IOCCC that celebrates one extreme of code formatting [obfuscated], but should we find other ways to celebrate well and uniquely formatted code?)

What I'd really want is a compiler that accepts RTF-like code files and an IDE that is a WYSIWYG editor. The ability to write some important part of code in bigger font or in bold and conversely, make the rarely used paths or boring boilerplate smaller would be great. You could use colors to distinguish different aspects/sections of the code. RTF comments could be way more readable. The possibilities are really great and I'm surprised no one is exploring that.

I "learned" coding with LabView. It's "graphical programming". After three years and ever-increasingly complex programs, I was longing to use a text-based editor.

LV is super practical for "quick and dirty" device control, but beyond that, it's an inefficient grind of connecting things.

LabView wasn't my first language but I used it a lot at my first job out of college and I felt the same way about it. It was great for communicating with all sorts of RF test equipment but it was terrible to do all the processing afterwards.

If anyone's using LV and would like to use C/C++ (without LV-CVI), there are C libs included in the DAQ driver package. This also has the advantage of not requiring a LabVIEW license at all.

There are editors that allow you to edit the abstract syntax tree (AST) directly. An AST is the parsed representation of your code without information about its presentation (e.g. spaces or tabs). Code can be presented in different formats for each programmer, since the formatting is part of the presentation but not the storage. The downside of these editors is that it looks like you are editing text, but actually the text doesn't really exist in memory, since the text is just a projection. Such editors are called 'projectional' editors, JetBrains has an implementation called MPS.

> Is there such an IDE?

IntelliJ Idea isn't exactly it, but it has many of the features you want (most comprehensively/maturely for Java, but to greater or lesser extents for Python, Go, Rust, Typescript, etc). I find using it feels less like editing text, and more like constructing a program at a conceptual level, than in any other environment I've used professionally.

> declare a function

You can use a function/method in code before creating it, and it can create the declaration for you. There's also support for automatically creating class members like constructors, setters/getters etc.

> rename this identifier

Yep, throughout a project.

> "call function x with y and z arguments"

Not exactly, but completion is comprehensive enough for this. You can also refactor a method/function signature, and it gets changed throughout the project.

It’s interesting to see some people preferring other ides/editors than intellij. For instance, vscode is exceptional, but I still far prefer webstorm because it has so many great features.

IntlliJ has a depth of code understanding unmatched by any other environment I've tried. Perhaps someone quite expert with emacs could improve on it, but at a great cost in time.

VS Code doesn't come close in these terms - editing in it is still 'editing text'. But Microsoft has been very canny with the combination of WSL2 & the VS Code remote extension - allowing essentially a true linux programming environment accessed via Windows GUI. That even tempts me, and I'm a fairly diehard Intellij user.

We could have our cake and eat it too in this case.

All an IDE should do is not allow freeform editing of text but rather only editing of text that relates to the AST - in other words, creating an AST by carefully selected text.

This would solve the issue of readability while enhancing the programming experience.

Yes, such tools exist, and they are really hard to use usually. It's hard to copy, hard to refactor, hard to compose, etc., and clicking by mouse is really slow.

I don't say that a good UX couldn't exist for such thing, but we already have that good UX in a form of text. Really. Think of it.

I know of at least one warehouse management system (and in fact maintain a deployment of it as part of my day job) where all the source code for the business logic exists in a SQL Server database; the vendor developed their own IDE of sorts for it that queries the different types of language objects for editing and eventual compilation. Most of the logic itself exists as "process objects" consisting of lists of code elements to execute (comparisons, assignments, database operations, even subprocesses) and pass/fail branches, all manipulated via the IDE's GUI. I suspect it's possible to manually edit the code via SQL (and in fact I'm looking into this, since the IDE is Windows-only and I'd like to do my editing in Linux), but much more tedious (lots of UUID manipulations and joins and such).

On a different note, Lisp would lend itself well to what you seek. While most Lisp/Scheme programming happens in a text editor, Lisp is inherently syntax-agnostic; sure, s-expressions are the most typical, but once upon a time there were M-expressions[1], and Scheme has support for alternative syntaxes[2]. Projects like Scheme Bricks[3] take this even further into visual representation.

[1]: https://en.wikipedia.org/wiki/M-expression

[2]: https://srfi.schemers.org/srfi-119/srfi-119.html

[3]: http://www.pawfal.org/dave/index.cgi?Projects/Scheme%20Brick...

> So why do we bother with all that coding style stuff...

Great minds discuss paradigms. Mediocre minds discuss languages. Small minds discuss coding style.

> ...we could make an IDE that edits the program itself instead of text?

Many IDEs have features that reach into the semantics of the code to allow for refactoring, autocompletion, and so on. This requires a language that is amenable to to such analysis.

Dynamic languages like Python and Javascript (without type annotations) make it difficult or impossible, because a lot of things can only be determined at runtime.

Languages like C and C++ make it difficult because of the text-based preprocessor and templates.

Languages like C# or Java make it easy and hence they have some of the best IDE support.

Code formatting is even more trivial and can easily be done with automated tools - if you can just settle on a particular configuration.

> Instead of editing text you could choose to "declare a function", "rename this identifier" or "call function x with y and z arguments" and then save it with some coding style.

Many IDEs and text editors have snippets that make declaring a function or writing a loop less tedious. Renaming identifiers is also commonly supported. Perhaps you're just not used to proper tools, or your language of choice prevents those tools from existing? Have you tried Visual Studio Code with its language addons?

> I know what I'm describing is pretty much visual programming, but I mean for "text" languages.

What you're describing is pretty much a modern IDE, which is full of visual aids.

> Great minds discuss paradigms. Mediocre minds discuss languages. Small minds discuss coding style.

And for some reason almost no minds discuss semantics.

I want this a lot too, but the way we've built our software stacks has overwhelming path dependence on plaintext. There's a lot of tooling that's a bit broken, like git diffs, because the diffing algorithm can't actually capture what the logical changes really were, but it's close enough so we shrug and move on.

You can see how the accumulation of these little warts starts warping the rest of the devflow. E.g. since git can't do great diffs, it can't do great automatic merges. So we start using dev styles that minimize the pain of merging, and we start emphasizing continuous integration partly to prevent large merge buildups.

It irritates me to no end that the most important part of any code is the symbol names, but we've solidified and ossified those as the literal unchanging way you reference code. Want to fix a typo in a method name? Too bad, that's a breaking change.

I think your point about continuous integration is very true. I'd maybe even go further, if you could make a version control system understood ASTs and these sort of 'declare me function' operations (and you had enough test coverage) maybe you could have all the operations from everyone go straight on to 'master', in real-time, ready to be deployed - no branches, beyond trunk-based development, more like trunk-only development.

My take here is that we lack universal tools for working at higher levels. The only thing we’ve managed to standardize on is ASCII/UTF

What we need is a standardized representation for tree structures and their schemas. XML is too complex. JSON and YAML isn’t good enough. Lisp is pretty good, but I think the text representation is off-putting for a lot of people and its general focus is not quite in the right direction (recursive lists of data/items rather than having typed nodes that contained list of other typed nodes, like XML, with schemas defining every node type)

Note that if your "standardized representation" includes things like letters and numbers, it qualifies as text. If we stuff pieces of text into boxes and connect them with lines, that's still text.

If you get rid of all text, what will you use for naming functions and variables? Icons?

Or just don't name anything: to reference anything, draw an arrow to it?

What do numeric literals look like?

> So why do we bother with all that coding style stuff if we could make an IDE that edits the program itself instead of text? (I get that text is a universal format, but that doesn't mean we have to edit it directly.)

A huge benefit of text is that if you learn to read code, you already know how to edit it too. This is because of WYTIWYS: What you type is what you see.

Higher level edits and refactoring are awesome, but when you just start using the environment you can't learn all the refactorings yet, while you only want to enter something similar to the code you saw on the whiteboard in class etc. WYTIWYS makes it easy.

Historically, many attempts at structural or projectional editors didn't adhere to WYTIWYS. I believe that this is a major reason for why they haven't gained popularity.

But recently there are several projects developing projectional editors which do adhere to WYTIWYS!

One is Lamdu (http://www.lamdu.org) (btw I'm one of its developers). In Lamdu we try to create a programming language with a friendly projectional editor which does adhere to WYTIWYS and also offers awesome unique features that projectional editors enable. (for more information see our short videos - https://www.youtube.com/channel/UCgvPEOFglvS4_ZEHi-PEctQ )

Another projectional editor adhering to WYTIWYS is Jetbrains MPS (https://www.jetbrains.com/mps/) . This one isn't limited to a single programming language! It is a general purpose language workbench.

I have thought about and wanted exactly this when refactoring on a branch. I later want to perform the same refactoring upon rebasing to a newer point on master. There have even been times where I've done this manually by either making mental notes, or explicit bullet points of operations as I perform them. It works great but is tedious and is easy to imagine that the IDE could do this, or the IDE provide an API that can run a script of transformations. JetBrains and their set of tools is the closest place where I can imagine this could be achieved. Perhaps in combination with the language being edited represented in MPS[0] form (of which I have no knowledge).

MPS does present a different aspect in the examples shown. It is still text editing, but not the linear word by word syntax we're used to. We can make up 2D, tree, or any other structure that can conceptually and compactly represent our thinking.

One more point I have on this is that the editor itself can recognize 'edit units' that are not mere characters inserted/replaced/deleted. As edits are made, it can make higher level 'checkpoints' whenever a unit is recognized. The examples in this post are great examples: function declaration, renaming, invocation. Then the undo/redo can show text operations as low-level points as well as higher level ones identifying larger logical units. Having that, one could perhaps select a range of these and cut them to be replayed at a later point. This is similar to how I'll make small local git commits and later reorder, squash or drop commits or make them into separate PRs.

[0] https://www.jetbrains.com/mps

Back in the late 90's, there were several CRUD web app generators that were quite good. I used a commercial one, and was demo'ed an internal one used by a small Michigan design house (govt. contractor.) They said it was their secret sauce, and I believe them.

Currently, there are several database ETL tools (Talend, Pentaho, etc.) which are graphical (think shitty like Labview), but anybody serious uses python or perl scripts.

Today I would look at Zapier or publishing a Google sheet.

https://zapier.com/learn/forms-surveys/best-online-form-buil...

In the 2000-2005 era, there was national advertising by those sketchy diploma-mill universities like U. of Phoenix to turn military veterans into C++ programmers because the Visual Studio IDE "did all the work for you."

Those TV ads were truly eyebrow-raising to me, since I learned all that the hard way (ie. paid development projects) and couldn't recall the IDE every writing a function for me.

The lightest-weight and most powerful text form builder is likely Perl's CGI::FormBuilder module. I've used it for several years and it is remarkable for building CRUD apps.

Apple's Resedit and Adobe's internal dialog layout editor both allow visual layout that saves to text resources.

OpenAPI has tools for generating a server API skeleton, but I think it has the same problem as all code generators: when you want to substantially change it, you'll want to check it in to git and hand-edit, like always.

Simply because writing is the best form of communication of ideas after speech, and using speech to program is just silly, not to mention cumbersome and not productive. Writing, since its invention, has become inseparable from humans and its quite understandable that it is extended to instruct computers, with the compiler as the, well, interpreter.

As for the mechanism you talk about, that's basically declarative style and a lot of platforms (for the lack of better word) do this, mainly in business logic and scientific applications. The most famous example is Excel. However, this style works like a charm only when the set of possible actions is predetermined, and is not conducive to creating new actions, which is why every single platform has some kind of scripting. And scripting is editing text. So there you go.

Your premise is incorrect. If all we cared about was the compiler's output, our programs would look like 100010101011000011101010. Programming involves logic. In humans, logic evolved through use of language and, later, written language.

Please please please follow whatever style guide is handed to you. I am so sick of looking at gobbledygook code.

> Please please please follow whatever style guide is handed to you. I am so sick of looking at gobbledygook code.

You might get either absolute refusal or slow subversion from me there. In my current place of work I was initially handed the utmost horror of horrors of style guides, namely the so-called google style guide. A thing that is optimized to result in code as unreadable as possible. Rebelling against that worked pretty well, so now the thing is gone. And, honestly, if I am ever going to apply for a job and hear that they use the google style guide I am not going to work in that place. I don't follow style guides. Style guides follow me. Currently planning the next rebellion as the utterly evil practice of demanding that every method shall be commented has emerged from whatever wretched place such things emerge.

A large part of the answer is historical(80 column text is derived from the IBM punchcard standards of yesteryear). The remainder is in information theory: we tend to use textual language because the data is a nice compromise between "compressed" and "editable". While it's true that "a picture is a thousand words", those thousand words are generally not abstract concepts like "homomorphism" or "ideology", and yet you can type those words with a few characters.

What you suggest is possible to some extent, it's just hard to standardize, much harder than gluing more stuff on top of the existing systems. You're looking at something that you could build a career on, if you find the right approach. There a lot of companies and projects that have tried to research moonshots and come up with good demos but bad production environments.

It may be that the best place for that technology is in prototyping environments. Similar to something being mocked up before cut into HTML/CSS/JS. The biggest problem I imagine with graphical is the maintenance of it.

Just as an experiment give scratch a try:

https://scratch.mit.edu/

I think you might find out why test is pretty handy.

I can hammer out a one liner with a bunch of methods to do a thing(s) pretty fast. Dragging stuff around, much much slower and IMO it's harder to understand what is actually going on.

Snap! (https://snap.berkeley.edu/) has a Scratch like UI that can be almost entirely navigated and edited by keyboard, Unreal Blueprints allows for a lot of keyboard based editing as well. The reason I mention this is one of the criticisms of visual programming is that it is inherently mouse based, and mouse interactions are inherently slower than keyboard.

Top-down, left-right flow in reading and writing text is an under-appreciated order. We learn it from a very young age and use it everyday in writing English.

Replacing our natural order to process language with a visual scripting environment doesn't really work. The flow control format needs to match the coding requirement, otherwise the default written text style is much better.

The best visual editors I've seen amplify the top-down, left-right structure and sometimes are not saved even then.

Organising ideas into a communicable stack of information has always been the realm of language. The move from pictographs to alphabets was a technology that allowed masses of people to be literate and spread the associated language far and wide, spreading the host civilization with it. Going back to pictographs for coding.. is a deep challenge.

You mean something like model-based development? That is a thing, at least I know it is in use for some safety critical development. The two products I am aware of are:

* SCADE Suite: https://www.ansys.com/products/embedded-software/ansys-scade...

* TargetLink: https://www.dspace.com/en/inc/home/products/sw/pcgs/targetli... (Generates C code from MathWorks SimuLink models)

I suppose the nice thing about these is that you can show some (safety and/or behavourial) properties directly on the model.

Yes, every IDE with code snippets is exactly that kind of IDE for text languages.

Also, DRAKON is a visual programming environment which supports a number of text backing languages.

http://drakon-editor.sourceforge.net/

To be honest, I think a decent IDE does this as much as makes practical sense.

Visual programming just seems awful - and yet a decent IDE can remove a lot of the pain points from the textual approach while keeping the advantages.

There actually was a promising Microsoft research project called "Intentional Programming"(IP) (https://en.wikipedia.org/wiki/Intentional_programming) a few decades ago. The idea is good but i believe due to it being a true disruptive technology and other market forces it was shelved.

PS: Charles Simonyi, the inventor of IP, wrote a paper called "The Death of Computer Languages, The Birth of Intentional Programming" which is worth a read.

Intentional programming is not tied to graphical representation even if that’s how it looked in a prototype. It’s more about separating program structure from detail, trying to better deliver on Dijkstra’s comment about a semantic layer at which one can be absolutely precise. I consider it required reading for anyone frustrated by the present state of programming.

The problem with IP was that it was all so hush-hush that there was no real "thing" i could get my hands on to understand it. I got that it was some form of a DSL or maybe a bunch of inter-linked DSLs connected together where you drew your specific requirement like a "Mindmap". But this is too high-level to get any idea of the implementation and usage. It could also be that this was all "much ado about nothing" in that the idea was well-known but marketing put a spin on the presentation to its own detriment.

Along with what others have said, Unreal's Blueprint editor does precisely this.

It's a good question and even if the text approach is superior we need a better reason than typically given.

I mean think about it. Suppose you want to communicate a JSON object to another programmer.

You can say: "the object consists of three key value pairs, the first key is named ... and its value is ..., the second ..."

Or you can say: "the object is that which you get from parsing the string that spells thus: curly bracket, space, double quote, ..."

Of course you'd prefer the former approach! Why then when we wish to communicate to a computer the same object, we adopt the "spelling approach"?

Because we're not verbally dictating instructions to the computer, we're writing them. Say you want to communicate that JSON object via chat to that programmer, how is this:

{"x":"bar", "y":"foo", "z":"foobar"}

Not the clearest way of communicating it?

For similar reasons, mathematical notation is used instead of explaining equations in plain English, despite mathematicians' audience not being computers.

Symbolic notation has value: while it takes more initial effort to understand, once you have grasped it, the result is far more concise, unambiguous and generalizable.

Because you would have to have dozens of such operations, at which point you have to filter through them, at which point it’s faster to just type what you want to do.

Seriously, the best thing I ever did was learn to type 140 wpm.

People try reinventing node/block based editors every few years, it never works because the complexity isn't linear and node/blocks optimise for the 'let a = 3;' type of line of code.

Or you just write in Chinese: your symbols are whole words.

A solution half-way to what you're talking about (it still utilises text editing) is Paredit/Parinfer for Lisp languages. They allow you to directly edit the program's abstract syntax tree. When coupled with a REPL you can evaluate sections of the syntax tree at will. It gives the dev a much finer grain of control than even the smallest unit test.

There are lots of "visual programming languages" with a list on wikipedia and recently posted here on HN.

The operations you list seem to be related to the kinds of things yo might do when 'refactoring' though. Have you looked into the kinds of operations happening there. "Pull Up", "Extract Method" etc

I find it interesting (and somewhat unexpected) that even digital hardware, while consisting of discrete elements, blocks, etc. that can be easily visualized, is still "defined" using pure-text "hardware definition languages."

That’s kind of true, but then you have to do layout and routing using what is essentially CAD software.

Do you mean an ide that you navigate around (mouse or keyboard) to create programming language constructs that then is turned into either text or a binary?

If so, my big question is what interface will be more efficient than text entry?

If not than perhaps I misunderstood your question.

You might be looking for something like blockly:

https://developers.google.com/blockly/guides/overview

Charles Simonyi would like to speak with you.

wikipedia.org/wiki/Intentional_programming

Bret Victor would, too:

http://worrydream.com/ (Warning, this site hijacks your mouse scroll and does weird things)

I too am a fan of visual programming and node-based and flow-based editors, but they are few and far between and tend to be highly specialized.

If you know of ones that are high quality please point me in the right direction.

unity and unreal are very visual when compared with text editors. They are also very popular apps for creating entire classes of applications, like video games.

Hi! Take a look at NodeRed... Still some code behind the scene at lowest layer but the visual display of algo is a starting point.

I've heard of it, but it generates JSON, doesn't it? What I mean is something like an editor/ide for C or Python or something.

Well sure, but that's just the storage format isn't it? Is that important if you never interact with it?

Because humans can only express themselves in two ways. Through their voice or through actuation of muscles. (Actually that's just one way...)

We already tried the voice thing and it doesn't work well at all beyond Alexa type personal assistants.

So basically muscle actuation is the only thing remaining. Well time to count the number of actuators your body possesses that it can use to express itself. 2 legs, 2 feet with tandem controlled toes, 2 arms, 2 eyes, 1 neck, two hands with 10 fingers. If we don't count our hands we only have only 7 actuators in total that we can use to control a computer. Our hands are such a tiny part of our body yet they exceed that number. 10 actuators that can be used for our body to express itself. Now imagine you are a dolphin or you are paralyzed and can't use anything below your neck. You have lost almost all ability to express yourself. There are still a few actuators left but compared to the power of 10 fingers they are absolutely nothing. 10 fingers allow humans to transmit 40 bits of information every single second (assuming average 60WPM) to their computer.

Since our hands are our primary way of communicating with a computer we have decided to create an input device that is worthy of their might. A keyboard lets us take advantage of the full potential of our hands. Just think about it. 106 keys at your fingertips. You can transmit a huge amount of information into the computer.

Without a hand you can still use a pointing device like a mouse or touch screen but you are not able to use the scroll wheel and at most you can only have a single mouse button. The biggest flaw: You are limited to interactions that are visible on the screen. The keyboard has no such restrictions, you can just type anything you want.

What I'm getting at is that typing text is the most natural way of interacting with a computer and the method with the highest data throughput. Text based programming languages take advantage of this affinity and this is why they have established themselves.

The type of IDE you are talking about has to be easier to use and faster than simply typing the code directly. Achieving this is a very difficult task and even if you succeed there is no shortage of programmers willing to learn text based languages, it simply isn't difficult enough to warrant a replacement.

The other comments saying this is just because of inertia or fashion(blub?) completely ignore the way humans interact with computers and therefore are not sufficient to answer your question. If it were that simple then we'd already see a reasonable split between the camps. Something like 3 text based languages to 2 visual languages and 1 voice based language.

What about Node Red or Apache Nifi?