Live data from Hacker News

The Liberating Experience of Common Lisp

ds9soft.com

61–70 of 126 posts

Re: The Liberating Experience of Common Lisp

#61
post #11

Having programmed professionally in 36 languages, I must agree with this. I am having so much fun with Lisp, that I am not likely to go back. > Often developers say how you can make a mess of a Common Lisp codebase because of such freedom it provides. But isn’t that the same with any language? There is a story about the code behind the terminal interface for Tops-10 for the PDO-10. It had been tweaked over the years…

> Three things are killer features for me with the slime+emacs running sbcl. First is that you can see the underlying source for anything down to the lisp implementation, e.g. the definition of 'macrolet'. If you’re working on a project (on its code), then you can (obviously) see its code as well. Statically typed languages make exploring the code a lot easier, especially with an IDE which leverages the type informat…

I was likely not clear in my explanation.

These three things are all done from the REPL. I don't have any experience doing C or C++ from a REPL.

I disagree that "Statically typed languages make exploring the code a lot easier." I'm not aware of an equivalent in C or C++ to the "esc-." method of going directly to the source.

The keystroke combination to find the definition of a function or symbol using slime and emacs is "esc-." That takes you right to the code. If it is a symbol defined by Lisp, you see the underlying code in the actual source for Lisp.

So the second thing is also done when running a program from the REPL. Once tripped, you can expand each element in the stack to see and inspect the variables local to that function. You can then edit the source for that function, compile only that function in place, then resume execution. I admin that I don't know how to do that in C or C++.

My explanation should have referenced the REPL, which is key to these.

Re: The Liberating Experience of Common Lisp

#62
post #41

It really echoes my first memories of personal computers. You powered it on, and it landed you in a BASIC environment. Apple IIs, C64’s and Ataris all had a full-screen editor environment where you could type code, run it, pause it, inspect variables, and continue running. It wasn’t LISP, sadly, but it was great as an introduction and moving to “more professional” environments and tools took away a great deal of free…

I’m slowly working in something like portacle+multimedia: so you can turn on the computer, emacs starts, an you go doing a little game…

I think deep inside the 8-bit retro people miss that, not the slow-low-resolution computers, but the experience of actually “making” something.

Re: The Liberating Experience of Common Lisp

#63
post #12

Apologies for donning my grumpy old man hat. I like CL as much as the average dev who's dabbled with it on weekends but can't find anyone to pay me to use it, but...this essay really adds so little to the conversation about it. There's not an awful lot explicitly wrong in it per se, but people have been writing these little puff pieces on their blogs about Lisp for (at least) twenty years now. This checks all the usu…

This is a good perspective. I did work in lisp, including production systems (albeit small systems), for many years and authored many open source projects in CL. I'd say the biggest hurdle was the community. There was a strange balance between getting contributors and people going off and rewriting the thing you're working on becuase they can do it better/make it faster/etc. It definitely skews towards people going lone-wolf. A lot of people said this going in but I ignored it because I love the language (still do) but eventually got burned out on trying to do anything real with CL. I absolutely did get highly impactful contributors on some of my projects, and I'm still thankful to them, but there was also some "this isn't fast enough I'm going to just rewrite it" that frustrated me a lot.

One place I think CL absolutely would shine is game dev. I started using it for that a bit and the ability to redefine the system while it's running is an incredible superpower. Forget compile times, rebuilding the state of a game can take a long time and being able to fix a bug or adjust behavior right then and there is really cool. This probably isn't even novel anymore given modern game engines, but at the time I loved it.

Re: The Liberating Experience of Common Lisp

#64
post #35

Earlier quoted context omitted.

I wish you could use Genera. If you like emacs/slime. You would see how much we lost :(

What Genera ideas are Emacs/SLIME missing out on that would improve them?

YouTube video demoing Genera, among other things:

https://www.youtube.com/watch?v=7RNbIEJvjUA

Re: The Liberating Experience of Common Lisp

#65
post #34

Earlier quoted context omitted.

I didn't give any career advice at all. Why did you think this was it? My career advice would be to keep developing in whatever established and practical language you are using and get paid to use if that's what you want.

Ah, then I accept your advice. I happen to like programming, but I also view it as a practical skill and a means to an end. That's the lens through which I was viewing your post. If your central point was that you personally enjoy Lisp, then I don't have an opinion one way or the other.

I also view it a as practical skill. I'm paid to write in a practical language which is mutating into a monster I no longer consider fun to write in.

But as I started a new project which eventually could be a business, then I can use whatever language I want, as long as it's practical for my use case. Why would I use any other language than one that I already know and like? It would make no sense. If you were to start your project, you would probably pick a language you enjoy using, rather than the one you are paid to use, unless it happens to be the same.

Re: The Liberating Experience of Common Lisp

#66
Am I the only one who just bounces off the ecosystem? I don't mean emacs/slime/sbcl, it's once you get beyond that.

In my most recent foray I wanted to give roswell, qlot, and quicklisp a proper try, because I really want to find the Right Way to consume dependencies with proper version management. It's what I'm used to in just about every other context. But the version of qlot you get through roswell is old, nothing in that stack is doing versioned dependency resolution, and despite claims of stability, SBCL and ASDF seem to have had incompatibilities recently that'll trip you up if you happen to install the wrong thing, so you don't get Clojure's "code from a decade ago just works" effect.

What have I missed? It feels like I'm holding it wrong.

Re: The Liberating Experience of Common Lisp

#67

Lisp really is an eye-opening experience when learning to structure programs and computations. Stumbling on Lisp in college was a fascinating experience for me in particular because I had been raised around C++ and Java, and my programming life up to that point had been a struggle understanding how to abstract a program into objects and how to build those objects' interfaces. Once I started down the path of functiona…

> Maybe because it's easy to decouple data from operations on that data, even if stateful You can use objects in C++ and Java without mixing code and data (by having data-only and code-only classes for example). I haven't fully read it, but there's a book from a clojure developer about about this: https://www.manning.com/books/data-oriented-programming The book itself uses Java, not Clojure.

Sorry for going off-topic, but why is this comment being downvoted?

The comment provides an alternative view on things and even links to a nice book. One may not agree with the perspective, but that's no reason to downvote.

Perhaps it's the user interface (a special upvoting wand would be most welcome for those of us whose fingers are too fat). Or have we reached the stage where script kiddies deploy downvoting bots if they didn't like a comment in another thread?

Re: The Liberating Experience of Common Lisp

#68
post #12

Apologies for donning my grumpy old man hat. I like CL as much as the average dev who's dabbled with it on weekends but can't find anyone to pay me to use it, but...this essay really adds so little to the conversation about it. There's not an awful lot explicitly wrong in it per se, but people have been writing these little puff pieces on their blogs about Lisp for (at least) twenty years now. This checks all the usu…

This is a good perspective. I did work in lisp, including production systems (albeit small systems), for many years and authored many open source projects in CL. I'd say the biggest hurdle was the community. There was a strange balance between getting contributors and people going off and rewriting the thing you're working on becuase they can do it better/make it faster/etc. It definitely skews towards people going l…

That's true of any language or project to be fair. Big egos are everywhere in software development.

Re: The Liberating Experience of Common Lisp

#69

Earlier quoted context omitted.

OP hasn't even really used Lisp in anger, yet This struck me, too. My current hobby project is in Go and I'm really quite enjoying it. It doesn't feel "soulless" to me at all. That said, I'm well aware that my opinion may be different if I had to write Go for a living instead of just for fun.

I've also been dabbling in Go recently, and I'm finding that the culture surrounding it is one of actually understanding what your code does. My main language is Ruby. It hits many of the same high notes that Lisp programmers talk about, and I enjoy writing it. There's just something about the practical, concrete nature of Go code that appeals to me.

Someone once wrote that "Ruby is an acceptable Lisp."

Is Go your first static language? It's not a particularly good one except for certain niches. You might try some others.

Re: The Liberating Experience of Common Lisp

#70
post #54
post #52

Earlier quoted context omitted.

A big piece of OO development is state management. If you're modeling a system having several interacting entities whose interactions may vary based off that entity's current state - then OO is most likely the way to go. You can encapsulate that state management in one place rather than having it strewn throughout the entire codebase. If you're doing information-oriented processing, whether it be a traditional batch…

CL can do OO programming too.

What killed Scala at my last employer was that nobody could agree on what idiomatic code should look like, so there were vast stylistic differences between areas. Despite working in the same language, it ended up being hard to move between codebases, in unpredictable ways.

This strikes me as the same sort of flexibility: you can do just about anything. If you do do just about anything, it's a bad time for all concerned.

Post reply on HN