From ... Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!134.222.94.5!npeer.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: Question about software "development" References: <3B55FE64.A9D21259@pandora.be> Mail-Copies-To: never From: Erik Naggum Message-ID: <3204624007044946@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 91 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Jul 2001 13:20:10 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader1.kpnqwest.net 995635210 193.71.66.1 (Fri, 20 Jul 2001 15:20:10 MET DST) NNTP-Posting-Date: Fri, 20 Jul 2001 15:20:10 MET DST Xref: archiver1.google.com comp.lang.lisp:13377 * Henk Zwaenepoel > I'm a C programmer who has taken an interest in Lisp. Welcome! > Lisp users and enthusiasts praise the ease of writing prototypes in lisp, > but: how do you start? With the most obvious part of the problem that needs to be solved before you can get any further. The point of this part of the problem-solving is _get_ further, _not_ to solve the big problem. This does not have to mean bottom-up, but that is frequently the most productive way to start. More often than not, you build the language up with a substrate of both functions, types, and macros to make writing the application more natural, and then it becomes possible to build stuff from the top down. > Do you start by creating a couple of simple functions or macros (bottom > up) that - after testing - you link together in 1 file (or several files; > something like C with definitions and libraries?) C as a development environment has a number of serious problems. One of them is the lack of any working ability to build a "development system" of your own. In Common Lisp, you define and load things into your Lisp image and interact with it from the editor (which may be integrated into the Lisp image), and it is not infrequent for people to build and dump their own Lisp images within which to do most of their work. The C compiler is the same in every invocation, and you need to include a tremendous amount of header files after a while if you do any "changes" to the language, thus discouraging any development in the language. > Do you create an executable file in your project, or do you always run it > in a special environment (interpreter). What is an executable? Is not the operating system a special environment and the shell an interpreter? There is absolutely _no_ difference from this mode of operation to Common Lisp, you just move into the Lisp world. > Or maybe you have something like a "Visual C" environment that > automatically creates a framework, where you only need to add extra > functions. Nothing stops anyone from building such things in Common Lisp, and some have done so, but you need to understand that this can be added to a Lisp system without turning your development system into a new "application". > What implementation of Lisp do you programmers use for your work (or at > home) Lispworks? Cmucl, Cl, Corman Lisp, Franz Lisp? Do you work in a > Unix- or Win32 like environment ? Do you use GUIs in your projects, or > only if it is really necessary (I mean real graphical GUIs, no TVISION > ASCII windows) It doesn't seem to get discussed often in this newsgroup. This clearly depends on the application you are writing. I fail to see how this is relevant to learning the language or how to use it. Are you implying that you only want to do things that others are doing in the same way they are doing it? If so, what's the point? Unlike the sorry impression you may get from other languages or even operating systems that are "married" to their user interfaces, there is such a thing as a general-purpose programming language. Lisp has been used to build some of the most advanced user interfaces around, from scratch, including the fine designs on which the Microsoft Windows cruft has been tacked. With the advent of less welcoming graphical systems, such as X and Windows, building GUI-based applications has become _much_ harder (and much more boring) than it used to be, and Lisp programmers have turned "inward" to build serious application frameworks that some drone interfaces to from the favorite GUI language via protocols or remote procedure calls or foreign function interfaces within the Lisp image. The key here is to make things work together. There is a lot of cheap labor out there that is actually willing to work with C++ and make Windows-based GUIs, and it would be a shame to use Lisp labor on such things. Some environments are so visual that you cannot get any serious work done at all, and in those, it makes sense to use the "native" language for the GUI cruft and a real language for the real work. But, hey, I love an intelligent GUI, too, but it is just so mindlessly boring work to build it, not to mention that most of the GUI tools you find are incredibly stupid and less efficient than a command-line interface would have been, or at least if you sent your employees on a touch-typing course like they required for the previous generation of keyboard users: typewriter secretaries. > Can you describe some of the projects that you are currently working on > and for which you find or have found Lisp to be the most productive tool? I think any answer to this question will be even more limiting than your previous question. > Sorry for the length, but I'm trying to get into the Lisp-spirit Then you should investigate other angles, too. #:Erik -- Travel is a meat thing.