Learn lisp in 5 steps(anthonyf.wordpress.com)
anthonyf.wordpress.com
Learn lisp in 5 steps
http://anthonyf.wordpress.com/2006/07/13/learn-lisp-in-5-easlily-written-steps/
4 comments
This list of steps applicable to learning any programming language.
1.) Switch to appropriate environment
2.) Download an IDE built for your language
3.) 2 + [insert language]Lint
4.) Read some books on the language
5.) Write a program that actually does something useful
Requiring an IDE specific to your language should be the exception, not the rule. Why the hell should you have to learn a completely different editor just to try out a new language? Is the language really so verbose and inexpressive that you can't even maintain it by hand?
An IDE is about making it easier to deal with your own code, not the language per se.
Any nontrivial program... say 50,000+ lines, would benefit from an IDE. Helps even simple tasks like finding all uses of a given function or pretty printing.
Any nontrivial program... say 50,000+ lines, would benefit from an IDE. Helps even simple tasks like finding all uses of a given function or pretty printing.
Oh. My objection isn't to having to learn an IDE, it's having to learn a new IDE, specific to that language. If you already know an editor which is excellent for editing, indexing, searching, navigating, slicing and dicing text, why should you have to learn a new editor that only even works for that one language (that you may not even use, in the long run)? Being that tightly coupled to the IDE should raise a red flag about the language's longevity / flexibility.
If my editor/IDE has to call out to utilities included with the language to run build tools, generate some kind of navigation tags, etc., that's fine. Needing a completely different editor just for that language seems crazy, though. If it's going to insist on that, it should at least be Smalltalk. ;)
By all means, put your time into an IDE which will remain useful for the next years (if not decades).
If my editor/IDE has to call out to utilities included with the language to run build tools, generate some kind of navigation tags, etc., that's fine. Needing a completely different editor just for that language seems crazy, though. If it's going to insist on that, it should at least be Smalltalk. ;)
By all means, put your time into an IDE which will remain useful for the next years (if not decades).
Ok, I largely agree... you really should be able to get away with knowing any of vi, emacs, vs, or eclipse ... getting language specific features via addins.
I only added that comment because I was thinking about PHP/JS vs...Java or Objective-C. It really makes sense to switch out of Coda and into Xcode.
I feel like anyone on HN has a basic idea of how to go about learning a programming language. If you sub in appropriate $books and $IDEs, there's nothing language-specific in the post. And to be honest, nothing all that new or all that notable.
Agreed, this is fluff, people are only responding to it because mentioning Lisp pushes HN's buttons.
If you want to read something good about Lisp, check out _Paradigms of Artificial Intelligence Programming_ by Peter Norvig, David Kranz's _ORBIT_, SICP, Dybvig's _Three Implementation Models for Scheme_, or the Lambda papers (http://library.readscheme.org/page1.html).
If you want to read something good about Lisp, check out _Paradigms of Artificial Intelligence Programming_ by Peter Norvig, David Kranz's _ORBIT_, SICP, Dybvig's _Three Implementation Models for Scheme_, or the Lambda papers (http://library.readscheme.org/page1.html).
I keep seeing all this talk of learning lisp but not a whole lot of rationale. Why should we learn lisp?
What will it replace? Why will it replace? etc...
What will it replace? Why will it replace? etc...
Paul Graham has half a dozen good essays in answer to your question:
http://www.paulgraham.com/articles.html
Why do you need rationale? I use lisp because its the language that gives me the most joy, you can spend a decade giving me rationale about how language X is better, but unless it can give me more joy i won't switch. But if you insist: common lisp is designed to write software. That is its sole purpose in existence. Its purpose is not to be object oriented, procedural, functional, declarative, low-level, high-level, big, small, pretty, cool, modern, fashionable, popular, or anything else, its common lisp, a language for people to write software in. For certain types of software and for certain types of people it is the best language, for other combinations, it is not so good.
Would you run away if I told you to? Probably not.
Would you run away if I told you there was an impending explosion? Probably.
Its one thing to tell people to do things. Its another to explain to them the benefits of doing so. Seemed like common sense...
Would you run away if I told you there was an impending explosion? Probably.
Its one thing to tell people to do things. Its another to explain to them the benefits of doing so. Seemed like common sense...
[deleted]
I'll take a small stab at giving a satisfactory answer.
Some of these apply to all Lisps, some don't apply to different Lisps, for varying reasons of implementation.
There are two basic reasons for learning a language - personal growth and for creating a product. In the realm of 'personal growth', Lisp opens the doors in your mind to working with macros and homoiconic code. It also shares with other dynamic languages the features of closures, currying, and the usual benefits of first-class functions. Scheme (as opposed to Common Lisp) has continuations, which are very powerful. These are all features that open the mind to new ways of thinking, hopefully for the better.
In the realm of the pragmatic -
Lisp- unlike other modern dynamic languages I know of ( I think Smalltalk can do this)- maintains an ability to version running objects in a system. It can perform hot-swapping of code remotely without bringing the run-time down. I haven't delved into this deeply yet, but I plan to later on. I believe Erlang is the only other major language that can hotswap well. Further, unlike the other mainstream dynamicaly typed languages going (Ruby, Perl, Python), Common Lisp can compile functions directly to native code. You will find SBCL is one of the best dynamic language contenders on the Alioth Shootout. (I'm not sure how Haskell and OCamls classify - I think they might generate binaries).
Therefore, Lisp is a good candidate for code that requires 'relatively' good performance, but isn't worth taking the time to do in C++.
The commercial Lisp implementations have GUIs that are supposed to work seamlessly on any of the 3 major OSs. That's a major feature in my book.
Lisp is famous for its ability to be expressive via its macro facility and the regular notation. So if you have a problem which your language is fighting you with - maybe you should find Lisp and check it out.
I've done some small work with a Lisp program that dynamically created random functions and then mucked with them on the fly in an optimization effort. It was, bluntly put, trivial to do the meta-function work. The chief difficulty was the actual algorithm (and my inexperience with Lisp. :-) ).
In regards to basic Lisp data storage, it is analogous to JSON's relationship with Javascript: really easy.
So to move this from a boostering to an engineering post, I'd like to consider some of the cons of Lisp.
Con 1 is the tooling. It's not as flashy as Java's or C#'s. If you need your IDE and refactoring tools, it's not going to fly for you. Personally, I just hang out in emacs for all development, so it's water off a duck's butt to me. :-)
Con 2 is the wreck of library finding. Quicklisp moved us into the 2010s with its release: it's on par or better than, say, cpan or gem. But there are still tons of libraries floating out there with crufty code that MAY be useful. This goes along with the ability of Lispers to write the same utility over and over again. Or, worse, have the same name for multiple libraries (clon for instance). I think that the library situation is getting way better though thanks to Xach.
Con 3 is the system integration. Like Python/Perl/Ruby, directly integrating into system calls is not trivial in the core language. This is massively different from C# or C++, where a system function just an using or an #include away. Common Lisp does have a solid foreign function interface from what I understand. I haven't used it yet though.
Con 4 is the lack of ability to run on super-low memory systems easily. Usually a Scheme-Lisp can be crammed in (I know of one that's been put on a system with 64K of memory). But I'm not convinced anything but C or ASM is the right tool for this job.
Con 5 is, let's face it, the weird. Continuations. Closures. Unrestricted lambdas. Macros. Parentheses. It's not Python/C++.
I'm not saying Lisp is the Uber-Language, the Ultimate Language From Which We All Go To (although historically, the ur-Lisp is the primordial ancestor of all dynamic languages from what I can tell). What I am saying is that it is a respectable general purpose language.
Some of these apply to all Lisps, some don't apply to different Lisps, for varying reasons of implementation.
There are two basic reasons for learning a language - personal growth and for creating a product. In the realm of 'personal growth', Lisp opens the doors in your mind to working with macros and homoiconic code. It also shares with other dynamic languages the features of closures, currying, and the usual benefits of first-class functions. Scheme (as opposed to Common Lisp) has continuations, which are very powerful. These are all features that open the mind to new ways of thinking, hopefully for the better.
In the realm of the pragmatic -
Lisp- unlike other modern dynamic languages I know of ( I think Smalltalk can do this)- maintains an ability to version running objects in a system. It can perform hot-swapping of code remotely without bringing the run-time down. I haven't delved into this deeply yet, but I plan to later on. I believe Erlang is the only other major language that can hotswap well. Further, unlike the other mainstream dynamicaly typed languages going (Ruby, Perl, Python), Common Lisp can compile functions directly to native code. You will find SBCL is one of the best dynamic language contenders on the Alioth Shootout. (I'm not sure how Haskell and OCamls classify - I think they might generate binaries).
Therefore, Lisp is a good candidate for code that requires 'relatively' good performance, but isn't worth taking the time to do in C++.
The commercial Lisp implementations have GUIs that are supposed to work seamlessly on any of the 3 major OSs. That's a major feature in my book.
Lisp is famous for its ability to be expressive via its macro facility and the regular notation. So if you have a problem which your language is fighting you with - maybe you should find Lisp and check it out.
I've done some small work with a Lisp program that dynamically created random functions and then mucked with them on the fly in an optimization effort. It was, bluntly put, trivial to do the meta-function work. The chief difficulty was the actual algorithm (and my inexperience with Lisp. :-) ).
In regards to basic Lisp data storage, it is analogous to JSON's relationship with Javascript: really easy.
So to move this from a boostering to an engineering post, I'd like to consider some of the cons of Lisp.
Con 1 is the tooling. It's not as flashy as Java's or C#'s. If you need your IDE and refactoring tools, it's not going to fly for you. Personally, I just hang out in emacs for all development, so it's water off a duck's butt to me. :-)
Con 2 is the wreck of library finding. Quicklisp moved us into the 2010s with its release: it's on par or better than, say, cpan or gem. But there are still tons of libraries floating out there with crufty code that MAY be useful. This goes along with the ability of Lispers to write the same utility over and over again. Or, worse, have the same name for multiple libraries (clon for instance). I think that the library situation is getting way better though thanks to Xach.
Con 3 is the system integration. Like Python/Perl/Ruby, directly integrating into system calls is not trivial in the core language. This is massively different from C# or C++, where a system function just an using or an #include away. Common Lisp does have a solid foreign function interface from what I understand. I haven't used it yet though.
Con 4 is the lack of ability to run on super-low memory systems easily. Usually a Scheme-Lisp can be crammed in (I know of one that's been put on a system with 64K of memory). But I'm not convinced anything but C or ASM is the right tool for this job.
Con 5 is, let's face it, the weird. Continuations. Closures. Unrestricted lambdas. Macros. Parentheses. It's not Python/C++.
I'm not saying Lisp is the Uber-Language, the Ultimate Language From Which We All Go To (although historically, the ur-Lisp is the primordial ancestor of all dynamic languages from what I can tell). What I am saying is that it is a respectable general purpose language.
Haskell and OCaml both typically compile to native code, and since they have REPLs, may fit your criteria for "dynamic" languages (which is a very fuzzy classification). LuaJIT also performs quite well, and IMHO is very pleasant to work with. Either way, Lisp performance is quite good, significantly better than Python or Ruby, which are often good enough.
Lisp's convenient format for data was a HUGE win, for a while, but other languages have caught up. Python has dicts, Lua has tables, Javascript has JSON, ML has its variant types, Erlang inherited Prolog's terms (its parallel to Lisp's s-expressions), etc. All of the above are extremely useful. Expressive data and simple code is far easier to maintain than overly simple data and compensatingly elaborate code. Languages without a good high-level format for structured data either lose out on a lot of functionality, or (sigh) fall back on XML.
Also, Quicklisp is quite nice, and props to Xach for setting it in motion.
Lisp's convenient format for data was a HUGE win, for a while, but other languages have caught up. Python has dicts, Lua has tables, Javascript has JSON, ML has its variant types, Erlang inherited Prolog's terms (its parallel to Lisp's s-expressions), etc. All of the above are extremely useful. Expressive data and simple code is far easier to maintain than overly simple data and compensatingly elaborate code. Languages without a good high-level format for structured data either lose out on a lot of functionality, or (sigh) fall back on XML.
Also, Quicklisp is quite nice, and props to Xach for setting it in motion.
I'm not sure what I mean by a 'dynamic' language. I know it when I see it. ;)
Well, less facetiously: if I can add in-language functions to the image, using the language facilities, while the deployed application is running/paused, I think of that as dynamic.
Data is an interesting thing. There's a crossover point between structured textual data that can be sucked in and when you want to start doing relational queries and stores. Then there's how data is handled in the program. The methods you describe above are very useful, but - insofar as I know of - I think they can be reimplemented without massive grief in other languages, depending on extensibility. Lua has a good reputation for speed; I take it you use it as a standalone?
Well, less facetiously: if I can add in-language functions to the image, using the language facilities, while the deployed application is running/paused, I think of that as dynamic.
Data is an interesting thing. There's a crossover point between structured textual data that can be sucked in and when you want to start doing relational queries and stores. Then there's how data is handled in the program. The methods you describe above are very useful, but - insofar as I know of - I think they can be reimplemented without massive grief in other languages, depending on extensibility. Lua has a good reputation for speed; I take it you use it as a standalone?
If being able to update code from a REPL while it's running counts, then yes, though OCaml and Haskell (AFAIK, less experience there) usually involve more edit-compile-reload, to take advantage of the utterly superior compile-time checking. OTOH, Erlang handles "change-in-flight" even better than Lisp does. Of the four, I prefer Erlang, but they're all respectable.
I use Lua both standalone and with C. (Its convenience with linked-in C code won me over from Python, actually.) It's my favorite general purpose language. Nothing against the great performance, but it was a great language before LuaJIT even existed.
Datalog also has a lot of potential as a data format. The industry seems to forget anything invented more than a fortnight ago, though, so it's probably passe until somebody charismatic finally invents it.
I use Lua both standalone and with C. (Its convenience with linked-in C code won me over from Python, actually.) It's my favorite general purpose language. Nothing against the great performance, but it was a great language before LuaJIT even existed.
Datalog also has a lot of potential as a data format. The industry seems to forget anything invented more than a fortnight ago, though, so it's probably passe until somebody charismatic finally invents it.
Interesting explanation.
Would you recommend Lisp to a C/Python developer who is focused on system applications?
Would you recommend Lisp to a C/Python developer who is focused on system applications?
For what purpose? What do you mean by system applications?
Certainly I would evaluate it as a reasonable language for anywhere where Python is used.....
Certainly I would evaluate it as a reasonable language for anywhere where Python is used.....
One application I spend a lot of time working on/modifying is my crawler. It uses Python's Beautiful Soup.
Other applications I use/work on are my master control application. It is written in C and handles configuration sharing between systems.
Other applications I use/work on are my master control application. It is written in C and handles configuration sharing between systems.
Depending on complexity and future plans, Common Lisp might be a good choice to create the controller in.
I don't think I'd want to try to reimplement Beautiful Soup without a really good reason! :)
I don't think I'd want to try to reimplement Beautiful Soup without a really good reason! :)
Lisp is a great language, both in the sense that it is remarkably powerful and that it has had a long legacy. Learning Lisp will teach you new and genuinely mind-expanding ideas (e.g. continuations), much like learning C and suddenly understanding pointers. Many other languages have been strongly influenced by elements from it, because its design makes it particularly convenient for prototyping languages. After learning Lisp, a lot of "experimental" ideas in (say) Ruby really won't be all that surprising - they've already been debated for over thirty years, after all. There are also many great research papers and books about programming that use a Lisp dialect as their lingua franca. (I'd suggest learning at least enough Lisp to read Peter Norvig's _Paradigms of Artificial Intelligence Programming_, but maybe you're a tl;dr kind of person.)
Still, Lisp isn't the only language you should learn. It's not like it sits alone, atop some mountain, wrapped in golden clouds. I learned a ton about language semantics from Lisp, sure, but I've also found inspiration in Prolog (unification!), OCaml (static typing, done right! plus LOTS of good compiler texts), Erlang, Forth, K, Oz, Lua, awk, Self, and many others over the years. I also prefer a mix of Lua, C, and Erlang for real work, though I know many people that prefer Common Lisp or various Scheme dialects. (Chicken and Scheme48 are both pretty practical, imho.)
It's much like learning object-oriented programming and functional programming and constraint/logic programming and several different styles of databases and Perl and ... Each will add different approaches to your problem-solving toolkit. Lisp can comfortably accommodate many different programming models, and real experience with it will introduce you to several.
Still, Lisp isn't the only language you should learn. It's not like it sits alone, atop some mountain, wrapped in golden clouds. I learned a ton about language semantics from Lisp, sure, but I've also found inspiration in Prolog (unification!), OCaml (static typing, done right! plus LOTS of good compiler texts), Erlang, Forth, K, Oz, Lua, awk, Self, and many others over the years. I also prefer a mix of Lua, C, and Erlang for real work, though I know many people that prefer Common Lisp or various Scheme dialects. (Chicken and Scheme48 are both pretty practical, imho.)
It's much like learning object-oriented programming and functional programming and constraint/logic programming and several different styles of databases and Perl and ... Each will add different approaches to your problem-solving toolkit. Lisp can comfortably accommodate many different programming models, and real experience with it will introduce you to several.
Step #2 involves learning LISP. As I embark to learn elisp, am I then to re-install Linux and emacs and SLIME? Then make my way to step 2 again...