Notices by DougMerritt (log😅 = 💧log😄) (dougmerritt@mathstodon.xyz)

@amszmidt @screwtape @glitzersachen @mark
If your point here is that Lisp compilers were originally more sophisticated than C compilers of the time, yes, that's my memory too.

Part of that is because Lisp compilers were on 36 bit mainframes while C compilers were on 16 bit 64KB minicomputers (and a little later, on 16 bit 64KB microcomputers), so there were definite reasons pushing towards that.

However, if you are also remembering that those sophisticated Lisp compilers emitted code that ran faster than what was emitted by those unsophisticated C compilers **in the general case**, then your memory is faulty.

C is a much, much easier language to compile efficiently. And to this day, Lisp has constructs that do not have simple fast machine code equivalents. Absolutely anything at all that is dynamic, for instance. C has no such things, aside from trivial still-fast constructs like function pointers. It doesn't even have built-in hash tables.

@amszmidt @screwtape @glitzersachen @mark
> I'd even go as far that overall, Lisp has been close to "C" performance for the last 40 years.

Sorry, but that is simply not supported by the numbers from 40 years ago, in the case of general purpose programming.

It was fast *enough* for many purposes, and for certain special purposes, and okay maybe sometimes on a Lisp Machine, but all of which is a different question than general purpose on common CPUs.

@amszmidt @screwtape @glitzersachen @mark
Yeah yeah yeah.

But I'm a compiler guy. (A) Your standards of efficiency are not my standards of efficiency. (B) Today's state of the art is obviously far better than in the 1980s, and I'm old. (C) Today's CPUs are so fast that efficiency matters (to users, not compiler people) vastly less than decades ago.

Anyway I'm spread out over many disciplines, and in programming, over many programming languages, so forgive me for not knowing what is obvious to you.

I *have* been aware of Lisp's role as a "systems programming language" for Emacs, though, since the first implementation of Lisp-based Emacs. It's for completely general purposes I was wondering about, and I shouldn't even wonder about that, since I'm aware that Lisp compilation has improved dramatically over time.

There's always going to be a battle for the highest levels of efficiency, though. Today people are trying to make Rust and Zig and such as efficient *always* as C, just like people used to try to make C as efficient as programming in assembly (a goal which has largely been long surpassed).

And there will always be purposes for which being within 2x (sometimes even 20x) of C is plenty good enough, and people in that domain will wonder why the above people are making a fuss.

@screwtape @glitzersachen @mark
Keyword arguments are great!

I've done so many zillions of lines of C for systems programming that it's hard for me to see it as undesirable in that capacity, even if there is in fact a better alternative.

What one is accustomed to typically feels natural and right, just from the habits and experience, not from careful judgements.

Anyways...how easy is it to compile Common Lisp into something nicely efficient, so that it's not unnatural to use it as a systems programming language?

@screwtape
If you read Winograd's SHRDLU book, it all makes sense, but of course it only captures a fraction of the programming, which was a tour de force.

Someone resurrected it once, but not in a form that I personally was able to use. Not sure about these days.

@screwtape
Etymology doesn't necessarily prove anything, but it *is* pretty weird that "CAR" was the mnemonic for "Contents of A Register" and "CDR" for "Contents of D Register" -- literal machine registers, not originally an abstraction at all.

BTW

> CDR coding was only really used on the Lisp Machine

That's 100% false.

@amszmidt
@ksaj

@screwtape @riley
As a historical note:

> There isn't a lot of cost (well, one cons to nil)

Back in the days when RAM was measured in kilobytes / kilowords, some implementations did in fact have space-optimized representations for short lists represented as small arrays.

See cdr-coding
https://en.wikipedia.org/wiki/CDR_coding

That might still be in some implementations today, since its savings might be significant in large structures or in aiding cache locality.
 
The first paper may well have been L. Peter Deutsch: A LISP Machine with Very Compact Programs. IJCAI 1973, Pages 697 - 703

This is covered in 7.13 in the classic "Anatomy of Lisp", John Allen (1937-2022), 1978 (long out of print, and the author once replied to my query saying he didn't think it was worthwhile updating it for more modern times).

Has a lot on implemention, but tends to talk about abstractions in terms of M-Expressions, which is no longer in style.

ACM has it online:
https://dl.acm.org/doi/pdf/10.5555/542865

Glowing review of "Anatomy" on goodreads: https://www.goodreads.com/book/show/1537412.Anatomy_of_LISP

"John Allen (1937-2022) and Anatomy of LISP" by Paul McJones
https://mcjones.org/dustydecks/archives/2024/04/11/1249/

@northernlights

Sorry, I just meant @ screwtape. You go ahead and be you.

@screwtape @kentpitman @SDF @nosrednayduj @sacha @hairylarry @pkw @rat @pizzapal

@northernlights @screwtape @kentpitman @SDF @nosrednayduj @sacha @hairylarry @pkw @rat @pizzapal
But, as usual, *everyone* should avoid mentioning which editor is their favorite. We don't want bloodshed! It's hard to clean up.

@prahou
Appearing to be pathetically ignorant is my superpower!

Somehow.

@screwtape @mdhughes @nosrednayduj @hairylarry @pkw @sacha @shizamura @rat @SDF @kentpitman

@screwtape
That's a relief; everyone was frantically searching for you in every nook and cranny.

You've been promising to finish Snow Crash for a while -- it's fun, go for it!

(Lunar new year is Wednesday but ok, gung hey fat choi)

@josephholsten @screwtape
Yeah I've done genetic and neural programming.

I get why you say that; the problem is that everyone has something different in mind for what constitutes "AGI" or similar.

@screwtape
That's fine, and thanks.

From my point of view you're only revealing the tip of an iceberg, and that tip sounds fairly standard for today's technology.

No doubt if your thoughts were ready for prime time there would be surprising things in the full reveal.

But I can't find open access for "On the Design of Software Individuals"; do you have a recommendation?

@screwtape
Yeah, I understand the latter.

As to the former, if I accidentally wandered into a cognitive dimension you wish to explore, that's fine, go ahead.

I just feel more comfortable if I feel like I know what we're talking about, is all.

@screwtape
I feel like I came in on the middle of something here.

Is this still bot related, or is this something else?

@screwtape
It's traditional (generally...not sure about Lambda in particular) to have a bot running around, nominally as a HELP system, but quotidianly as a mascot / mildly comic relief.

Are you planning to have one? Is Lmsys suitable for that, or something else?

@screwtape
I suppose.

I can't remember if I told you my take on LLMs (which wasn't clear a few years ago): they're much better with language than previous AI, but they *still* don't think.

The problem is that humans have confused language and thinking since prehistory.

But they are different. I think that vast majority of people who have studied both cognitive science *and* modern linguistics would concur.

@screwtape
What would that look like?

@glitzersachen @pthenq1 @taschenorakel @nixCraft
Yep. In the actual psychology research literature, since 1943 there's been research on "Fluid and crystallized intelligence":

https://en.wikipedia.org/wiki/Fluid_and_crystallized_intelligence

According to that, the young use "fluid intelligence", they do reasoning "that depend only minimally on prior learning".

As person ages, naturally they are capable of using more and more learning in their reasoning; they are able to use more "Crystallized intelligence".

'It reflects the effects of experience and acculturation. Horn notes that crystallized ability is a "precipitate out of experience,"'

Both kinds have advantages. More modern research shows that use of Fluid intelligence by the young is much faster, by milliseconds, than Crystallized intelligence.

But Crystallized intelligence is more often accurate.

There are simply tradeoffs, not that age makes either group inherently better or worse than the other. It depends on the task at hand.

@screwtape @kentpitman @ksaj @TheGibson @mdhughes @baruchel @nosrednayduj @ratxue @hairylarry
Although you weren't talking to *me*, for the record, I enjoyed today's episode, and wouldn't call it a disaster, even though it wasn't up to your own high standards.

(I thought I posted something along those lines hours ago, but apparently I sent it to the bit bucket in sky somehow)