Live data from Hacker News

Ask HN: Why is programming editing text?

news.ycombinator.com

11–20 of 79 posts

Re: Ask HN: Why is programming editing text?

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

Re: Ask HN: Why is programming editing text?

#12
post #6

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=1516003…

oh thanks, some of them are indeed interesting

Re: Ask HN: Why is programming editing text?

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

Re: Ask HN: Why is programming editing text?

#15

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.

Re: Ask HN: Why is programming editing text?

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

Re: Ask HN: Why is programming editing text?

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

Re: Ask HN: Why is programming editing text?

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

Re: Ask HN: Why is programming editing text?

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

Re: Ask HN: Why is programming editing text?

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

Post reply on HN