Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Liberating Experience of Common Lisp

ds9soft.com

Post reply on HN
Print view View original

81–90 of 126 posts

Re: The Liberating Experience of Common Lisp

#81

Post by ivan4th »

regularfry wrote: post #70
anthk wrote: post #54

Earlier quoted context omitted.

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 concern…

Common Lisp has CLOS (Common Lisp Object System), which is quite sophisticated object system with metaobject protocol and multiple dispatch, as a part of its spec. Not that it's smth people need to invent on their own each time

Re: The Liberating Experience of Common Lisp

#82

Post by downut »

regularfry wrote: post #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 this comment, I am a common-lisp noob, no competency at all. I have used and written a lot of sw in a lot of languages over 40 years though.

Keeping in mind the concepts of per-user and per-project installations, I have done the following experiments:

1) Quicklisp only. Not beating on Zach but we're getting close to a year w/o updates, so something like cl-transducers needs to be installed from upstream. Upshot is, other than the lack of updates, adding packages works perfectly. But I am curious how to delete a package. Installation is per-user, although stuffing packages into the asdf visible directories give some customization ability. (I think?)

2) The whole shebang: ros + ros-quicklisp + qlot. I spent a few weeks with this combo, digging around the code and installation structure, and... I have no idea how to manage this thing down the road. Seems to work, but there's a lot of assumptions about per-project vs per-user package installation. AFAICT, ros packaging means per-project quicklisp, which is fine, but no versioning. So then add qlot. Now we have versioning, which is great, but how do ros installed quicklisp packages interact with qlot? Especially since qlot add is a thing.

3) In order to simplify the system (ahem) I decided to follow the hints in the qlot installation section and simply install qlot with no quicklisp or ros on a clean system (ahem). I also reinstalled sly from clean and found out that I had to install sly-quicklisp in order for it to work. That was yesterday and I'm still scratching my head about what kind of a beast I am working with. What part is quicklisp and what part is qlot? I am also working a lot closer to asdf, experimenting at each step. Learning a lot, but, I'm not really getting a lot of happiness out of wading through at the source code level all these overlapping packaging systems (ahem). If I persevere I suspect I'll know a lot about the current state-of-the-art of lisp library packaging.

I am right now contemplating clearing the deck once again and doing the 2) ros + ros-quicklisp + qlot again, because it seem to work fairly smoothly and provides the opportunity for per-project versioning. I'll have to defer the understanding part into the future, though.

Re: The Liberating Experience of Common Lisp

#83

Post by erik_seaberg »

ds9soft wrote: post #18
wk_end wrote: 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…

Blog post author here: True. But there's no reason not to write when you are in anger about other languages that you do use every single day. I guess I was just venting and also reaffirming my intention to use CL. I have used it before in a previous job for a quick tool and I know it can be used for more complex stuff, which I have already started building. I haven't been writing a major piece of software in Lisp for…

"Used in anger" means for a serious goal. It's an analogy for firing a gun in combat rather than just for training or testing.

Re: The Liberating Experience of Common Lisp

#84

Post by pfdietz »

wglb wrote: post #14
adamc wrote: post #2

I can relate. I read Graham's book on Common Lisp more than 20 years ago and was entranced. But opportunities to use it in the day job are few and far between, and I would have qualms about recommending it, in most contexts. For a lot of purposes, its libraries are just nowhere near as good as Python or JavaScript or Java. And some of its superpowers (macros!) can also be used really, really badly. There was an essay…

> Lisp being a "language for smart people" But doesn't autocad have lisp as a language behind the scenes and I would guess that autocad is used by folks who aren't full-time programmers? Also, I always found a way to use lisp, even when I was CSO. But admittedly these were side projects.

It has a version of lisp behind the scenes. It's not Common Lisp.

Re: The Liberating Experience of Common Lisp

#85

Post by dokyun »

whartung wrote: post #71
ilc wrote: post #35

Earlier quoted context omitted.

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

But here's the thing, and I don't know, I never worked with Genera. But. Genera has been gone for over 30 years. At the time, it was certainly revolutionary. But in the computing world, where things move VERY fast, whatever made Genera amazing clearly wasn't amazing enough to replicate in full anywhere else. I'm not even talking about other languages, trying to get that dynamic environment in modern languages, with m…

Another thing is, that despite Genera having been gone from the real world for over 30 years, it is still nonfree, and most of the interesting software that ran on it hasn't been publically archived either. That has made it essentially worthless to most people who would otherwise be interested in it. On the contrary, the MIT Lisp Machine system from which Genera was derived is completely free, as well as the LMI system which was another derivative. And there are a small handful of enthusiasts who continue to use, share and improve them.

Re: The Liberating Experience of Common Lisp

#86

Post by anthk »

dokyun wrote: post #85
whartung wrote: post #71

Earlier quoted context omitted.

But here's the thing, and I don't know, I never worked with Genera. But. Genera has been gone for over 30 years. At the time, it was certainly revolutionary. But in the computing world, where things move VERY fast, whatever made Genera amazing clearly wasn't amazing enough to replicate in full anywhere else. I'm not even talking about other languages, trying to get that dynamic environment in modern languages, with m…

Another thing is, that despite Genera having been gone from the real world for over 30 years, it is still nonfree, and most of the interesting software that ran on it hasn't been publically archived either. That has made it essentially worthless to most people who would otherwise be interested in it. On the contrary, the MIT Lisp Machine system from which Genera was derived is completely free, as well as the LMI syst…

Not Genera, but InterLisp/Medley it's MIT licensed.

Re: The Liberating Experience of Common Lisp

#87

Post by dokyun »

anthk wrote: post #86
dokyun wrote: post #85

Earlier quoted context omitted.

Another thing is, that despite Genera having been gone from the real world for over 30 years, it is still nonfree, and most of the interesting software that ran on it hasn't been publically archived either. That has made it essentially worthless to most people who would otherwise be interested in it. On the contrary, the MIT Lisp Machine system from which Genera was derived is completely free, as well as the LMI syst…

Not Genera, but InterLisp/Medley it's MIT licensed.

Yes, and the Medley Interlisp revival project seems to have become very successful.

Re: The Liberating Experience of Common Lisp

#89

Post by Ferret7446 »

taylodl wrote: post #52
netbioserror wrote: post #4

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…

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…

You don't need OO for state management. Plain data structures and functions work just fine.

The core aspects of OO like inheritance are not that useful for most problems.

Re: The Liberating Experience of Common Lisp

#90

Post by threatofrain »

Ferret7446 wrote: post #89
taylodl wrote: 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…

You don't need OO for state management. Plain data structures and functions work just fine. The core aspects of OO like inheritance are not that useful for most problems.

IMO inheritance is more syntactical QoL than core. That’s just code DRY stuff and composition is fine for that too. The architectural elements of OO are state machine modeling (encapsulation) and message passing.
Post reply on HN