Re: New editor/Integrated Development Environment/compiler

Willem <willem@toad.stack.nl> writes:


> Pascal J. Bourguignon wrote:
> ) So what's missing? The filing part. One thing you can do to ensure a
> ) clear break of mindset is to store the code into a data base instead of
> ) text files. For a start, you could store it in a postgres database.
> ) There's a pg.el on the web, which let you communicate directly to
> ) postgres. You may store each definition in a different row.
>
> NOOOO! Not Uniface again! I can tell you from experience that storing
> code into a database instead of text files is absolutely horrible.
>
> Of course, it looks great at the beginning when you're whipping up code
> and you don't need to worry about file structure or whatever, but when it
> grows bigger you're left with a horrible mess in a proprietary format.
>
> And then you want to put the whole thing into some kind of version control
> system, preferrably with multiple staging areas and whatnot, and then
> you're *really* in trouble.




> Here's a break of mindset for you: A filesystem is a database, but with the
> added advantages that it's atransparent, and there are loads and loads of
> existing tools that integrate with it, including version control, backup,
> to name but a few.


Yes. But that's the point in this thread, we want to get rid of the
existing tools. Remember, the key words were: IDE, and code
structure.


Of course, we know that unix is the ultimate Integrated Development
Environment. But some people don't like unix (there are arguments,
see one below), and want something even more "integrated", ie. in a
single application. Never mind that applications or systems are all
the same: they're virtual machines.


So the question is that we want a non-unix virtual machine, in which
it may be easier to provide integrated tools of higher quality than
unix. One way to do this, is to provide an image based environment,
where there is no separation of addressing spaces (nowadays, with
64-bit processors, and with controlled environment programming
languages, there's no technical reason to keep separate addressing
spaces), and therefore where the tools can better integrate. This is
what you observe in emacs, Lisp Machines and Smalltalk.


The single critisism of unix I'll mention here is that (due to the
separation of addressing spaces), it favors communication between
processes based on serialized text streams. Hence tools such as vi,
which deal with lines of characters, instead of syntaxic editors,
working on the syntactical structure of the code.


On the contrary, when you have all your objects in the same addressing
space, you can easily "edit", ie. modify directly those objects
(ie. the syntactic tree of a program, there's no need to "edit" lines
of characters), and the compilers can use directly the modified
syntactic tree to compile the modified function.


There's no need for files, each function or method can be compiled
separately. This helps greatly while developing because instead of
having a edit-save-compile-debug-loop, you can use a
read-eval-print-loop, with feedback at a much finer grain.




So you don't need files to store code. No programming language use this
notion of file. Either they have notions such as units (Pascal),
modules (Modula-2), packages (Ada), or just a full stream of characters
making up a compilation unit (C, C++).


You may want to structure your code at a higher level than the syntactic
elements provided by the language, but this can be done easily with
simple tools, eg. the method categories in Smalltalk. Notably, it means
that you can organize your code dynamically, having different views,
different classifications than the rigid sequence of a file.




As for versionning, of course, databases don't prevent it. On the
contrary, it's easy to add a column "version", to store several versions
of a function in a database.


But again, as I mentioned above, this means you won't use git (or not
the git as it is, which uses the unix files as units of versionning),
but a better versionning system, well integrated to your system.


As for the proprietary format, I entirely agree. We want to be able to
exchange our programs, possibly on different systems. That's why there
are features such as the fileOut: and fileIn: methods in Smalltalk (and
equivalent in InterLisp, see the reference provided), to serialize or
deserialize the code into ASCII for interchange.






So remember, we're not in the context of the unix IDE, with tools such
as vim, gcc, git and tag, but in the context of a different system, with
a different granularity of integration, and where the tools can work
directly with the data objects that represent the programs, instead of
having to serialize/deserialize constantly meaningless ASCII streams.


--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
[One big address space with a database? Sounds like we're on our way
to reinventing the IBM S/38. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.