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

111–120 of 126 posts

Re: The Liberating Experience of Common Lisp

#111

Post by lispm »

winter_blue wrote: post #109
lispm wrote: post #108

Earlier quoted context omitted.

> Most of the features I've described above work with C and C++ IDEs In Common Lisp you won't need an IDE and you won't need to instrument the application with a debugger, because much of the features are built into the language runtime. For example Common Lisp has an error handling system with resumeable exceptions. Another example is the object system where the objects are updated on changes. For example I can load…

All of this late binding, and needing a runtime, seems to suggest even a JIT LISP implementation (e.g. SBCL) might not be able to achieve performance similar to a "zero-cost abstraction" language like Rust. When you're in debug mode (e.g. with C++ or Rust or a JVM language), there's a bunch of debug info added to the binary plus various optimizations are turned off. I'm sure some optimizations that C++ / Rust / LLVM…

> might not be able to achieve performance similar to a "zero-cost abstraction" language like Rust

That might be the case, even though SBCL might have some performance improving features, like a runtime compiler (which can be used to improve performance at runtime) and the capability to implement assembler extensions to the compiler from Lisp.

> There's an argument to be made for this approach, at least for software that's run on customers' computer. For server side software, I can see why having always-available debuggability is useful.

I see no reason, why this should not be useful on the client side, too. Many software systems on the client side have ways to extend them. Doing this in the main implementation language can have advantages, instead of doing it in a limited macro or scripting language.

Re: The Liberating Experience of Common Lisp

#112

Post by dunefox »

taylodl wrote: post #102
lispm wrote: post #101

Earlier quoted context omitted.

> not a core aspect of OO One of the core aspects of OO is reuse of functionality, typically by inheritance or delegation. We can find one or both in most OO languages.

I wouldn't say reuse of functionality is a core aspect of OO, but I will say that's a core reason why OO was so heavily adopted in the 90s. It's mind-numbing to recall how much time and money was wasted on making things "reusable" only to never be reused.

> I wouldn't say reuse of functionality is a core aspect of OO,

That's what was taught to me in computer science at university, along with Java (sadly).

Re: The Liberating Experience of Common Lisp

#113

Post by dunefox »

lispm wrote: post #93
ivan4th wrote: post #81

Earlier quoted context omitted.

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

The Meta-Object Protocol is optional and not a part of the standard.

It would be far more consistent than the Scala in the example, if everyone used SBCL with the same implementation, right?

Re: The Liberating Experience of Common Lisp

#114

Post by dunefox »

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…

Please do continue to write about Lisp.

Re: The Liberating Experience of Common Lisp

#115

Post by regularfry »

ivan4th wrote: post #81
regularfry wrote: post #70

Earlier quoted context omitted.

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

Well yes. The problem isn't people building their own implementation. The problems with Scala aren't with them inventing their own type system, or pattern matching, or whatever. It's the lack of agreement on what is the idiomatic subset of features to use in a given environment.

Re: The Liberating Experience of Common Lisp

#116

Post by dunefox »

oersted wrote: post #58
RandomCitizen12 wrote: post #13

> How long before Copilot is able to write all the code any Go developer now writes by hand? A long time ago I read someone saying "Lisp is the only language where I spend more time thinking than typing". Recently, when I was telling ChatGPT what logic I wanted written on what data structures, I realized the same was true about having an LLM write any other language.

Honestly, to me that sounds like a red flag. There are already too many temptations to get on a purist mood and spend ages thinking about elegant code structure. I know, it's ambiguous, "more time thinking than typing" might imply that you spend more time thinking about the core problem you are solving. But let's be real, it's Lisp, you are thinking about how to model your problem elegantly in Lisp, not about how to…

> But let's be real, it's Lisp, you are thinking about how to model your problem elegantly in Lisp, not about how to solve it.

But let's be real, it's Java, you are thinking about how to model your problem as a class structure in Java, not about how to solve it.

Re: The Liberating Experience of Common Lisp

#117

Post by anthk »

lispm wrote: post #93
ivan4th wrote: post #81

Earlier quoted context omitted.

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

The Meta-Object Protocol is optional and not a part of the standard.

Every modern CL compiler (SBCL, CCL, ECL)... will implement it 'de facto'.

Re: The Liberating Experience of Common Lisp

#118

Post by lispm »

anthk wrote: post #117
lispm wrote: post #93

Earlier quoted context omitted.

The Meta-Object Protocol is optional and not a part of the standard.

Every modern CL compiler (SBCL, CCL, ECL)... will implement it 'de facto'.

It's just that "it" has no defined standard. See https://github.com/pcostanza/closer-mop/blob/master/features... for the MOP differences on platforms which have support.

Closer to MOP is a library which tries to fix many/most of these differences.

https://github.com/pcostanza/closer-mop

Re: The Liberating Experience of Common Lisp

#119

Post by taylodl »

lispm wrote: post #103
taylodl wrote: post #102

Earlier quoted context omitted.

I wouldn't say reuse of functionality is a core aspect of OO, but I will say that's a core reason why OO was so heavily adopted in the 90s. It's mind-numbing to recall how much time and money was wasted on making things "reusable" only to never be reused.

> I wouldn't say reuse of functionality is a core aspect of OO You'll find it in practically every object-oriented language, starting with Simula. Later Smalltalk, Actors, CLOS, C++, Self, Java, Objective-C, Python, JavaScript, ... > making things "reusable" only to never be reused. It's similar mind-numbing how much has been reused.

> It's similar mind-numbing how much has been reused.

My experience is the reuse comes from frameworks. I'd love to hear if you've had another experience.

Re: The Liberating Experience of Common Lisp

#120

Post by lispm »

taylodl wrote: post #119
lispm wrote: post #103

Earlier quoted context omitted.

> I wouldn't say reuse of functionality is a core aspect of OO You'll find it in practically every object-oriented language, starting with Simula. Later Smalltalk, Actors, CLOS, C++, Self, Java, Objective-C, Python, JavaScript, ... > making things "reusable" only to never be reused. It's similar mind-numbing how much has been reused.

> It's similar mind-numbing how much has been reused. My experience is the reuse comes from frameworks. I'd love to hear if you've had another experience.

Yes, there are a bunch of frameworks, which make use of inheritance and/or delegation.

Flavors (an early object-oriented system for Lisp, early 80s) provided multiple-inheritance, mixins, method combinations, etc. and a bunch of software made use of its features. Object Lisp was another OO system for Lisp, which one used for example in an interface builder, which made extensive use of delegation. The Common Lisp Object System later was designed improving on Flavors and LOOPS (from Xerox), switching away from message passing, adding multiple dispatch. Thus dispatch based on inheritance works over possibly multiple arguments.

Inheritance and delegation have a long history in Lisp going back to the 70s.

Post reply on HN