33 ms·

A Tour of the Lisps

358 points by medo-bear 3y ago

netcraft 3y ago
after decades of programming, lisp has always been that thing that intrigues me endlessly, but I haven't had a chance to actually wield it myself. but so many people whose opinions I respect love lisps, and not just for a little while. Clojure especially. Other ideas like datomic and xtdb are also high on my list of things I need to experience. I think im going to have to make an intentional effort to find a lisp job next time.
- epgui 3y ago
  Doing Clojure at CircleCI, a few years ago, redefined who I was as an engineer… FWIW. It’s an incredible language. Today I work with python (sigh) and every day I long for Clojure.
  - behnamoh 3y ago
    I keep hearing sentiments like this but then I wonder, if Clojure or <another awesome Lisp> is so much better than Python <or some other mainstream language>, then why are we still writing in those languages? If it's because of libraries, then the question is: Why do people write libraries for these languages and not the Lisp ones?
    - galaxyLogic 3y ago
      Because of habit. There is always a cost in trying to learn something new, to the level you are on with some other language and it's tooling and libraries. Programmers who program in some language for a few years realize they are still learning more about it, all the time. Therefore they know if they switched to another language it would also take them a few years to attain the same level of mastery. And then there is similar inertia with an organization that has lots of code in some specific language already.
      - colingw 3y ago
        Yes, it's more than just about the language itself, as I describe here: https://www.fosskers.ca/en/blog/software-dev-langs https://www.fosskers.ca/en/blog/software-dev-langs For some people, community signals are very important. Massive conferences or raw number of libraries, etc., indicate some inner quality of that language's ecosystem that they value.
        galaxyLogic 3y ago
        Nice link, holistic viewpoint!
    - Zambyte 3y ago
      Social forces and economics. Lisps were winning in academia for a while. Unix started winning in the engineering world before Lisp systems really got their feet under them. Engineers made a lot of money, and academia shifted focus to the systems that were making money. Now everyone programs for Unix instead of Lisp.
    - epgui 3y ago
      For the same reason people can't change their well-established habits and opinions, particularly those that have network effects. Language popularity has little to do with how well languages are designed or how simple they actually are. Most popular languages are popular for historical reasons.
    - tikhonj 3y ago
      At the end of the day, things get popular through social processes, so it's far more a matter of social factors—some of which are practically random—than any intrinsic qualities of the thing itself.
    - deleted 3y ago
      [deleted]
    - ParetoOptimal 3y ago
      I can say at least that Haskell is this way for me.
      - epgui 3y ago
        I think you'd rewire your brain "equally well" with either Haskell or Clojure. I prefer Haskell's type system, but Clojure has better syntax IMO.
    - crote 3y ago
      Because it's weird enough to be off-putting, and it doesn't solve a real-world problem. If you look at the arguments in favor of Lisp, they'll often boil down to it being "beautiful", "elegant", "flexible", or even "magical". It's a very minimal language which allows you to do absolutely anything - a lot of which would be an absolute nightmare in most other languages. You could implement just about any programming paradigm in Lisp if you want to. I believe this makes it very appealing to computer scientists, or other people with a more mathematical background. However, this flexibility is also a massive footgun: if you're not careful your junior developer might end up reinventing the wheel a dozen times, and writing completely unmaintainable code in the process. On the other hand, most other programming languages look kind-of the same. They are all quite opinionated about how stuff is supposed to work, with a lot of hardware details leaking into the language. However, they are very easy to learn: most of it is just "do a bunch of operations in succession" taken to the extreme. Anyone who knows C# will be able to pick up a basic understanding of C, Python, or JavaScript well within a day, and a lot of people new to programming will be able to write not-completely-terrible code within a month or two when given the right guidance. They don't need to know about all the abstractions and technical details to be a functioning member of your team. When you're running a business, you don't care about any of that beauty or flexibility. You want code which is quick and easy to write, trivial to read, and understandable by even the worst programmer in your company. In practice that means in your comparison you'll be choosing Python over Lisp. Heck, Go was developed entirely around this principle, cutting out as many language features as possible. And because all the other companies are making the same choice there will also be way more libraries for Python, making the gap even larger. So yeah, in a stroke of irony Lisp isn't more popular because it is better.
      - evdubs 3y ago
        > Because it's weird enough to be off-putting, and it doesn't solve a real-world problem. Nonsense. Quoth Wikipedia, "Lisp pioneered many ideas in computer science, including tree data structures, automatic storage management, dynamic typing, conditionals, higher-order functions, recursion, the self-hosting compiler, and the read–eval–print loop." These are all solutions to real world problems. So many languages borrow features that were originally developed in Lisp. > However, this flexibility is also a massive footgun: if you're not careful your junior developer might end up reinventing the wheel a dozen times, and writing completely unmaintainable code in the process. Plenty of code written in Lisp looks just like your Python, Ruby, JavaScript, Java, et al programs where you're defining structures or classes, writing and calling functions, importing useful libraries, etc. Plenty of this Lisp code is just as maintainable as the non-S-expression code. > Anyone who knows C# will be able to pick up a basic understanding of C, Python, or JavaScript well within a day Same with Lisp. It's just: (function arg1 arg2) Instead of function(arg1, arg2) > You want code which is quick and easy to write, trivial to read, and understandable by even the worst programmer in your company. There is plenty of "lowest common denominator" code like this written in Lisp. Much Lisp code is not buried under inscrutable macros, just like not all Java code is buried under layers of inscrutable classes.
    - __MatrixMan__ 3y ago
      Most Python users aren't software engineers. They're students, scientists, business analysts... We're lucky that we were able to drag them away from Excel. Asking them to learn yet another programming language might be a bit much. And if they did, it wouldn't probably be a lisp (it would probably be among: C, Javascript, Julia, Go, Nim). I want to move on from Python, but there are so many more people that I can help if I stay.
      - tugberkk 3y ago
        I have the same problem. It is a good language to teach to non-cs majors. If you want to build something out of the box, use Python. However, GPT is coming and maybe we won't even use Python anymore for simpler tasks.
    - kazinator 3y ago
      > Why do people write libraries for these languages and not the Lisp ones? 1. They want their names to be widely recognized, so they find a popular bandwagon to hop onto. 2. Raw numbers? More people using Python means more people trying to make libraries for Python, means more libraries remaining in the race after you eliminate the crap from people who don't know how to write libraries. Note that Python is, by now, an old language. It wasn't instantly popular, and you wouldn't have predicted it. In, say, 1999, you had to be some GNU/Linux person to even know what Python is. It was far from obvious that, of all things, it would get so popular. That Eric Raymond article in the Linux Journal around that time probably gave it a bit of a boost. Python definitely rode on the coattails of increasing GNU/Linux popularity, too. More people using Linux started asking questions how to script this and that, and going "gack!" at shell or perl programming. It seems Python might appeal to survivors of VisualBasic shifting gears into GNU/Linux stuff.
    - roenxi 3y ago
      I don't think anyone is saying Clojure is better than Python in the abstract. Clojure has a different style from Python and that style can be more fun and is better for some specific tasks like application programming and anything that wants to use multiple CPU cores. Tends to have better long term prospects too, old Python code doesn't work in my experience but things on the JVM have cockroach powers. As for why things are and aren't popular, who knows? It is quite possible that people just don't like the look of the parenthesis, or there are a couple of key libraries that aren't good but nobody vocal has put there finger on which ones. The error messaging isn't quite up to a standard that people want to deal with. Or maybe popularity is really just about pure random chance, at most 4 languages get to have >20% market share, by definition.
      - epgui 3y ago
        > I don't think anyone is saying Clojure is better than Python in the abstract Actually, I will make that claim without hesitation.
    - crq-yml 3y ago
      Lisps are "wizard" languages: the runtime semantic is kept close to the syntax, which also means that you can rapidly extend the syntax to solve a problem. This quality is true of Forth as well, and shares some energy with APL and its "one symbol for one behavior" flavor. With respect to their metaprogramming, the syntactical approach hands you a great foot-gun in that you can design syntax that is very confusing and specific to your project, which nobody else will be able to ramp up on. But Algols, including Python, are "bureaucrat" languages: rather than condensing the syntax to be the exact specification of the program, they define a right way to form the expression, and then the little man inside the compiler rubber stamps it when you press the run button. In other words, they favor defining a semantics and then adding a syntax around that, which means that they need more syntax, it's harder to explain the behavior of a syntactical construction, and it's harder to extend to have new syntax. But by being consistent in a certain form-filling way, they enable a team to collaborate and hand off relatively more code. IMHO, a perfectly reasonable approach I'm exploring now for personal work is to have a Lisp(or something that comes close enough in size, dynamic behavior, and convenience, like Lua) targeting a Forth. The Forth is there to be a stack machine with a REPL. You can extend the Forth upwards a little bit because it can metaprogram, or downwards to access the machine. It is better for development than a generic bytecode VM because it ships in a bootstrappable form, with everything you need for debugging and extension - it is there to be the layer that talks to the machine, as directly as possible, so nothing is hidden behind a specialized protocol. And you can use the Lisp to be the compiler, to add the rubber-stamping semantics, work through resource tracking issues, do garbage collection and complicated string parsing, and generate "dumb" Forth code where it's called for. That creates a nice mixture of legibility and configurability, where you can address the software in a nuts-and-bolts way or with "I want an algorithm generating this functionality".
      - Karrot_Kream 3y ago
        > IMHO, a perfectly reasonable approach I'm exploring now for personal work is to have a Lisp(or something that comes close enough in size, dynamic behavior, and convenience, like Lua) targeting a Forth. I've had this idea for a while now but never got around to actually executing it. I'd love to follow your progress if you're doing it publicly.
    - coldtea 3y ago
      >If it's because of libraries, then the question is: Why do people write libraries for these languages and not the Lisp ones? Because libraries already exist for those languages, as well as support, vendors, and a big ecosystem, familiar syntax, and jobs. So they write libraries for languages that are already popular. If you meant, "but why wasn't some Lisp the one that gain popularity back in the day, when C, C++, Python, and Java didn't exist or where still fresh?" I think because: 1) it was too advanced for the procedural mindset at the time, 2) it was not sufficiently efficient in those primitive 16 bit machines 3) fragmentation and most importantly, no killer app and major vendor backing or OS first-class support (like C had for UNIX, C++ for Windows, and Java got from SUN).
    - eduction 3y ago
      This is a great talk on exactly this topic from a Clojure conference, if you want a long answer. It focuses on the “functional” feature of Clojure but all of it applies to the whole language (and probably any good lisp) IMO. https://youtu.be/QyJZzq0v7Z4?si=y3hhYaInMkRLBCJK https://youtu.be/QyJZzq0v7Z4?si=y3hhYaInMkRLBCJK My brief text answer (focused on Clojure): -python has been around about 20 more years than Clojure -the advantages of Clojure vs python/etc probably aren’t nearly as big as python vs a non memory managed, compiled, static language like C. That whole generation of “scripting” languages had the wind at their backs in a way Clojure and its contemporaries never quite will (though Clojure et al tend to be much better at concurrency and parallelism and this will help a lot) -unfamiliar syntax (not Algol like) and paradigm (not oop)- and the truth is many programmers back away slowly when a thing is too alien -hasn’t found a niche as big as data science or scientific computing or CRUD website building - I think python has aggregated some great academic niches, at least one of which (ML/data science) exploded in popularity. Ruby had the rails community. Clojure seems to have some popularity in fintech but has no big single niche yet that it dominates.
- karmakaze 3y ago
  My take on Lisp after going (partway) through SICP, is that it's a syntax and not so much a language. The language is what you build up for the particular kinds of things you need to do. This is both the strength and weakness of Lisp, with a tight-knit competent team, everything is elegantly achievable. However on a small/understaffed team or one with high turnover, each member has to onboard onto that team's language built using Lisp. Imagine the best and worst DSLs that you've had to use. Joining a Lisp team would be somewhere on that spectrum though I hope their homegrown/app language is far better than the average/bad DSL. Clojure is much better in that it has many 'batteries included' and opinions on things to make different codebases less different than with other Lisps.
  - bcrosby95 3y ago
    My take on Lisps is that people overblow the DSL aspect of it. I just write functions that call other functions, as opposed to methods that call other methods.
    - pfdietz 3y ago
      That's a fine thing to do in Common Lisp. If you ever change your mind, it's very easy to change a function into a generic function and split off the body into one or more methods.
      - deleted 3y ago
        [deleted]
  - nerdponx 3y ago
    If it's any help, SICP is the wrong place to start for actually learning Scheme as a practical language. It's for learning about "the structure and interpretation of computer programs", which is not the same thing as "writing useful computer programs".
  - tmtvl 3y ago
    SICP is a great, wonderful book. But it's even better when balanced with Seibel's Practical Common Lisp. It's like the Dean Martin to SICP's Jerry Lewis.
- horeszko 3y ago
  > I think im going to have to make an intentional effort to find a lisp job next time. Does anyone have any tips on where to find a lisp job?
  - reikonomusha 3y ago
    Lisp jobs are sometimes advertised in Who's Hiring threads, Reddit's r/lisp, etc. There's a Lisp job advertised on Reddit [1,2] right now even. Another good source is to check out the companies in [3] and see if they have any openings on their website (or cold-emailing). [1] https://www.reddit.com/r/ProgrammingLanguages/s/AZmouaoARl https://www.reddit.com/r/ProgrammingLanguages/s/AZmouaoARl [2] https://jobs.lever.co/dodmg/af802f7f-4e44-4457-9e49-14bc47bd8b31 https://jobs.lever.co/dodmg/af802f7f-4e44-4457-9e49-14bc47bd... [3] https://github.com/azzamsa/awesome-lisp-companies https://github.com/azzamsa/awesome-lisp-companies
  - john-shaffer 3y ago
    https://jobs.braveclojure.com/ https://jobs.braveclojure.com/
cmrdporcupine 3y ago
While I agree with the author that there's something about Rust (my day-job lang & goto personal lang these days) that just lacks... elegance... I've also never found the Lisp (and many other FPs) emphasis on recursion all that compelling. Aesthetically or computationally. I find the programs written this way hard to reason about and read. Personally. For me, the underutilized gold mine feels like logic languages (Prolog et al.) Though I know recursion is used there a lot, too.
- epgui 3y ago
  It’s like anything else, you get used to it just as easily.
  - cmrdporcupine 3y ago
    I take it as: mathematicians like recursion, so they put some recursion in your recursion...
    - epgui 3y ago
      There's a strong argument to be made that mathematicians tend to build the simplest abstractions conceptually, especially in comparison to computer scientists. Personally, when I stumble upon some maths, I pay close attention. It has paid off.
  - whartung 3y ago
    ...or don't use it. Scheme likes to tout it because of tail call optimization. Common Lisp can do it, but doesn't really shove it as a first principle of "Common Lisping" (and CL does not dictate tail call optimization). I don't use it (save when it's necessary). I just iterate using the supplied iterators (do, dolist, loop, whatever). I can't speak to other functional languages.
    - ska 3y ago
      CL's iteration primitives are more capable that those provided by most languages, which often makes for a very clean approach. Recursion is sometimes the easiest way to reason about a problem though, so it's nice to have decent support and TCO.
whartung 3y ago
Regarding Guile, and, mind, I'm on macOS, but I found it not easy to get started with. I'm looking for a compiled Scheme or Lisp. By that I mean, I want "prog.ext" to create the executable "prog". I want this because I want to make some command line utilities, and I would like the actual code compiled (vs some p-code bundled with an interpreter). I had tried to get started with Guile, as all of its packages looked attractive, but was stymied. It's been awhile, so I can't express details. It had to do with a combination of things like packages, modules, and I know I ran into a version issue (I think I wasn't running the latest version from my package manager, so it didn't have something in the documentation). Anyway, for such an extensive system, I found it surprisingly frustrating. I've been trying Gambit, which seems like it would be a really nice fit, but it's fighting with my Mac, because macOS doesn't put stuff in /usr/include (wchar.h in this case), and all of my efforts to fix that have failed (save I have not tried upgrading to whatever the latest macOS is). Maybe I can try ECL, maybe that will work. But, anyway, Guile, while attractive, just surprised me at how I wasn't really able to make it work for me enough to make me look elsewhere.
- 7thaccount 3y ago
  What about chicken scheme or chez scheme?
  - nerdponx 3y ago
    Chicken kind of felt like a dying ecosystem when I tried it, and it's also not very fast. The standard library itself is kind of limited, so if I couldn't find an egg for something I wanted to do, I felt very stuck. Chez is good because it's supported by Akku, but I'm not sure if it will ever support R7RS. It does have a really nice FFI though, and the docs are very good.
    - hajile 3y ago
      R7RS isn't worth supporting right now. R5RS is too small for real work unless you add tons of SRFIs, so they created R6RS for people who want to get stuff done. But the the R5RS people got ticked off because "its too big". R7RS was supposed to be a compromise with a tiny R7RS-small, but later adding most of the R6RS features with R7RS-large. It's now been a decade and R7RS-large seems to be completely dead.
huqedato 3y ago
After reading the article (BTW a good one), one thing intrigues me: why the author left Haskell for Lisp(s) ?
- deleted 3y ago
  [deleted]
- behnamoh 3y ago
  At some point you realize Haskell and/or its ecosystem keeps breaking things too much and you move on.
  - ParetoOptimal 3y ago
    I love Haskell and know there are efforts to fix this, but I find it hard to disagree.
    - tome 3y ago
      Not just efforts, but both GHC HQ and the Core Libraries Committee making stability a top priority. Expect casual breaking changes in the Haskell world to become a thing of the past, in very short order (in fact the most recent release of GHC (9.8) had very few breaking changes).
      - ParetoOptimal 3y ago
        I've been out of the loop for a bit, so that's great news to hear!
- kccqzy 3y ago
  I did the same and I treat Haskell as a rite of passage. At this point it's cliche to say that Haskell makes you a better programmer in other languages, but it's true. You really immerse yourself in Haskell for a few years, and you become a better programmer even when you aren't writing Haskell. I'm referring to universal things like "making invalid states unrepresentable" or "preferring to parse than to validate" or "functional core imperative shell" that can work well and lead to cleaner code in any language. (The actual reason I left Haskell was because I switched my employer. Choosing an employer is IMO a bit more important than choosing the language to code in.)
sph 3y ago
I believe this article is selling Guile short. I think it is the most pragmatic Lisp around. I love Lisp's ideas but I find all modern implementations terrible. I would go so far as to say Lisp aren't popular because what we have today is not good enough. Common Lisp is the most advanced one, but it is like C++: it does everything and the kitchen sink. Design by committee. You want functional programming AND imperative? You want documentation that reads like an IBM mainframe manual? You want a standard library with names as cryptic as ANSI C? We got all that. But frankly, it is the one to build serious production software with. Racket is the best for a beginner, but it keeps having that academic, "we made it for the kids" feel of being easy to understand but not very pragmatic for a seasoned programmer. And it is one of a kind, so a good Racket developer might never know Lisp itself. Schemes are fun, but the only standard everyone agrees to relegates to small embeddable languages almost like Lua. They are not made to live on their own almost. Since the standard is very simple, there are half a million implementations that are not very practical. But of these, there is Guile, which has a pretty decent documentation AND standard library (even a built in PEG parser!), actively developed and it is my opinion that is it very underrated and the only Lisp worth my time these days. To be honest, the most popular Lisp in the world is Emacs Lisp bar none. How's that Guile port coming along anyway?
- velcrovan 3y ago
  > Racket is the best for a beginner, but it keeps having that academic, "we made it for the kids" feel of being easy to understand but not very pragmatic for a seasoned programmer. And it is one of a kind, so a good Racket developer might never know Lisp itself. As someone trying to write definitively about cold hard reasons Racket remains in relative obscurity, I would be interested to know specifics you can provide for this view. Is it just academia vibes? Or are there specific aspects of Racket that in your view repel “seasoned programmers”? I notice you praise Guile for having decent documentation and standard library. How do you believe Racket’s documentation and standard library compare to Guile’s?
  - sph 3y ago
    Sorry, I don't have anything more concrete than "general vibes." Like, there's thousands of libraries and modules in Racket, sometimes competing with each other, that feel like they have been developed for a school project and kept around. And it is no secret that Matthew Flatt, one of the lead developers, is actually a professor at Utah University. In my experience, it is pretty easy to tell when a language and ecosystem is developed in academia, or developed by software engineers by trade. They have two very different goals and approaches to the same problem. The former might focus on educational purpose for newbies, the latter on shipping production-ready software for professionals. (In my humble opinion, this is one of the reasons Smalltalk never went very far in the real world. Too much focus on the educational aspect of it.)
nerdponx 3y ago
I feel like I say this a lot, but if you like Guile you should really check out Gauche. It has more "batteries" included than Python, several of the "alien technology" features that people expect from Common Lisp, and good documentation to help you navigate it all. Scheme itself has a reputation for being very "minimal", and R7RS itself is great, but it also shines as a base for bigger languages like Guile and Gauche. Clojure is pretty cool too though. I love that it really has a life of its own as a "third" dialect to complement Common Lisp and Scheme. Can't speak for Elisp, not enough room in my brain to learn Emacs after years of Vim. If you like Python, I'd also like to shout out Hy (https://hylang.org/ https://hylang.org/), which compiles to Python, and like Fennel is to Lua, it does a reasonably good job of bolting on s-expressions while preserving the semantics of the underlying language. It's definitely a "bigger" language than Fennel, but Python is similarly "bigger" than Lua. Hy has also developed its own distinct feel, especially when you take into account the first-party Hyrule utility library (https://hyrule.readthedocs.io/en/master/index.html https://hyrule.readthedocs.io/en/master/index.html) which provides a lot of very interesting macros, deriving lots of useful ideas from both Common Lisp and Clojure.
- rcarmo 3y ago
  I've been using Hy on and off. Off because it broke "let" at one point and I had a few critical things (like my entire site engine) written in it, and on because I like it a lot. But it's not a great LISP for performance (Fennel can run rings around it when using luajit), and I wish they shipped a 1.0 (I cringe every time I read the changelog for a release and check the "breaking changes" part, which is always... beefy).
  - Zambyte 3y ago
    > Off because it broke "let" at one point It wouldn't be very difficult to provide an implementation of `let` that behaves how you would like though, so there is that at least.
- drekipus 3y ago
  I tried Hy for 2023 AoC and loved it, but it broke after day 8 because the solution I wrote crashed after 40mins. but re writing the same logic in python took 2 mins to complete. Hy is nice, but "compiling to python" isn't
FrustratedMonky 3y ago
Not even an honorable mention for F#? Why does Haskell get a mention, since it is also just another ML based language. Seems like F# is trying to solve the same problems as LISP. Lot of same features. Edit: Did like article. Is serious question LISP-> Clojure-> F#. There are similarities. Edit2: Guess it is a stretch. But not insultingly so. Have seen articles comparing Lisp macros to F# Type Providers.
- nerdponx 3y ago
  F# isn't a Lisp, so I think it's fair to consider it out of scope. I think the only reason Haskell got mentioned is because the author has experience with it and was using it as a personal point of reference.
charlotte-fyi 3y ago
Don't really get the criticism of Clojure for being hosted on the JVM, particularly relative to its status as a "productive" Lisp. Like oh, you get access to one of the biggest and most mature library ecosystems out there as well as best in class operational tooling? Obviously there are use cases where the JVM doesn't fit and all things being equal I prefer shipping statically linked binaries too, but the JVM still feels like an obvious "pro" here.
- askonomm 3y ago
  And quite a lot of people actually do ship statically linked binaries with Clojure, using GraalVM. Clojure LSP server for example is distributed as a static binary.
  - colingw 3y ago
    Yes, although that solution can't yet be said to be "push button". My impression is that there are a decent amount of people who want non-JVM, native Clojure. Hence efforts like Janet and Jank.
- ska 3y ago
  I think hosted is almost tautologically a mixed bag - you get access to the host (both +ves and -ves) but you also introduce a layer and some invariable friction.
- whateveracct 3y ago
  The JVM precludes general tail-call elimination though.
  - thmorriss 3y ago
    the clojure loop construct is often cleaner than code written to be tail recursive
    - uyrifo 3y ago
      And often faster: https://medium.com/hackernoon/faster-clojure-reduce-57a104448ea4 https://medium.com/hackernoon/faster-clojure-reduce-57a10444... Yet it’s always noted as code smell associated with “inexperienced candidates” in interviews. For that matter, first and last too: https://medium.com/hackernoon/faster-clojure-reduce-57a104448ea4 https://medium.com/hackernoon/faster-clojure-reduce-57a10444... The amount of paired programmers suggesting changing nths to firsts and lasts is demoralizing.
im_down_w_otp 3y ago
> Why do print-line-debugging to find out what's happening at a location in code when you can just be inside your program and inspect everything live as it's running? Yes, that's because print-effing one's way to understanding is also among the most crude methods of debugging. An excellent alternative to doing that is to use an actual debugger. That will also allow you to be "inside your program".
- foobarian 3y ago
  How do you "get inside your program" on a locked down production box? Watched by SOX auditors like hawks? Any answer offered needs to be comparably easy to checking in an extra printf and letting ci/cd deploy it.
  - im_down_w_otp 3y ago
    I used to be an Erlang engineer, and you would have needed very explicit security controls around being able to attach to an Erlang cluster to get the "insider your program" experience. This was in FinTech, so I'm familiar with the constraint. I would imagine you'd need the same thing for accessing the runtime of any production deployed application(s) in such an unfettered manner. Erlang, Lisp, C, or other?
- ctrw 3y ago
  The difference with lisps is that the debugger is always part of the runtime and you have full access to all the languages capabilities while inside. I've yet to see a C debugger which does more than a fancy version of printf. Imagine being able to compile functions on the go while still running your main program with all the state saved.
galaxyLogic 3y ago
Includes this great comment by Simon Peyton-Jones in support of incremental typing: "I think to try to specify all that a program should do, you get specifications that are themselves so complicated that you're not longer confident that they say what you intended."
- kqr 3y ago
  I think, though, that when reading this quote it should be taken in the context of e.g. Haskell exhibiting incremental typing – because it doesn't try to specify everything. It can't.
  - graemep 3y ago
    Does not seem to fit with the previous bit of the quote: "dynamic languages are still interesting and important. There are programs you can write which can't be typed by a particular type system but which nevertheless don't "go wrong" at runtime, which is the gold standard - don't segfault, don't add integers to characters. They're just fine."
LAC-Tech 3y ago
The big thing I took away from LISP is that having everything be prefix solves a lot of problems. Seriously, the arguments people have in languages like Zig about whether to have "operator overloading" just seem a bit silly. Operators are just functions, it's very silly to make them syntastically different. But I never got much into REPL driven development. Probably because I just couldn't wrap my head around emacs.
- mpweiher 3y ago
  Smalltalk solves that by having everything be infix. With fewer parentheses. ¯\_(ツ)_/¯
  - LAC-Tech 3y ago
    Yeah that's another approach to it, one I think could definitely be borrowed (though I wouldn't do it exactly how smalltalk did). And then of course there's the "concatenative" family where everything is postfix.
    - mpweiher 3y ago
      How would you make it different? One change that I made in ObjS is that I added the pipe so you don't need to parenthesize chained keyword messages. ((receiver msg1:arg1) chained1:arg2) chained2:arg3 vs. receiver msg1:arg1 | chained1:arg2 | chained2:arg3 Having colon keywords does get in the way a little, as I also need them for schemes (URIs are part of the language) and I would also like them for type-specifiers, as type-after really seems the better way. I can probably pull all that off syntactically, not sure about aesthetically.
      - LAC-Tech 3y ago
        I've actually thought about this a lot! 1. no more keyword parameters 2. every message has exactly one argument, which may be a tuple. 3. "obj.msg" becomes short hand for "obj msg ()" 4. if a message expects 2 element tuple and you give it a one element one.. it returns a closure that expects the rest of the arguments. ie "add1 = 1.+"
beepbooptheory 3y ago
Does anyone know how to get a lisp job? Or have any experiences to share? Its been a dream for a while for me, and I think I am possibly ready (at least with common lisp, have started doing more clojure recently though). It just seems so impenetrable to me, I don't even know how to begin to search for it.
- colingw 3y ago
  The Clojure Slack has active channels for both job posters and job seekers.
- neilv 3y ago
  I got mine by contributing to some niche communities, and developing open source packages. A great foot in the door is when someone is using and likes some software that you have written. If they know it came from you, and can easily find out you're available when they're ready to hire. Of course, that's not an option for everyone -- some people simply haven't yet had the free time or paid opportunity to make open source -- and we should try not penalize people for that. But it's much better positive signal than a job-seeker approach of "I spent person-months memorizing Leetcode medium-difficulty answers, and rehearsing whiteboard interview stage presence like a rockstar." Beware that good Lisp-family jobs are rare, and don't tend to be highest-paying. Outside of relative pay within categories like enterprise Java-shop programmer. (Aside: From a hiring perspective, using some beloved niche language with few jobs available is also a great way to pick up mythical "10x" hires, and retain them for a long time. :) But, more seriously, it's ethical to make sure that prospective hires for unpopular niche keywords realize what they're getting into, in the current software job environment that often assumes fad-following & job-hopping strategy, and is skeptical/derisive of people whose resumes don't look like that.)
  - colingw 3y ago
    If the Stackoverflow Dev Survey is to be believed, CL and Clojure devs actually make decent money.
    - 3y ago
dogprez 3y ago
> [Fennel] also lacks Common Lisp's debuggability, given that it sits entirely within Lua's runtime. I'm not sure exactly what feature the OP was referring to. It sounds like they don't think you can get a REPL for an executing Fennel process? You can. If you are only using it for AOT Fennel->Lua you can't, you have to include its runtime.
- schemescape 3y ago
  Last I checked, Lua was “bring your own debugger”. Assuming that hasn’t changed, a REPL is nice, but you can’t pause and inspect anything by default.
  - emidln 3y ago
    Why can't you just put the equivalent of `(repl)` wherever you want to debug and drop into your REPL?
    - schemescape 3y ago
      Short answer: I don’t know. That sounds like a good idea, but how would that access local variables in the caller (to inspect state)? I remember the Lua C API exposes a lot of information, but I didn’t think it was accessible from scripts. Of course, it was a long time ago and I could have easily missed something at the time. Happy to be corrected! Edit: you might also run into difficulties trying to redefine non-global functions to add the call to “repl”.
  - dogprez 3y ago
    Fennel has a form `assert-repl` which will drop into the REPL wherever, if the condition fails. For writing games you can launch the REPL in the game loop if a keyboard button is pressed. But what you can't do, that I know of, is interrupt arbitrary execution and get a Fennel REPL. You'd probably need a lua debugger of some sort for that. I'm not that familiar with that though.
  - colingw 3y ago
    To be the most fair, Fennel 1.4 recently released with an `assert-repl` form that opens a repl when some assertion fails, in which you can inspect local variables, etc. That's getting closer to CL. https://git.sr.ht/~technomancy/fennel/tree/1.4.0/item/changelog.md#new-forms https://git.sr.ht/~technomancy/fennel/tree/1.4.0/item/change...
JonChesterfield 3y ago
I really like Kernel. John Shutt's thesis language. It throws away a bunch of incidental complexity from scheme, most notably the minor disaster of hygienic macros. It follows a minor tangent on cyclic data which I'm not convinced matters very much. Implementations are a bit DIY. An interesting play would be to implement rsr7 scheme in kernel, semi-metacircular fashion.
- spindle 3y ago
  Does picolisp scratch that itch for you?
  - mst 3y ago
    Kernel is operative rather than applicative - i.e. fexpr-based - and I don't think you can get something quite the same without it. (arguably a macro is really just a limited fexpr that's executed and the results inlined at compile time, though I mean that as 'morally equivalent' rather than making a technical claim since I haven't attempted to implement that in my fexpr based interpreters yet)
    - JonChesterfield 3y ago
      Did you go with first class environments? If so defmacro builds a fexpr with an an extra eval in the dynamic environment plus a flag to tell the compiler it must be inlined (and that various other things should be reported as semantic errors). You can get somewhat close to fexpr with lazy evaluation but it turns out that's not the same thing either. Taking the arguments apart and building different things out of them is a superset of stashing it somewhere to evaluate later. (lambda (x) ...) ; evaluate the argument in the caller, bind it to the name x (fexpr (x) ...) ; bind the argument to the name x (normal (x) ...) ; make a thunk out of the argument and the environment (macro (x) ...) ; bind the argument to x then do the force inline & extra eval on call It's interesting that macros are the one with a bunch of extra work to do after the call whereas fexpr does the bare minimum of adding stuff to the lexical environment. Lambda maps eval across the arguments, normal maps make-thunk across the arguments.
  - 3y ago
dannyobrien 3y ago
As an amateur coder, this really matches my journey, though with a slightly different ordering: after the usual BASIC/Perl/Python homebase, a few years really expanding my mind in Haskell-land, followed by a "well, I've bounced off Lisp in the past, let's see what I make of it now", then having real joy in writing Clojure, exploring Guile and Scheme, and then coming finally to appreciate Common Lisp, warts and all. I still "see the parentheses", and I wish there was a way (outside Coalton) to integrate the security that a strong typechecker can provide, but I really do enjoy working in the Lisp ecosystems now, and feel like I understand Lispers excitement at what they have.
- Y_Y 3y ago
  > to integrate the security that a strong typechecker can provide Have you checked out typed-racket? That's a reasonably nice way to get strong typing by tackling type correctness contracts on top of otherwise standard racket. There's also Alexis King's marvellous Hackett, which seems to be finished for now, but was positive proof that you can have - and eat - all the curry-flavoured cake you want while staying in scheme.
- medo-bear 3y ago
  > I wish there was a way (outside Coalton) to integrate the security that a strong typechecker can provide, Common lisp is optionally strongly typed. SBCL has extensive type checking facilities. Coalton is statically typed. Security does not imply strong (or static) typing, and strong typing definitely does not imply security (thinking your code is secure just because you used strong or static typing is silly). In fact code complexity that static typing introduces can have detrimental effects to overall security. Helpful starting point on state of type checking in common lisp: https://lispcookbook.github.io/cl-cookbook/type.html https://lispcookbook.github.io/cl-cookbook/type.html
  - dannyobrien 3y ago
    Just to be clearer, I meant security as in confidence in the code running correctly, rather than defended against vulnerabilities.
thetwentyone 3y ago
Also an interesting Lisp for it’s size is femtolisp from one of the co-creators of Julia: https://github.com/JeffBezanson/femtolisp https://github.com/JeffBezanson/femtolisp
- rcarmo 3y ago
  I have a femtolisp quote at the top of my LISP resources page: https://taoofmac.com/space/dev/lisp https://taoofmac.com/space/dev/lisp
Jeaye 3y ago
I appreciate the shout out to jank, the native Clojure dialect on LLVM with C++ interop. :) Lisp has such a colorful history and Clojure, in my opinion, made it even more accessible and practical. People complain about Clojure's error messages, but, coming from C++, anything that doesn't corrupt memory and segfault is golden.
- mark_l_watson 3y ago
  I also liked that reference since I had not heard of Jank before. It is a work in progress so I just added a calendar entry for 9 months from now to check it out. https://jank-lang.org/ https://jank-lang.org/
dartharva 3y ago
Article topic notwithstanding, I am curious in the design choice of moving the "Table of Contents" to the right side of the text and links for other blog entries to the left. Aren't the sides conventionally swapped as with default Blogspot/Wordpress blog templates? Also, what was the objective behind shaping the text as a Q&A-style interview when it's only a personal blog?
- colingw 3y ago
  The questions were originally posed by a Doom Emacs community member, so I answered them as-is. The site is designs as it is because I'm not a frontend guy xD
agambrahma 3y ago
Sounds like he'd like Coalton
- colingw 3y ago
  CL-embedded langs like Coalton and April are mentioned in the article.
hiAndrewQuinn 3y ago
Scheme has a special place in my heart after working through SICP as a late high schooler. I probably haven't actively written anything in Scheme in a decade, but it later inspired me to learn Haskell to a decent level of depth, just to see what the "other" functional languages feel like. So much the same, yet so much different.
- eggdaft 3y ago
  Scheme was taught in my first year of CS. One thing I noticed is that those who hadn’t coded through their teenage years found scheme much easier to learn than other languages we were being taught in the first year. I think that was because scheme felt more like mathematics and everyone had done A Level maths (in the UK), many to an advanced level. Immutability and functions make a lot more sense than weird variables that keep changing and - what the heck are classes? We just unlearn this mathematical thinking when we start hacking Python etc.
codr7 3y ago
I spent a lot of time unsuccessfully bending Common Lisp into something I could love. It's still one of my favorite problem solving languages, but far from trivial to fix from the inside. Tried writing my own readers that compile to Common Lisp. Then I ended up on a side track to write my own interpreters; mostly Forths at first, then gradually more Lisp-like and practical creations. My latest attempt may be found here: https://github.com/codr7/jalang https://github.com/codr7/jalang
matheusmoreira 3y ago
> How can newcomers get the most out of learning Lisp? Make your own lisp. I chose that route even though I had never written lisp code before. Finally understood its elegance.
hickelpickle 3y ago
I've had a really pleasant experience with Kawa scheme recently, which is a scheme that runs on the JVM, compiles to bytecode and provides easy interop with Java. I needed a scripting language for a project, and it ended up developing into me implementing a repl like admin console that allows me to administer events and query data/state (project is a game back-end so everything was already event-based with thread-safe dispatching and an entity system accessed via a singleton). Being able to inter-opt with java is great, as I can wrap scheme procedures in functional interfaces and use them as drop in replacements for java functions, as my event system was already based on predicates and consumers for event handling. I've worked through some of the SICP and have always wanted to get more into scheme/lisp, but the barrier of starting a full project in it always kept me from getting much hands on experience. Its been quite enlightening actually getting to work with a form of REPL driven development and getting my hands dirty with coding some scheme, having access to the JVM means I can do practically anything with it, with out needing to bootstrap tons of code, and using it in a project with a large scope lets me solve real-world problems with it vs just toying around which has been what most of my scheme/lisp experience was before.
- SeanLuke 3y ago
  To me, Kawa is easily the best Lisp that targets the JVM. And I say that hating Scheme. I'm a Common Lisp guy. Because it is really fast, well designed, and mostly Scheme compliant (no call/cc of course). And it has first in class interoperability with Java and the JVM. After Kawa, I'd pick ABCL. It's not as fast as Kawa and its interoperability isn't nearly as good, but it is effectively a 100% standards-compliant Common Lisp: what more could you ask for? Only last would I pick Clojure. It's designed to feel "sort of immutable" but this is impossible if you want any degree of interoperability with the JVM. As a result, you wind up with lots of Refs and other fun stuff which in my experience make Clojure much slower than Kawa and ABCL. It's always slower by quite a lot, but in fact I've had a few extreme situations where Clojure would wind up being __literally__ three orders of magnitude slower.
MarkG509 3y ago
Over 40 yrs ago, I had a programming assignment in college that I wrote in Lisp. My Prof, a non-Lisp-er, asked me to rewrite it, expecting C or Pascal. But I took him through my Lisp code, and was able to argue for the 'A' on that assignment. I might have created a Lisp-er in the process.
onetimeuse92304 3y ago
> What's your current mental model of an "ideal Lisp"? > It would be something like a fusion of Clojure and Common Lisp, (...) Mine would be, too. Unfortunately, that's not possible. Clojure is one of those few languages actually designed by somebody who knows what they are doing. Clojure's limitations come from the limitations of the platform it is running on and certain design criteria (interoperability) that were necessary for its success.
- fulafel 3y ago
  There could be a Clojure implementation hosted on a CL. In fact someone seems to have started on one: https://github.com/ruricolist/cloture https://github.com/ruricolist/cloture
- gmfawcett 3y ago
  > Clojure is one of those few languages actually designed by somebody who knows what they are doing Not saying you're wrong. But look at the authors of Scheme and the CL spec... Rich may have seen far, but he was standing on the shoulders of giants.
a2code 3y ago
What makes Lisp (Scheme) great (for me) is that functions are first class citizens, the prefix syntax is consistent, tail call recursion optimization makes it runnable, and metaprogramming allows for powerful abstractions. What I would also emphasize is that using lambda expressions makes you wonder when to define something and when to omit the definition. Lisp is simple to learn but difficult to master. What I would like to do is to use Lisp to solve complex problems. The problem is that abstractions are not often efficient. For example, consider computing the calculus product rule. An S-expression abstracts the function: (lambda (u v) (* u v). With metaprogramming, this becomes a new S-expression (lambda (u v) (+ (* (d u) v) (* u (d v)))), where (d u) and (d v) further compute the derivative. To optimize this further, you need implementation dependent code and replace abstractions of S-expressions with native machine code. This is where I feel that the troubles with Lisp start.
- hayley-patton 3y ago
  > To optimize this further, you need implementation dependent code and replace abstractions of S-expressions with native machine code This can be done by a program called a compiler. There are many compilers for Lisp. (In other words, the same argument applies to every language ever which doesn't exactly correspond to machine code.)
  - a2code 3y ago
    And yet to extend Python, for example, you write code once. To extend Lisp, you have to extend a multiplicity of implementations you find relevant.
- JonChesterfield 3y ago
  There are properly good lisp compilers. The baseline is good and they're extensible - you can teach them things about your domain. SBCL for lisp. Maybe racket for scheme.
mark_l_watson 3y ago
Nice article! The author captured many of my own feelings of Clojure compared to Common Lisp. I have been happily using Lisp languages since the 1970s and CL since 1982. I retired several months ago but I still spend time coding for my own research projects and for my book examples. I have been torn between going all in using just one of Racket or Common Lisp. Racket is a fun environment and I like the community but I have so much history with CL. I don’t know if I will choose just one, but it would be a good idea! The article didn’t mention the Hy language that compiles to Python AST. For a while I was very enthusiastic about Hy and I wrote a book about it. It used to have a “let” macro that mapped Lisp variable scoping to the jankyness of Python but that support has gone away and I feel like using “setv” and just accepting Python like scoping is a bridge too far for me. The philosophy behind Hy is great, but it is not my philosophy. I love the Clojure language (and I donated money to the project at the beginning) but I only use Clojure when I am being paid to use it for specific projects. The Bork Dude’s Babashka language is a fast loading Clojure, and I had a lot of fun for a while setting up a nice dev environment and using it for all recreational programming for a week. Babashka is worth a serious look.
- kagevf 3y ago
  For racket do you use Dr racket or emacs?
mustermannBB 3y ago
Biggest issue with most Lisps is, IMHO, that you need emacs for a great developer experiences when it comes to tools. And emacs is not for everyone.
- colingw 3y ago
  Not so for Clojure, there's great integration for both the Vim family and VSCode.
  - edanm 3y ago
    Seconding this, Clojure was my introduction to Lisps, and I used only VSCode with it. One of the greatest development environments I've ever used, and about half the fun of learning Clojure for me. (The other half being learning the language itself, of course!)
masfoobar 3y ago
I have toyed with various lisps and schemes over the years. Eventually - since around 2012 (ish) my focus has been with GNU Guile. Which won me over originally was the documentation, and the C functions following the same format as my own. Being able to add Guile into my game did really speed up my time "hacking" 3D scenes and features, before converting them over to C code. Then started to use GNU Guile for building a personal website, and other toy projects on my server. While I don't use GNU Guile for much these days, I certainly think it should be given, atleast, half the reputation Python gets today. I think the problem with GNU Guile is that (last time I checked) was that it was very Linux focused. Always had trouble with it on Windows. I dont own a Mac but assume to be the same there as well. Of course, I have GNU Guile on my Windows machine thanks to WSL2.

358 points by medo-bear 3y ago

after decades of programming, lisp has always been that thing that intrigues me endlessly, but I haven't had a chance to actually wield it myself. but so many people whose opinions I respect love lisps, and not just for a little while. Clojure especially. Other ideas like datomic and xtdb are also high on my list of things I need to experience. I think im going to have to make an intentional effort to find a lisp job next time.

epgui 3y ago
Doing Clojure at CircleCI, a few years ago, redefined who I was as an engineer… FWIW. It’s an incredible language. Today I work with python (sigh) and every day I long for Clojure.
- behnamoh 3y ago
  I keep hearing sentiments like this but then I wonder, if Clojure or <another awesome Lisp> is so much better than Python <or some other mainstream language>, then why are we still writing in those languages? If it's because of libraries, then the question is: Why do people write libraries for these languages and not the Lisp ones?
  - galaxyLogic 3y ago
    Because of habit. There is always a cost in trying to learn something new, to the level you are on with some other language and it's tooling and libraries. Programmers who program in some language for a few years realize they are still learning more about it, all the time. Therefore they know if they switched to another language it would also take them a few years to attain the same level of mastery. And then there is similar inertia with an organization that has lots of code in some specific language already.
    - colingw 3y ago
      Yes, it's more than just about the language itself, as I describe here: https://www.fosskers.ca/en/blog/software-dev-langs https://www.fosskers.ca/en/blog/software-dev-langs For some people, community signals are very important. Massive conferences or raw number of libraries, etc., indicate some inner quality of that language's ecosystem that they value.
      - galaxyLogic 3y ago
        Nice link, holistic viewpoint!
  - Zambyte 3y ago
    Social forces and economics. Lisps were winning in academia for a while. Unix started winning in the engineering world before Lisp systems really got their feet under them. Engineers made a lot of money, and academia shifted focus to the systems that were making money. Now everyone programs for Unix instead of Lisp.
  - epgui 3y ago
    For the same reason people can't change their well-established habits and opinions, particularly those that have network effects. Language popularity has little to do with how well languages are designed or how simple they actually are. Most popular languages are popular for historical reasons.
  - tikhonj 3y ago
    At the end of the day, things get popular through social processes, so it's far more a matter of social factors—some of which are practically random—than any intrinsic qualities of the thing itself.
  - deleted 3y ago
    [deleted]
  - ParetoOptimal 3y ago
    I can say at least that Haskell is this way for me.
    - epgui 3y ago
      I think you'd rewire your brain "equally well" with either Haskell or Clojure. I prefer Haskell's type system, but Clojure has better syntax IMO.
  - crote 3y ago
    Because it's weird enough to be off-putting, and it doesn't solve a real-world problem. If you look at the arguments in favor of Lisp, they'll often boil down to it being "beautiful", "elegant", "flexible", or even "magical". It's a very minimal language which allows you to do absolutely anything - a lot of which would be an absolute nightmare in most other languages. You could implement just about any programming paradigm in Lisp if you want to. I believe this makes it very appealing to computer scientists, or other people with a more mathematical background. However, this flexibility is also a massive footgun: if you're not careful your junior developer might end up reinventing the wheel a dozen times, and writing completely unmaintainable code in the process. On the other hand, most other programming languages look kind-of the same. They are all quite opinionated about how stuff is supposed to work, with a lot of hardware details leaking into the language. However, they are very easy to learn: most of it is just "do a bunch of operations in succession" taken to the extreme. Anyone who knows C# will be able to pick up a basic understanding of C, Python, or JavaScript well within a day, and a lot of people new to programming will be able to write not-completely-terrible code within a month or two when given the right guidance. They don't need to know about all the abstractions and technical details to be a functioning member of your team. When you're running a business, you don't care about any of that beauty or flexibility. You want code which is quick and easy to write, trivial to read, and understandable by even the worst programmer in your company. In practice that means in your comparison you'll be choosing Python over Lisp. Heck, Go was developed entirely around this principle, cutting out as many language features as possible. And because all the other companies are making the same choice there will also be way more libraries for Python, making the gap even larger. So yeah, in a stroke of irony Lisp isn't more popular because it is better.
    - evdubs 3y ago
      > Because it's weird enough to be off-putting, and it doesn't solve a real-world problem. Nonsense. Quoth Wikipedia, "Lisp pioneered many ideas in computer science, including tree data structures, automatic storage management, dynamic typing, conditionals, higher-order functions, recursion, the self-hosting compiler, and the read–eval–print loop." These are all solutions to real world problems. So many languages borrow features that were originally developed in Lisp. > However, this flexibility is also a massive footgun: if you're not careful your junior developer might end up reinventing the wheel a dozen times, and writing completely unmaintainable code in the process. Plenty of code written in Lisp looks just like your Python, Ruby, JavaScript, Java, et al programs where you're defining structures or classes, writing and calling functions, importing useful libraries, etc. Plenty of this Lisp code is just as maintainable as the non-S-expression code. > Anyone who knows C# will be able to pick up a basic understanding of C, Python, or JavaScript well within a day Same with Lisp. It's just: (function arg1 arg2) Instead of function(arg1, arg2) > You want code which is quick and easy to write, trivial to read, and understandable by even the worst programmer in your company. There is plenty of "lowest common denominator" code like this written in Lisp. Much Lisp code is not buried under inscrutable macros, just like not all Java code is buried under layers of inscrutable classes.
  - __MatrixMan__ 3y ago
    Most Python users aren't software engineers. They're students, scientists, business analysts... We're lucky that we were able to drag them away from Excel. Asking them to learn yet another programming language might be a bit much. And if they did, it wouldn't probably be a lisp (it would probably be among: C, Javascript, Julia, Go, Nim). I want to move on from Python, but there are so many more people that I can help if I stay.
    - tugberkk 3y ago
      I have the same problem. It is a good language to teach to non-cs majors. If you want to build something out of the box, use Python. However, GPT is coming and maybe we won't even use Python anymore for simpler tasks.
  - kazinator 3y ago
    > Why do people write libraries for these languages and not the Lisp ones? 1. They want their names to be widely recognized, so they find a popular bandwagon to hop onto. 2. Raw numbers? More people using Python means more people trying to make libraries for Python, means more libraries remaining in the race after you eliminate the crap from people who don't know how to write libraries. Note that Python is, by now, an old language. It wasn't instantly popular, and you wouldn't have predicted it. In, say, 1999, you had to be some GNU/Linux person to even know what Python is. It was far from obvious that, of all things, it would get so popular. That Eric Raymond article in the Linux Journal around that time probably gave it a bit of a boost. Python definitely rode on the coattails of increasing GNU/Linux popularity, too. More people using Linux started asking questions how to script this and that, and going "gack!" at shell or perl programming. It seems Python might appeal to survivors of VisualBasic shifting gears into GNU/Linux stuff.
  - roenxi 3y ago
    I don't think anyone is saying Clojure is better than Python in the abstract. Clojure has a different style from Python and that style can be more fun and is better for some specific tasks like application programming and anything that wants to use multiple CPU cores. Tends to have better long term prospects too, old Python code doesn't work in my experience but things on the JVM have cockroach powers. As for why things are and aren't popular, who knows? It is quite possible that people just don't like the look of the parenthesis, or there are a couple of key libraries that aren't good but nobody vocal has put there finger on which ones. The error messaging isn't quite up to a standard that people want to deal with. Or maybe popularity is really just about pure random chance, at most 4 languages get to have >20% market share, by definition.
    - epgui 3y ago
      > I don't think anyone is saying Clojure is better than Python in the abstract Actually, I will make that claim without hesitation.
  - crq-yml 3y ago
    Lisps are "wizard" languages: the runtime semantic is kept close to the syntax, which also means that you can rapidly extend the syntax to solve a problem. This quality is true of Forth as well, and shares some energy with APL and its "one symbol for one behavior" flavor. With respect to their metaprogramming, the syntactical approach hands you a great foot-gun in that you can design syntax that is very confusing and specific to your project, which nobody else will be able to ramp up on. But Algols, including Python, are "bureaucrat" languages: rather than condensing the syntax to be the exact specification of the program, they define a right way to form the expression, and then the little man inside the compiler rubber stamps it when you press the run button. In other words, they favor defining a semantics and then adding a syntax around that, which means that they need more syntax, it's harder to explain the behavior of a syntactical construction, and it's harder to extend to have new syntax. But by being consistent in a certain form-filling way, they enable a team to collaborate and hand off relatively more code. IMHO, a perfectly reasonable approach I'm exploring now for personal work is to have a Lisp(or something that comes close enough in size, dynamic behavior, and convenience, like Lua) targeting a Forth. The Forth is there to be a stack machine with a REPL. You can extend the Forth upwards a little bit because it can metaprogram, or downwards to access the machine. It is better for development than a generic bytecode VM because it ships in a bootstrappable form, with everything you need for debugging and extension - it is there to be the layer that talks to the machine, as directly as possible, so nothing is hidden behind a specialized protocol. And you can use the Lisp to be the compiler, to add the rubber-stamping semantics, work through resource tracking issues, do garbage collection and complicated string parsing, and generate "dumb" Forth code where it's called for. That creates a nice mixture of legibility and configurability, where you can address the software in a nuts-and-bolts way or with "I want an algorithm generating this functionality".
    - Karrot_Kream 3y ago
      > IMHO, a perfectly reasonable approach I'm exploring now for personal work is to have a Lisp(or something that comes close enough in size, dynamic behavior, and convenience, like Lua) targeting a Forth. I've had this idea for a while now but never got around to actually executing it. I'd love to follow your progress if you're doing it publicly.
  - coldtea 3y ago
    >If it's because of libraries, then the question is: Why do people write libraries for these languages and not the Lisp ones? Because libraries already exist for those languages, as well as support, vendors, and a big ecosystem, familiar syntax, and jobs. So they write libraries for languages that are already popular. If you meant, "but why wasn't some Lisp the one that gain popularity back in the day, when C, C++, Python, and Java didn't exist or where still fresh?" I think because: 1) it was too advanced for the procedural mindset at the time, 2) it was not sufficiently efficient in those primitive 16 bit machines 3) fragmentation and most importantly, no killer app and major vendor backing or OS first-class support (like C had for UNIX, C++ for Windows, and Java got from SUN).
  - eduction 3y ago
    This is a great talk on exactly this topic from a Clojure conference, if you want a long answer. It focuses on the “functional” feature of Clojure but all of it applies to the whole language (and probably any good lisp) IMO. https://youtu.be/QyJZzq0v7Z4?si=y3hhYaInMkRLBCJK https://youtu.be/QyJZzq0v7Z4?si=y3hhYaInMkRLBCJK My brief text answer (focused on Clojure): -python has been around about 20 more years than Clojure -the advantages of Clojure vs python/etc probably aren’t nearly as big as python vs a non memory managed, compiled, static language like C. That whole generation of “scripting” languages had the wind at their backs in a way Clojure and its contemporaries never quite will (though Clojure et al tend to be much better at concurrency and parallelism and this will help a lot) -unfamiliar syntax (not Algol like) and paradigm (not oop)- and the truth is many programmers back away slowly when a thing is too alien -hasn’t found a niche as big as data science or scientific computing or CRUD website building - I think python has aggregated some great academic niches, at least one of which (ML/data science) exploded in popularity. Ruby had the rails community. Clojure seems to have some popularity in fintech but has no big single niche yet that it dominates.
karmakaze 3y ago
My take on Lisp after going (partway) through SICP, is that it's a syntax and not so much a language. The language is what you build up for the particular kinds of things you need to do. This is both the strength and weakness of Lisp, with a tight-knit competent team, everything is elegantly achievable. However on a small/understaffed team or one with high turnover, each member has to onboard onto that team's language built using Lisp. Imagine the best and worst DSLs that you've had to use. Joining a Lisp team would be somewhere on that spectrum though I hope their homegrown/app language is far better than the average/bad DSL. Clojure is much better in that it has many 'batteries included' and opinions on things to make different codebases less different than with other Lisps.
- bcrosby95 3y ago
  My take on Lisps is that people overblow the DSL aspect of it. I just write functions that call other functions, as opposed to methods that call other methods.
  - pfdietz 3y ago
    That's a fine thing to do in Common Lisp. If you ever change your mind, it's very easy to change a function into a generic function and split off the body into one or more methods.
    - deleted 3y ago
      [deleted]
- nerdponx 3y ago
  If it's any help, SICP is the wrong place to start for actually learning Scheme as a practical language. It's for learning about "the structure and interpretation of computer programs", which is not the same thing as "writing useful computer programs".
- tmtvl 3y ago
  SICP is a great, wonderful book. But it's even better when balanced with Seibel's Practical Common Lisp. It's like the Dean Martin to SICP's Jerry Lewis.
horeszko 3y ago
> I think im going to have to make an intentional effort to find a lisp job next time. Does anyone have any tips on where to find a lisp job?
- reikonomusha 3y ago
  Lisp jobs are sometimes advertised in Who's Hiring threads, Reddit's r/lisp, etc. There's a Lisp job advertised on Reddit [1,2] right now even. Another good source is to check out the companies in [3] and see if they have any openings on their website (or cold-emailing). [1] https://www.reddit.com/r/ProgrammingLanguages/s/AZmouaoARl https://www.reddit.com/r/ProgrammingLanguages/s/AZmouaoARl [2] https://jobs.lever.co/dodmg/af802f7f-4e44-4457-9e49-14bc47bd8b31 https://jobs.lever.co/dodmg/af802f7f-4e44-4457-9e49-14bc47bd... [3] https://github.com/azzamsa/awesome-lisp-companies https://github.com/azzamsa/awesome-lisp-companies
- john-shaffer 3y ago
  https://jobs.braveclojure.com/ https://jobs.braveclojure.com/

cmrdporcupine 3y ago

While I agree with the author that there's something about Rust (my day-job lang & goto personal lang these days) that just lacks... elegance... I've also never found the Lisp (and many other FPs) emphasis on recursion all that compelling. Aesthetically or computationally. I find the programs written this way hard to reason about and read. Personally. For me, the underutilized gold mine feels like logic languages (Prolog et al.) Though I know recursion is used there a lot, too.

epgui 3y ago
It’s like anything else, you get used to it just as easily.
- cmrdporcupine 3y ago
  I take it as: mathematicians like recursion, so they put some recursion in your recursion...
  - epgui 3y ago
    There's a strong argument to be made that mathematicians tend to build the simplest abstractions conceptually, especially in comparison to computer scientists. Personally, when I stumble upon some maths, I pay close attention. It has paid off.
- whartung 3y ago
  ...or don't use it. Scheme likes to tout it because of tail call optimization. Common Lisp can do it, but doesn't really shove it as a first principle of "Common Lisping" (and CL does not dictate tail call optimization). I don't use it (save when it's necessary). I just iterate using the supplied iterators (do, dolist, loop, whatever). I can't speak to other functional languages.
  - ska 3y ago
    CL's iteration primitives are more capable that those provided by most languages, which often makes for a very clean approach. Recursion is sometimes the easiest way to reason about a problem though, so it's nice to have decent support and TCO.

whartung 3y ago

Regarding Guile, and, mind, I'm on macOS, but I found it not easy to get started with. I'm looking for a compiled Scheme or Lisp. By that I mean, I want "prog.ext" to create the executable "prog". I want this because I want to make some command line utilities, and I would like the actual code compiled (vs some p-code bundled with an interpreter). I had tried to get started with Guile, as all of its packages looked attractive, but was stymied. It's been awhile, so I can't express details. It had to do with a combination of things like packages, modules, and I know I ran into a version issue (I think I wasn't running the latest version from my package manager, so it didn't have something in the documentation). Anyway, for such an extensive system, I found it surprisingly frustrating. I've been trying Gambit, which seems like it would be a really nice fit, but it's fighting with my Mac, because macOS doesn't put stuff in /usr/include (wchar.h in this case), and all of my efforts to fix that have failed (save I have not tried upgrading to whatever the latest macOS is). Maybe I can try ECL, maybe that will work. But, anyway, Guile, while attractive, just surprised me at how I wasn't really able to make it work for me enough to make me look elsewhere.

7thaccount 3y ago
What about chicken scheme or chez scheme?
- nerdponx 3y ago
  Chicken kind of felt like a dying ecosystem when I tried it, and it's also not very fast. The standard library itself is kind of limited, so if I couldn't find an egg for something I wanted to do, I felt very stuck. Chez is good because it's supported by Akku, but I'm not sure if it will ever support R7RS. It does have a really nice FFI though, and the docs are very good.
  - hajile 3y ago
    R7RS isn't worth supporting right now. R5RS is too small for real work unless you add tons of SRFIs, so they created R6RS for people who want to get stuff done. But the the R5RS people got ticked off because "its too big". R7RS was supposed to be a compromise with a tiny R7RS-small, but later adding most of the R6RS features with R7RS-large. It's now been a decade and R7RS-large seems to be completely dead.

huqedato 3y ago

After reading the article (BTW a good one), one thing intrigues me: why the author left Haskell for Lisp(s) ?

deleted 3y ago
[deleted]
behnamoh 3y ago
At some point you realize Haskell and/or its ecosystem keeps breaking things too much and you move on.
- ParetoOptimal 3y ago
  I love Haskell and know there are efforts to fix this, but I find it hard to disagree.
  - tome 3y ago
    Not just efforts, but both GHC HQ and the Core Libraries Committee making stability a top priority. Expect casual breaking changes in the Haskell world to become a thing of the past, in very short order (in fact the most recent release of GHC (9.8) had very few breaking changes).
    - ParetoOptimal 3y ago
      I've been out of the loop for a bit, so that's great news to hear!
kccqzy 3y ago
I did the same and I treat Haskell as a rite of passage. At this point it's cliche to say that Haskell makes you a better programmer in other languages, but it's true. You really immerse yourself in Haskell for a few years, and you become a better programmer even when you aren't writing Haskell. I'm referring to universal things like "making invalid states unrepresentable" or "preferring to parse than to validate" or "functional core imperative shell" that can work well and lead to cleaner code in any language. (The actual reason I left Haskell was because I switched my employer. Choosing an employer is IMO a bit more important than choosing the language to code in.)

sph 3y ago

I believe this article is selling Guile short. I think it is the most pragmatic Lisp around. I love Lisp's ideas but I find all modern implementations terrible. I would go so far as to say Lisp aren't popular because what we have today is not good enough. Common Lisp is the most advanced one, but it is like C++: it does everything and the kitchen sink. Design by committee. You want functional programming AND imperative? You want documentation that reads like an IBM mainframe manual? You want a standard library with names as cryptic as ANSI C? We got all that. But frankly, it is the one to build serious production software with. Racket is the best for a beginner, but it keeps having that academic, "we made it for the kids" feel of being easy to understand but not very pragmatic for a seasoned programmer. And it is one of a kind, so a good Racket developer might never know Lisp itself. Schemes are fun, but the only standard everyone agrees to relegates to small embeddable languages almost like Lua. They are not made to live on their own almost. Since the standard is very simple, there are half a million implementations that are not very practical. But of these, there is Guile, which has a pretty decent documentation AND standard library (even a built in PEG parser!), actively developed and it is my opinion that is it very underrated and the only Lisp worth my time these days. To be honest, the most popular Lisp in the world is Emacs Lisp bar none. How's that Guile port coming along anyway?

velcrovan 3y ago
> Racket is the best for a beginner, but it keeps having that academic, "we made it for the kids" feel of being easy to understand but not very pragmatic for a seasoned programmer. And it is one of a kind, so a good Racket developer might never know Lisp itself. As someone trying to write definitively about cold hard reasons Racket remains in relative obscurity, I would be interested to know specifics you can provide for this view. Is it just academia vibes? Or are there specific aspects of Racket that in your view repel “seasoned programmers”? I notice you praise Guile for having decent documentation and standard library. How do you believe Racket’s documentation and standard library compare to Guile’s?
- sph 3y ago
  Sorry, I don't have anything more concrete than "general vibes." Like, there's thousands of libraries and modules in Racket, sometimes competing with each other, that feel like they have been developed for a school project and kept around. And it is no secret that Matthew Flatt, one of the lead developers, is actually a professor at Utah University. In my experience, it is pretty easy to tell when a language and ecosystem is developed in academia, or developed by software engineers by trade. They have two very different goals and approaches to the same problem. The former might focus on educational purpose for newbies, the latter on shipping production-ready software for professionals. (In my humble opinion, this is one of the reasons Smalltalk never went very far in the real world. Too much focus on the educational aspect of it.)

nerdponx 3y ago

I feel like I say this a lot, but if you like Guile you should really check out Gauche. It has more "batteries" included than Python, several of the "alien technology" features that people expect from Common Lisp, and good documentation to help you navigate it all. Scheme itself has a reputation for being very "minimal", and R7RS itself is great, but it also shines as a base for bigger languages like Guile and Gauche. Clojure is pretty cool too though. I love that it really has a life of its own as a "third" dialect to complement Common Lisp and Scheme. Can't speak for Elisp, not enough room in my brain to learn Emacs after years of Vim. If you like Python, I'd also like to shout out Hy (https://hylang.org/ https://hylang.org/), which compiles to Python, and like Fennel is to Lua, it does a reasonably good job of bolting on s-expressions while preserving the semantics of the underlying language. It's definitely a "bigger" language than Fennel, but Python is similarly "bigger" than Lua. Hy has also developed its own distinct feel, especially when you take into account the first-party Hyrule utility library (https://hyrule.readthedocs.io/en/master/index.html https://hyrule.readthedocs.io/en/master/index.html) which provides a lot of very interesting macros, deriving lots of useful ideas from both Common Lisp and Clojure.

rcarmo 3y ago
I've been using Hy on and off. Off because it broke "let" at one point and I had a few critical things (like my entire site engine) written in it, and on because I like it a lot. But it's not a great LISP for performance (Fennel can run rings around it when using luajit), and I wish they shipped a 1.0 (I cringe every time I read the changelog for a release and check the "breaking changes" part, which is always... beefy).
- Zambyte 3y ago
  > Off because it broke "let" at one point It wouldn't be very difficult to provide an implementation of `let` that behaves how you would like though, so there is that at least.
drekipus 3y ago
I tried Hy for 2023 AoC and loved it, but it broke after day 8 because the solution I wrote crashed after 40mins. but re writing the same logic in python took 2 mins to complete. Hy is nice, but "compiling to python" isn't

FrustratedMonky 3y ago

Not even an honorable mention for F#? Why does Haskell get a mention, since it is also just another ML based language. Seems like F# is trying to solve the same problems as LISP. Lot of same features. Edit: Did like article. Is serious question LISP-> Clojure-> F#. There are similarities. Edit2: Guess it is a stretch. But not insultingly so. Have seen articles comparing Lisp macros to F# Type Providers.

nerdponx 3y ago
F# isn't a Lisp, so I think it's fair to consider it out of scope. I think the only reason Haskell got mentioned is because the author has experience with it and was using it as a personal point of reference.

charlotte-fyi 3y ago

Don't really get the criticism of Clojure for being hosted on the JVM, particularly relative to its status as a "productive" Lisp. Like oh, you get access to one of the biggest and most mature library ecosystems out there as well as best in class operational tooling? Obviously there are use cases where the JVM doesn't fit and all things being equal I prefer shipping statically linked binaries too, but the JVM still feels like an obvious "pro" here.

askonomm 3y ago
And quite a lot of people actually do ship statically linked binaries with Clojure, using GraalVM. Clojure LSP server for example is distributed as a static binary.
- colingw 3y ago
  Yes, although that solution can't yet be said to be "push button". My impression is that there are a decent amount of people who want non-JVM, native Clojure. Hence efforts like Janet and Jank.
ska 3y ago
I think hosted is almost tautologically a mixed bag - you get access to the host (both +ves and -ves) but you also introduce a layer and some invariable friction.
whateveracct 3y ago
The JVM precludes general tail-call elimination though.
- thmorriss 3y ago
  the clojure loop construct is often cleaner than code written to be tail recursive
  - uyrifo 3y ago
    And often faster: https://medium.com/hackernoon/faster-clojure-reduce-57a104448ea4 https://medium.com/hackernoon/faster-clojure-reduce-57a10444... Yet it’s always noted as code smell associated with “inexperienced candidates” in interviews. For that matter, first and last too: https://medium.com/hackernoon/faster-clojure-reduce-57a104448ea4 https://medium.com/hackernoon/faster-clojure-reduce-57a10444... The amount of paired programmers suggesting changing nths to firsts and lasts is demoralizing.

im_down_w_otp 3y ago

> Why do print-line-debugging to find out what's happening at a location in code when you can just be inside your program and inspect everything live as it's running? Yes, that's because print-effing one's way to understanding is also among the most crude methods of debugging. An excellent alternative to doing that is to use an actual debugger. That will also allow you to be "inside your program".

foobarian 3y ago
How do you "get inside your program" on a locked down production box? Watched by SOX auditors like hawks? Any answer offered needs to be comparably easy to checking in an extra printf and letting ci/cd deploy it.
- im_down_w_otp 3y ago
  I used to be an Erlang engineer, and you would have needed very explicit security controls around being able to attach to an Erlang cluster to get the "insider your program" experience. This was in FinTech, so I'm familiar with the constraint. I would imagine you'd need the same thing for accessing the runtime of any production deployed application(s) in such an unfettered manner. Erlang, Lisp, C, or other?
ctrw 3y ago
The difference with lisps is that the debugger is always part of the runtime and you have full access to all the languages capabilities while inside. I've yet to see a C debugger which does more than a fancy version of printf. Imagine being able to compile functions on the go while still running your main program with all the state saved.

galaxyLogic 3y ago

Includes this great comment by Simon Peyton-Jones in support of incremental typing: "I think to try to specify all that a program should do, you get specifications that are themselves so complicated that you're not longer confident that they say what you intended."

kqr 3y ago
I think, though, that when reading this quote it should be taken in the context of e.g. Haskell exhibiting incremental typing – because it doesn't try to specify everything. It can't.
- graemep 3y ago
  Does not seem to fit with the previous bit of the quote: "dynamic languages are still interesting and important. There are programs you can write which can't be typed by a particular type system but which nevertheless don't "go wrong" at runtime, which is the gold standard - don't segfault, don't add integers to characters. They're just fine."

LAC-Tech 3y ago

The big thing I took away from LISP is that having everything be prefix solves a lot of problems. Seriously, the arguments people have in languages like Zig about whether to have "operator overloading" just seem a bit silly. Operators are just functions, it's very silly to make them syntastically different. But I never got much into REPL driven development. Probably because I just couldn't wrap my head around emacs.

mpweiher 3y ago
Smalltalk solves that by having everything be infix. With fewer parentheses. ¯\_(ツ)_/¯
- LAC-Tech 3y ago
  Yeah that's another approach to it, one I think could definitely be borrowed (though I wouldn't do it exactly how smalltalk did). And then of course there's the "concatenative" family where everything is postfix.
  - mpweiher 3y ago
    How would you make it different? One change that I made in ObjS is that I added the pipe so you don't need to parenthesize chained keyword messages. ((receiver msg1:arg1) chained1:arg2) chained2:arg3 vs. receiver msg1:arg1 | chained1:arg2 | chained2:arg3 Having colon keywords does get in the way a little, as I also need them for schemes (URIs are part of the language) and I would also like them for type-specifiers, as type-after really seems the better way. I can probably pull all that off syntactically, not sure about aesthetically.
    - LAC-Tech 3y ago
      I've actually thought about this a lot! 1. no more keyword parameters 2. every message has exactly one argument, which may be a tuple. 3. "obj.msg" becomes short hand for "obj msg ()" 4. if a message expects 2 element tuple and you give it a one element one.. it returns a closure that expects the rest of the arguments. ie "add1 = 1.+"

beepbooptheory 3y ago

Does anyone know how to get a lisp job? Or have any experiences to share? Its been a dream for a while for me, and I think I am possibly ready (at least with common lisp, have started doing more clojure recently though). It just seems so impenetrable to me, I don't even know how to begin to search for it.

colingw 3y ago
The Clojure Slack has active channels for both job posters and job seekers.
neilv 3y ago
I got mine by contributing to some niche communities, and developing open source packages. A great foot in the door is when someone is using and likes some software that you have written. If they know it came from you, and can easily find out you're available when they're ready to hire. Of course, that's not an option for everyone -- some people simply haven't yet had the free time or paid opportunity to make open source -- and we should try not penalize people for that. But it's much better positive signal than a job-seeker approach of "I spent person-months memorizing Leetcode medium-difficulty answers, and rehearsing whiteboard interview stage presence like a rockstar." Beware that good Lisp-family jobs are rare, and don't tend to be highest-paying. Outside of relative pay within categories like enterprise Java-shop programmer. (Aside: From a hiring perspective, using some beloved niche language with few jobs available is also a great way to pick up mythical "10x" hires, and retain them for a long time. :) But, more seriously, it's ethical to make sure that prospective hires for unpopular niche keywords realize what they're getting into, in the current software job environment that often assumes fad-following & job-hopping strategy, and is skeptical/derisive of people whose resumes don't look like that.)
- colingw 3y ago
  If the Stackoverflow Dev Survey is to be believed, CL and Clojure devs actually make decent money.
  - 3y ago

dogprez 3y ago

> [Fennel] also lacks Common Lisp's debuggability, given that it sits entirely within Lua's runtime. I'm not sure exactly what feature the OP was referring to. It sounds like they don't think you can get a REPL for an executing Fennel process? You can. If you are only using it for AOT Fennel->Lua you can't, you have to include its runtime.

schemescape 3y ago
Last I checked, Lua was “bring your own debugger”. Assuming that hasn’t changed, a REPL is nice, but you can’t pause and inspect anything by default.
- emidln 3y ago
  Why can't you just put the equivalent of `(repl)` wherever you want to debug and drop into your REPL?
  - schemescape 3y ago
    Short answer: I don’t know. That sounds like a good idea, but how would that access local variables in the caller (to inspect state)? I remember the Lua C API exposes a lot of information, but I didn’t think it was accessible from scripts. Of course, it was a long time ago and I could have easily missed something at the time. Happy to be corrected! Edit: you might also run into difficulties trying to redefine non-global functions to add the call to “repl”.
- dogprez 3y ago
  Fennel has a form `assert-repl` which will drop into the REPL wherever, if the condition fails. For writing games you can launch the REPL in the game loop if a keyboard button is pressed. But what you can't do, that I know of, is interrupt arbitrary execution and get a Fennel REPL. You'd probably need a lua debugger of some sort for that. I'm not that familiar with that though.
- colingw 3y ago
  To be the most fair, Fennel 1.4 recently released with an `assert-repl` form that opens a repl when some assertion fails, in which you can inspect local variables, etc. That's getting closer to CL. https://git.sr.ht/~technomancy/fennel/tree/1.4.0/item/changelog.md#new-forms https://git.sr.ht/~technomancy/fennel/tree/1.4.0/item/change...

JonChesterfield 3y ago

I really like Kernel. John Shutt's thesis language. It throws away a bunch of incidental complexity from scheme, most notably the minor disaster of hygienic macros. It follows a minor tangent on cyclic data which I'm not convinced matters very much. Implementations are a bit DIY. An interesting play would be to implement rsr7 scheme in kernel, semi-metacircular fashion.

spindle 3y ago
Does picolisp scratch that itch for you?
- mst 3y ago
  Kernel is operative rather than applicative - i.e. fexpr-based - and I don't think you can get something quite the same without it. (arguably a macro is really just a limited fexpr that's executed and the results inlined at compile time, though I mean that as 'morally equivalent' rather than making a technical claim since I haven't attempted to implement that in my fexpr based interpreters yet)
  - JonChesterfield 3y ago
    Did you go with first class environments? If so defmacro builds a fexpr with an an extra eval in the dynamic environment plus a flag to tell the compiler it must be inlined (and that various other things should be reported as semantic errors). You can get somewhat close to fexpr with lazy evaluation but it turns out that's not the same thing either. Taking the arguments apart and building different things out of them is a superset of stashing it somewhere to evaluate later. (lambda (x) ...) ; evaluate the argument in the caller, bind it to the name x (fexpr (x) ...) ; bind the argument to the name x (normal (x) ...) ; make a thunk out of the argument and the environment (macro (x) ...) ; bind the argument to x then do the force inline & extra eval on call It's interesting that macros are the one with a bunch of extra work to do after the call whereas fexpr does the bare minimum of adding stuff to the lexical environment. Lambda maps eval across the arguments, normal maps make-thunk across the arguments.
- 3y ago

dannyobrien 3y ago

As an amateur coder, this really matches my journey, though with a slightly different ordering: after the usual BASIC/Perl/Python homebase, a few years really expanding my mind in Haskell-land, followed by a "well, I've bounced off Lisp in the past, let's see what I make of it now", then having real joy in writing Clojure, exploring Guile and Scheme, and then coming finally to appreciate Common Lisp, warts and all. I still "see the parentheses", and I wish there was a way (outside Coalton) to integrate the security that a strong typechecker can provide, but I really do enjoy working in the Lisp ecosystems now, and feel like I understand Lispers excitement at what they have.

Y_Y 3y ago
> to integrate the security that a strong typechecker can provide Have you checked out typed-racket? That's a reasonably nice way to get strong typing by tackling type correctness contracts on top of otherwise standard racket. There's also Alexis King's marvellous Hackett, which seems to be finished for now, but was positive proof that you can have - and eat - all the curry-flavoured cake you want while staying in scheme.
medo-bear 3y ago
> I wish there was a way (outside Coalton) to integrate the security that a strong typechecker can provide, Common lisp is optionally strongly typed. SBCL has extensive type checking facilities. Coalton is statically typed. Security does not imply strong (or static) typing, and strong typing definitely does not imply security (thinking your code is secure just because you used strong or static typing is silly). In fact code complexity that static typing introduces can have detrimental effects to overall security. Helpful starting point on state of type checking in common lisp: https://lispcookbook.github.io/cl-cookbook/type.html https://lispcookbook.github.io/cl-cookbook/type.html
- dannyobrien 3y ago
  Just to be clearer, I meant security as in confidence in the code running correctly, rather than defended against vulnerabilities.

thetwentyone 3y ago

Also an interesting Lisp for it’s size is femtolisp from one of the co-creators of Julia: https://github.com/JeffBezanson/femtolisp https://github.com/JeffBezanson/femtolisp

rcarmo 3y ago
I have a femtolisp quote at the top of my LISP resources page: https://taoofmac.com/space/dev/lisp https://taoofmac.com/space/dev/lisp

Jeaye 3y ago

I appreciate the shout out to jank, the native Clojure dialect on LLVM with C++ interop. :) Lisp has such a colorful history and Clojure, in my opinion, made it even more accessible and practical. People complain about Clojure's error messages, but, coming from C++, anything that doesn't corrupt memory and segfault is golden.

mark_l_watson 3y ago
I also liked that reference since I had not heard of Jank before. It is a work in progress so I just added a calendar entry for 9 months from now to check it out. https://jank-lang.org/ https://jank-lang.org/

dartharva 3y ago

Article topic notwithstanding, I am curious in the design choice of moving the "Table of Contents" to the right side of the text and links for other blog entries to the left. Aren't the sides conventionally swapped as with default Blogspot/Wordpress blog templates? Also, what was the objective behind shaping the text as a Q&A-style interview when it's only a personal blog?

colingw 3y ago
The questions were originally posed by a Doom Emacs community member, so I answered them as-is. The site is designs as it is because I'm not a frontend guy xD

agambrahma 3y ago

Sounds like he'd like Coalton

colingw 3y ago
CL-embedded langs like Coalton and April are mentioned in the article.

hiAndrewQuinn 3y ago

Scheme has a special place in my heart after working through SICP as a late high schooler. I probably haven't actively written anything in Scheme in a decade, but it later inspired me to learn Haskell to a decent level of depth, just to see what the "other" functional languages feel like. So much the same, yet so much different.

eggdaft 3y ago
Scheme was taught in my first year of CS. One thing I noticed is that those who hadn’t coded through their teenage years found scheme much easier to learn than other languages we were being taught in the first year. I think that was because scheme felt more like mathematics and everyone had done A Level maths (in the UK), many to an advanced level. Immutability and functions make a lot more sense than weird variables that keep changing and - what the heck are classes? We just unlearn this mathematical thinking when we start hacking Python etc.

codr7 3y ago

I spent a lot of time unsuccessfully bending Common Lisp into something I could love. It's still one of my favorite problem solving languages, but far from trivial to fix from the inside. Tried writing my own readers that compile to Common Lisp. Then I ended up on a side track to write my own interpreters; mostly Forths at first, then gradually more Lisp-like and practical creations. My latest attempt may be found here: https://github.com/codr7/jalang https://github.com/codr7/jalang

matheusmoreira 3y ago

> How can newcomers get the most out of learning Lisp? Make your own lisp. I chose that route even though I had never written lisp code before. Finally understood its elegance.

hickelpickle 3y ago

I've had a really pleasant experience with Kawa scheme recently, which is a scheme that runs on the JVM, compiles to bytecode and provides easy interop with Java. I needed a scripting language for a project, and it ended up developing into me implementing a repl like admin console that allows me to administer events and query data/state (project is a game back-end so everything was already event-based with thread-safe dispatching and an entity system accessed via a singleton). Being able to inter-opt with java is great, as I can wrap scheme procedures in functional interfaces and use them as drop in replacements for java functions, as my event system was already based on predicates and consumers for event handling. I've worked through some of the SICP and have always wanted to get more into scheme/lisp, but the barrier of starting a full project in it always kept me from getting much hands on experience. Its been quite enlightening actually getting to work with a form of REPL driven development and getting my hands dirty with coding some scheme, having access to the JVM means I can do practically anything with it, with out needing to bootstrap tons of code, and using it in a project with a large scope lets me solve real-world problems with it vs just toying around which has been what most of my scheme/lisp experience was before.

SeanLuke 3y ago
To me, Kawa is easily the best Lisp that targets the JVM. And I say that hating Scheme. I'm a Common Lisp guy. Because it is really fast, well designed, and mostly Scheme compliant (no call/cc of course). And it has first in class interoperability with Java and the JVM. After Kawa, I'd pick ABCL. It's not as fast as Kawa and its interoperability isn't nearly as good, but it is effectively a 100% standards-compliant Common Lisp: what more could you ask for? Only last would I pick Clojure. It's designed to feel "sort of immutable" but this is impossible if you want any degree of interoperability with the JVM. As a result, you wind up with lots of Refs and other fun stuff which in my experience make Clojure much slower than Kawa and ABCL. It's always slower by quite a lot, but in fact I've had a few extreme situations where Clojure would wind up being __literally__ three orders of magnitude slower.

MarkG509 3y ago

Over 40 yrs ago, I had a programming assignment in college that I wrote in Lisp. My Prof, a non-Lisp-er, asked me to rewrite it, expecting C or Pascal. But I took him through my Lisp code, and was able to argue for the 'A' on that assignment. I might have created a Lisp-er in the process.

onetimeuse92304 3y ago

> What's your current mental model of an "ideal Lisp"? > It would be something like a fusion of Clojure and Common Lisp, (...) Mine would be, too. Unfortunately, that's not possible. Clojure is one of those few languages actually designed by somebody who knows what they are doing. Clojure's limitations come from the limitations of the platform it is running on and certain design criteria (interoperability) that were necessary for its success.

fulafel 3y ago
There could be a Clojure implementation hosted on a CL. In fact someone seems to have started on one: https://github.com/ruricolist/cloture https://github.com/ruricolist/cloture
gmfawcett 3y ago
> Clojure is one of those few languages actually designed by somebody who knows what they are doing Not saying you're wrong. But look at the authors of Scheme and the CL spec... Rich may have seen far, but he was standing on the shoulders of giants.

a2code 3y ago

What makes Lisp (Scheme) great (for me) is that functions are first class citizens, the prefix syntax is consistent, tail call recursion optimization makes it runnable, and metaprogramming allows for powerful abstractions. What I would also emphasize is that using lambda expressions makes you wonder when to define something and when to omit the definition. Lisp is simple to learn but difficult to master. What I would like to do is to use Lisp to solve complex problems. The problem is that abstractions are not often efficient. For example, consider computing the calculus product rule. An S-expression abstracts the function: (lambda (u v) (* u v). With metaprogramming, this becomes a new S-expression (lambda (u v) (+ (* (d u) v) (* u (d v)))), where (d u) and (d v) further compute the derivative. To optimize this further, you need implementation dependent code and replace abstractions of S-expressions with native machine code. This is where I feel that the troubles with Lisp start.

hayley-patton 3y ago
> To optimize this further, you need implementation dependent code and replace abstractions of S-expressions with native machine code This can be done by a program called a compiler. There are many compilers for Lisp. (In other words, the same argument applies to every language ever which doesn't exactly correspond to machine code.)
- a2code 3y ago
  And yet to extend Python, for example, you write code once. To extend Lisp, you have to extend a multiplicity of implementations you find relevant.
JonChesterfield 3y ago
There are properly good lisp compilers. The baseline is good and they're extensible - you can teach them things about your domain. SBCL for lisp. Maybe racket for scheme.

mark_l_watson 3y ago

Nice article! The author captured many of my own feelings of Clojure compared to Common Lisp. I have been happily using Lisp languages since the 1970s and CL since 1982. I retired several months ago but I still spend time coding for my own research projects and for my book examples. I have been torn between going all in using just one of Racket or Common Lisp. Racket is a fun environment and I like the community but I have so much history with CL. I don’t know if I will choose just one, but it would be a good idea! The article didn’t mention the Hy language that compiles to Python AST. For a while I was very enthusiastic about Hy and I wrote a book about it. It used to have a “let” macro that mapped Lisp variable scoping to the jankyness of Python but that support has gone away and I feel like using “setv” and just accepting Python like scoping is a bridge too far for me. The philosophy behind Hy is great, but it is not my philosophy. I love the Clojure language (and I donated money to the project at the beginning) but I only use Clojure when I am being paid to use it for specific projects. The Bork Dude’s Babashka language is a fast loading Clojure, and I had a lot of fun for a while setting up a nice dev environment and using it for all recreational programming for a week. Babashka is worth a serious look.

kagevf 3y ago
For racket do you use Dr racket or emacs?

mustermannBB 3y ago

Biggest issue with most Lisps is, IMHO, that you need emacs for a great developer experiences when it comes to tools. And emacs is not for everyone.

colingw 3y ago
Not so for Clojure, there's great integration for both the Vim family and VSCode.
- edanm 3y ago
  Seconding this, Clojure was my introduction to Lisps, and I used only VSCode with it. One of the greatest development environments I've ever used, and about half the fun of learning Clojure for me. (The other half being learning the language itself, of course!)

masfoobar 3y ago

I have toyed with various lisps and schemes over the years. Eventually - since around 2012 (ish) my focus has been with GNU Guile. Which won me over originally was the documentation, and the C functions following the same format as my own. Being able to add Guile into my game did really speed up my time "hacking" 3D scenes and features, before converting them over to C code. Then started to use GNU Guile for building a personal website, and other toy projects on my server. While I don't use GNU Guile for much these days, I certainly think it should be given, atleast, half the reputation Python gets today. I think the problem with GNU Guile is that (last time I checked) was that it was very Linux focused. Always had trouble with it on Windows. I dont own a Mac but assume to be the same there as well. Of course, I have GNU Guile on my Windows machine thanks to WSL2.