Titles like this are worst than clickbait. It should be mandatory to have descriptive titles on HN.
To save everyone a click: "The Holonforth programming systems combine browser, editor and umbilical target link. And in the DOS systems also: assembler, compiler, linker, debugger and interpreter."
I would literally rather have the title be "This programming system is going to change the world and put you out of a job if you don't learn it" rather than some random name.
"Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead."
.. yeah I have no idea. I barely glanced at this and I immediately thought of Content Management System and then had nightmare flashbacks to when I had to admin web servers running Wordpress and Whatever and ran away
This is a neat idea. I think it could be a tool that really shapes the workflow for a programmer and the way we think about writing code. Think about it: we have this loose correlation between a module and a text file. But you could conceptually put two module’s worth of concepts into one file. Or split a single module between two files. That looseness leads to code that is hard to understand and manage. If the UI you use forces you to work on one unit of the program at a time you are much less likely to create the Monster Function of Doom or 1000 modules that don’t do anything but provide indirection. I think UI usability may suffer a bit but a well designed IDE of this sort could really transform how we think about software architecture.
So that's not new. There was an extended BASIC in the Sinclair QL that allowed you to browse units and functions in the left pane, and edit the code in the right pane.
Before that, there was a system on the Burroughs B20 series that had a similar design; browse on the left, edit on the right.
Correct, the Burroughs B20 is from 01982, the Sinclair QL is from 01984, and Smalltalk's class browser (pictured on the HolonForth page and cited in the text as a key inspiration) was already more or less in its current form in 01976, the biggest difference from today being that the screen was one bit per pixel, not grayscale or color. (The Smalltalk language and virtual machine have changed enormously, but the browser is almost unchanged.)
A hierarchical view of your programs, classes, functions, etc. on the left. The root node is where you started, so if you just open a class, you get the eveything that belongs to that class, but you can also open a whole namespace. On the right you can then edit the code.
The syntax of ABAP may be not tho everyone's taste (modern ABAP looks better though), but the capabilities to write business software in a completely integrated system are magical.
The database is "just there". SQL to access the DB is a first class citizen of the language. Your datatypes are the same in the database and your programs. You can use the primitive datatypes to create rich datatypes with attached default values and validation logic. When you build a input field in the GUI and connect it to the database field everything just works.
How are ABAP's capabilities for abstractions and static typing? I think those matter a lot more than syntax. Can you write, for example, a quickselect function that operates on an array of some arbitrary type with a user-defined ordering, or on an abstract indexable container? Can the type system guarantee that a subroutine can't modify a data structure you pass it a reference to?
(Of course there's lots of "business software" that doesn't need this kind of thing.)
ABAP is used in the ERP systems domain. Once you try to do things outside of those abstractions it becomes difficult or even impossible. This is what basically suffocated the 4GLs of the 1990s. They were too constrained and at the edges problems tend to require unanticipated functionality.
It is the non-functional requirements that cause the most implementation problems.
This is how IEC 61131-3 is structured in automation vendor IDE's. Thanks to decades of brain damage many of the IDE's don't deal with textual source code but proprietary binary project files and you click to create POU's, progrm organizational units. Want to write a function? You have to click to create it as a POU and work on the code in a new window. In some IDE's the POU is even plit into a local variable window and a code window. Awful.
One thing about forth in a linear file is you can define a word (word is the forth term for subroutine or function), use it in another word, and redefine the word to something else after that without affecting the previous word. (Generally the word list (dictionary) is just a linked list and you search by starting from the newest word.) So I'm curious how the hierarchical words are stored and in what order they are searched.
One thing about forths is that you can easily change that if you want.
The simplest way to handle this is by patching the old word to jump to the new definition. If it bothers you that that leaves junk around, you can write words that compact the dictionary.
Alternatively, if you have malloc/free, it’s easy to change the dictionary to be a list of pointers to malloced word definitions, and, when defining a word whose name matches that of an already existing word, to update that pointer to point to the new definition, and then cleanup the old definition by freeing its memory. That may fragment your heap, though, and may affect performance.
I've actually used Visual Age for Java, and its "repository" was an existential threat. It was basically incompatible with revision control (a gigantic binary blob) and it could be corrupted, for example (true story) by exceeding some maximum repository file size.
You lose the ability to use a 3rd party editor, traditional source control, grep and various other small command line tools. Also god forbid if the database is corrupted during a crash or sudden power loss.
This is what we already have, but the problem is that hierarchical browser -> filesystem is a lossy process and you have to continually reindex the filesystem to maintain the browser. If the hierarchy is first-class and the files are derived, this is less of a problem because the source of truth is the same shape as the conceptual structure of the environment.
But you gain the ability to use tools that understand the language or the underlying AST, they look at the structure rather than a context free view of text.
You add the tools to the IDE.
As for database corruption - that is a well known issue databases have good resilience to crashes and power losses
I am not sure which environment you referred to; I've used squeak smalltalk, and not impressed. I actually like smalltalk so I ended up using GNU smalltalk which doesn't rely on a code browser.
I've been back-and-forth in my Forth systems along the years on this topic.
Just having a built-in code editor (like the traditional "block editor" - or at least it was traditional in the last century) has some advantages - for instance if your editor commands are written in Forth you can use Forth as the scripting language for the editor, and create macros etc. on the spot just like you would with code editors such as Emacs or Vim.
It does have the disadvantages OP mentions.
You say, "you add the tools to the IDE"... Except some tools are too complex to code and test and you have too little time. In the end, you'll have to wait until someone else does it for you and if you are using niche software such as this one, you can wait a long time. Why wait for someone finally making a "diff" tool when it already exists for text files?
Database corruption is not something you can brush aside like this, because it can happen that a bug in your Forth system corrupts your database (or your image or your blockfile). When you make a critical change, you therefore have to make a backup of your system first. (As for AST, this is mostly irrelevant in Forth, which has almost no syntax).
These days I agree with OP. For better or worse, text files are the lowest common denominator, so text files have more advantages.
Generally speaking, this the same dilemma as with software that does a lot of things (for instance GitHub/Gitlab/Gitea, that are not just Git anymore). True, you benefit from the integration sometimes, but there's usually a couple of features that are weaker or done poorly. Functionality overlap with other software that go a bit overboard with feature integration. You can easily end up with two or three different wikis in each software. In the end, you either tell users to use just one of them, or you let them spread the information in the various wiki and let them blame each other because of the mess it creates.
The topic of "why are we still using flat files for source" is not exactly new. Code editors have evolved but clearly not in this direction - "language servers" were favored for instance. I think there is some kind of consensus that a language should not depend on an IDE. "Do one thing and do it well" is already hard enough.
Looking at this tool, if I had to work in this environment the first thing I would do is figure out how to edit the files in Emacs. This looks extremely frustrating and painful and very much not compatible with how someone would need to use it to be productive. Imagine you have to jump between 3 functions for some reason, you have to go through this 4 level + deep hierarchy? Why? How does this help?
There are lots of ways of organizing the world hierarchically, that you CAN do that does not mean it's helpful to do it, more `organized` does not imply better.
Neat, but not more. I prefer to define my own context (splitting into files as I see fit) and using code folding etc. which can achieve a similar result without fundamentally changing workflows (as others pointed out - editors, git, grep, ..). Each time you want to write a new function ("word" I guess) requires somewhat of a context switch as you have to navigate through a GUI to where it should go, where just swapping files in my editors buffers feel more naturally. But then again I have never tried working like this and maybe I'd have to try
This is another (interesting) spin on the language workbench / program as datastructure concept.
Honestly, the problem is that people think they want faster horses. You see the usual banal comments here "what if the database crashes", "I just want to edit with Emacs", but no consideration (usually due to no exposure) of the upside of always having the program in a state that can be comprehended mechanically.
It's unfortunate, because it ties us to maintaining and building programs like it's the 70s. For a fresher take on what this could enable if the general programming population were a bit less reactionary, consider the (sadly moribund) http://mbeddr.com
37 comments
[ 4.5 ms ] story [ 71.9 ms ] threadTo save everyone a click: "The Holonforth programming systems combine browser, editor and umbilical target link. And in the DOS systems also: assembler, compiler, linker, debugger and interpreter."
I would literally rather have the title be "This programming system is going to change the world and put you out of a job if you don't learn it" rather than some random name.
https://news.ycombinator.com/newsguidelines.html
.. yeah I have no idea. I barely glanced at this and I immediately thought of Content Management System and then had nightmare flashbacks to when I had to admin web servers running Wordpress and Whatever and ran away
Before that, there was a system on the Burroughs B20 series that had a similar design; browse on the left, edit on the right.
Yeah, I approve of non-linear code editors.
I think Smalltalk-72 did not have the browser.
A hierarchical view of your programs, classes, functions, etc. on the left. The root node is where you started, so if you just open a class, you get the eveything that belongs to that class, but you can also open a whole namespace. On the right you can then edit the code.
https://help.sap.com/saphelp_gbt10/helpdata/EN/46/9d783e3a7d...
The syntax of ABAP may be not tho everyone's taste (modern ABAP looks better though), but the capabilities to write business software in a completely integrated system are magical.
The database is "just there". SQL to access the DB is a first class citizen of the language. Your datatypes are the same in the database and your programs. You can use the primitive datatypes to create rich datatypes with attached default values and validation logic. When you build a input field in the GUI and connect it to the database field everything just works.
That makes me really miss working with SAP.
(Of course there's lots of "business software" that doesn't need this kind of thing.)
It is the non-functional requirements that cause the most implementation problems.
https://en.wikipedia.org/wiki/IEC_61131-3
The simplest way to handle this is by patching the old word to jump to the new definition. If it bothers you that that leaves junk around, you can write words that compact the dictionary.
Alternatively, if you have malloc/free, it’s easy to change the dictionary to be a list of pointers to malloced word definitions, and, when defining a word whose name matches that of an already existing word, to update that pointer to point to the new definition, and then cleanup the old definition by freeing its memory. That may fragment your heap, though, and may affect performance.
I'm just wondering how it works in Holonforth. I checked their guide as well.
Some other languages can exploit it too. And some clever web-based REPLs approximate decently to it.
I'd love to see this idea growing outside the Smalltalk world because is very valuable and influential to the DX (developer experience).
I vaguely remember seeing it in IBM's Visual Age for Java in the early 2000's.
Yes, it was pretty amazing.
Oh, if I'm recalling correctly, it had workspace for live scripting and it could inspect the objects returned by snippets as Smalltalk could?
Why not do the opposite -- have code live in files, index them and overlay a hierarchical browser on top?
You add the tools to the IDE.
As for database corruption - that is a well known issue databases have good resilience to crashes and power losses
Just having a built-in code editor (like the traditional "block editor" - or at least it was traditional in the last century) has some advantages - for instance if your editor commands are written in Forth you can use Forth as the scripting language for the editor, and create macros etc. on the spot just like you would with code editors such as Emacs or Vim.
It does have the disadvantages OP mentions.
You say, "you add the tools to the IDE"... Except some tools are too complex to code and test and you have too little time. In the end, you'll have to wait until someone else does it for you and if you are using niche software such as this one, you can wait a long time. Why wait for someone finally making a "diff" tool when it already exists for text files?
Database corruption is not something you can brush aside like this, because it can happen that a bug in your Forth system corrupts your database (or your image or your blockfile). When you make a critical change, you therefore have to make a backup of your system first. (As for AST, this is mostly irrelevant in Forth, which has almost no syntax).
These days I agree with OP. For better or worse, text files are the lowest common denominator, so text files have more advantages.
Generally speaking, this the same dilemma as with software that does a lot of things (for instance GitHub/Gitlab/Gitea, that are not just Git anymore). True, you benefit from the integration sometimes, but there's usually a couple of features that are weaker or done poorly. Functionality overlap with other software that go a bit overboard with feature integration. You can easily end up with two or three different wikis in each software. In the end, you either tell users to use just one of them, or you let them spread the information in the various wiki and let them blame each other because of the mess it creates.
The topic of "why are we still using flat files for source" is not exactly new. Code editors have evolved but clearly not in this direction - "language servers" were favored for instance. I think there is some kind of consensus that a language should not depend on an IDE. "Do one thing and do it well" is already hard enough.
There are lots of ways of organizing the world hierarchically, that you CAN do that does not mean it's helpful to do it, more `organized` does not imply better.
Honestly, the problem is that people think they want faster horses. You see the usual banal comments here "what if the database crashes", "I just want to edit with Emacs", but no consideration (usually due to no exposure) of the upside of always having the program in a state that can be comprehended mechanically.
It's unfortunate, because it ties us to maintaining and building programs like it's the 70s. For a fresher take on what this could enable if the general programming population were a bit less reactionary, consider the (sadly moribund) http://mbeddr.com