Stories
Slash Boxes
Comments

SoylentNews is people

Journal by turgid

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.

 

Reply to: Distractions from the mediocre - Which Lisp

    (Score: 3, Insightful) by DannyB on Monday November 29 2021, @08:42PM

    by DannyB (5839) Subscriber Badge on Monday November 29 2021, @08:42PM (#1200684)

    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:

    • "Persistent" data structures. eg, everything is immutable. No surgical splicing operations on data structures like Common Lisp can do. Now this has a profound effect on solving many types of tree search or graph search algorithms. Game play. Puzzle solution. Etc. If I make a mutation to, say, a game board, I still have the original board. And the new mutated board. Even if all I did was change one element of a large array -- I now have two versions of that large array. And it is efficient. This means you never have to develop operations that copy an entire data structure. This automatically happens when you change anything. You have the original still, and the modified version. And it is not a giant copy. (Internal implementation: they still share immutable structure of much of the non changed parts. You don't have to worry about how it works. It's all explained.)
    • List operations are lazy. This has another profound effect. You can simply implement infinite lists of things via recursion and not worry about getting stuck in an infinite loop. As you pull more and more elements off the infinite list, more and more of the list gets created. Such as a list of all prime numbers, or Fibonacci numbers, or Pythagorean right triangle integer triplets. Try creating a list combinations or permutations function that works on an infinite list. "Give me every possible 6 element group of prime numbers."
    • side diversion: if you develop a lot of functions to do with prime numbers, you start to find there are a lot of interesting problems that are now easily solved

    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!

Post Comment

Edit Comment You are not logged in. You can log in now using the convenient form below, or Create an Account, or post as Anonymous Coward.

Public Terminal

Anonymous Coward [ Create an Account ]

Use the Preview Button! Check those URLs!


Logged-in users aren't forced to preview their comments. Create an Account!

Allowed HTML
<b|i|p|br|a|ol|ul|li|dl|dt|dd|em|strong|tt|blockquote|div|ecode|quote|sup|sub|abbr|sarc|sarcasm|user|spoiler|del>

URLs
<URL:http://example.com/> will auto-link a URL

Important Stuff

  • Please try to keep posts on topic.
  • Try to reply to other people's comments instead of starting new threads.
  • Read other people's messages before posting your own to avoid simply duplicating what has already been said.
  • Use a clear subject that describes what your message is about.
  • Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)
  • If you want replies to your comments sent to you, consider logging in or creating an account.

If you are having a problem with accounts or comment posting, please yell for help.