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

It's 2023, so of course I'm learning Common Lisp

log.schemescape.com

Post reply on HN
Print view View original

261–270 of 346 posts

Re: It's 2023, so of course I'm learning Common Lisp

#261

Post by eadmund »

SanderNL wrote: post #218
ilrwbwrkhv wrote: post #3

Steel Bank Common Lisp is the workhorse which led me to build profitable software companies. I don't think I would be as productive without it. The repl driven workflow is amazing and the lisp images are rock solid and highly performant.

I think the times when your tech stacks mattered in the slightest are mostly behind us. Also: it's good you concocted some arcane shit that works like a charm, but now nobody - except the ones whose pay you express in number of zeroes - is touching it.

I think that you’re just restating the Blub point of view. You look back on the tech stacks of the past, and can see how they were worse than the ones we have today, but looking at the ones today you think that there are no more improvements to be made — or at least, none that matter.

Given that (I assume) you really do appreciate how much better the stacks of today are then the ones of the past, that seems a highly unwarranted assumption. Heck, I will tell you this: as much as a Lisp stack is better than the alternatives today, it’s not perfect. There’s a ton of future work to improve things even above the current state of the art.

But that state of the art is still better than what everyone else is using. What’s great about Lisp is that improvements are possible: with other technologies, there are more hard limits on what can be done.

Re: It's 2023, so of course I'm learning Common Lisp

#263

Post by SanderNL »

eadmund wrote: post #261
SanderNL wrote: post #218

Earlier quoted context omitted.

I think the times when your tech stacks mattered in the slightest are mostly behind us. Also: it's good you concocted some arcane shit that works like a charm, but now nobody - except the ones whose pay you express in number of zeroes - is touching it.

I think that you’re just restating the Blub point of view. You look back on the tech stacks of the past, and can see how they were worse than the ones we have today, but looking at the ones today you think that there are no more improvements to be made — or at least, none that matter. Given that (I assume) you really do appreciate how much better the stacks of today are then the ones of the past, that seems a highly…

Given the myriad other variables that go into a successful software business, the choice of stack and its various modes of expressing whatever transformation on whatever data it is you are mangling is so exceedingly minor a consideration that I'm close to experiencing it as professional negligence to even fuss over it to the degree it is being fussed over by many people.

I'm not dissing Lisp by any means by the way.

Re: It's 2023, so of course I'm learning Common Lisp

#264

Post by kgwgk »

dleslie wrote: post #138
Capricorn2481 wrote: post #100

Earlier quoted context omitted.

I'm confused. Why aren't you all just working on your own machines?

The classic lisp way is to build a runtime image by editing the image while running it, then dumping a binary. You never specifically need to load a source file. But you can't easily collaborate with that style of development.

> The classic lisp way is to build a runtime image by editing the image while running it, then dumping a binary. You never specifically need to load a source file.

Says who?

Re: It's 2023, so of course I'm learning Common Lisp

#265

Post by db48x »

pjc50 wrote: post #244
db48x wrote: post #64

Earlier quoted context omitted.

See also advertising. C++ and Java had enormous advertising budgets, while Common Lisp had virtually none. For years, virtually every programming book and magazine was touting C++ and then later Java. Every conference, every keynote, everything a CTO might ever read or notice was telling them to use C++ or Java.

C++ itself never had a marketing budget! The nearest you might find is marketing for implementations back when people paid for programming languages, but the only surviving one of those is really Visual Studio. Lisp has had decades to break out of its niche if it delivered a really advantageous solution, but somehow that never happened.

Yes, and whose advertisements do you think show up in every single one of those magazines? Which implementations get mentioned by every single C++ book? Which organization sponsored every single C++ conference? Don’t forget that they had stiff competition from the advertising budgets of other large companies, such as Oracle and IBM.

Also, don’t forget that Lisp machines were once the most coveted development machines on the market. But Symbolics had to develop not only the language and IDE, but also the OS, the hardware, the microcode, and everything else all at once. It’s pretty telling that they soon began running Unix (on a separate processor) and then their next product was an add–in card for an Apple Macintosh II containing a Lisp processor ASIC. By then the C++ hype train was gathering steam and the AI winter had begun. Symbolics didn’t survive, and their direct competitor LMI had even less chance. So it’s not that Lisp offers no advantages, it’s just that market conditions killed off the companies that were offering it. Note that these market conditions were created by advertising and shifting public perception.

I thus return to my thesis, which is that the market success of a language has little, if anything, to do with the advantages of the language. Instead marketing and advertising rule the day.

Re: It's 2023, so of course I'm learning Common Lisp

#266

Post by getpokedagain »

sireat wrote: post #159
lispm wrote: post #156

Earlier quoted context omitted.

How does it look like in Python? In Lisp: CL-USER 43 > (+ 1 (foo 20)) Error: Undefined operator FOO in form (FOO 20). 1 (continue) Try invoking FOO again. 2 Return some values from the form (FOO 20). 3 Try invoking something other than FOO with the same arguments. 4 Set the symbol-function of FOO to another function. 5 Set the macro-function of FOO to another function. 6 (abort) Return to top loop level 0. Type :b fo…

Hmm, what advantage does Lisp offer here over Python? >>> 1 + foo(20) Traceback (most recent call last): File " ", line 1, in NameError: name 'foo' is not defined >>> def foo(a): ... return a + 21 File " ", line 2 return a + 21 ^ IndentationError: expected an indented block >>> def foo(a): ... return a + 21 ... >>> 1 + foo(20) 42 >>> Mind the hilarious indentation error, as I had not touched the old-school REPL in ag…

You got a lot of correct but verbose responses. Put in layman's terms you had to run 1 + foo(20) again. If 1 + foo(20) were replaced by a complex and long winded function you would have lost all of that state and needed to run it all again. What if 1 + foo(20) had to read several TB of data in a distributed manner. You would have to do that all again.

There are ways around this and of course you could probably develop your own crash loop system in python but in lisp you simply continue where it failed. It's already there.

You mention doing things in Jupyter and ETLs which are often long running. This could be hugely beneficial to you.

Re: It's 2023, so of course I'm learning Common Lisp

#267

Post by realharo »

aidenn0 wrote: post #257
realharo wrote: post #242

Earlier quoted context omitted.

Won't you also be more likely to write code based on data that you happen to have in the current situation, but not for data that covers every situation? E.g. code that accesses an optional property as if it was always present, because it happens to be present when you're writng the code, etc. That seems like a possible pitfall when relying on a REPL heavily, but I haven't used such a language myself, so can't speak…

And with TDD, aren't you ore likely to write code based on the current tests you have, but not code that covers every situation? Any time writing code, you (should) aim for the general situation and then test it with whatever edge-cases you think of at the time. The REPL lets you live-test. I know many people who dump their REPL history to a file and turn them into tests.

My point was, having an actual example of data in front of you, instead of only definition of the structure/schema/interface/type of the data could push people more towards relying on things specific to that example. Especially in dynamically typed languages, but also for things like trying to take the first element of a list that might be empty (in languages where that doesn't return an `Option`), etc.

And I wonder whether someone observed that in practice.

Re: It's 2023, so of course I'm learning Common Lisp

#268

Post by eadmund »

mathisfun123 wrote: post #86
LispSporks22 wrote: post #85

Earlier quoted context omitted.

In TFA, go to the “Try this in your favorite repl”, try that in your “repl” and that would be the fine distinction you’re missing.

>The answer to that question is the differentiating point of repl-driven programming. In an old-fashioned Lisp or Smalltalk environment, the break in foo drops you into a breakloop. do you want me to show you how to do this in a python repl? it's literally just breaking on exception...

No, it’s not: an exception unwinds the stack all the way up to where the exception is caught. By the time the enclosing Python pseudo-REPL sees the undefined function error, all the intervening stack frames have dissolved. The way it works is that a function tries code, and catches exceptions.

In Lisp (and I believe Smalltalk), it doesn’t work that way: there is an indirection. Rather than try/except, a function registers a condition handler; when that particular condition happens, the handler is called without unwinding the stack. That handler can do anything, to include reading and evaluating more code. And re-trying the failed operation.

It would be possible to implement this in Python, of course, but it doesn’t offer the affordances (e.g. macros) that Lisp has, and it’s not built into the language like it is in Lisp (e.g., every single unoptimised function call in Lisp offers an implicit ‘retry’).

Re: It's 2023, so of course I'm learning Common Lisp

#269

Post by eadmund »

mathisfun123 wrote: post #148
vkazanov wrote: post #143

Earlier quoted context omitted.

The answer to all these things should be "just doesn't work in practise", not for real programs anyways. Unlike Lisp, Python doesn't lean itself well to this mode of development. Primitive CLI-like tinkering, figuring out language features, calc-like usage - maybe. But not a single time in 15 years of doing Python across the industry I saw anybody using these features for serious program development, or live coding,…

>Primitive CLI-like tinkering, figuring out language features, calc-like usage - maybe. But not a single time in 15 years of doing Python across the industry I saw anybody using these features for serious program development, or live coding, or REPL-driven development. I swear you people are like ostriches in the sand over this - Django, pytest, fastapi, pytorch, Jax, all use these features and more. I work on DL com…

> Really what this convo is doing is underscoring for me how there really is nothing more to be learned from lisp - I had a lingering doubt that I'd missed some aspect but you guys are all repeating the same thing over and over.

No, you keep on misunderstanding what people are trying to tell you. It’s a communication failure. The thing that you think you are doing in Python is not the thing that people are doing in Lisp.

As an example, I suppose that when you’re developing code in Python’s pseudo-REPL you often reimport a file containing class definitions. When you do that, what happens to all the old objects with the old class definition? Nothing, they still belong to the old class.

If you did this on a REPL connected to a server, what would happen to the classes of objects currently being computed on? Nothing, they would still belong to the old class.

In Lisp, it’s different. There is a defined protocol for what happens when a class is redefined. Every single object belonging to the old class gets updated to the new class. You can define code to get called when this happens (say, you added a new mandatory field, or need to calculate a new field based on old ones — and of course ‘calculate’ could also mean ‘open a network connection, dial out to a database and look up the answer’ or even ‘print the old object and offer the system operator a list of options for how to proceed’). And everything that is currently in-flight gets updated, in a regular and easy-to-understand way.

People are telling you ‘with Lisp central air conditioning, I can easily heat my house in the winter’ and you are saying ‘with Python, I can easily build a fire whenever my house gets cold too!’

Re: It's 2023, so of course I'm learning Common Lisp

#270

Post by eadmund »

mathisfun123 wrote: post #142
lispm wrote: post #140

Earlier quoted context omitted.

> I have already addressed this: FullForm No you haven't addressed it. The "Wolfram Language" user typically does not write code in FullForm. It's used as an internal representation. > it's just that it's very good at beta reduction and not so good at compiling code... https://reference.wolfram.com/language/ref/Compile.html See "Details and Options"

>The "Wolfram Language" user typically does not write code in FullForm. It's used as an internal representation. I have no clue what you're talking about - it's an available primitive and I use it all the time. >and not so good at compiling code... Lol I am 100% sure that the majority of lisps cannot be aot compiled.

> Lol I am 100% sure that the majority of lisps cannot be aot compiled.

    CL-USER> (defun foobar (x) (1+ x))
    FOOBAR
    CL-USER> (disassemble #'foobar)
    ; disassembly for FOOBAR
    ; Size: 35 bytes. Origin: #x5365BF44                          ; FOOBAR
    ; 44:       498B4510         MOV RAX, [R13+16]                ; thread.binding-stack-pointer
    ; 48:       488945F8         MOV [RBP-8], RAX
    ; 4C:       BF02000000       MOV EDI, 2
    ; 51:       488BD3           MOV RDX, RBX
    ; 54:       FF14251001A052   CALL QWORD PTR [#x52A00110]      ; SB-VM::GENERIC-+
    ; 5B:       488B5DF0         MOV RBX, [RBP-16]
    ; 5F:       488BE5           MOV RSP, RBP
    ; 62:       F8               CLC
    ; 63:       5D               POP RBP
    ; 64:       C3               RET
    ; 65:       CC10             INT3 16                          ; Invalid argument count trap
    NIL
    CL-USER>
There you go: #'FOOBAR is AOT-compiled down to four MOVs, a CALL, two MOVs, a CLC, a POP and a RET.
Post reply on HN