From: "Pascal J. Bourguignon" Newsgroups: comp.programming,comp.compilers,comp.editors Subject: Re: New editor/Integrated Development Environment/compiler Date: Mon, 11 Apr 2011 18:53:21 +0200 Organization: Informatimago Lines: 103 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <11-04-021@comp.compilers> References: <11-04-009@comp.compilers> <11-04-011@comp.compilers> <11-04-018@comp.compilers> NNTP-Posting-Host: news.iecc.com X-Trace: gal.iecc.com 1302573990 19388 64.57.183.58 (12 Apr 2011 02:06:30 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Tue, 12 Apr 2011 02:06:30 +0000 (UTC) Keywords: editor, tools Posted-Date: 11 Apr 2011 22:06:30 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.stben.net!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!feeder.news-service.com!postnews.google.com!news2.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!news-out.readnews.com!news-xxxfer.readnews.com!news.misty.com!news.iecc.com!nerds-end Xref: x330-a1.tempe.blueboxinc.net comp.programming:203 comp.compilers:88 comp.editors:61 Willem 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]