The way I came to lisp was via the Squeak mailing lists: people were crediting Lisp a lot for most of the ideas which seem to make Smalltalk-80 unique. Now that I have played around with Lisp for a while I get the impression: it's a really cool language, but it does not deliver the environment that Squeak has. To be more precise: This environment just seems to be hidden from the beginner. (Or have these ideas really got lost during the Common Lisp standardization process?)
There is a cool book for learning Squeak from Mark Guzdial, Squeak. Object-Oriented Design with Multimedia Applications. It has extensive sections on tool use, exactly what I am missing from Lisp books. The spirit of Squeak is, that it is more than a language: it is an environment for developing ideas.
While the task of the book is easier because it has to handle only one specific Smalltalk-80 implementation, I would very much appreciate an introduction on how to use the Lisp language features like the debugger (not just the small appendix in Graham's ACL), the ways to find methods / functions etc. - all these things that seem to be built into Lisp but are not normally regarded as the "programming language", although they make using the language much more productive. (Now, of course, macros are part of it, but I mean the more fundamental things.)
It seems that even Peter Seibel's very interesting book is missing such a section - but I didn't have time for a close look so far.
Let me give you an example: I tried to figure out how to do s.th. as simple as setting a break point. Now I found a function "break". The hyperspec says:
"break formats format-control and format-arguments and then goes directly into the debugger without allowing any possibility of interception by programmed error-handling facilities.
If the continue restart is used while in the debugger, break immediately returns nil without taking any unusual recovery action."
This does not exactly tell a newbie like me, if this is the usual way to set a breakpoint. To make it worse, in SLIME with SBCL this does not open the SLIME debugger, but the SBCL one.
Christian Hofer wrote: > The way I came to lisp was via the Squeak mailing lists: people were > crediting Lisp a lot for most of the ideas which seem to make > Smalltalk-80 unique. Now that I have played around with Lisp for a while > I get the impression: it's a really cool language, but it does not > deliver the environment that Squeak has. To be more precise: This > environment just seems to be hidden from the beginner. (Or have these > ideas really got lost during the Common Lisp standardization process?)
> There is a cool book for learning Squeak from Mark Guzdial, Squeak. > Object-Oriented Design with Multimedia Applications. It has extensive > sections on tool use, exactly what I am missing from Lisp books. The > spirit of Squeak is, that it is more than a language: it is an > environment for developing ideas.
Apparently, this used to be true in the case of Lisp Machines as well. Note that Squeak is its own operating system, so to speak, that doesn't care much about the platform that it runs on. The typical Common Lisp implementation nowadays tries to deliver an environment in which you can develop applications that integrate well with the existing infrastructure. Note, however, that the ANSI standard is intentionally agnostic in this respect.
> This does not exactly tell a newbie like me, if this is the usual way to > set a breakpoint. To make it worse, in SLIME with SBCL this does not > open the SLIME debugger, but the SBCL one.
IIUC, it's up to a CL vendor to spell out what debugging capabilities exist in a specific implementation and how to use them. Note that SLIME is a pretty new effort, so documentation is lacking at the moment. Furthermore, all the environments for CL based on emacs / xemacs have to deal with the fact that there is a gap between the development environment and the CL implementation that needs to be crossed, and this can lead to inconsistencies. A combination of emacs + Smalltalk would suffer from similar problems, probably even more so.
It's a good idea to check out the (commercial) implementations that come with environments that better integrate with CL because they are implemented in the same language. They also come with documentation that should help you to get your questions answered.
Pascal Costanza wrote: > IIUC, it's up to a CL vendor to spell out what debugging capabilities > exist in a specific implementation and how to use them. Note that SLIME > is a pretty new effort, so documentation is lacking at the moment. > Furthermore, all the environments for CL based on emacs / xemacs have to > deal with the fact that there is a gap between the development > environment and the CL implementation that needs to be crossed, and this > can lead to inconsistencies. A combination of emacs + Smalltalk would > suffer from similar problems, probably even more so.
Thank you for your answer, but I'm not yet quite convinced ;-)
When people are implementing s.th. as great as SLIME, they e.g. know how to implement "Metapoint". I didn't have a look at this, but my impression has been that - despite some differences between the implementations - there are certain mechanisms built into Lisp that ensure the working of such a tool. I.e. what I am missing is (although my example maybe gave this impression) not so much descriptions of how a certain specific environment works, but what the internal working of the Lisp environments are: What is so special about symbols that allows Lisp to be as flexible as it is compared to other languages? While there are some some explanations in all books I have looked in so far, I would appreciate, if exactly this aspect could be stressed more: There is s.th. very special about Lisp (and it's not only macros!), and it has to do with symbols and with the reason, why Lisp does not create usual "stand-alone" applications. I admit that I could figure that probably out myself in more detail if I found the time for it at the moment (perhaps should just do this instead of spending my time with cll) - as everyone else does. But if I didn't have come from Smalltalk, I maybe had not realized this at all, and would have just asked: "And how do I build a stand-alone application?"
Christian Hofer wrote: > The way I came to lisp was via the Squeak mailing lists: people were > crediting Lisp a lot for most of the ideas which seem to make > Smalltalk-80 unique. Now that I have played around with Lisp for a while > I get the impression: it's a really cool language, but it does not > deliver the environment that Squeak has.
I tried to live with early versions of QKS SmalltalkAgents for the Mac, so I think I know what you mean, and you are right, Lisp IDEs suck. That was my first, uh, second reaction to Lisp, the first being that Lisp was fucking awesome.
The good news is that in time you will have developed your own IDE, if you will, of ways of to use Lisp to help you develop Lisp. As for the IDEs, they vary. You would like AllegroCL on win32, which has "Set Breakpoint" under the Run menu, shortcut F7, and just about everything else you might be accustomed to under Squeak: Lisp editor, project manager, class browser, GUI builder, etc, etc. This might be the one Lisp IDE that can hold its own in a comparison with those of C++/Java.
Christian Hofer wrote: > I.e. what I am missing is (although > my example maybe gave this impression) not so much descriptions of how a > certain specific environment works, but what the internal working of the > Lisp environments are: What is so special about symbols that allows Lisp > to be as flexible as it is compared to other languages?
I think I still don't completely understand what you mean, but you might want to read the two following papers (which happen to be my two favorite Lisp papers ;), in that order:
It sounds like you need a Lisp book with a friendly treatment of tools such as break, trace, step, and time. One standard text is Winston and Horn, "Lisp", 3rd ed. It has a chapter on these tools, with enough information to get you started.
Christian Hofer <ch_s...@gmx.de> wrote in message <news:c8nai2$cu8$1@online.de>... > The way I came to lisp was via the Squeak mailing lists: people were > crediting Lisp a lot for most of the ideas which seem to make > Smalltalk-80 unique. Now that I have played around with Lisp for a while > I get the impression: it's a really cool language, but it does not > deliver the environment that Squeak has. To be more precise: This > environment just seems to be hidden from the beginner. (Or have these > ideas really got lost during the Common Lisp standardization process?)
> There is a cool book for learning Squeak from Mark Guzdial, Squeak. > Object-Oriented Design with Multimedia Applications. It has extensive > sections on tool use, exactly what I am missing from Lisp books. The > spirit of Squeak is, that it is more than a language: it is an > environment for developing ideas.
> While the task of the book is easier because it has to handle only one > specific Smalltalk-80 implementation, I would very much appreciate an > introduction on how to use the Lisp language features like the debugger > (not just the small appendix in Graham's ACL), the ways to find methods > / functions etc. - all these things that seem to be built into Lisp > but are not normally regarded as the "programming language", although > they make using the language much more productive. (Now, of course, > macros are part of it, but I mean the more fundamental things.)
> It seems that even Peter Seibel's very interesting book is missing such > a section - but I didn't have time for a close look so far.
> Let me give you an example: I tried to figure out how to do s.th. as > simple as setting a break point. Now I found a function "break". The > hyperspec says:
> "break formats format-control and format-arguments and then goes > directly into the debugger without allowing any possibility of > interception by programmed error-handling facilities.
> If the continue restart is used while in the debugger, break immediately > returns nil without taking any unusual recovery action."
> This does not exactly tell a newbie like me, if this is the usual way to > set a breakpoint. To make it worse, in SLIME with SBCL this does not > open the SLIME debugger, but the SBCL one.
Christian Hofer <ch_s...@gmx.de> writes: > It seems that even Peter Seibel's very interesting book is missing > such a section - but I didn't have time for a close look so far.
And it's not done yet. I've yet to write my chapter on symbols (and packages) which you asked about in another thread. Please do send any comments about either what's there that you like or dislike or what's not that you think should be.
Christian Hofer <ch_s...@gmx.de> wrote in message <news:c8nd9o$i9l$1@online.de>... > I.e. what I am missing is (although > my example maybe gave this impression) not so much descriptions of how a > certain specific environment works, but what the internal working of the > Lisp environments are: What is so special about symbols that allows Lisp > to be as flexible as it is compared to other languages?
I think it is more that most languages don't allow you access to "variable names," than some particularly impressive mojo on lisp's part. Lisp seems like a repetition of one trick, which is the self-interested opening up of the environment to the language user. (As I understand, the traditional benchmark for this opening-up is about increasing expressive power without reducing it in other useful places. Which is likely why it's probably wrong to say CL is a dynamic language, even if it currently happens to be more dynamic than most languages out there. Also this might show where CL can no longer evolve.)
> While there are > some some explanations in all books I have looked in so far, I would > appreciate, if exactly this aspect could be stressed more: There is > s.th. very special about Lisp (and it's not only macros!), and it has to > do with symbols and with the reason, why Lisp does not create usual > "stand-alone" applications.
I recently noticed what a powerful idea it was, how lexical scope and dynamic extent interacted. (A closure performing a 'nonlocal exit' to a block or tagbody, say.) In comparison, my older epiphany about syntactic abstraction seems trivial and immature in comparison. I think lisp's control over syntax is this incredibly flashy thing which doesn't fail in capturing peoples' imaginations, and it certainly is a power multiplier, but lisp is not just about that.
> When people are implementing s.th. as great as SLIME, they e.g. know how > to implement "Metapoint". I didn't have a look at this, but my > impression has been that - despite some differences between the > implementations - there are certain mechanisms built into Lisp that > ensure the working of such a tool.
Maybe you can speak with the Slime developers about your ideas. If these features are as trivial as you imply and would make the devs happy, they'll probably bake it in. I suspect Slime is rather new...
Kenny Tilton wrote: > The good news is that in time you will have developed your own IDE, if > you will, of ways of to use Lisp to help you develop Lisp.
This is exactly what I was trying to express: it's not really a problem that open source IDEs suck, as long as it is possible to develop one's own IDE. I would like to have a description of the interiors of Lisp that make this possible: the power that is contained in the possibility to access the whole programming environment as I know it from Squeak.
But obviously - what I didn't know so far - the implementations are just too different.
Thank you for your answers, they gave me a better impression of what Lisp actually is and what it is not. Still, Lisp is the coolest and most powerful language I have ever seen! (But this is what I first thought when I saw Java, later when I saw Smalltalk, and maybe some time in the future I will think that of Prolog or Oz or some other language - who knows)
My first goal is finishing SICP, maybe I get a better understanding then...
Christian Hofer <ch_s...@gmx.de> writes: > This does not exactly tell a newbie like me, if this is the usual way to > set a breakpoint. To make it worse, in SLIME with SBCL this does not > open the SLIME debugger, but the SBCL one.
> I hope you can understand what I mean.
Having once struggled to learn how to use Lisp, then having used Squeak, I'm pretty sure I know what it is you're asking. The different Lisp implementations are too divergant to write a newbie-friendly guide for what you want. However, the concepts are similar, so we can all understand each other when a user of Lisp X asks a user of Lisp Y, "how do you find the source form for <blank>".
To learn what to look for, you should focus on a particular environment. The open source IDEs are in the process of catching up, but right now are lightyears behind what you're used to. If you have a Mac, I'd recommend getting MCL, otherwise try Allegro for Windows, or LispWorks. They all have demo/personal versions available, and I can vouch for the fact that MCL has the manual you're looking for, "Getting Started with Macintosh Common Lisp."
If you're married to open source software, Hemlock (which runs in CMUCL) still has the best documentation.
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
Christian Hofer <ch_s...@gmx.de> wrote in message <news:c8oepm$id0$1@online.de>... > My first goal is finishing SICP, maybe I get a better understanding then...
SICP seems to be about every OTHER language than lisp. IIRC, access to code-as-data is almost exclusively through the ' operator; macros are only mentioned in a footnote which essentially warns people away from them.
I still think SICP is one of the whoopass books, just that I remember having a pretty anti-lisp conception of lisp after reading it. PLT Scheme was a great IDE, but after writing a few Scheme programs, it became clear how limited everything was. Fortunately, I soon tried Common Lisp.
Scheme is the ultimate ontological attack against lisp.
Thomas F. Burdick wrote: > Having once struggled to learn how to use Lisp, then having used > Squeak, I'm pretty sure I know what it is you're asking. The > different Lisp implementations are too divergant to write a > newbie-friendly guide for what you want. However, the concepts are > similar, so we can all understand each other when a user of Lisp X > asks a user of Lisp Y, "how do you find the source form for <blank>".
> To learn what to look for, you should focus on a particular > environment. The open source IDEs are in the process of catching up, > but right now are lightyears behind what you're used to. If you have > a Mac, I'd recommend getting MCL, otherwise try Allegro for Windows, > or LispWorks. They all have demo/personal versions available, and I > can vouch for the fact that MCL has the manual you're looking for, > "Getting Started with Macintosh Common Lisp."
> If you're married to open source software, Hemlock (which runs in > CMUCL) still has the best documentation.
Maybe I am more married to open source than I am ready to admit. But on the other hand, when I first started with CL, people told me to get used to Emacs. Now I am quite used to it and I hate to click around the different Lispworks tabbed windows with the mouse. What is worse, it does not offer an exact copy of the useful Emacs key bindings that are offered by SLIME. I even don't know if it would run in Linux compatibility mode on FreeBSD (my desktop OS - besides my iBook). (Portable) Hemlock on the other hand didn't even recognize my German keyboard and its umlauts.
Thus, I am quite happy with SLIME, but will probably have to use another environment to better get acquainted to the available tools until I know more of the Lisp internals.
Christian Hofer <ch_s...@gmx.de> writes: > Now I am quite used to it and I hate to click around > the different Lispworks tabbed windows with the mouse. What is worse, > it does not offer an exact copy of the useful Emacs key bindings that > are offered by SLIME.
Well you know that you can "script" the editor. So what prevents you from adding your favourite keyboard shortcuts?
> I even don't know if it would run in Linux > compatibility mode on FreeBSD (my desktop OS - besides my > iBook). (Portable) Hemlock on the other hand didn't even recognize my > German keyboard and its umlauts.
I remember reading that there shouldn't be a problem. But do not have the URL at hand.
Regards Friedrich -- Please remove just-for-news- to reply via e-mail.
> It seems that even Peter Seibel's very interesting book is missing such > a section - but I didn't have time for a close look so far.
> Let me give you an example: I tried to figure out how to do s.th. as > simple as setting a break point. Now I found a function "break". The > hyperspec says:
> "break formats format-control and format-arguments and then goes > directly into the debugger without allowing any possibility of > interception by programmed error-handling facilities.
The lack of a readily available "How to USE CL" piece has been a lament of mine for somekind.
There always seemed to be a large amount of folklore that buzzes in the background about using Lisp, but very little written about it.
The kind of thing that were you working next to a Lisp Guru, he wouldn't just be kibitzing your code or style, but also code layout, and tool use.
How often do you come up on a co-worker and see them struggling with some process to which you know a much easier way? Then, perhaps you might chime in with how to do it the better way.
For me, this is a key motivation behind Lisp In A Box, particularly for someone like Peter, because it will give him a reasonably consistent and portable laboratory on which he can describe not just CL language elements and syntax, but also package layout, interaction with Emacs and how SLIME/ILISP/etc interface and interact with CL to make both easier and more powerful.
This kind of thing, if nothing else, gives readers a baseline for when they move on to another environment. "In LIAB, I could do X by doing Y. How can I do the same thing in QED Lisp?". With several implementations, it can't be expected the book authors go into detail about using the system. But with a readily available, portable, and painless to install system, a book author could easily leverage that.
I'm sure for many features, Allegro, LW and MCL overlap, but for new people who simply have no exposure to those features, they simply may not know what they're missing, or write some feature off as less important than it sounds.
"Will Hartung" <wi...@msoft.com> writes: > The kind of thing that were you working next to a Lisp Guru, he wouldn't > just be kibitzing your code or style, but also code layout, and tool use. ... > For me, this is a key motivation behind Lisp In A Box, particularly for > someone like Peter, because it will give him a reasonably consistent and > portable laboratory on which he can describe not just CL language elements > and syntax, but also package layout, interaction with Emacs and how > SLIME/ILISP/etc interface and interact with CL to make both easier and more > powerful.
I only got off the ground with Lisp (if I am indeed off the ground) because of the existence of SLIME. I may have been able to get off the ground sooner if I switched to Debian Linux sooner than I did (from a different Linux distro). But that's debatable because by the time I switched over to Debian, I was too busy with other things to deal with Lisp.
Now that I am working on picking up Lisp, I have other obstacles. Even with a high quality environment, I have no personal contact with any Lispers. Everyone I know thinks Lisp is a dead language and is either playing with Java, Perl, or (in one odd case) Ada.
That leaves me with the Internet as my only support mechanism. I can't watch people's workflow over the Internet.
Another requirement I have is a uniform environment between Mac OS X and Linux. I use both and don't want to have to deal with different key bindings or anything else that adds to what I need to learn. The learning curve is steep enough for me thank you very much. Emacs + Slime to the rescue again! The carbon build of Emacs I have from CVS + Slime from CVS gives me an almost identical look and feel with Emacs from Debian + Slime from CVS.
I also got uControl for my Mac so I could map the caps lock key to the ctrl function.
So what am I left with? The hump I needed to get over to start mucking about with Lisp was sufficiently lowered for /me/. I can't speak for others. I can now poke around the Hyperspec and enter code into a lisp buffer (not just the repl) in Slime and play around with it. I even noticed this evening (doing a C-h b in the lisp buffer) that there are key bindings to toggle trace/untrace of a function in Slime. I'll have to try those. But so far I've been mostly on my own working out an efficient workflow so that the tools are working with me to help me with Lisp.
I think the workflow issue is very important. I expect a lot of potential neo-lispers are like me in that they have no one looking over their shoulder as they do stuff. I also expect there are plenty of people like me who do not want to go through C-h t or read the entire Emacs manual. I actually don't care to have to learn any ELisp as well. ANSI Common Lisp is big enough.
LIAB can really help with this. It is also possible that people may be better served by the trial versions of LW and Alegro. I'm something of a FOSSite, so I went the Free route even though it also ment a steeper climb. Free is not without cost ;-).
I don't know how much lead time Peter has before his book is cast in camera copy, but a workflow appendix would probably be a very good thing. Workflow should not be considered an advanced topic either. Dealing with the debugger, for example, is something that is likely to come up very early on. So far, my main goal has been to get out of the debugger.
Norvig's PAIP has some stuff related to that in Part III. But it already assumes some reasonable amount of knowledge. Norvig is talking about program efficiency, not programmer efficiency.
With LIAB, one can get very specific about workflow. But it would be nice to have good coverage of a broad subset of things lispers do to produce working code. I can't imagine that some of the more complex macro examples I have seen were conceived fully formed. Functions less trivial than (fib n) probably also go through a code test recode cycle. All that involves working with the tools and with Lisp's own built in facilities to get the job done.
-- I wouldn't mind the rat race so much if it wasn't for all the damn cats.
David Steuber <da...@david-steuber.com> writes: > I only got off the ground with Lisp (if I am indeed off the ground) > because of the existence of SLIME.
Can you say why? I'm curious, because for me it would be the opposite. Having to learn an IDE tool like SLIME would be an obstacle.
> I think the workflow issue is very important.
That makes me wonder too: when did "workflow" start being a word that was used in such contexts? (And when did it start being a word?)
[This is not a criticism of you. I work on workflow tools these days. I'm just wondering where this way of thinging entered the picture and when.]
> I can't imagine that some of the more complex > macro examples I have seen were conceived fully formed. Functions > less trivial than (fib n) probably also go through a code test recode > cycle. All that involves working with the tools and with Lisp's own > built in facilities to get the job done.
It's not necessary to do anything very elaborate. Lisp probably has less need for fancy IDEs than most languages.
Jeff Dalton wrote: > David Steuber <da...@david-steuber.com> writes:
>> I only got off the ground with Lisp (if I am indeed off the ground) >> because of the existence of SLIME.
> Can you say why? I'm curious, because for me it would be > the opposite. Having to learn an IDE tool like SLIME > would be an obstacle.
It was the same for me, actually; I started with ilisp, but gravitated towards Slime fairly quickly.
In either case it was anything but an obstacle; the IDE gives me better debugging capabilities, automatic indentation, *editing* capabilities, and so on and so forth repeating itself redundantly without end /ad/ /infinitum/. [1]
The alternative is (was) to work with the raw REPL, what you get when typing 'sbcl' at the command line. Sure, that's still better than what you get with Python (mostly) or Java (definitely), but Lisp is supposed to be beyond that.
Slime is a large part of what makes Lisp the best language for me. More to the point: I already knew Emacs, and Slime doesn't get in the way (a lot [2]. I don't need to use its features if I don't want to.
>> I think the workflow issue is very important.
> That makes me wonder too: when did "workflow" start being > a word that was used in such contexts? (And when did it > start being a word?)
> [This is not a criticism of you. I work on workflow > tools these days. I'm just wondering where this way > of thinging entered the picture and when.]
What does workflow mean for you?
For me, in Java, it's edit-compile-run-insert_print_statements-compile-run-repeat. I never *did* find a debugger I liked; Eclipse might make things better, but I'm too lazy to learn it right now.
In Lisp, I can do... well, anything I want. I've yet to think of anything that would be good for debugging that Lisp/Slime doesn't already do.
>> I can't imagine that some of the more complex >> macro examples I have seen were conceived fully formed. Functions >> less trivial than (fib n) probably also go through a code test recode >> cycle. All that involves working with the tools and with Lisp's own >> built in facilities to get the job done.
> It's not necessary to do anything very elaborate. Lisp > probably has less need for fancy IDEs than most languages.
Yes, because of the REPL; yet, as mentioned, Slime doesn't get in the way; you can treat it as nothing but an enhanced REPL if you like.
--
1: My newsreader uses cursive for this, and similar for other decorations. Does yours? Can I rely on it, these days?
2: I want to put (declare (optimize debug)) in .sbclrc, but it doesn't work. Please help me?
In article <gmrtc.4379$RL3.85...@news2.e.nsc.no>, Svein Ove Aas <svein+usene...@brage.info> wrote:
>Jeff Dalton wrote: >> Can you say why? I'm curious, because for me it would be >> the opposite. Having to learn an IDE tool like SLIME >> would be an obstacle.
>The alternative is (was) to work with the raw REPL, what you get when >typing 'sbcl' at the command line. Sure, that's still better than what >you get with Python (mostly) or Java (definitely), but Lisp is supposed >to be beyond that.
No, no. The alternative is to work in your favorite editor (which you already know), set up a build script to automate compilation of your program, and then run it.
That's how I worked in Java until I went to the trouble of familiarizing myself with NetBeans; it's how I worked in .NET until I went to the trouble of using Visual Studio; it's how I worked in Perl at all times; and it's how I'm working in Lisp until I go to the trouble of learning SLIME. (Of course, since my preferred editor is Emacs, the learning curve shouuld be rather shorter, here.)
>> It's not necessary to do anything very elaborate. Lisp >> probably has less need for fancy IDEs than most languages.
>Yes, because of the REPL; yet, as mentioned, Slime doesn't get in the way; >you can treat it as nothing but an enhanced REPL if you like.
I don't see how the REPL has a thing to do with IDEs. The point of an IDE is to be (as the name indicates) an integrated development environment, to bring together all (or, at least, most of) the tools you normally use -- the editor, the compiler, the build configuration stuff, the debugger, the version control, the resource editors, the unit test runners -- in one place, working in a single interface. The REPL doesn't do anything toward integrating those tools.
In article <fx465ahltha....@todday.inf.ed.ac.uk>, Jeff Dalton <j...@todday.inf.ed.ac.uk> wrote:
> > I think the workflow issue is very important.
> That makes me wonder too: when did "workflow" start being > a word that was used in such contexts? (And when did it > start being a word?)
Don't know about anyone else, but I think I first came across the word when I started poking my nose into the printing industry in the mid 80's (because of PostScript).
>> Yes, because of the REPL; yet, as mentioned, Slime doesn't get in the way; >> you can treat it as nothing but an enhanced REPL if you like.
[Mike:]
> I don't see how the REPL has a thing to do with IDEs. The point of an > IDE is to be (as the name indicates) an integrated development > environment, to bring together all (or, at least, most of) the tools > you normally use -- the editor, the compiler, the build configuration > stuff, the debugger, the version control, the resource editors, the > unit test runners -- in one place, working in a single interface. The > REPL doesn't do anything toward integrating those tools.
I suppose it depends on what you think the process of "development" is. For me, an interactive command line -- a REPL -- *is* a key development tool, in any language that has one. The "command line" bit isn't absolutely essential here; something like a Smalltalk environment (have a play with Squeak if you never have) would do too even though what it provides isn't exactly a command line :-). But the ability to interact directly with the system is an amazingly helpful development tool, and I miss it enormously when I'm writing software in a language (implementation) that lacks that ability.
So, for me, the REPL has as much to do with IDEs as the debugger, the class browser, or the compiler.
Jeff Dalton <j...@todday.inf.ed.ac.uk> writes: > David Steuber <da...@david-steuber.com> writes:
> > I only got off the ground with Lisp (if I am indeed off the ground) > > because of the existence of SLIME.
> Can you say why? I'm curious, because for me it would be > the opposite. Having to learn an IDE tool like SLIME > would be an obstacle.
Well it's nice to use an editor for code. But what's really nice is that SLIME gives you a repl buffer as well as a code buffer. You can play with things in the repl. But what I really like is that in the code buffer, I can do things like C-c C-c to compile a function or macro definiton, C-x C-e to eval an expression, C-c RET to see a macroexpand-1, etc. The repl is there, but the need to use it is greatly diminished.
There are other cool things like autodoc-mode that show hints in the mini buffer for function/macro arguments. You can lookup symbols at the point in the CLHS.
Everything is made easier.
> > I think the workflow issue is very important.
> That makes me wonder too: when did "workflow" start being > a word that was used in such contexts? (And when did it > start being a word?)
I got contaminated by this at my last job. I had to design and implement a workflow system for a website. At the time, I had no idea what the heck one of those things was.
> [This is not a criticism of you. I work on workflow > tools these days. I'm just wondering where this way > of thinging entered the picture and when.]
Work. Flow. I don't know.
It seems like a reasonable way to describe the process of development though.
> > I can't imagine that some of the more complex > > macro examples I have seen were conceived fully formed. Functions > > less trivial than (fib n) probably also go through a code test recode > > cycle. All that involves working with the tools and with Lisp's own > > built in facilities to get the job done.
> It's not necessary to do anything very elaborate. Lisp > probably has less need for fancy IDEs than most languages.
One other thing I like is being able to doodle in the editor and use a simple key chord to see if the code will compile and run. I can stick litle test forms after the functions I've just compiled to see if I get what I'm hoping for.
I'm still learning the language, so I find all this incredibly useful.
I expect that next to Xcode, Visual Studio .NET, etc, many people won't think of Emacs + SLIME as a fancy IDE. Underneath that text interface though is some cool stuff.
-- An ideal world is left as an excercise to the reader. --- Paul Graham, On Lisp 8.1
David Steuber <da...@david-steuber.com> writes: > C-c RET to see a macroexpand-1, etc.
Why do you (and Emacs) talk about it as C-c RET when C-c C-m is actually mnemonic? I suppose you do it because Emacs does, but that's no excuse for things like Emacs's manual using C-x RET for the Mule bindings....
> > David Steuber <da...@david-steuber.com> writes:
> >> I only got off the ground with Lisp (if I am indeed off the ground) > >> because of the existence of SLIME.
> > Can you say why? I'm curious, because for me it would be > > the opposite. Having to learn an IDE tool like SLIME > > would be an obstacle.
> It was the same for me, actually; I started with ilisp, but gravitated > towards Slime fairly quickly.
> In either case it was anything but an obstacle; the IDE gives me better > debugging capabilities, automatic indentation, *editing* capabilities, > and so on and so forth repeating itself redundantly without > end /ad/ /infinitum/. [1]
Emacs with a suitable Lisp-editing mode gives you automatic indentation, and editing. Lisp systems have step and trace and backtrace built-in. You can also run your Lisp in an Emacs shell buffer, thus making it easy to edit commands as you type them in and to repeat commands.
You get a lot without having to work out how to install and use an IDE tool.
(I used to use ILISP and even adapted it to some Lisps that it didn't already support, so I thought it was worth a fair amount of trouble. But if I'd needed to work out how to use ILISP before I could do much with Lisp, it would have been an obstacle.)
> In Lisp, I can do... well, anything I want. I've yet to think of > anything that would be good for debugging that Lisp/Slime doesn't > already do.
I've written additional debugging tools for some systems, built-in tools weren/t sufficient. Fortunately, Lisp makes it easy to do that.
David Steuber <da...@david-steuber.com> writes: > Jeff Dalton <j...@todday.inf.ed.ac.uk> writes:
> > David Steuber <da...@david-steuber.com> writes:
> > > I only got off the ground with Lisp (if I am indeed off the ground) > > > because of the existence of SLIME.
> > Can you say why? I'm curious, because for me it would be > > the opposite. Having to learn an IDE tool like SLIME > > would be an obstacle.
> Well it's nice to use an editor for code. But what's really nice is > that SLIME gives you a repl buffer as well as a code buffer.
Emacs can do that for you: run your Lisp in a shell buffer. Your REPL is there, and you use other buffers for editing files.
Here are some obstacles to using SLIME:
* It works with only some Common Lisps.
* It looks like you're supposed to get it from the CVS repository rather than just grabbing a tar file from a URL.
* The web page http://common-lisp.net/project/slime/ currently doesn't work, and that's the site the obvious Google search gives you and the one linked from Cliki.
* You then have to learn the various commands and key bindings.
> You can play with things in the repl. But what I really like is > that in the code buffer, I can do things like C-c C-c to compile > a function or macro definiton, C-x C-e to eval an expression, > C-c RET to see a macroexpand-1, etc. The repl is there, but > the need to use it is greatly diminished.
Ok, but those sound more like habits you'd get into after you'd been using SLIME for a while, rather than things that would get you off the ground with Lisp.
Were you used to having an IDE for other languages before you started using Lisp?
