Comment by kens | Hacker News Reader

Comment by kens | Hacker News Reader

My unpopular opinion is that computing is stuck in a local maximum based on technology from the 1970s.

In particular, typing into an 80x25 terminal window with unformatted fixed-width characters should be obsolete; we don't need compatibility with punch cards any more. There was a thread a week ago about displaying graphs in your terminal using ASCII graphics. This shouldn't be necessary!

Also, code shouldn't be a sequence of 80-character lines like a deck of punch cards. It makes no sense to carefully organize the order of code in a file for things that don't matter. Chunks should float around and be displayed as sensible, not tied to an arbitrary location in a file. Code should be more like a database than a flat file. (Yes, I know the arguments that flat files are better for tools like grep.) We should get out of the 1970s editor model; Emacs is from 1976 and vi from 1978.

The whole command-line operating system approach is like being stuck in the 1970s, even using the same commands. Yes, small tools composable with pipes are nice, but there must be a better approach. We have powerful graphics, but we're typing into terminal windows that simulate a Teletype.

To summarize my unpopular rant, hardware and I/O is exponentially better than the 1970s, but our programming environment is still stuck with the approaches of the 1970s. Computing needs to get out of this local maximum. For a supposedly fast-moving field, computing changes at a glacial pace.

Win32 was a great step forward. A stable interface that has lasted for decades, despite Microsoft's best efforts to move on.

Programs written using the Win32 GUI and forms still work decades later. Its a shame there isn't an equivalent in the Linux world.

---

We should have rich source text by now. You should be able to freely time comments, include notes, links, images, etc. in the source code of a program, and still have it compile correctly.

---

We should be able to directly modify the Abstract Syntax Tree of programs, renaming as it is stored in the tree would cause it to correctly change the name of every use with zero errors. Refactoring this way would be much faster and more reliable.

Arent Jupyter notebooks the rich source text, are you looking for something similar to be natively supported by the compiler instead of the overhead of a Jupyter process.

Your "unpopular rant" (or one pretty much like it) has 376k views and 12k likes on youtube![1] (Recommended watch, not least for demystifying the origin of vi's navigation keys and the choice of ~/ for /home/you.)

1: https://www.youtube.com/watch?v=8Ab3ArE8W3s&t=1012s (link jumps to 16:52)

Wow, that video is exactly my thoughts, but expressed much better!

There have been incremental improvements lately that might lead to code in a db instead of flat files at some point in the near future:

- rise of autoformatters

- language servers decoupling editing from editors

- all in one build tools (cargo, go)

This might be case of happens slowly then all at once.

It's not an insane jump from LSPs to new editor UIs and since the code is formatted on save, people care less about the minutiae of 80 char lines.

Text files are a meh proxy for ASTs, which is what we actually write when writing programs. I want a programming language in which I can edit ASTs.

80 character lines are a near-optimum for readability. And command line interfaces are convenient to use via keyboard over remote, possibly high-latency connections, where a more direct interaction becomes clunky. It's also easy to extend: you don't have to change anything in the UX, just add a new command. Moreover a CLI allows for the expression of complex behaviors that are all but impossible to render in a "user-friendly", interaction-based UX.

> 80 character lines are a near-optimum for readability.

Counterpoint: 80 chars is too short for writability. You need to make arbitrary splits and refactors all the time and it ends up hurting readability.

120 is a better sweet spot to strive for in my opinion.

So instead of editing and compiling text files what should we be doing instead?

I don't have the solution; I just see the problem :-) Programs could be in some sort of database rather than a set of files, so the code you're interested in gets displayed without you caring about how it is broken down into a sequence of lines in a file. Sort of like how a database shows you the data you want, rather than needing to put entries in the right order. You shouldn't need to think about how your methods are ordered in the file or even what file they go into.

The display could be more like a smart word processor, where you can format code however you want. (A feature that the Xerox Alto provided.) You should be able to stick images in your code to describe things, rather than creating ASCII graphics. Tabs vs spaces shouldn't even exist.

Oddly that was how BASIC worked in the actual 70s. line numbers were virtual. Though I think the implementation left much to be desired.

Smalltalk basically did that. The code can be serialized to text (and usually is) but in the system it's just in a database. What file represents what source code, doesn't matter to the user. The system can create directories and files as needed to represent it in whatever the sane way to represent it is. You're just editing the code and not dealing with the mundane and tedious serialization bits. You don't have to get into nonsensical wars about what goes in what file or what directory, you just care about packages, classes, and methods.

The database analogy breaks down pretty quickly though. Instead of deciding what file to put something in, you have to decide which table. And you're not going to have a single database for all your code, so you'll have to decide which database to put the code in, and which table within that database.

And now we're created libraries and packages.

Not to mention that sometimes a database gets too big and performance goes down, so maybe we want to split it up or shard it or something. And I haven't even mentioned all the database types out there, relational, document, graph, time-series...

Further to Jtsummers reply, with ENVY/Manager "All code is stored in a central database rather than in files associated with a particular image."

page 4 https://www.google.com/books/edition/Mastering_ENVY_Develope...

I'd want to be working in a system where an AST is the first class representation, exchange format, etc. That everything could be dumped to text format should be a private choice and unknown to the beginner developer, much like debugging with AST or assembly is today.

Reply on news.ycombinator.com