Which LISP should I learn? Years ago I read about Scheme and wrote some hello world level code. I learned about lambda functions and currying. I also looked at racket. A few years ago, much of my day job involved the JVM and I was getting sick of Java so I got a book on Clojure, which is a very nice language, but I never wrote any.
A few days ago I downloaded and built the latest version of DrRacket.
Should I go straight to Haskell? Or what about other functional languages? Is Erlang worth a look?
I need something stimulating to distract my brain from the mundane nature of everyday life, and mediocre programming languages.
(Score: 3, Insightful) by DannyB on Monday November 29 2021, @08:42PM
There is a lot more than I can write here. I hope some of these ideas will fire your imagination.
From late 1986 to early 1993 I got into Common Lisp. Wrote lots of fun code. Not to do anything practical. But to stretch my abilities. Solve puzzles. Dabble with natural language processing (remember early 90's now so don't be judgemental). Pattern matching. Pattern rewriting systems. Toy compilers. Toy text "adventure" type games. (Yes, Lisp is good for this)
I started looking at Clojure because it was interesting, and it happened to run on JVM. In 2014 I started seriously playing with Clojure. Like my Common Lisp adventures, I wrote lots of code, but not to do anything really practical. Just to scratch my own itch. Solve interesting problems. Learn things. Project Euler problems. [projecteuler.net]
I've dabbled with DrRacket.
Some things that are outstanding about Clojure:
In a nutshell, in Clojure more so than Common Lisp, I could think about my problem and not end up with weird bugs because I ended up mutating data structures for "efficiency" but that efficiency ruined some abstraction. In other words, Clojure let me think at a higher level and not get bogged down in machine details -- even in Common Lisp.
I will always fondly remember Common Lisp. But I had loads of fun with Clojure.
Think about: how would you build an infinite list of Pythagorean triples? A2+B2=C2. Iterate through all of the possible A's. For each A, iterate through all of the possible B's. But how far? When do you stop searching for a higher B because you can prove there will never be another, and you should now move on to the next A? When you are iterating over the A's and B's should you iterate only over your infinite list of prime numbers, or all possible integers? Obviously, each search for B values should begin with the current A value, but why?
This is but one of many examples of experimentation, learning and diversion that you can do a lot of thinking about. Some of the thinking is about math and proving things. Some thinking is about efficiency of algorithms. (And I don't mean saving a cpu cycle or a byte here or there like in C.)
I know it's a solved problem, but write: A sudoku solver. A rubick's cube solver. An "unblock me" solver. (Google it) Write a Minimax game engine that supports plug in board scoring functions for TicTacToe, Connect 4, Checkers and Reversi all using the same generic Minimax engine.
If you're using Clojure in Java instead of Javascript, you can also access MIDI.
If you're in to Scheme, get a book called The Reasoned Schemer which introduces you to a logic system called Mini-Kanren. Clojure has a similar system as a package called Core.Logic.
In fact, the library/packages available for Clojure are fertile ground for experimentation. Try InstaParse. You just feed it grammar. No need to worry about LALR or LL(1), or right or left recursive. Just mix them all up together in your grammar and InstaParse will parse your input from your grammar and build a tree for you.
I truly hope your muse will distract you from the ordinary, mundane, mediocre of every day programming and languages. Best of luck!