6 ms·
I have yet to understand the Lisp craze, no matter how many blog articles I read about it's beauty. Although I will admit Lisp machines were pretty neat.
by akhilcacharya 11y ago
I have yet to understand the Lisp craze, no matter how many blog articles I read about it's beauty.
Although I will admit Lisp machines were pretty neat.
- giancarlostoro 11y agoYou'd have to sit down and learn it and try it out for yourself. At least that's the case for me.
- akhilcacharya 11y agoTrue, I have Scheme, Racket, and Clojure installed on my machine. I tried to get started, but I couldn't think of any simple projects that would accentuate the "uniqueness" of Lisp dialects. Maybe I'll pick it up again after my love affair with Go dries up.
- giancarlostoro 11y agoNot sure if games interest you, but "Realm of Racket" is a fun read to get into Racket with. I mostly got into the rest of Lisp because I liked Racket.
- joshuapants 11y agoI'll second that, it's a great book. Sort of a cousin to Land of Lisp, simultaneously a bit more academic and a bit more gentle to newcomers.
- fao_ 11y agoDoes it have to be unique? A small project that you use now and then that needs an upgrade would probably benefit from being written in lisp (in some manner).
- agumonkey 11y agomaybe take the https://www.coursera.org/course/proglang https://www.coursera.org/course/proglang MOOC at one point you write a small evaluator, then extend it through macros. Shows you how to get the linguistic trait you'd like in a few lines. One thing lisp has been used to demonstrate since its birth. (the course uses ruby and sml for other subjects)
- tptacek 11y agoSome of Lisp appreciation is like appreciating the Pixies: it's hard to see what's so amazing about it when so many of its good points have been expropriated by later projects. It's easy to see what's so powerful about Lisp when your only comparison is C, but it's not 1998 anymore, and most new code is written in high-level garbage collected languages. The rest of Lisp you appreciate by learning to appreciate real macros.
- agumonkey 11y agoI've read a few books about lisp tininess, beauty etc. I don't know it was late 70s research bias or not. But it seems that no matter how many lisp genes are picked up by other language. Its symbolic/recursive nature can't be matched, and everything else is secondary.
- jarcane 11y agoIt's the syntax. The elementary nature of s-expressions makes it fairly trivial to mangle them freely, and define all kinds of clever tree structures and so on, all in an easy and consistent way. It also means you never have to remember much symbolic weirdness, you just have to remember (operator atom atoms ...), and that's it. I think only the functional languages like Haskell and F# come close to the same expressiveness, just from very different angles; auto-currying and lazy evaluation save a lot of boilerplate, and the former is tricky to do in Lisp for precisely one of the reasons it's so flexible (easy variable arguments).
- agumonkey 11y agoIt's a little more than syntax to me, even though it's part of it. Maybe a ~rapprochement between syntax semantics evaluation of recursive domains/categories. The fact that the construction of data through sexps belongs to that same philosophy as valuation between any domains. That the same recursive idea permeates through the whole system.
- mahmud 11y agoLisp is more like the Velvet Underground than the Pixies ;-)
- nickpsecurity 11y agoThere were three things that really did it for me: powerful macro's + language designed to be easily macro'd; incremental compilation; updating live code. The macro's let me extend it however I liked. OOP was invented? Add a library. Aspects? Add a library. Type-checking? Add a library. In each case, the language itself transforms to more effectively use the approach with much zero-overhead potential given the transforms are usually at compile-time. I had DSL's for common things such as GUI's, state-machines, and databases. Let me do so much with so little work while having consistency across the whole thing. The second was incremental compilation. I was an imperative programmer and mostly used that style. Languages such as C++ interrupt one's mental flow with long compile cycles. Interactive languages, especially scripting, tended to be too slow in production. LISP let me compile individual functions in a fraction of a second after writing them. Think, type, hit button, examine results, and repeat. The flow stays there and you just keep pumping out more of your solution. That my main DSL was compatible with a C++ subset meant I could just autogenerate that at the end to benefit from its compilers or portability. Otherwise, I stayed in LISP. The third thing was something that I tried with C/C++. Self-modifying code for AI and security applications was one use. Another was updating apps live. LISP made both pretty easy. The program ran as an instance while you made it in certain development environments. You were in a way always working with a live program. Also, you could drop a member variable in a class definition and all running instances of that class would loose it. Just like that. So easy to change while being able to compile to fast code with type & safety level declarations. So, it was a language that could do anything I want it to do, allow rapid iterations at max flow, and even change running systems if they weren't good enough. Still haven't felt this full effect in other languages. The old LISP machines went further [1] in that they could take you to any problem in the app or OS right at the source code without crashing. Like LISP apps, you can inspect the issue, modify the code of the running system, optionally modify the instance, and proceed how you wanted to. Still waiting for that feature in Windows or Linux development. ;) [1] http://www.symbolics-dks.com/Genera-why-1.htm http://www.symbolics-dks.com/Genera-why-1.htm
- rndn 11y agoPerhaps this helps: https://www.youtube.com/watch?v=HM1Zb3xmvMc https://www.youtube.com/watch?v=HM1Zb3xmvMc