There's easier ways to add backdoors to Linux. Most distributions come with loads of binary drivers, anything could be in there. This is one of the reasons why OpenBSD will not include any binary drivers.
Re:21st Century started in 1958?
on
Land of Lisp
·
· Score: 1
I am totally missing the point you're trying to make. I think the important parts of CLOS and AOP is the idea of "join points" - flexible ways of specifying when particular code needs to run. There's nothing fundamental or theoretical about it, but it's an extremely powerful way of making simpler systems (otherwise you're just copy-pasting patterns to program around the fact that everything in your system is being forced through message-passing).
Re:Hi- I'm the Author
on
Land of Lisp
·
· Score: 1
I think it could work. The book starts out at a very basic level. The only trouble I could see is that it doesn't define what functions and variables are, but it explains how to define a variable and how to define a function and what that does. Other than that, it pretty much starts out at the beginning explaining what the different types are and how they work, arithmetic and binary numbers, etc.
When it comes to typing, there's no advantage to microcode and baked-in type schemes vs byte-addressed but word-aligned machines (ie - pretty much 99% of today's computers). On 32-bit systems you get 3 bits of tag - more than enough for the basic types you need to make a fast runtime. 64-bit gives you 4 tag bits, and if you actually look at any CL compilers today, most of them are unused.
Further, you can exploit various properties of modulo arithmetic over the full pointer to actually produce *faster* code than would be possible with baked-in type checking (see the alignment section in "Arm porting notes and issues" in the Clozure wiki; I'd link but Slashdot box won't let me copy-paste, probably as an anti-spam measure).
As far as GC goes, the biggest problem isn't the hardware, it's the operating system. Look at the Azure Linux kernel patches - they're getting similar GC performance on commodity 64-bit hardware as they did on their custom Java processors with various GC-accelerating features.
You'd be surprised at the number of people working on that (in terms of large-scale "LispM in the cloud" startups, and even new OS efforts). The problem IMO is that Lisp programmers were 15 years late to the Free Software game, and didn't understand the value of portability. The 90s were basically a lost decade for Lisp infrastructure because of that, but I think it's really changed in the past 5 years.
It's amazing how prescient RMS was on the issue. If you didn't know, he started the FSF because he believed Symbolics, the first commercial Lisp machine spinoff from MIT, was going down the wrong path. He was totally validated on everything. If Genera had been open sourced, Symbolics probably would still be a thriving company today.
Re:LISP a bad choice as a starter language.
on
Land of Lisp
·
· Score: 1
I think Conrad addresses this criticism effectively in the first few chapters of the book. There's no weird recursive code, and the whole premise is you just download CLISP, get a prompt, and start working (on Debian, apt-get it). That's not any harder than getting Python.
I also don't see how Lisp is not a marketable skill, it's been pretty good at putting bread on my table for a few years now.
Re:21st Century started in 1958?
on
Land of Lisp
·
· Score: 1
CLOS IMO has almost nothing to do with Smalltalk or object-oriented programming. It's a system for structuring code in large programs in a way more akin to aspect-oriented programming (I think that Kiczales' subsequent work on AOP in Java is far less usable than CLOS). When combined with dynamic binding, CLOS is really the only practical solution for building really large, maintainable systems today without resorting to "brute force and thousands of slaves" (as Alan Kay calls it) and re-writes every 10 years. The only alternatives that seem to work is to break everything up into untrusted components of a distributed system, but that's a lot of overhead and extra engineering if you can't use off-the-shelf stuff.
Hi- I'm the Reviewer
on
Land of Lisp
·
· Score: 2, Informative
I'm the reviewer, so I can probably explain how this happens.
I started out writing posts on my blog about old obscure distributed systems and programming books that I thought deserved more attention. Then I got a copy of Masterminds of Programming for giving a lightning talk at a conference (International Lisp Conference 2007; O'Reilly were giving out books to lightning talkers), and decided to write a review on my blog (it's an interesting book).
A few months later, Peter Seibel's Coders at Work was about to come out, and Peter noticed that I had written about Masterminds and decided that I would be interested in a preview copy of Coders at Work (which I was). Then he mentioned that I should consider writing a review for Coders at Work on Slashdot instead of my blog, and I liked the suggestion, so I wrote a review (it is a good book). Peter says it helped the book's sales a lot.
I heard about Land of Lisp from the O'Reilly media relations mailing list (I'm on the list because I'm the O'Reilly User Groups program contact for the Montreal JavaScript user's group; they give us discounts and freebies). The media relations list is basically O'Reilly spamming you with descriptions of upcoming titles - if you think something is interesting, you ask them to send you a review copy. Actually, I had heard about Land of Lisp a long time ago (the book was originally supposed to come out in 2007), but forgot about it in the meantime. If it wasn't for the O'Reilly mailing list, I wouldn't have heard about the book until after it had come out (and then only because I'm very involved in the Lisp community).
So the lesson here is you should look for someone interested in the book's subject who has written about other books before, offer to send them a review copy, and suggest they write a review for Slashdot. It helps to stroke their egos ("I really like your writing, would you like a super-special advanced exclusive preview copy for super-smart special people? The proles won't get to see this for another two months!")
Obviously blogs are the best places to find these people; look at blog aggregators on whatever subjects your book is about (for example, the Lisp-related postings on my blog are syndicated on Planet Lisp and Russian Lisp Planet).
O'Reilly has by far the best book promotion efforts of any technical publisher (media relations mailing list, user's group program, and an extremely active presence at conferences), but it's actually not very effective compared to being part of whatever community your book is about, and simply informing community members of your book's existence. Conrad does pretty well in this respect. I'm sure if I hadn't written a review of Land of Lisp for Slashdot, someone else would have.
Re:Oh Come On! This is a Book Review!
on
Land of Lisp
·
· Score: 1
Hahaha, I knew someone would make that comment! But it really is called "why's (poignant) guide to ruby" and not "why's poignant guide to ruby."
Re:Programmers at Work (1989)
on
Coders At Work
·
· Score: 1
Talk about not knowing the history of the field! I haven't read Programmers at Work yet, but it is on my to-read list. I completely forgot about it when writing this review.
Re:Does this complement "Code Complete"
on
Coders At Work
·
· Score: 1
Code Complete obviously has a lot more technical details in its advice on writing code. A lot of them are very specific to C/C++. A lot of them should be obvious. Coders at Work has a lot more general guidance that can be applied in any programming setting, and more importantly they're put into better context so you can kind of get why people recommend doing what they recommend. Code Complete is not that great at explaining "why." I think both are worth reading.
Slashdot Mirror
There's easier ways to add backdoors to Linux. Most distributions come with loads of binary drivers, anything could be in there. This is one of the reasons why OpenBSD will not include any binary drivers.
I am totally missing the point you're trying to make. I think the important parts of CLOS and AOP is the idea of "join points" - flexible ways of specifying when particular code needs to run. There's nothing fundamental or theoretical about it, but it's an extremely powerful way of making simpler systems (otherwise you're just copy-pasting patterns to program around the fact that everything in your system is being forced through message-passing).
I think it could work. The book starts out at a very basic level. The only trouble I could see is that it doesn't define what functions and variables are, but it explains how to define a variable and how to define a function and what that does. Other than that, it pretty much starts out at the beginning explaining what the different types are and how they work, arithmetic and binary numbers, etc.
When it comes to typing, there's no advantage to microcode and baked-in type schemes vs byte-addressed but word-aligned machines (ie - pretty much 99% of today's computers). On 32-bit systems you get 3 bits of tag - more than enough for the basic types you need to make a fast runtime. 64-bit gives you 4 tag bits, and if you actually look at any CL compilers today, most of them are unused.
Further, you can exploit various properties of modulo arithmetic over the full pointer to actually produce *faster* code than would be possible with baked-in type checking (see the alignment section in "Arm porting notes and issues" in the Clozure wiki; I'd link but Slashdot box won't let me copy-paste, probably as an anti-spam measure).
As far as GC goes, the biggest problem isn't the hardware, it's the operating system. Look at the Azure Linux kernel patches - they're getting similar GC performance on commodity 64-bit hardware as they did on their custom Java processors with various GC-accelerating features.
You'd be surprised at the number of people working on that (in terms of large-scale "LispM in the cloud" startups, and even new OS efforts). The problem IMO is that Lisp programmers were 15 years late to the Free Software game, and didn't understand the value of portability. The 90s were basically a lost decade for Lisp infrastructure because of that, but I think it's really changed in the past 5 years.
It's amazing how prescient RMS was on the issue. If you didn't know, he started the FSF because he believed Symbolics, the first commercial Lisp machine spinoff from MIT, was going down the wrong path. He was totally validated on everything. If Genera had been open sourced, Symbolics probably would still be a thriving company today.
I think Conrad addresses this criticism effectively in the first few chapters of the book. There's no weird recursive code, and the whole premise is you just download CLISP, get a prompt, and start working (on Debian, apt-get it). That's not any harder than getting Python.
I also don't see how Lisp is not a marketable skill, it's been pretty good at putting bread on my table for a few years now.
CLOS IMO has almost nothing to do with Smalltalk or object-oriented programming. It's a system for structuring code in large programs in a way more akin to aspect-oriented programming (I think that Kiczales' subsequent work on AOP in Java is far less usable than CLOS). When combined with dynamic binding, CLOS is really the only practical solution for building really large, maintainable systems today without resorting to "brute force and thousands of slaves" (as Alan Kay calls it) and re-writes every 10 years. The only alternatives that seem to work is to break everything up into untrusted components of a distributed system, but that's a lot of overhead and extra engineering if you can't use off-the-shelf stuff.
I'm the reviewer, so I can probably explain how this happens.
I started out writing posts on my blog about old obscure distributed systems and programming books that I thought deserved more attention. Then I got a copy of Masterminds of Programming for giving a lightning talk at a conference (International Lisp Conference 2007; O'Reilly were giving out books to lightning talkers), and decided to write a review on my blog (it's an interesting book).
A few months later, Peter Seibel's Coders at Work was about to come out, and Peter noticed that I had written about Masterminds and decided that I would be interested in a preview copy of Coders at Work (which I was). Then he mentioned that I should consider writing a review for Coders at Work on Slashdot instead of my blog, and I liked the suggestion, so I wrote a review (it is a good book). Peter says it helped the book's sales a lot.
I heard about Land of Lisp from the O'Reilly media relations mailing list (I'm on the list because I'm the O'Reilly User Groups program contact for the Montreal JavaScript user's group; they give us discounts and freebies). The media relations list is basically O'Reilly spamming you with descriptions of upcoming titles - if you think something is interesting, you ask them to send you a review copy. Actually, I had heard about Land of Lisp a long time ago (the book was originally supposed to come out in 2007), but forgot about it in the meantime. If it wasn't for the O'Reilly mailing list, I wouldn't have heard about the book until after it had come out (and then only because I'm very involved in the Lisp community).
So the lesson here is you should look for someone interested in the book's subject who has written about other books before, offer to send them a review copy, and suggest they write a review for Slashdot. It helps to stroke their egos ("I really like your writing, would you like a super-special advanced exclusive preview copy for super-smart special people? The proles won't get to see this for another two months!")
Obviously blogs are the best places to find these people; look at blog aggregators on whatever subjects your book is about (for example, the Lisp-related postings on my blog are syndicated on Planet Lisp and Russian Lisp Planet).
O'Reilly has by far the best book promotion efforts of any technical publisher (media relations mailing list, user's group program, and an extremely active presence at conferences), but it's actually not very effective compared to being part of whatever community your book is about, and simply informing community members of your book's existence. Conrad does pretty well in this respect. I'm sure if I hadn't written a review of Land of Lisp for Slashdot, someone else would have.
Hahaha, I knew someone would make that comment! But it really is called "why's (poignant) guide to ruby" and not "why's poignant guide to ruby."
Talk about not knowing the history of the field! I haven't read Programmers at Work yet, but it is on my to-read list. I completely forgot about it when writing this review.
Code Complete obviously has a lot more technical details in its advice on writing code. A lot of them are very specific to C/C++. A lot of them should be obvious. Coders at Work has a lot more general guidance that can be applied in any programming setting, and more importantly they're put into better context so you can kind of get why people recommend doing what they recommend. Code Complete is not that great at explaining "why." I think both are worth reading.