"Dr.X" <nospam_at_...@rxp.com> writes: > Wow, this is probably the most active ng on programming I have > ever seen. maybe I can learn something here. I want to learn a > programming language. can anyone tell me why I should look at > lisp?
Yes.
>is there any sort of "visual" lisp I can get, sortta like > "visual" basic or some type of IDE that will help with the > learning curve?
Yes, I prefer LispWorks which is an excellent choice.
> is there a freebee download?
you can try out their test version
> is there a dll or > runtime gadget I have to get to start with?
What do you mean by this?
> CAUTION, STUPID > QUESTION AHEAD: is there a program anywhere that will allow lisp > to be run directly on the windows scripting host? some kind of > "lisp script"?
LispWorks on windows supports COM therefor it should be possible to use it for "Scripting" too. But I'm sure for the start it's not the easiest thing to do.
> > Don't be so sure. Greenblatt *still* programs Lisp this way.
> And if you use too many go tags, does the lisp machine compiler > error still say "That's too many go tags, RG!" ? [1] Actually, I'm > not sure of the precise message text, and am not in the right room > to just type in a test to my LispM, but I recall it used to mention > him by name. :-)
> > > Don't be so sure. Greenblatt *still* programs Lisp this way.
> > And if you use too many go tags, does the lisp machine compiler > > error still say "That's too many go tags, RG!" ? [1] Actually, I'm > > not sure of the precise message text, and am not in the right room > > to just type in a test to my LispM, but I recall it used to mention > > him by name. :-)
> > [1] RG = Richard Greenblatt
> Who is this Richard Greenblatt?
Well see Hackers from Stephen Levy. Starting around chapter 4 I cite: "... Greenblatt was a hacker waiting to be happen" Of course a Lisp Hacker ;-) and what makes him even more outstanding is that he is regarded as the "Father" of LispMachines. I just can suggest reading that book it's really facinating.
Friedrich Dominicus <fr...@q-software-solutions.com> writes: > Well see Hackers from Stephen Levy. Starting around chapter 4 I > cite: "... Greenblatt was a hacker waiting to be happen" Of course a > Lisp Hacker ;-) and what makes him even more outstanding is that he > is regarded as the "Father" of LispMachines. I just can suggest > reading that book it's really facinating.
Thanks. I tried to get this book about one or two years ago and it seemed to be out of print. I just checked again with Amazon and it looks like now it's available again - maybe a reprint -, so I ordered it.
Kenny Tilton <ktil...@nyc.rr.com> writes: > Nils Goesche wrote:
> > Most people only arrive at Common Lisp after learning several > > other programming languages, and it is hard to tell how hard it > > really is to use Lisp as a first programming language, especially > > as I am not sure if there is any book on Lisp that is really > > directed at total programming newbies.
> Touretzky, David S. "Common Lisp: A Gentle Introduction to Symbolic > Computing" at least /includes/ programming newcomers amongst its > intended audience.
I was actually just about to recommend this book. I recently recommended it for a friend's much younger sibling who has no experience programming whatsoever, and apparently he's eating it up.
BTW, anyone know of a good easy-to-use for a newbie GUI system for MCL? We almost pointed this kid at Squeak, but figured that a multiparadigm language was probably less likely to give him the OO equivilent of the BASIC hangups we both suffered from. If we can avoid having to re-port Garnet, that'd be nice...
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
Nils Goesche wrote: > :-) I quickly realized that you don't get very far with that and > switched to 6502 Assembler for the next few years. But that is not > a way I'd recommend to the OP :-) But then: The reason we like > high level languages is that they free us from doing the same ugly > low level details over and over again; but how is someone who doesn't > even /know/ those details supposed to appreciate, and, more importantly, > make use of that? Or ever really understand the difference between > EQ and EQL? I think it is impossible to ever become a good programmer > if you don't know how a computer actually works, internally. So, frankly > I think it would still be best to learn programming with C, actually.
I'm not sure 6502 assembler is such a bad thing to learn early on. I think I'd recommend new programmers to learn
- an assembly language, so they get a good feel for what computers can fundamentally do and how fast. (I'd recommend ARM assembler, because it's simple and elegant.)
- C, for pragmatic reasons and also because its close correspondence with machine code helps to give a feel for what the computer does when you feed it a loop or an assignment or something.
- a much higher level language (Common Lisp would be good; Python or Smalltalk would do OK, too), to appreciate that programming doesn't have to hurt and to teach modes of thinking that arise only with difficulty at lower levels.
I think it's very difficult (I won't say impossible) to become a really good programmer if you don't have all three perspectives.
-- Gareth McCaughan Gareth.McCaug...@pobox.com .sig under construc
Gareth.McCaug...@pobox.com (Gareth McCaughan) writes: > Nils Goesche wrote:
> > :-) I quickly realized that you don't get very far with that and > > switched to 6502 Assembler for the next few years.
> I'm not sure 6502 assembler is such a bad thing to learn > early on. I think I'd recommend new programmers to learn
> - an assembly language, so they get a good feel for > what computers can fundamentally do and how fast. > (I'd recommend ARM assembler, because it's simple > and elegant.)
Right. ARM would be great. But how is the newbie supposed to test his code? Maybe there are emulators that run on a PC, but IIRC running my code on an emulator wouldn't have satisfied me very much. And he is not likely to get access to a JTAG debugger any time soon :-)
> - C, for pragmatic reasons and also because its close > correspondence with machine code helps to give a > feel for what the computer does when you feed it > a loop or an assignment or something.
ACK. I also think that one of the main reasons why knowing C is so important is that all those Lisp FFI interfaces connect to /C/ :-)
> - a much higher level language (Common Lisp would be > good; Python or Smalltalk would do OK, too), to > appreciate that programming doesn't have to hurt > and to teach modes of thinking that arise only with > difficulty at lower levels.
> I think it's very difficult (I won't say impossible) to > become a really good programmer if you don't have all three > perspectives.
Certainly. An open question remains, which perspective should come first. Frankly, I believe the most low level one the student still enjoys would be best.
Regards, -- Nils Goesche Ask not for whom the <CONTROL-G> tolls.
> I'm not sure 6502 assembler is such a bad thing to learn > early on. I think I'd recommend new programmers to learn
> - an assembly language, so they get a good feel for > what computers can fundamentally do and how fast. > (I'd recommend ARM assembler, because it's simple > and elegant.)
> - C, for pragmatic reasons and also because its close > correspondence with machine code helps to give a > feel for what the computer does when you feed it > a loop or an assignment or something.
> - a much higher level language (Common Lisp would be > good; Python or Smalltalk would do OK, too), to > appreciate that programming doesn't have to hurt > and to teach modes of thinking that arise only with > difficulty at lower levels.
> I think it's very difficult (I won't say impossible) to > become a really good programmer if you don't have all three > perspectives.
I agree.
Furthermore, I've got a nice Apple ][ emulator on my Mac, and original Apple ][+ manuals, including the monitor ROM listing, circuit diagram and so forth.
That was a machine that you could study and without too much trouble understand every part of at *all* levels.
8 bit micros are a bit hard to get real things done on, so I suspect that you'd want to transition to something else fairly quickly. SPIM isn't too bad (MIPS emulator), but doing real native programs is better, PowerPC is nearly as clean as MIPS and ARM, and with OS X you're not going to bring the machine down when you make the inevitable mistakes.
Here's a little program that I used to help expose my partner to some ASM programming last year:
li r20,1 loop: li r3,line mr r4,r20 bl printf addi r20,r20,1 cmpi cr0,r20,10 ble loop
li r3,tail bl printf li r3,0 return
head: .ascii "Content-type: text/html\n\n" .asciz "<html><body><h1>Counting to ten!</h1><p>\n" tail: .asciz "</body></html>\n" line: .asciz "i = %d<p>\n" -----------------------------------------------------------
I think CGI programs are a great way to introduce people to programming. Nice and simple and yet you can get quite nice formatting and user interfaces. Well ... what people these days are used to accepting, anyway :-)
There are a couple of fine points that I've glossed over in that program for simplicity -- stubs to deal with dynamic linking, wrappers around function call to deal with saving/restoring the PC and the callee-save registers (r13-r31). Here are the necessary macros:
----------------------------------------------------------- .globl _main _main: b main
> li r20,1 > loop: li r3,line > mr r4,r20 > bl printf > addi r20,r20,1
[snip]
Wow, I'm impressed. /My/ partner (wife) would /slap/ me if I tried to expose her to something like this, instead of taking her to the most fashionable restaurant in town :-)
Regards, -- Nils Goesche Ask not for whom the <CONTROL-G> tolls.
* Nils Goesche <n...@cartan.de> | ACK. I also think that one of the main reasons why knowing C is so | important is that all those Lisp FFI interfaces connect to /C/ :-)
Although clearly tongue-in-cheek, this is true only because C is the predominant Other Language as seen from Common Lisp. Back when Fortran was the Other Language, Common Lisp competed aggressively with it in its domain, with a lot of mathy stuff that I doubt is used very much. Now that all that computing is about is burning billions of Hz in GUIs, Common Lisp needs to interface to the lingua franca of those tools
| Certainly. An open question remains, which perspective should come | first. Frankly, I believe the most low level one the student still | enjoys would be best.
I cannot parse the last sentence, but for what it might be worth, Donald Knuth thinks assembly language is such a great vehicle for understanding computing that he has invented his own in order to teach people The Art of Computer Programming. I tend to agree, except that I would _so_ have loved TAoCP to have been based on, say, the PDP-10 instruction set and design rather than the el bizarro toy computer that MIX sort of codes to.
/// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
> | Frankly, I believe the most low level one the student still > | enjoys would be best.
> I cannot parse the last sentence, but for what it might be worth, Donald > Knuth thinks assembly language is such a great vehicle for understanding > computing that he has invented his own in order to teach people The Art > of Computer Programming. I tend to agree, except that I would _so_ have > loved TAoCP to have been based on, say, the PDP-10 instruction set and > design rather than the el bizarro toy computer that MIX sort of codes to.
Have you taken a look at his new toy, MMIX? 256 64-bit gp registers, 32 special registers, and 2^64 bytes VM. Some posters in c.l.forth are livid about register overkill, lack of `proper' stack support (the J register is alive and well), combining float and integer support in a register, not to mention the number of transitors it would take to implement the design.
"Geoff Summerhayes" <sNuOmSrPnA...@hNoOtSmPaAiMl.com> writes: > Have you taken a look at his new toy, MMIX? 256 64-bit gp registers, > 32 special registers, and 2^64 bytes VM. Some posters in c.l.forth > are livid about register overkill, lack of `proper' stack support > (the J register is alive and well), combining float and integer > support in a register, not to mention the number of transitors it > would take to implement the design.
Do you think that as the price of hardware drops, the future of CPU's is likely to be what we now think of as wasteful? I'm just trying to guess why Knuth would go for an unrealistic design -- maybe it's because he thinks it won't remain unrealistic.
"Geoff Summerhayes" <sNuOmSrPnA...@hNoOtSmPaAiMl.com> wrote: > Have you taken a look at his new toy, MMIX? 256 64-bit gp registers, > 32 special registers, and 2^64 bytes VM. Some posters in c.l.forth > are livid about register overkill, lack of `proper' stack support > (the J register is alive and well), combining float and integer > support in a register, not to mention the number of transitors it > would take to implement the design.
Consider the numbers of transistors used in modern Intel CPUs and it doesn't seem too spectacularly odd.
They should keep in mind that it is designed as an _educational tool_. It's not intended as the be-all and end-all of what CPUs should look like.
The presence of "blemishes" strikes me as a downright _good_ thing, as, in the real world, Nth generation CPUs seldom stay completely clean.
The notion of using 64 bit floats should make it obvious that this isn't something expected to be characteristic of typical future system designs. Actually, that should be pedagogically quite useful as it should be not too difficult to build interesting examples that stress 64 bit floats to the point of them breaking, and that's exactly the sort of thing that's useful to have students come to understand.
If they learn that floats have some weaknesses, that would surely be a more useful result than the typical thing of students concluding that "Lisp is only good for processing lists" or rubbish like that. -- (reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa")) http://www3.sympatico.ca/cbbrowne/linuxxian.html "Absolutely nothing should be concluded from these figures except that no conclusion can be drawn from them." -- By Joseph L. Brothers, Linux/PowerPC Project
Geoff> "Erik Naggum" <e...@naggum.net> wrote in message Geoff> news:3225694045810240@naggum.net... >> * Nils Goesche <n...@cartan.de> >> >> | Frankly, I believe the most low level one the student still >> | enjoys would be best. >> >> I cannot parse the last sentence, but for what it might be worth, Donald >> Knuth thinks assembly language is such a great vehicle for understanding >> computing that he has invented his own in order to teach people The Art >> of Computer Programming. I tend to agree, except that I would _so_ have >> loved TAoCP to have been based on, say, the PDP-10 instruction set and >> design rather than the el bizarro toy computer that MIX sort of codes to. >>
Geoff> Have you taken a look at his new toy, MMIX? 256 64-bit gp Geoff> registers, 32 special registers, and 2^64 bytes VM. Some
I think Ultrasparcs have 200 64-bit registers, but you can only access 32 at a time, because of the register windows. :-) They also support 2^64 bytes of VM. I think HP PA-RISC has a 96-bit virtual space.
> Do you think that as the price of hardware drops, the future of CPU's > is likely to be what we now think of as wasteful? I'm just trying to > guess why Knuth would go for an unrealistic design -- maybe it's > because he thinks it won't remain unrealistic.
I don't know what `what we now think of as wasteful' is so I can't argue the point. As for the unrealistic part, have you looked at, for example, the Itanium line from Intel?
* "Geoff Summerhayes" | Have you taken a look at his new toy, MMIX?
No, I have not even heard about it. Is it used in the next edition of TAoCP and the remaining volumes?
| 256 64-bit gp registers, 32 special registers, and 2^64 bytes VM.
Heh, I like. That probably also means Unicode characters, instead of the rather bizarre character set used in MIX. :) It might be more work to implement an emulator, however. A MIX emulator is not that easy, either, due to the TeX-like random complexity.
| Some posters in c.l.forth are livid about register overkill, lack of | `proper' stack support (the J register is alive and well), combining | float and integer support in a register, not to mention the number of | transitors it would take to implement the design.
I would worry more about the cost of context switching on this design.
/// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
> > Have you taken a look at his new toy, MMIX? 256 64-bit gp registers, > > 32 special registers, and 2^64 bytes VM. > Do you think that as the price of hardware drops, the future of CPU's > is likely to be what we now think of as wasteful?
> I'm just trying to guess why Knuth would go for an unrealistic > design -- maybe it's because he thinks it won't remain unrealistic.
It's definitely quite realistic today.
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
Raymond Toy <t...@rtp.ericsson.se> writes: > I think HP PA-RISC has a 96-bit virtual space.
I have a feeling that that's only used in the Superdome, their NUMA box, where you have 64-bits of address space per node, and the rest addresses the node.
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
> | 256 64-bit gp registers, 32 special registers, and 2^64 bytes VM.
> Heh, I like. That probably also means Unicode characters, instead of the > rather bizarre character set used in MIX. :) It might be more work to > implement an emulator, however. A MIX emulator is not that easy, either, > due to the TeX-like random complexity.
Hey, I kind of liked it! I haven't had a chance to read the specification all the way through yet, I wonder if we'll still get a revised version the cute bootstrap problem 1.3.2(26) My attempt just fit, I remember being annoyed that his solution was shorter.
> | Some posters in c.l.forth are livid about register overkill, lack of > | `proper' stack support (the J register is alive and well), combining > | float and integer support in a register, not to mention the number of > | transitors it would take to implement the design.
> I would worry more about the cost of context switching on this design.
Rahul> Raymond Toy <t...@rtp.ericsson.se> writes: >> I think HP PA-RISC has a 96-bit virtual space.
Rahul> I have a feeling that that's only used in the Superdome, their NUMA Rahul> box, where you have 64-bits of address space per node, and the rest Rahul> addresses the node.
Not having ever seen or really used an HP, I can't say. However, I think that every memory reference has the 64-bit value in a register which is added to a 64-bit value from the space register, which is left shifted 32 bits. Thus 96 bits of space. (Only on the 64-bit versions.)
But I don't have my HP arch book here, so I can't check right now.
Erik Naggum wrote: > * "Geoff Summerhayes" > | Have you taken a look at his new toy, MMIX?
> No, I have not even heard about it. Is it used in the next edition of > TAoCP and the remaining volumes?
> | 256 64-bit gp registers, 32 special registers, and 2^64 bytes VM.
> Heh, I like. That probably also means Unicode characters, instead of the > rather bizarre character set used in MIX. :) It might be more work to > implement an emulator, however. A MIX emulator is not that easy, either, > due to the TeX-like random complexity.
Fortunately, Knuth has already written more than one MMIX emulator. There's a whole book containing the code (as a "literate program"). One emulator is simple and straightforward. The other is a big hairy thing that simulates multiple execution units and all that stuff.
-- Gareth McCaughan Gareth.McCaug...@pobox.com .sig under construc
> > I'm not sure 6502 assembler is such a bad thing to learn > > early on. I think I'd recommend new programmers to learn
> > - an assembly language, so they get a good feel for > > what computers can fundamentally do and how fast. > > (I'd recommend ARM assembler, because it's simple > > and elegant.)
> Right. ARM would be great. But how is the newbie supposed to > test his code? Maybe there are emulators that run on a PC, but > IIRC running my code on an emulator wouldn't have satisfied me > very much. And he is not likely to get access to a JTAG debugger > any time soon :-)
Foo. I'd forgotten that there aren't any real computers with ARMs inside any more. (My last-but-one computer was an Acorn Risc PC, based on an ARM6. Already obsolete in some ways before it was released, but rather nice even so.)
If we wait a few years, someone might have found a way to make PDAs usable for programming. ARM is doing very well in that space.
-- Gareth McCaughan Gareth.McCaug...@pobox.com .sig under construc
On Sat, 23 Mar 2002 02:01:26 +0000, Gareth.McCaug...@pobox.com (Gareth
McCaughan) wrote: > If we wait a few years, someone might have found a way to > make PDAs usable for programming. ARM is doing very well > in that space.
Future Palm devices with Palm OS 5.x will be based on ARM chips.
