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

91–100 of 126 posts

Re: The Liberating Experience of Common Lisp

#91

Post by whartung »

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…

> Another thing is, that despite Genera having been gone from the real world for over 30 years, it is still nonfree

Eh. That's a non-starter. The code may be closed, the concepts aren't. We've been reinventing the wheel for ages, and the Genera developer experience apparently isn't novel enough to be worthy of being reinvented.

Re: The Liberating Experience of Common Lisp

#92

Post by lispm »

threatofrain wrote: post #90
Ferret7446 wrote: post #89

Earlier quoted context omitted.

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.

The Common Lisp Object System does not use message passing.

Re: The Liberating Experience of Common Lisp

#93

Post by lispm »

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

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

Re: The Liberating Experience of Common Lisp

#94

Post by lispm »

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…

> I don't know how, or what made it more than what Slime might offer beyond nice access to the Mac toolbox).

GNU Emacs plus SLIME is a remote development environment for an external Common Lisp, using a text-editor-based environment.

Macintosh Common Lisp was an integrated GUI-based Common Lisp develop environment written in itself.

Those are two very different things.

> Flavors (Genera's object system)

CLOS and Flavors are both Genera's object systems. CLOS was actually co-developed by Symbolics. The core designers were Keene & Moon from Symbolics Inc., Kiczales & Bobrow from Xerox PARC. and DeMichiel & Gabriel from Lucid Inc.

Re: The Liberating Experience of Common Lisp

#95

Post by ds9soft »

erik_seaberg wrote: post #83
ds9soft wrote: post #18

Earlier quoted context omitted.

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.

Thanks for the correction.

Re: The Liberating Experience of Common Lisp

#96

Post by lispm »

winter_blue wrote: post #49
wglb wrote: 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…

Common Lisp also provides type information, dynamic type information.

    CL-USER 72 > (defclass person () (name age))
    #
I can now ask Lisp to find the class object named person.

    CL-USER 73 > (find-class 'person)
    #
Now I've got a real class object, not just a pointer to dead code. I can inspect it, change it...

I'm adding a slot to an existing class:

    CL-USER 74 > (defclass person () (name age height))
    #
I can then ask for the slots of that class.

    CL-USER 75 > (class-direct-slots (find-class 'person))
    (#
     #
     #)
I can define a method for it.

    CL-USER 76 > (defmethod greet ((a-person person)) (format t "Hello ~a" (slot-value a-person 'name)))
    #
I now can retrieve the method object from its generic function.

    CL-USER 77 > (find-method #'greet () (list (find-class 'person)))
    #
That's live code exploration using dynamic types.

> You can do this with most major languages today as well.

Hmm, I'm in this graphics program on my Mac, how do I "break" the program and then interact with its Objective-C objects?

Re: The Liberating Experience of Common Lisp

#97

Post by ds9soft »

dannyobrien wrote: post #79

I'm a big fan of lisps, and haven't played sufficiently with rust to have an opinion -- but I will note that the benefits of a sophisticated type system is qualitatively different from, say, the statically-typed environment of C or Objective-C. The comparison I make when thinking about CL is something like Haskell or Elm, which /do/ have that feel of "if it compiles, it works". Without that, I do have the feeling of…

The sense of security is provided by a good test suite (which you still need) plus SBCL type annotations.

Re: The Liberating Experience of Common Lisp

#98

Post by taylodl »

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.

> You don't need OO for state management.

Of course you don't, that's why I said OO is most likely the way to go.

I also spoke of more than simple state management - If you're modeling a system having several interacting entities whose interactions may vary based off that entity's current state - isn't simple state management.

You still don't have to go OO to solve that problem, it's just a very good choice in most circumstances.

Also, inheritance is not a core aspect of OO. It's a common aspect of OO and even a popular aspect, but it's not core. To wit, there are OO systems not having inheritance.

Re: The Liberating Experience of Common Lisp

#99

Post by lispm »

AnimalMuppet wrote: post #51
wglb wrote: post #45

Earlier quoted context omitted.

I think that the idea that Lisp is for smart people is misguided and wrong. I don't think a person needs to be a genius to do well in Lisp. As a long-time C and Fortran and Python programmer (and many other languages) it took a long time for me to adjust to the different way of thinking necessitated by Lisp. Also if Copilot or LLM write Go code, why do we think it can't write Lisp code? I've dealt with code in many l…

> I think that the idea that Lisp is for smart people is misguided and wrong. I think it's a misunderstanding. People think that other people are like them (and in particular, think like them). I think that some languages are a better fit for how some people think. Other languages are a better fit for how other people think. It's not "smart vs. dumb", it's different thinking styles. Now, if FP (or at least non-proced…

One idea of using Lisp is to learn new thinking styles for programming. Thinking styles are not fixed. For example an early hurdle in programming / computer science is recursion. Lisp gave the teachers a tool to teach thinking of software development in terms of programming with recursive functions&datastructures, starting with linked lists and operations for it...

Unfortunately students often got the impression that Lisp is only good for learning new ways of thinking (in combination with a theory of recursive functions) and not for actual software development.

Re: The Liberating Experience of Common Lisp

#100

Post by lispm »

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…

Part of the Common Lisp experience is tool building at the language level.

You could be digging a hole with your hands. But thinking a moment, somebody came up with the idea of a shovel. That made a huge difference.

Similar, tool building & usage at the language level can also make a huge difference. In larger applications this makes code much more compact and makes a person more productive.

Post reply on HN