I think you don't realize that if you had 500 of disposable income to spend during the PS1 generation of games, you (theoretically) have $600 to spend now. The median household income in the US has risen from $34,000 a year in 1995 (when the $50 price was originally set) to $44,000 a year in 2005.
Every buy RPGs? They usually required the big carts. I remember paying $60 or $70 for Final Fantasy III. Chrono Trigger was I think $70 here, and around $100 in Japan.
What is this "again" you speak of? Games are cheaper now than they've been in the 17 years since I got my first console. When did these cheap games come out?
$300 for a console is hardly that bad! The Sega Saturn came out at $400 ($498 adjusted for inflation), the PSX came out at $300 ($373 adjusted for inflation). The NES came out at $200 ($354 adjusted for inflation), while the SNES came out at $200 too ($282 adjusted for inflation).
$60 for a game ain't too bad either. Anybody remember paying $60 for SNES games back in the day? That's $85 in today's money! Games have been stuck at $50 for a decade. During that whole time, the cost of making a game has gone way up. Even still, moving up to $60 doesn't even cover inflation somce then!
Did you read either my post or the post I replied to? This isn't about "Apple should sell OS X standalone" or "I want to pirate OS X". It's about: "I think Apple's hardware is crap and I'd gladly pay extra to run the software on a platform of my choice". The OP implied that the only reason for someone who likes OS X to want to run it on a generic PC, instead of buying a Mini, is because they are cheap. That's just not true. Even if I could get a G5 for the same price I paid for my Athlon, I wouldn't do it.
You're forgetting that Apple ships a new OS every 12-18 months. Meanwhile, a person upgrades their Mac once every several years. Like I said, I'd be willing to pay $200 a year to keep getting the newest versions of OS X. After just one upgrade cycle, that blows away the margin lost from me not buying a Mini.
My point is that the original poster made a very stupid statement. He asked: "if you liked MacOS X so much, you would have bought a Mini". The Mini is completely useless to me. It just doesn't have the horsepower to run the things I run. I don't care if its more expensive for me to just buy the software than it is to get the Mini. I don't want to have to run such a nice OS on such a POS box.
Your comment makes no sense. Why would I want to sell my Athlon? It's a dual-core 2.2GHz Athlon64 (with 1MB of cache on each chip) with 2GB of RAM and a 250GB disk. It's an all-SATA, all-PCI Express, dual network ports, Firewire, and a nice, quiet case (Antec P180). You can't even buy an equivalent G5, certainly not for the $1300 I spent building it.
I'm really into compiler programming, and Apple doesn't make sell an equivalent processor for me. The G5's integer throughput is pretty bad (its long pipeline puts it closer to a P4 than an Athlon in efficiency). To get even near the same performance for the code I run on a G5, I'd have to move up to the 2.7GHz watercooled model, and even then, the relatively small 512KB cache hurts performance on integer code.
On the other hand, I love OS X, and would gladly give Apple my money. But I refuse to live with inferior hardware to do it.
Ok? Got it? If you really wanted OSX as much as you purport you would have bought a mac mini.
Question: why in the world would I want to spend $500 on a crappy Mac Mini when I've got an Athlon X2 sitting on my desk? My computer is pretty fast, but its still not fast enough for some of the stuff I run. Why on earth would I want to downgrade so much?
On the other hand, I'd happily pay Apple $200 (or whatever they're charging for OS X these days) every upgrade cycle to run OS X on my computer. It's not about cheap, it's about choice!
Your arguments may make sense why C, C++ and Java are more popular than Lisp, but it doesn't explain why Python and Ruby are as well.
Consider the niches that Python and Ruby target: web programming and systems glue. There is a large body of existing code in these languages for doing those tasks. Meanwhile, consider the niche that Lisp originally occupied: AI and compiler theory. Guess which niche has more programmers?
Your demographics argument is species. Old Lisp programmers where young once.
Yes, but when they were young (or equivalently, when Lisp was much more popular than it is now), the internet either didn't exist, or was very limited in scope. Without the internet, you can only have basically one kind of open source: academic. Academic open source tends to produce a very specific type of software, a kind that is usually not very interesting to your average user. By the time the modern open source movement came around, with people working on "mainstream software" for "regular users" across the internet, the popularity of Lisp had already passed.
So where are all their mainstream applications they wrote in their youth?
They wrote lots of applications, just probably not ones you'd be interested in. If you're an engineer, you'll still run into the occasional Lisp program, and if you're into compilers or computational theory, some of the best tools are still in Lisp. Of the dozen or so programs I use regularly on my desktop (Evince, Firefox, etc), two are Lisp programs (Maxima, a mathematics package, and Emacs). Given that Lisp programmer community was never even 10% as large as the C programming community, 2 programs out of 12 doesn't seem so bad.
You can't blame bitrot, because my current FreeBSD system has dozens of utilities that are directly descended from twenty year old code.
FreeBSD is an OS. C's original niche was programming operating systems. It is no surprise that in the realm of operating systems, there is a lot of old C code. Lisp's original niche was compilers and AI. There is still a lot of old Lisp code in these realms.
Hell, the Free Software movement itself was started by a Lisp programmer! Other than parts of emacs, where are his Lisp programs?
The FSF's explicit goal was to create a replacement for UNIX. Is it really any surprise that most of the code ended up being written in C?
Today's world is UNIX-centric. The API for Windows might be different, but all the concepts (from files to memory mapping) are basically the same. As a result of being UNIX-centric, they are C centric. Ever wonder why files in every mainstream OS are untyped bytestreams? Because those are the easiest thing to deal with in C!
Lisp, Smalltalk, etc, were not just languages that ran on UNIX. During their heyday, they were alternative systems in their own right. When UNIX took over the world, these alternative systems died, and a lot of old Lisp code died with them. Python, Ruby, etc, are all much more recent. They arose in a time when the UNIX machine model had already won-out. They grew up integrated with how UNIX did things. Thus, when new programmers look at a language, they flock to the languages that integrate well with their existing OS.
Now, this does bring up a good point. The world today is very different from the 1970's and 1980's. In a very real sense, Lisp is living in the past. Lisp dates from a time when people still expected to pay for compilers. Thus, the best Lisp implementations are still proprietory. So effort has to be put in to improving the existing free implementations. Lisp dates from a time when a programming language was just a spec and maybe a reference compiler. Now, it's got to have a good, free development environment and a large stack of pre-built libraries. It would not be a strech to say that if C and C++ didn't have the kind of inertia they did, Java, Python, etc, would blow them off the map.
Is it really surprising? Most programs are written in C, C++ or Java. By your logic, these are the only languages suitable for writing mainstream applications. That's a silly thing to say. I refuse to believe that ML, Smalltalk, Lisp, Scheme, etc, can all be well-liked by their users, but somehow "unsuitable for mainstream programming".
In reality, the problem is systematic. The commercial industry is too risk-averse to take a chance on Lisp (or any non-hyped language, for that matter), so basically you're talking about open-source code. At that point, three factors come into play. First, Lisp programmers are generally an older set. The average OSS programmer is 27, according to certain studies. So you've got a democraphic problem there. This is not to mention the biggest demographic problem of all: there just aren't that many Lisp programmers, and an even smaller number with the free time to work on an Open Source project! Second, existing systems are massively hostile to Lisp-like languages. They have VMs that don't mesh well with garbage collection. They have memory protection mechanisms that impose a "10% OS tax" on everything, but do nothing for Lisp programs which are safe without such mechanisms! They have APIs that are exposed only in C (or worse, C++!), and are usually built without any consideration to ease of binding. Last of all, you have inertia. It's easy to do things the same way as you always have. Better ways of doing things usually give way to "standard" ways of doing things.
My guess is that you meant "a feature of the Java and C++ class systems".
That's true. Sorry for not being clearer. Although, I should point out that defining a library to do these things is trivial, since every Lisp with a C-FFI already has the functionality under the hood.
Granted, most of the time you don't want to do these things, and LISP (and, to some extent, Java) prevents you from doing these things accidentally, but if you want to do these things on purpose, you can't in (most dialects of) LISP (without relying on external libraries).
One thing that I've learned about Lisp is that the distinction between "library" and "language" is pretty meaningless. I mean, most of the stuff in the Common Lisp standard is library stuff. Even basic functionality is implemented as macros on top of the language. So if you have to load an implementation-specific machine-words module to do something, it's not that big of a deal.
I'd also point out that those features you pointed out have very large down-sides. They make the language much more difficult to optimize, because the compiler has to account for pointers being able to overwrite pretty much any data. Also, they require very expensive machinery within the OS and hardware (a VMM, an MMU, etc). Look at the size of the TLBs on an Athlon64 sometime. The L1 data TLB takes up as much space as all three integer ALUs put together! If you add up the space taken up by the L1 and L2 data and instruction TLBs, plus the CAM flush filter, you have enough die space to add an entire fourth integer channel, with an AGU, ALU, scheduler, and reorder buffer! Not only that, but the TLB lookup adds a full clock-cycle to the 3-clock L1 cache latency. That's a 50% performance penalty! All of this stuff would be completely unnecessary if C code couldn't overwrite random memory locations.
Good point. It must be the keyword in loop that I'm remembering. If it isn't obvious, I'm one of those people who stays a good distance away from loop...
I have a copy sitting at home:) I agree that its a great book, but it really highlights for me how much C++'s template mechanism blows. Those techniques are nice, but they're unusable in real code. Have you ever tried to trace through a compiler error resulting from a typo when using Loki or some of the more esoteric Boost libraries? They're unreadable! A small typo in a lambda expression that would cause a single error message in a Lisp compiler becomes several screenfuls of tracing through a template expansion. Worse, the error locator never gives you the right line number, because of the way the template expansion works. To top it all off, there is no C++ equivalent of Lisp's MACROEXPAND, so you can't see what a template trick will expand to without writing it out on paper.
Your point is well taken, but note that your problem is basically a combination of lacking documentation and you still learning the language. The first is the fault of the language (well, the implementation, but still), while the latter is nobody's fault, because it's an inevitable situation. I would assume that if you were on the clock, you would already know the language you were working in. Ie. if the project were in C++, you'd already know C++, or else you wouldn't have gotten hired to work on it.
What implementation are you on, anyway? Depending on what kind of networking you need, the trivial-sockets library could be up your ally. Very simple way to connect Lisp to a network. If you're on SBCL, there is SB-BSD-SOCKETS, which exports an API pretty similar to standard UNIX sockets. Of course, for the best in documentation quality, springing for a copy of Allegro CL will get you the ACL socket API. Since you're a student, you can get a copy for a mere $99, or about what you'd pay for an academic version of any other commercial software.
You're right, design patterns aren't duplicated code. They're duplicated patterns of code. Nearly all languages have a tool for handling duplicated code (functions), but few have tools to handle duplicated patterns of code. Lisp macros, however, do allow you to codify patterns in code.
Lisp macros and C macros share only a name. The C preprocessor is just a simple text-substitution mechanism. In comparison, Lisp macros are functions that take source code as input, and return source code as output. They have all the generality of regular functions, except the compiler invokes them at compile-time to expand calls.
The simplest examples of Lisp macros are defining new control structures. For example, Lisp has no direct equivalent of Python's "for elt in container" syntax. However, it's easy to write a macro that takes the statement (for (x in list)...)" and expands it to an iteration using Lisp's native 'do' loop. Now, that's just scratching the surface of macros. Since macros are just functions, you can do anything with them, including writing a language on top of Lisp. This might seem like a bit of a strange idea, but domain-specific languages are hardly a new concept (ie: SQL), and its easier to build them on top of a mature platform instead of writing your own compiler.
With regards to macros and patterns, an easy way to think about things is to realize that functions are useful when you need to apply the same code to different data, while macros are useful when you need to apply the same structure to different code. The classical idea is that you can't package up design patterns into a library. That's because few languages have macros (ie: functions that operate on source code). When you have such a feature, packaging up design patterns becomes easy. Just codify the invariant parts into the macro, and put the parts of the code that change as parameters to the macro. If you've read Alexanderescu's book "Modern C++ Design", you'll see that this is precisely what he does with C++ templates (which are a limited and kludgy form of macros). This is big news in the C++ world, for the simple reason that it makes code less tedious to write and less error prone.
Undoubtedly. Design patterns are helpful in any code, they're just easier to use when the language is properly set up to handle it. Now, it's true that a lot of people can't afford to "non standard" tools. The potential for being blamed if something goes wrong is quite high indeed. However, my point was merely that mainstream languages are not ideally geared towards working with patterns. That does not mean that they'll always be that way, however. Mainstream languages are increasingly ripping entire pages out of the books of dynamic languages (eg: Java 1.5, C# 2.0). Over time, the tools will get better, and looking at what existing dynamic languages do know could give you an edge when the mainstream languages incorporate their features.
What's your reasoning behind the assertion that Lisp isn't suitable for most "mainstream programming tasks". Just saying it doesn't make it true.
I don't think any real Lisp user will tell you that Lisp is perfect. There is a litany of complaints your average Lisp user has about the language (even Paul Graham). However, most will tell you that its definitely better than what exists in the mainstream. Lisp users are kind of like Linux users in that way, actually. Feature for feature, mainstream languages just can't compete with Lisp. And it's not just a Lisp thing. Listen to Python or Ruby folks talk about how much more productive they are in those languages versus Java or C++. There is a reason for that. It's because those languages are more like Lisp.
Not really. I haven't encountered a feature of Java or C++ that is not directly expressible in CLOS. This includes fancy new Java 1.5 and C# 2.0 stuff like properties, etc. Now, once you get out into real OO languages, like Smalltalk, you might find something, but its doubtful.
Beyond that, as Graham points out, there are few patterns in well-written Lisp code. If a Lisp programmer finds himself repeating the same pattern of code over and over, he'll just write a macro to codify the pattern. It should be noted that CLOS itself is mostly just a big macro package. Now, compilers generally have some knowledge of CLOS these days, for optimization purposes, but they don't really need to.
The loop macro itself is an acquired taste, but Lisp doesn't have any particular problem with it. C++ programmers try to find a "for loop" in Lisp, but there isn't really an equivalent. There is a 'for' macro of course, but it's not like in C++ where its used for all iteration, even when it doesn't really make sense. Instead, Lisp programmers use a range of iteration techniques that fit the bill. They use map, mapcar, for, dolist, etc, whichever makes sense in the given spot. In Lisp, there is almost always an iteration construct that expresses exactly the iteration you want to do, without you having to try and figure out how to express your iteration in terms of 'for'. Of course, if there isn't, you can always use loop, or write a macro to roll your own.
Patterns themselves are good to have in code, but the idea that they must be reimplemented for each case (as opposed to being packaged up into a concrete, first-class language object) really shows the limitations of mainstream languages. Peter Norvig (formerly at Harlequin, and now at Google) did a good writeup of the issue. Paul Graham also has an interesting take on this subject.
LOL. I find it depressing that I know most of what those words mean, but I'm an aerospace major. I learned most of them in my EE courses and from hanging out on comp.lang.lisp...
I'm all for the progress of science and all, but as far as I'm concerned, this new technology, for the forseeable future, will mainly be useful to rich people who can afford to buy such treatments. It bothers me that so much of the public debate is tied up in this issue because frankly, in the grand scheme of things, it's not really so big. We have very significant health issues in this country. Our inner cities have public health indicators that more resemble a developing nation's than a superpower's. For every $1m that is spent on stem cell technology to cure a single Parkinsons patient, that same $1m could help hundreds of young people living with chronic malnutrition.
Again, my point is not that this money should instead be going to fund these things instead, but rather that I think the public doesn't really have any perspective on where the problems in our society really are, and wastes a lot of time getting caught up in a debate that is less important than other ones.
Second, everyone says that Bush is against stem cell research.
Okay.
He is only against federal funding to embryonic stem cell research.
Because that's the only thing he has control over?
That doesn't mean he wants to ban it, well he does, but that is besides the point.
So he wants to ban it, but he isn't against it? That makes perfect sense...
Bush doesn't believe in stem-cell research. He is trying to limit the research that goes on. Politically, there are only a couple of ways he can do that. He can push congress to pass a law saying stem cell research is banned. As you rightly point out, this is what he wants to do. But Congress won't do that, and Bush can't make them do that. So he does what he can --- he issues a directive that the federal government won't fund stem cell research, with the hopes that the research will wither away without federal dollars.
Slashdot Mirror
I think you don't realize that if you had 500 of disposable income to spend during the PS1 generation of games, you (theoretically) have $600 to spend now. The median household income in the US has risen from $34,000 a year in 1995 (when the $50 price was originally set) to $44,000 a year in 2005.
Every buy RPGs? They usually required the big carts. I remember paying $60 or $70 for Final Fantasy III. Chrono Trigger was I think $70 here, and around $100 in Japan.
What is this "again" you speak of? Games are cheaper now than they've been in the 17 years since I got my first console. When did these cheap games come out?
$300 for a console is hardly that bad! The Sega Saturn came out at $400 ($498 adjusted for inflation), the PSX came out at $300 ($373 adjusted for inflation). The NES came out at $200 ($354 adjusted for inflation), while the SNES came out at $200 too ($282 adjusted for inflation).
$60 for a game ain't too bad either. Anybody remember paying $60 for SNES games back in the day? That's $85 in today's money! Games have been stuck at $50 for a decade. During that whole time, the cost of making a game has gone way up. Even still, moving up to $60 doesn't even cover inflation somce then!
Did you read either my post or the post I replied to? This isn't about "Apple should sell OS X standalone" or "I want to pirate OS X". It's about: "I think Apple's hardware is crap and I'd gladly pay extra to run the software on a platform of my choice". The OP implied that the only reason for someone who likes OS X to want to run it on a generic PC, instead of buying a Mini, is because they are cheap. That's just not true. Even if I could get a G5 for the same price I paid for my Athlon, I wouldn't do it.
You're forgetting that Apple ships a new OS every 12-18 months. Meanwhile, a person upgrades their Mac once every several years. Like I said, I'd be willing to pay $200 a year to keep getting the newest versions of OS X. After just one upgrade cycle, that blows away the margin lost from me not buying a Mini.
My point is that the original poster made a very stupid statement. He asked: "if you liked MacOS X so much, you would have bought a Mini". The Mini is completely useless to me. It just doesn't have the horsepower to run the things I run. I don't care if its more expensive for me to just buy the software than it is to get the Mini. I don't want to have to run such a nice OS on such a POS box.
Your comment makes no sense. Why would I want to sell my Athlon? It's a dual-core 2.2GHz Athlon64 (with 1MB of cache on each chip) with 2GB of RAM and a 250GB disk. It's an all-SATA, all-PCI Express, dual network ports, Firewire, and a nice, quiet case (Antec P180). You can't even buy an equivalent G5, certainly not for the $1300 I spent building it.
I'm really into compiler programming, and Apple doesn't make sell an equivalent processor for me. The G5's integer throughput is pretty bad (its long pipeline puts it closer to a P4 than an Athlon in efficiency). To get even near the same performance for the code I run on a G5, I'd have to move up to the 2.7GHz watercooled model, and even then, the relatively small 512KB cache hurts performance on integer code.
On the other hand, I love OS X, and would gladly give Apple my money. But I refuse to live with inferior hardware to do it.
Ok? Got it? If you really wanted OSX as much as you purport you would have bought a mac mini.
Question: why in the world would I want to spend $500 on a crappy Mac Mini when I've got an Athlon X2 sitting on my desk? My computer is pretty fast, but its still not fast enough for some of the stuff I run. Why on earth would I want to downgrade so much?
On the other hand, I'd happily pay Apple $200 (or whatever they're charging for OS X these days) every upgrade cycle to run OS X on my computer. It's not about cheap, it's about choice!
Your arguments may make sense why C, C++ and Java are more popular than Lisp, but it doesn't explain why Python and Ruby are as well.
Consider the niches that Python and Ruby target: web programming and systems glue. There is a large body of existing code in these languages for doing those tasks. Meanwhile, consider the niche that Lisp originally occupied: AI and compiler theory. Guess which niche has more programmers?
Your demographics argument is species. Old Lisp programmers where young once.
Yes, but when they were young (or equivalently, when Lisp was much more popular than it is now), the internet either didn't exist, or was very limited in scope. Without the internet, you can only have basically one kind of open source: academic. Academic open source tends to produce a very specific type of software, a kind that is usually not very interesting to your average user. By the time the modern open source movement came around, with people working on "mainstream software" for "regular users" across the internet, the popularity of Lisp had already passed.
So where are all their mainstream applications they wrote in their youth?
They wrote lots of applications, just probably not ones you'd be interested in. If you're an engineer, you'll still run into the occasional Lisp program, and if you're into compilers or computational theory, some of the best tools are still in Lisp. Of the dozen or so programs I use regularly on my desktop (Evince, Firefox, etc), two are Lisp programs (Maxima, a mathematics package, and Emacs). Given that Lisp programmer community was never even 10% as large as the C programming community, 2 programs out of 12 doesn't seem so bad.
You can't blame bitrot, because my current FreeBSD system has dozens of utilities that are directly descended from twenty year old code.
FreeBSD is an OS. C's original niche was programming operating systems. It is no surprise that in the realm of operating systems, there is a lot of old C code. Lisp's original niche was compilers and AI. There is still a lot of old Lisp code in these realms.
Hell, the Free Software movement itself was started by a Lisp programmer! Other than parts of emacs, where are his Lisp programs?
The FSF's explicit goal was to create a replacement for UNIX. Is it really any surprise that most of the code ended up being written in C?
Today's world is UNIX-centric. The API for Windows might be different, but all the concepts (from files to memory mapping) are basically the same. As a result of being UNIX-centric, they are C centric. Ever wonder why files in every mainstream OS are untyped bytestreams? Because those are the easiest thing to deal with in C!
Lisp, Smalltalk, etc, were not just languages that ran on UNIX. During their heyday, they were alternative systems in their own right. When UNIX took over the world, these alternative systems died, and a lot of old Lisp code died with them. Python, Ruby, etc, are all much more recent. They arose in a time when the UNIX machine model had already won-out. They grew up integrated with how UNIX did things. Thus, when new programmers look at a language, they flock to the languages that integrate well with their existing OS.
Now, this does bring up a good point. The world today is very different from the 1970's and 1980's. In a very real sense, Lisp is living in the past. Lisp dates from a time when people still expected to pay for compilers. Thus, the best Lisp implementations are still proprietory. So effort has to be put in to improving the existing free implementations. Lisp dates from a time when a programming language was just a spec and maybe a reference compiler. Now, it's got to have a good, free development environment and a large stack of pre-built libraries. It would not be a strech to say that if C and C++ didn't have the kind of inertia they did, Java, Python, etc, would blow them off the map.
Is it really surprising? Most programs are written in C, C++ or Java. By your logic, these are the only languages suitable for writing mainstream applications. That's a silly thing to say. I refuse to believe that ML, Smalltalk, Lisp, Scheme, etc, can all be well-liked by their users, but somehow "unsuitable for mainstream programming".
In reality, the problem is systematic. The commercial industry is too risk-averse to take a chance on Lisp (or any non-hyped language, for that matter), so basically you're talking about open-source code. At that point, three factors come into play. First, Lisp programmers are generally an older set. The average OSS programmer is 27, according to certain studies. So you've got a democraphic problem there. This is not to mention the biggest demographic problem of all: there just aren't that many Lisp programmers, and an even smaller number with the free time to work on an Open Source project! Second, existing systems are massively hostile to Lisp-like languages. They have VMs that don't mesh well with garbage collection. They have memory protection mechanisms that impose a "10% OS tax" on everything, but do nothing for Lisp programs which are safe without such mechanisms! They have APIs that are exposed only in C (or worse, C++!), and are usually built without any consideration to ease of binding. Last of all, you have inertia. It's easy to do things the same way as you always have. Better ways of doing things usually give way to "standard" ways of doing things.
My guess is that you meant "a feature of the Java and C++ class systems".
That's true. Sorry for not being clearer. Although, I should point out that defining a library to do these things is trivial, since every Lisp with a C-FFI already has the functionality under the hood.
Granted, most of the time you don't want to do these things, and LISP (and, to some extent, Java) prevents you from doing these things accidentally, but if you want to do these things on purpose, you can't in (most dialects of) LISP (without relying on external libraries).
One thing that I've learned about Lisp is that the distinction between "library" and "language" is pretty meaningless. I mean, most of the stuff in the Common Lisp standard is library stuff. Even basic functionality is implemented as macros on top of the language. So if you have to load an implementation-specific machine-words module to do something, it's not that big of a deal.
I'd also point out that those features you pointed out have very large down-sides. They make the language much more difficult to optimize, because the compiler has to account for pointers being able to overwrite pretty much any data. Also, they require very expensive machinery within the OS and hardware (a VMM, an MMU, etc). Look at the size of the TLBs on an Athlon64 sometime. The L1 data TLB takes up as much space as all three integer ALUs put together! If you add up the space taken up by the L1 and L2 data and instruction TLBs, plus the CAM flush filter, you have enough die space to add an entire fourth integer channel, with an AGU, ALU, scheduler, and reorder buffer! Not only that, but the TLB lookup adds a full clock-cycle to the 3-clock L1 cache latency. That's a 50% performance penalty! All of this stuff would be completely unnecessary if C code couldn't overwrite random memory locations.
Good point. It must be the keyword in loop that I'm remembering. If it isn't obvious, I'm one of those people who stays a good distance away from loop...
I have a copy sitting at home :) I agree that its a great book, but it really highlights for me how much C++'s template mechanism blows. Those techniques are nice, but they're unusable in real code. Have you ever tried to trace through a compiler error resulting from a typo when using Loki or some of the more esoteric Boost libraries? They're unreadable! A small typo in a lambda expression that would cause a single error message in a Lisp compiler becomes several screenfuls of tracing through a template expansion. Worse, the error locator never gives you the right line number, because of the way the template expansion works. To top it all off, there is no C++ equivalent of Lisp's MACROEXPAND, so you can't see what a template trick will expand to without writing it out on paper.
Not really. MacOS Classic was pretty much the height of UI design. OS X is catching back up to where they used to be, but they aren't there yet.
Your point is well taken, but note that your problem is basically a combination of lacking documentation and you still learning the language. The first is the fault of the language (well, the implementation, but still), while the latter is nobody's fault, because it's an inevitable situation. I would assume that if you were on the clock, you would already know the language you were working in. Ie. if the project were in C++, you'd already know C++, or else you wouldn't have gotten hired to work on it.
What implementation are you on, anyway? Depending on what kind of networking you need, the trivial-sockets library could be up your ally. Very simple way to connect Lisp to a network. If you're on SBCL, there is SB-BSD-SOCKETS, which exports an API pretty similar to standard UNIX sockets. Of course, for the best in documentation quality, springing for a copy of Allegro CL will get you the ACL socket API. Since you're a student, you can get a copy for a mere $99, or about what you'd pay for an academic version of any other commercial software.
You're right, design patterns aren't duplicated code. They're duplicated patterns of code. Nearly all languages have a tool for handling duplicated code (functions), but few have tools to handle duplicated patterns of code. Lisp macros, however, do allow you to codify patterns in code.
...)" and expands it to an iteration using Lisp's native 'do' loop. Now, that's just scratching the surface of macros. Since macros are just functions, you can do anything with them, including writing a language on top of Lisp. This might seem like a bit of a strange idea, but domain-specific languages are hardly a new concept (ie: SQL), and its easier to build them on top of a mature platform instead of writing your own compiler.
Lisp macros and C macros share only a name. The C preprocessor is just a simple text-substitution mechanism. In comparison, Lisp macros are functions that take source code as input, and return source code as output. They have all the generality of regular functions, except the compiler invokes them at compile-time to expand calls.
The simplest examples of Lisp macros are defining new control structures. For example, Lisp has no direct equivalent of Python's "for elt in container" syntax. However, it's easy to write a macro that takes the statement (for (x in list)
With regards to macros and patterns, an easy way to think about things is to realize that functions are useful when you need to apply the same code to different data, while macros are useful when you need to apply the same structure to different code. The classical idea is that you can't package up design patterns into a library. That's because few languages have macros (ie: functions that operate on source code). When you have such a feature, packaging up design patterns becomes easy. Just codify the invariant parts into the macro, and put the parts of the code that change as parameters to the macro. If you've read Alexanderescu's book "Modern C++ Design", you'll see that this is precisely what he does with C++ templates (which are a limited and kludgy form of macros). This is big news in the C++ world, for the simple reason that it makes code less tedious to write and less error prone.
Undoubtedly. Design patterns are helpful in any code, they're just easier to use when the language is properly set up to handle it. Now, it's true that a lot of people can't afford to "non standard" tools. The potential for being blamed if something goes wrong is quite high indeed. However, my point was merely that mainstream languages are not ideally geared towards working with patterns. That does not mean that they'll always be that way, however. Mainstream languages are increasingly ripping entire pages out of the books of dynamic languages (eg: Java 1.5, C# 2.0). Over time, the tools will get better, and looking at what existing dynamic languages do know could give you an edge when the mainstream languages incorporate their features.
What's your reasoning behind the assertion that Lisp isn't suitable for most "mainstream programming tasks". Just saying it doesn't make it true.
I don't think any real Lisp user will tell you that Lisp is perfect. There is a litany of complaints your average Lisp user has about the language (even Paul Graham). However, most will tell you that its definitely better than what exists in the mainstream. Lisp users are kind of like Linux users in that way, actually. Feature for feature, mainstream languages just can't compete with Lisp. And it's not just a Lisp thing. Listen to Python or Ruby folks talk about how much more productive they are in those languages versus Java or C++. There is a reason for that. It's because those languages are more like Lisp.
Not really. I haven't encountered a feature of Java or C++ that is not directly expressible in CLOS. This includes fancy new Java 1.5 and C# 2.0 stuff like properties, etc. Now, once you get out into real OO languages, like Smalltalk, you might find something, but its doubtful.
Beyond that, as Graham points out, there are few patterns in well-written Lisp code. If a Lisp programmer finds himself repeating the same pattern of code over and over, he'll just write a macro to codify the pattern. It should be noted that CLOS itself is mostly just a big macro package. Now, compilers generally have some knowledge of CLOS these days, for optimization purposes, but they don't really need to.
The loop macro itself is an acquired taste, but Lisp doesn't have any particular problem with it. C++ programmers try to find a "for loop" in Lisp, but there isn't really an equivalent. There is a 'for' macro of course, but it's not like in C++ where its used for all iteration, even when it doesn't really make sense. Instead, Lisp programmers use a range of iteration techniques that fit the bill. They use map, mapcar, for, dolist, etc, whichever makes sense in the given spot. In Lisp, there is almost always an iteration construct that expresses exactly the iteration you want to do, without you having to try and figure out how to express your iteration in terms of 'for'. Of course, if there isn't, you can always use loop, or write a macro to roll your own.
Patterns themselves are good to have in code, but the idea that they must be reimplemented for each case (as opposed to being packaged up into a concrete, first-class language object) really shows the limitations of mainstream languages. Peter Norvig (formerly at Harlequin, and now at Google) did a good writeup of the issue. Paul Graham also has an interesting take on this subject.
LOL. I find it depressing that I know most of what those words mean, but I'm an aerospace major. I learned most of them in my EE courses and from hanging out on comp.lang.lisp...
I'm all for the progress of science and all, but as far as I'm concerned, this new technology, for the forseeable future, will mainly be useful to rich people who can afford to buy such treatments. It bothers me that so much of the public debate is tied up in this issue because frankly, in the grand scheme of things, it's not really so big. We have very significant health issues in this country. Our inner cities have public health indicators that more resemble a developing nation's than a superpower's. For every $1m that is spent on stem cell technology to cure a single Parkinsons patient, that same $1m could help hundreds of young people living with chronic malnutrition.
Again, my point is not that this money should instead be going to fund these things instead, but rather that I think the public doesn't really have any perspective on where the problems in our society really are, and wastes a lot of time getting caught up in a debate that is less important than other ones.
Let me tryy to figure out your line of thought.
Second, everyone says that Bush is against stem cell research.
Okay.
He is only against federal funding to embryonic stem cell research.
Because that's the only thing he has control over?
That doesn't mean he wants to ban it, well he does, but that is besides the point.
So he wants to ban it, but he isn't against it? That makes perfect sense...
Bush doesn't believe in stem-cell research. He is trying to limit the research that goes on. Politically, there are only a couple of ways he can do that. He can push congress to pass a law saying stem cell research is banned. As you rightly point out, this is what he wants to do. But Congress won't do that, and Bush can't make them do that. So he does what he can --- he issues a directive that the federal government won't fund stem cell research, with the hopes that the research will wither away without federal dollars.
YOu might as well say "steak is great for the guy going to Sizzlers, but that's in it for the cow?"