Ask HN: Why is programming editing text?

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.

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.

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

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

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.

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

"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.

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/

> 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 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

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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)

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.

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

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.