Thats a *disadvantage* as it is encouraging, er, 'wooly thinking'
It can be handy during debugging. I don't recommend using cdaadr (et al) in production code.
They just couldn't write a parser for shit so they took the old adage "If in doubt, bracket" far too seriously and made it compulsory.
Wrong. Lisp has parentheses in specific places, leaving no doubt about where you're supposed to put them. Adding excessive parentheses to Lisp code changes it.
And the parens and the code-data equivalence do have a purpose. They make working with the code programmatically very easy, which allows Lisp macros. The macros that every Lisp fan always mentions. They wouldn't be nearly as useful if Lisp didn't use the parentheses. And the parens are amazingly easy to edit with proper editor support.
The big problem with elisp is that it doesn't have lexical scoping, which can be very inconvenient sometimes.
It would help if you thought of Common Lisp and Scheme as different languages. Then you could go and download Lisp in a Box and get started off right with Common Lisp, which has a lot of cool stuff written for it. Yes, I'm biased.:-)
Lisp isn't functional. It can do functional things, but it can also be used naturally to write procedural and object-oriented code. And sometimes prolog-style code. And sometimes ML-style pattern-matching code. And sometimes code in other styles that you don't hear about very often.
Unfortunetly, the lack of a consistant (across implementations) and expansive runtime library makes scheme next to useless for a lot of practical purposes. *sigh*.
Have you tried PLT Scheme? I've heard good things about it, and it may be what you're looking for.
I've been doing web programming in Lisp recently. I've been using UnCommonWeb, which is a continuation-based web programming framework, and Yaclml, a library for HTML generation. Also the CLSQL database interface library adds some syntax for building SQL queries, which simplifies things and makes SQL injection attacks impossible. I've got to say, it's loads of fun.
Re:This is not a troll, but a query...
on
Practical Common Lisp
·
· Score: 2, Interesting
I think the parens confuse almost everyone. They gave me a headache until I learned the editor keystrokes for manipulating them easily and learned to look at the indentation instead of the parentheses. Now I have trouble with other languages. It's amazing how anything different from what we're used to (whatever we're used to) seems hard to use, isn't it?
You probably know this, but be careful with recursion. The other day I saw a function someone had written which used recursion to cons up a list. I rewrote it into a function about the same size which used explicit looping (with nasty details hidden by the LOOP macro). The new version was clearer and about 50 times faster (and used less memory).
Use recursion wisely. You can use it for all iteration, but you shouldn't.
And I'm not a Ruby programmer---but the sort of code generation you describe has three major disadvantages compared with Lisp's. First, it requires heavy string manipulation, which is ugly and error-prone. Second, using eval (or the Ruby equivalent) at runtime is slow. Third, this sort of thing falls into the realm of Scary Hack World in Ruby, while it's well supported in Lisp.
Well, try looking at the PCL chapter on making an HTML-generation library that lets you intersperse Lisp code with a weird parenthesesified version of HTML. Here's an example of the code you can write with it:
(Sorry I had to put that on one line, but Slashdot doesn't handle code indentation very well.)
This HTML generation stuff is very useful, and it's pretty difficult to make without using macros. Also, this compiles down to efficient code, rather than being interpreted.
There are other examples. For example, the LOOP uber-macro doesn't require any special support from the Lisp implementation, but it's practically a mini-language for expressing common looping idioms.
It's much easier to use than assembly. In assembly language, for example, it would be non-trivial to do something like this:
(remove-if-not #'oddp list-of-numbers)
That returns a list of all odd numbers in a list of numbers. With this sort of a difference in ease of use, why are you comparing Lisp to assembly language? My guess is that you're just talking out your ass.
The advantage of car and cdr is that you can compose them into things like cdadr. Not that you should, except when you're in a hurry.
If you don't want to use car and cdr, use first and rest. You have a choice.
Re:My first exposure to list ( and a mirror of boo
on
Practical Common Lisp
·
· Score: 3, Insightful
Some of the key differences between Haskell and Lisp are:
Haskell has a strong typing system, similar to that of ML. Lisp's type system is optional, and while many Lisp implementations can do type inference and checking, it isn't required, nor is it as big a part of the language.
Haskell is purely functional, and it fakes side-effects with the Monad design pattern. Lisp has side-effects, with all the advantages and disadvantages that entails.
Haskell uses lazy evaluation. Lisp uses strict evaluation unless you explicitly ask for lazy evaluation.
Lisp, thanks to all those parentheses, has very powerful macros. I know every Lisp fan says this, but they're really cool. Haskell relies more on higher-order functions and infix syntax for that sort of thing, which isn't as powerful but which you may find to be a decent tradeoff.
Haskell has significant whitespace, like Python. Lisp doesn't.
I find that editing Lisp code is easier than editing Haskell code, due to the excellent Lisp editing modes available for various text editors. OTOH, maybe that's partly because haskell-mode for emacs is pretty rough.
Lisp can generally be made faster than Haskell, which is very nice in bottlenecks. For the rest of the program, though, this isn't so major.
Unfortunately it pales in comparison to the actual problem: overpopulation.
The birth rate is decreasing. Rejoice!
[Edible vaccines] An ability which is not only vastly offset by potential dangers of screwing around with protein chains in food and thus causing all sorts of unimagineable long-term digestive and other diseases, it is also totally impractical since the vaccines are variable based on strains of the viruses/bacteria they are aimed at. Strains which evolve at immense speed.
Can you give a possible mechanism for these "unimagineable long-term digestive and other diseases" that may come from monkeying around with protein chains? Last time I checked, proteins were broken down into amino acids during digestion, rendering their structure moot, so I assume you're talking about some weird chemical change in the plant itself---but what? And when does worrying about such far-off fears cross the line from prudence to paranoia?
The nuclear industry is one of the most cautious I know of. Look at the redundant safety systems and the layers of steel and concrete (not to mention red tape) protecting all modern US, Canadian, and European nuclear plants and you'll agree: they're very cautious.
Because it isn't called "recycling". Seriously, it was done to make a political point and it's stuck ever since. And since Greenpeace et al always oppose measures to make nuclear power better for some reason, people don't seem too interested in reviving it in the US.
"Designed to sell more of their own pesticides"? Genetically modified food reduces the need for pesticides, as well as reducing the amount of farmland we have to use. Perhaps you're thinking of "Roundup-ready" crops which are immune to the plant-killer "Roundup". The thing there, though, is that Roundup is one of the most environmentally friendly ways to kill weeds that I know of, and Roundup-ready crops make it possible to use Roundup instead of less friendly herbicides.
With SBCL it's not too hard to make standalone executable bundles. It won't give you a single executable file, though; you still need the SBCL executable along with your core file.
You can do something similar on CLISP, although it could be a minor headache to make this work on multiple platforms.
GCL can make standalone executables. This is how the Windows version of the Maxima computer algebra system is distributed: as a GCL-generated EXE file. It's also getting quite a bit faster, since they added some type inference code.
ECL is fairly new, so it's not as mature as the others, but it looks very promising. It can generate standalone executable files on all major platforms and a few minor ones.
GCL is free, mature, runs on all the Bug Three OSes, and is a compiler. CLISP is also free, mature, and cross-platform, but it's generally slower than other CL implementations.
The de facto way of interfacing with C in Common Lisp is the UFFI library. It runs on most Lisp implementations, but sadly it does not yet support GCL or CLISP. If you decide to play with either of those, you should probably just try its foreign function interface. CLISP in particular is noted for having an excellent FFI.
Try SBCL, CMUCL, GCL, or CLISP. They're all good Lisp implementations. SBCL and CMUCL compile to native code directly and are probably the fastest free CL implemetations, GCL compiles via C (and therefore GCC), and CLISP has a bytecode interpreter.
That's fine, but he has a point. How much actual real-world good does that do? It does plenty of theoretical good, but so does making the speed limit 10 MPH. By far the better solution is to make sure that the system is safe from remote attacks.
Which is easier: running a program as non-root or ensuring that it has no remote vulnerabilities? And can you be as sure about the second one as you can be about the first?
Slashdot Mirror
It can be handy during debugging. I don't recommend using cdaadr (et al) in production code.
They just couldn't write a parser for shit so they took the old adage "If in doubt, bracket" far too seriously and made it compulsory.
Wrong. Lisp has parentheses in specific places, leaving no doubt about where you're supposed to put them. Adding excessive parentheses to Lisp code changes it.
And the parens and the code-data equivalence do have a purpose. They make working with the code programmatically very easy, which allows Lisp macros. The macros that every Lisp fan always mentions. They wouldn't be nearly as useful if Lisp didn't use the parentheses. And the parens are amazingly easy to edit with proper editor support.
It would help if you thought of Common Lisp and Scheme as different languages. Then you could go and download Lisp in a Box and get started off right with Common Lisp, which has a lot of cool stuff written for it. Yes, I'm biased. :-)
Lisp isn't functional. It can do functional things, but it can also be used naturally to write procedural and object-oriented code. And sometimes prolog-style code. And sometimes ML-style pattern-matching code. And sometimes code in other styles that you don't hear about very often.
Have you tried PLT Scheme? I've heard good things about it, and it may be what you're looking for.
You could check out the book being reviewed. It's very clear, and it's online for free.
(if (or (practicalp lisp) (commonp lisp)) (monkeys-fly-out 'my-ass) (life-as-normal))
Also, we'll want to define those two functions:
(defun practicalp (x) (eql x lisp))
(defun commonp (x) (not (eql x lisp)))
I've been doing web programming in Lisp recently. I've been using UnCommonWeb, which is a continuation-based web programming framework, and Yaclml, a library for HTML generation. Also the CLSQL database interface library adds some syntax for building SQL queries, which simplifies things and makes SQL injection attacks impossible. I've got to say, it's loads of fun.
I think the parens confuse almost everyone. They gave me a headache until I learned the editor keystrokes for manipulating them easily and learned to look at the indentation instead of the parentheses. Now I have trouble with other languages. It's amazing how anything different from what we're used to (whatever we're used to) seems hard to use, isn't it?
Use recursion wisely. You can use it for all iteration, but you shouldn't.
Better yet, and actually valid code: (second '("No." "Yes!" "Maybe..."))
And I'm not a Ruby programmer---but the sort of code generation you describe has three major disadvantages compared with Lisp's. First, it requires heavy string manipulation, which is ugly and error-prone. Second, using eval (or the Ruby equivalent) at runtime is slow. Third, this sort of thing falls into the realm of Scary Hack World in Ruby, while it's well supported in Lisp.
(html (:ul (dolist (item stuff)) (html (:li item))))
(Sorry I had to put that on one line, but Slashdot doesn't handle code indentation very well.)
This HTML generation stuff is very useful, and it's pretty difficult to make without using macros. Also, this compiles down to efficient code, rather than being interpreted.
There are other examples. For example, the LOOP uber-macro doesn't require any special support from the Lisp implementation, but it's practically a mini-language for expressing common looping idioms.
(remove-if-not #'oddp list-of-numbers)
That returns a list of all odd numbers in a list of numbers. With this sort of a difference in ease of use, why are you comparing Lisp to assembly language? My guess is that you're just talking out your ass.
If you don't want to use car and cdr, use first and rest. You have a choice.
The birth rate is decreasing. Rejoice!
[Edible vaccines] An ability which is not only vastly offset by potential dangers of screwing around with protein chains in food and thus causing all sorts of unimagineable long-term digestive and other diseases, it is also totally impractical since the vaccines are variable based on strains of the viruses/bacteria they are aimed at. Strains which evolve at immense speed.
Can you give a possible mechanism for these "unimagineable long-term digestive and other diseases" that may come from monkeying around with protein chains? Last time I checked, proteins were broken down into amino acids during digestion, rendering their structure moot, so I assume you're talking about some weird chemical change in the plant itself---but what? And when does worrying about such far-off fears cross the line from prudence to paranoia?
The nuclear industry is one of the most cautious I know of. Look at the redundant safety systems and the layers of steel and concrete (not to mention red tape) protecting all modern US, Canadian, and European nuclear plants and you'll agree: they're very cautious.
Because it isn't called "recycling". Seriously, it was done to make a political point and it's stuck ever since. And since Greenpeace et al always oppose measures to make nuclear power better for some reason, people don't seem too interested in reviving it in the US.
"Designed to sell more of their own pesticides"? Genetically modified food reduces the need for pesticides, as well as reducing the amount of farmland we have to use. Perhaps you're thinking of "Roundup-ready" crops which are immune to the plant-killer "Roundup". The thing there, though, is that Roundup is one of the most environmentally friendly ways to kill weeds that I know of, and Roundup-ready crops make it possible to use Roundup instead of less friendly herbicides.
You can do something similar on CLISP, although it could be a minor headache to make this work on multiple platforms.
GCL can make standalone executables. This is how the Windows version of the Maxima computer algebra system is distributed: as a GCL-generated EXE file. It's also getting quite a bit faster, since they added some type inference code.
ECL is fairly new, so it's not as mature as the others, but it looks very promising. It can generate standalone executable files on all major platforms and a few minor ones.
I hope someone gets something out of this.
The de facto way of interfacing with C in Common Lisp is the UFFI library. It runs on most Lisp implementations, but sadly it does not yet support GCL or CLISP. If you decide to play with either of those, you should probably just try its foreign function interface. CLISP in particular is noted for having an excellent FFI.
Try SBCL, CMUCL, GCL, or CLISP. They're all good Lisp implementations. SBCL and CMUCL compile to native code directly and are probably the fastest free CL implemetations, GCL compiles via C (and therefore GCC), and CLISP has a bytecode interpreter.
It already supports POP3, but not IMAP unless they've changed it lately.
Which is easier: running a program as non-root or ensuring that it has no remote vulnerabilities? And can you be as sure about the second one as you can be about the first?