6 ms·
What value would learning Lisp provide, if you're not curious and learning for the love of learning, or you're not an emacs user?
by jossclimb 3y ago
What value would learning Lisp provide, if you're not curious and learning for the love of learning, or you're not an emacs user?
- gjvc 3y agoWhat value would learning Lisp provide, if you're not curious and learning for the love of learning, or you're not an emacs user? What do you want?! A dollar value addition to your salary? To answer your question: Knowing about an important and highly influential part of the industry in which you work. If that sort of thing is not important to you, by all means let it pass you by.
- teddyh 3y ago“LISP is worth learning for a different reason – the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot.” — <http://www.catb.org/~esr/faqs/hacker-howto.html#skills1 http://www.catb.org/~esr/faqs/hacker-howto.html#skills1>
- gjvc 3y agoStill working and waiting for that profound enlightenment experience. Still hopeful.
- jimbokun 3y agoMaybe you had already picked up the concepts of Lisp from other languages. Although the approach to macros is still quite distinctive. To the point that if a language has Lisp like macros, it’s probably considered a Lisp.
- ra1231963 3y ago[flagged]
- packetlost 3y agoSoftware is such a vast industry with a lot of different goals, viewpoints, and tools. Such a close-minded and wasteful statement, I find it hard to believe you are as successful as you say. Something is only a waste of time if you get nothing out of it, but that's not for you to determine for someone else.
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- aa-jv 3y agoFast implementation of working app logic that can later be turned into an app-generator for any other language with great ease.
- jossclimb 3y agoWhat does that mean? Why not start in my native preferred language?
- kazinator 3y agoWhat does "native language" mean here? Your mother sang lullabies in C++? Chances are that what you know and prefer is one of the first two or three things you ever used, which was decided for you by someone else, directly or indirectly. If you think that makes it "native", you're deceiving yourself.
- jstx1 3y ago[flagged]
- anthk 3y agoCL is used in pretty serious contexts (read: avionics) with little changes over time. JS has the weekly framework syndrome.
- xh-dude 3y agoLisp is profound, not esoteric - the ideas apply in any language
- matheusmoreira 3y agoIt's hard to describe. Implementing Lisp is the best way to understand just how powerful the ideas are. I thought I had a reasonable understanding of the language but making my own still changed me.
- Barrin92 3y agoCommon Lisp is a big, general purpose language and implementations like SBCL are fast so you can pretty much write whatever you want in it. Having a fast, high level expressive, dynamic language with a powerful macro system is generally where Lisps excel. And if you like functional programming there's Clojure.
- Jach 3y agoThe value depends on what you already know and whether you want to substitute potentially inferior versions of the thing to acquire or make use of the knowledge. I'll list some ideas of useful concepts you may or may not have picked up already. First, a lot of languages have closures these days, do you know them and more generally how to tastefully use higher-order functions? When Java 8 came out, I could see a difference between programmers who had useful experience or instruction (Scheme + SICP is still great on this) using closures elsewhere prior, excited programmers who were using them for the first time even if frequently not tastefully, and old programmers who had never strayed outside their lane and look at any new language feature or evolution that they now have to learn and contend with to keep up with a shady eye, never mind the potential benefits. Second, some languages have something like macros, how familiar are you with metaprogramming? Maybe you'll be satisfied with C++? A comparison from the author of the CLASP implementation who is an expert in both langs: Lisp macros are to C++ templates as poetry is to IRS tax forms. Third, do you know OOP, or perhaps you know it quite well from things like Java/Python/C++/Ruby/JS and dislike it? The Common Lisp Object System (CLOS) was the first ANSI standardized OOP system and yet it's a lot different from other attempts. In particular, it does not couple classes together with methods, they are defined separately which avoids a lot of common OOP problems while giving you multiple dispatch for free (eliminating some verbose design patterns too). It's also got less commonly seen things like metaclasses (with a whole book written on just the meta-object protocol highly praised by Alan Kay), multiple inheritance, a way to redefine classes and reshape existing objects at runtime (overload an 'update-instance-for-redefined-class method), and a poor man's initial support for maybe 70-80% of the value of aspect oriented programming with :before/:after/:around method combinators out of the box that can be further augmented if needed for the full value. Some of the ideas can be had with effort (perhaps done for you already via libraries) in other langs. Fourth, do you know about conditions and restarts, a way to handle errors that's not just goto error or classic stack-unwinding exceptions? There's a whole (short) book ("The Common Lisp Condition System: Beyond Exception Handling with Control Flow Mechanisms") on just this topic if individual chapters/essays elsewhere aren't enough for you. I don't know a good alternative for getting this concept, thus the value of it may be limited to whether you can actually use it or an imitation (the book author did implement a version for Java: https://github.com/phoe/cafe-latte https://github.com/phoe/cafe-latte). Fifth, do you have experience in incrementally writing and debugging a program as it's running, or have you only ever done the usual edit > compile > run > observe and repeat cycle? Common Lisp is still the best for this, Clojure is ok, Java with JRebel gives you maybe 80-90% of the practical benefits. TDD maybe gives 20-30% of the practical benefits while being tedious. Some people definitely do not like the style, but if you haven't seen the style to determine that for yourself, you're missing out. (And if you're freaking out about error checking, you can get some compile-time warnings from SBCL about bad types or missing functions and so forth; they're just warnings instead of errors because you can fix them as you go, you can redefine (even if you're in a debugger context) and continue rather than restart everything and lose any state. In SBCL, redefining a function also recompiles it for you. 'compile and 'compile-file are standardized built-in functions to the language you can invoke at runtime, rather than a separate program.) As for editors, you don't have to use emacs. (I prefer vim.) https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... gives a list of alternatives besides those two. The main things IMO that you need as far as editor support goes: highlight matching parens (basically everything), and ability to talk to the running Lisp to provide the features of my fifth point. To elaborate even further on that, such support gives you redefinition, debugging (breaking/stepping/tracing), disassembling, intellisense-style function doc and even symbol auto-complete, and jump-to-code/cross-referencing features, all part of Lisp itself and conveniently/portably accessed with regular Lisp code talking to the editor typically over a socket rather than needing to be implemented externally. The main development feature, editor or otherwise, still lacking from anyone (though someone was working on this, I haven't followed up in a long while) is mass auto-refactoring; in practice it's not a huge limitation because you don't couple things as heavily as in other languages that necessitate frequent huge refactorings, and you can use the same sorts of tools people used just fine prior to semantic mass-refactoring tools becoming more common. (I use Grepper with vim for mass-rename.) Fowler's 2nd edition of "Refactoring" uses JavaScript with no fancy tools in part just to show the point that the discipline isn't tool dependent anyway.