Classic Kenny!
Common Lisp used to be much of my programming world also.
Ooh Ooh My Turn Why Lisp? (2008)
11–20 of 160 posts
Re: Ooh Ooh My Turn Why Lisp? (2008)
#12> most Common Lisp implementations are native compiled. ... isn't it nice to compile down to the metal?
Is just the interpreter native or does cl compile your app to native as well?
Re: Ooh Ooh My Turn Why Lisp? (2008)
#13[deleted]
Re: Ooh Ooh My Turn Why Lisp? (2008)
#14It's a nice perspective. Very practical and down to earth. There is another side though, and that is that learning to think of code as data is extremely empowering and translates well when working with a fairly large set of other languages (Perl, Python, Ruby, and now even Java). Learning Lisp turns you into a better programmer.
I like Scheme/Lisp but I don't know if I buy the whole "learning Lisp turns you into a better programmer". Maybe more knowledgeable but not necessarily a better a developer.
In some ways learning a really flexible language like Lisp can turn you even into a really bad developer. I say "developer" instead of "programer" because I want to emphasize working with others and thus sharing code with others. Of course this is based on some past observations working with MIT grads and various other academia so take my opinion with a grain of salt.
IMO the language that really changed everything for me was the ML family of languages and maybe C. I would say knowing C and ML is more worthwhile than Lisp (Lisp is not exactly hard to learn anyway... the basics that is).
Re: Ooh Ooh My Turn Why Lisp? (2008)
#15> most Common Lisp implementations are native compiled. ... isn't it nice to compile down to the metal? Is just the interpreter native or does cl compile your app to native as well?
SBCL compiles to native.
In fact thats how you check if the function was tail-optimized -- it will have a JMP opcode instead of CALL
Re: Ooh Ooh My Turn Why Lisp? (2008)
#16> he simply asked if Python could gracefully manipulate Python code as data
Have there been any big LISP macro code injection vulnerabilities in the wild?
Re: Ooh Ooh My Turn Why Lisp? (2008)
#17> most Common Lisp implementations are native compiled. ... isn't it nice to compile down to the metal? Is just the interpreter native or does cl compile your app to native as well?
SBCL compiles to native. In fact thats how you check if the function was tail-optimized -- it will have a JMP opcode instead of CALL
To add to this, Most of them compile to native. I think the exception is CLISP. Certain implementations have both because compiling was costly at one point.
Re: Ooh Ooh My Turn Why Lisp? (2008)
#18"The question is where will we be in five years, the answer is using Common Lisp, because of language features" says the author in the comments. This was 8 years ago.
Kind of rude of me to take that potshot, but it's there. I've been reading these "Why Lisp?" Arguments for years and yet it still remains pretty niche. The longer this goes on the more I am unable tell Lisp advocates apart from Perl advocates. They both sound like write-only languages. They make a lone programmer feel very productive and Free, but it results in essentially unmaintainable code. I've written and attempted to maintain much more Perl than Lisp, many years ago, so please tell me if I'm wrong.
Re: Ooh Ooh My Turn Why Lisp? (2008)
#19It's a nice perspective. Very practical and down to earth. There is another side though, and that is that learning to think of code as data is extremely empowering and translates well when working with a fairly large set of other languages (Perl, Python, Ruby, and now even Java). Learning Lisp turns you into a better programmer.
I like Scheme/Lisp but I don't know if I buy the whole "learning Lisp turns you into a better programmer". Maybe more knowledgeable but not necessarily a better a developer. In some ways learning a really flexible language like Lisp can turn you even into a really bad developer. I say "developer" instead of "programer" because I want to emphasize working with others and thus sharing code with others. Of course this i…
I'm biased, but there's a big difference between "learning lisp" (well enough to transliterate that python program) and really getting the code as data concept.
I'd say that learning X really well is always a positive because whenever you learn something in depth you can then apply the concepts elsewhere. And there are still lisp-only concepts, so learning lisp is positive. ML is good too. Also spending time with a well designed concurrent language is beneficial.
Re: Ooh Ooh My Turn Why Lisp? (2008)
#20"The question is where will we be in five years, the answer is using Common Lisp, because of language features" says the author in the comments. This was 8 years ago. Kind of rude of me to take that potshot, but it's there. I've been reading these "Why Lisp?" Arguments for years and yet it still remains pretty niche. The longer this goes on the more I am unable tell Lisp advocates apart from Perl advocates. They both…
I'm developing a language that's a superset of Lua and Lisp. It's still in its infancy, but here's an example of a Lisp/Lua function in a module that can be imported as a (+...) macro that expands into Lua `a + b + c + ...` expression.
https://github.com/meric/l2l/blob/rewrite/l2l/macro/arithmet...
The idea is programmers will write in Lua whenever readability is prioritised, and when homoiconicity is required, for example in the use of domain specific languages, lisp can be switched to. The lisp part can be used to produce macros that expand into Lua.
Would be great to know your thoughts!