Which one should I learn?
Why not both?
Scheme is one of those languages that are easy to learn but hard to master. I'd say start with Scheme, then try Common Lisp, see if you like it. If you don't, you can always go back to Scheme. (Disclaimer: I'm a Schemer who does Clojure at work.)
One thing I always hated about CL is that it's not a very functional language, as in it gets in my way when I try to do things the FP way and immutably; not to mention Lisp-2 screws with my intuition of higher order functions. You should bear this in mind if you're a functional programmer at heart like I am. If you do end up going with CL, consider looking into fset, modf and Sycamore for persistent data structures, and folio2 for FP utility functions that augment Alexandria and Serapeum.
>>3
Learning Scheme first can make it harder to get into CL, or you get more annoyed by the historical baggage.
CL is better enjoyed when you accept that it isn't functional, which isn't bad in itself.
>>4
Honestly, I actually find the historical baggage to be rather charming but I do realise I'm in the minority. I first got into Scheme for being a dynamically typed functional language (the only alternative was Erlang) and soon fell in love with the macro system and expressiveness of Lisp. Still, I find writing bluntly imperative code to be very annoying, which mostly keeps me away from CL for most tasks.
>>3 how is common lisp not functional? I don't know anything about functional programming except that you use functions for everything
>>6
There are different definitions of "functional languages", but I consider 1. functions are data 2. functions are composed 3. data is immutable to be the general style. Now languages can either support or enforce this. If supporting is enough, then C is functional (1. function pointers; 2. eg. qsort; 3. const).
But because this seems absurd, I prefer to say that these kinds of languages "support a functional style". Functional languages either have to be designed so that a functional style is intended (Scheme) or required (Haskell).
Common Lisp can be programmed in a functional style, but you're going to suffer inefficiencies, because you're expected to think about memory and garbage collection (when to use nreverse or reverse). Also mutation is quite central, something you easily recognize when considering all the macros that work on generalized variables (setf, push, rotatef, ...).
So all in all, you can write bits and pieces in a functional style, and knowing when doing so aids performance and readability is what one learns with time, but the trying to do everything as if it were Haskell, is not the best approach.
(IMO)
>>6 At one time, people talked about functional programs as being made up of expressions. Evaluate the expressions (by function application) and you have your program. I think in this sense CL
But then people became more concerned with pure functions, which don't have side effects and always have the same output for the same input. Purely functional scheme, for instance, would mean not using set! or any other ! functions. Since even updating a database, saving a file, or opening a window are side effects, you can't get much done purely.
If you look at the implementation of the SRFIs or grep over your scheme, you can see it's rife with set!, so as far as scheme being functional in this sense, it's mainly just that users are encouraged to localize their use of these functions and make as many functions as they can pure.
But scheme is not purely functional.
But in CL you can, for instance, update a class, and all the running instances of that class will update to be instances of the new class. That doesn't sound very functional (in the pure sense) but it does sound good for development.
>>1
If you plan to tackle a real project, Scheme will be frustrating with its lack of libraries. On the other hand, you can find almost everything you need in CL.
There are maybe a few exceptions, Racket, Chicken, Guile and Gerbil are the first to come to my mind but they're all far from CL's ecosystem. You should start with reading SICP nonetheless, you'll learn a bit of Lisp, of which both Scheme and CL are dialects.
>>9
It's worth noting though, that Guile has quite a lot of libraries that CL lacks by default, or would require some package management to include. See https://www.gnu.org/software/guile/manual/html_node/API-Reference.html and https://www.gnu.org/software/guile/manual/html_node/Guile-Modules.html.
Racket has even more, but I never read too much about it. The interactive plotting always looked cool: https://docs.racket-lang.org/plot/
>>2,9
It doesn't really matter which you begin to learn with because the subset of the languages that you would realistically use are so similar. This is why “The Little Schemer” and “The Seasoned Schemer” are able to have their examples work in both Common Lisp and Scheme with extremely little deviation from the source they provide.
Would love to know your thoughts on clojure vs a more traditional lisp. (clojurian who's thinking aobut picking up a more traditional lisp).
>>12
I only studied Clojure briefly, but Gerald Sussman has been known to program in Clojure, and commented on his regret of not thinking of the idea of generalized sequences, maps, etc. as Clojure has them. I think the main difference is that Clojure (along with most other Lisps made since 2000) is intended for programming concurrent networked systems while Lisps are traditionally focused on single user applications. For this reason Common Lisp and Scheme for example have low level primitives, no startup-time, mutation, optimizing compilers, and native code generation (although for all of these less so for Scheme which has other priorities). Another difference is in there not being a layer below Common Lisp or Scheme which it interacts with. If something goes wrong it goes wrong in Common Lisp or Scheme, and with a descent error message.
java is fucking stupid and slow... Clojure based on Java
Connect dot
>>14
It may come to you as a surprise but Java is incredibly fast. They manage to get near-native performance... on virtual machines. There are trillions of dollars relying on Java, you'd better believe the JVMs have been optimized.
Go read any benchmark, Java is orders of magnitude faster than any of the scripting languages you might be familiar with.
http://textboard.org/prog/93/1
Go find C, C++, Java, and then things like PHP, Python or Ruby in the execution time column. Take a mental note and remember which ones are ``slow as fuck''.
Clojure based on Java
Clojure is a dialect of Lisp that compiles into JVM the platform bytecode, if that's what you meant. Maybe you've read memes on a consumer electronics board for teenagers, about Java the language being overly verbose? They weren't criticism of the JVM, which is largely acclaimed.
Connect brain
Java is amazingly fast. You are a decade behind with your stereotypes.
>>14,15
And by the way, Oracle's HotSpot JVM is written in C++ and Assembly, while the GPLed HotSpot Zero is a port with "zero Assembly".
>>15-17
To be clear >>13 is not saying the same thing as >>14. Clojure is clearly very fast within its problem domain, but what makes fast concurrent networked applications is not necessarily the same thing that makes fast single user applications. While avoiding mutation would be a boon to performance of the former it's detrimental to the performance of the latter. While startup time is irrelevant for distributed systems with uptime in the years, it is more relevant for (especially smaller) single user applications (uptime might have been fixed with Graal, I'm not sure). Similarly, low level primitives are rarely relevant to concurrent networked applications, but can often come in handy when interacting with a single system.
>>18
I enjoyed very much using Erlang. It's another functional programming language that excels at fast concurrent networked applications.
But if you happen to need the slightest number crunching, you'll be left with unsafe FFI because it's so painfully slow. I imagine that's where you, Clojure people, appreciate having all the Java libraries at your disposal with their fast single user execution time.
>>15-17
YHBT
both are retarded memes at this point. Learn python
>>21 how could someone say something so controversial yet so brave
I imagine that's where you, Clojure people, appreciate having all the Java libraries at your disposal with their fast single user execution time.
Right, but this introduces its own problems, especially when the underlying Java library is not solid, or you need functionality not provided for by a library. You can easily end up debugging or writing Java rather than Lisp, which was the other point mentioned in >>13.
>>24
I imagine that you either had a prior knowledge of Java or that you had to learn it to be a better Clojure programmer?
Is ClojureScript actually used for front-end development or are they just trying to push it? Maybe the huge size of Java's ecosystem is a barrier for aspiring Clojure programmers.
I imagine that you either had a prior knowledge of Java or that you had to learn it to be a better Clojure programmer?
The stereotype is that Clojure programmers are grumpy bearded Java programmers who manage to sneak in Clojure into existing Java code bases to avoid flagellation by their corporate overlords. This isn't universally the case but does seem pretty common judging by the Clojure conferences and what not.
Is ClojureScript actually used for front-end development or are they just trying to push it? Maybe the huge size of Java's ecosystem is a barrier for aspiring Clojure programmers.
I don't know anything about ClojureScript, but I certainly think that Clojure would be unusable for the target audience without Java's ecosystem.
I imagine that you either had a prior knowledge of Java or that you had to learn it to be a better Clojure programmer?
I just realized you were referring to me specifically, as I mentioned in >>13 I have very little Clojure experience, and no Java experience. I've read a introductory book on Clojure, and read about the language, and listened to talks by the designer. I have a very limited perspective on the language, and so everything I say should be read with some suspicion, as it has been. I've just been trying to answer >>12, and responding to anything I can.
>>25
I thought the stereotype of a Clojure programmer is someone who things he knows a lot more about lisp than he actually does, like the one mentioned in Peter Norvig's recent article: https://medium.com/@peternorvig/ive-consed-every-pair-54ef5d9d93b6
>>27
It seems like most people new to thing tend to evangelize it and think they know more about it than they do. Anyway I don't think I'm going to be of much use on this topic anymore, if I was of any before, so I'll leave the rest to someone else if there are any further questions.
Which is the most productive lisp?
I'm going through Common Lisp book right now.
It seems most Schemers have that strange cult aura. I genuinely want to make things with Lisp.
I do like avoiding the concept of OOP, if that means anything.
I guess the question of "which lisp" is extremely ironic... isn't it?
Yeah, I think I'm just going to use Common Lisp for all of my projects.
8-)
>>29
What kind of things do you want to make?
>>30
Toying around with the idea of making websites predominantly, after I finish these books. Then if I get comfortable enough, different domains. Replacing ruby on rails for more strenuous use cases.
What would you want to make (or are making)?
To elaborate, I would first want to make my personal website with lisp as a transpiler of html/js. That's the testing grounds. Afterward I would hope that it'd be fun enough to make spin off sites, just to make things. Although I can do these things in the usual vanilla way, it is tiresome to reinvent over and over. It'd be cool to port over common design patterns into my own library which'll be extensible because all of these other "UI libraries" are black boxes (which makes sense, as the primary demographic are those who want to avoid creating new components at all costs).
Also, these popular blog-centric projects just aren't easily extensible i.e. Hugo. It feels rigid. Everyone says lisp is the least rigid thing imaginable, so why not give it a try? I would hope that it's also timeless. Emacs feels timeless, for example.
But yeah, if it feels nice enough then how simple it'd be to move components/patterns around to make some single page domains. Little small things. Little document sites, sharing grounds, quick mockups for whatever project I have.
Making it frictionless to mock up a new site, basically. Haven't the time to look around the libraries available, but I was happy to find there was a js transpiler at least.
It may not be an ideal use case, but it just seems amusing to try
Of course I'm exaggerating the issue. It really isn't difficult. I'm just procrastinating. But it does seem like there's a better way to create websites.
The lisp LEGO analogy seems like it'd be useful for navigating html.
https://shaunlebron.github.io/parinfer/#uncovering-lisp
>>31
For Common Lisp, you could use cl-who [1] to generate HTML. For Racket, take a look at the xml library, which has "xexpr"s for writing HTML (xexpr->string is useful). For Scheme, look up SXML, which can be transformed to HTML. cl-who is the most widely used out of all these, so for web development, use Common Lisp (or Clojure if that's acceptable to you).
>>33
I found a modern HTML generator[0] that drops the baggage of XHTML. What are your thoughts?
After additional clicking around, I do find more confidence in the longevity of Common Lisp.
The chapters and examples around classes in Practical Common Lisp worried me, but it doesn't seem to be a dominant pattern, which is relieving. Although I know that lisp is flexible to where I can use my own patterns, I'm not confident enough in my abilities to shed the usual convention of a language when starting out.
But it seems that defclass is more often used as an advanced struct.
>>35
I have not used Spinneret. For Common Lisp, I have only used cl-who and AllegroServe's htmlgen [1]. I might give Spinneret a try, now that it has been added to GNU Guix (I use Guix as my package manager for Common Lisp). For HTML generators, I prefer libraries that have a function that takes a simple Lisp list and returns HTML.
[1]: https://github.com/franzinc/aserve/blob/acl10.1express_update20211007_rc1/doc/htmlgen.md
>>35
I see more and more talk of GNU Guix. It's nice to hear its ecosystem flourishing.
Do you find yourself running into more or less annoyances than a usual distro?
For HTML generators, I prefer libraries that have a function that takes a simple Lisp list and returns HTML.
This is the type of library I would prefer as well.
At this moment a static site generator is what I'm aiming for.
After giving additional thought, I would be curious how a Ruby on Rails replacement in Common Lisp would perform, or how to properly interlace it with the View component.
Usually MVC frameworks come with their own embed HTML templates that the controller can interlace with the data requested.
Curious how one would structure such a thing for a Common Lisp framework, keeping in mind performance... and if there's a way to escape hatch out of writing the usual HTML (which isn't all that bad, but it seems compelling to generate it instead).
Generating the entire HTML page on each request dynamically sounds like a performance issue, if one is using HTML templating libraries.
But I wouldn't know the performance, just a guess.
Probably should look up what is out there after posting this
I see more and more talk of GNU Guix. It's nice to hear its ecosystem flourishing.
Do you find yourself running into more or less annoyances than a usual distro?
I use GNU Guix as a package manager on Ubuntu. I don't use "Guix System" (the standalone OS). Guix is good for getting Common Lisp libraries, with all the dependencies sorted out for you. I use Guix because I don't use Quicklisp. There are more than 500 Common Lisp libraries in Guix at the moment, and it is easy to package additional libraries, since all the foundational ones have already been packaged (e.g. alexandria, usocket, cffi, hunchentoot, etc.).
I also use Guix for:
* Getting newer versions of software that are not yet available in Ubuntu.
* Installing programs from source. With Guix, I can know exactly what a C program depends on, instead of guessing which versions of headers and libraries it really uses.
>>37
You've encouraged me to look a bit deeper, and thank you for the clarification. It slipped my mind that there could be use cases using Guix without the OS.
Did some additional reading. The docs look pleasant. I once gave NixOS a go some years ago and it was a lot of work to get it all configured: which again only reveals how fragile the systems we use are. The syntax of Nix was confusing at times, or not all that expressive. I wasn't patient enough and the documentation was rather lacking, so I reverted back to Fedora. The fact is that I couldn't even create the computer I type on today from scratch...
Some use cases that interests me are lang version management and deployment[0]. I'm currently using asdf[1] for version management, but have no solution for reproducible deployments. To be fair I haven't deployed complex systems a whole lot, but it'd be nice to Do It Right. Having confidence in production would be nice, is all. Most people get that confidence with Docker I suppose.
One thing I'm curious about is your opinion on Nix vs Guix.
[0] https://gitlab.com/pjotrp/guix-notes/-/blob/master/ELIXIR.org
[1] https://github.com/asdf-vm/asdf
One thing I'm curious about is your opinion on Nix vs Guix.
I originally used Nix before moving to Guix. I originally moved because I needed to use Common Lisp libraries and found that there were far more Common Lisp libraries in Guix than in Nix. Here is my biased opinion:
Advantages of Guix over Nix:
* Better documentation.
* Better programming language (Guile Scheme). If you are familiar with Scheme, it is much easier to create your own packages in Guix.
* Friendlier command line interface.
* More Common Lisp libraries.
Advantages of Nix over Guix:
* More packages overall.
* Bigger community.
Overall, I have chosen to use Guix because it is easier to use.
Common Lisp. Common, usual, ordinary, but not extraordinary. Patiently waiting to be replaced as it sits on the sidelines while other languages are updated for the 21st century. Common Lisp is comfortable in the 20th century and wants to stay there forever, even as the world moves past it.