5 ms·

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

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.

eterps 4y ago
Good point! Image based programming systems should be mountable as a filesystem to alleviate some of these concerns IMO.
- bitwize 4y ago
  But then you've just reinvented storing code in files, poorly. Why not do the opposite -- have code live in files, index them and overlay a hierarchical browser on top?
  - fiddlerwoaroof 4y ago
    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.
bbqbbqbbq 4y ago
pasc1878 4y ago
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
- derekzhouzhen 4y ago
  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.
- astrobe_ 4y ago
  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.
SighMagi 4y ago
These automobile contraptions are cool, but how do I hitch it to my horses?
- iLoveOncall 4y ago
  Except this thing here is a horse, not an automobile.

eterps 4y ago

Good point! Image based programming systems should be mountable as a filesystem to alleviate some of these concerns IMO.

bitwize 4y ago
But then you've just reinvented storing code in files, poorly. Why not do the opposite -- have code live in files, index them and overlay a hierarchical browser on top?
- fiddlerwoaroof 4y ago
  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.

bbqbbqbbq 4y ago

pasc1878 4y ago

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

derekzhouzhen 4y ago
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.
astrobe_ 4y ago
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.

SighMagi 4y ago

These automobile contraptions are cool, but how do I hitch it to my horses?

iLoveOncall 4y ago
Except this thing here is a horse, not an automobile.