Conversation

Notices

1. Embed this notice
   Mark T. Tomczak (mark@mastodon.fixermark.com)'s status on Wednesday, 16-Apr-2025 02:16:01 JST Mark T. Tomczak

   • screwlisp
   • Glitzersachen.de

   @glitzersachen @screwtape In my case? Actually yes. ;)

   I mean, I do suspend it from time-to-time. But broadly speaking, I have three emacs instances I care about on the daily:

   1. An instance on my corporate laptop (stays up all the time, preserves state when the laptop sleeps)

   2. An instance on the headless developer machine I remote into (stays up all the time, only reboots when that machine reboots, which is "When IT forces me to, they can take my developer session from my cold, dead hands...")

   3. An instance on my personal hack-about laptop, which I suspend when I'm not using but otherwise stays up perpetually until the laptop takes a full restart, which is when I'm forced to (see (2)).

   • Embed this notice
     Alfred M. Szmidt (amszmidt@mastodon.social)'s status on Wednesday, 16-Apr-2025 02:15:58 JST Alfred M. Szmidt

     in reply to

     • screwlisp
     • Glitzersachen.de
     • DougMerritt (log😅 = 💧log😄)

     @dougmerritt > 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?

     (compile-file "FOO.lisp") ;; Common Lisp is and always has been a systems programming language!

     @screwtape @glitzersachen @mark

   • Embed this notice
     DougMerritt (log😅 = 💧log😄) (dougmerritt@mathstodon.xyz)'s status on Wednesday, 16-Apr-2025 02:15:59 JST DougMerritt (log😅 = 💧log😄)

     in reply to

     • screwlisp
     • Glitzersachen.de

     @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?

   • Embed this notice
     screwlisp (screwtape@mastodon.sdf.org)'s status on Wednesday, 16-Apr-2025 02:16:00 JST screwlisp

     in reply to

     • Glitzersachen.de

     @glitzersachen
     I do agree that it is a regret that the high level implementation language of the lisp editor, emacs modernly is and has been C rather than lisp.

     @mark
     you should tag this toot #emacs for more people to enjoy

   • Embed this notice
     Alfred M. Szmidt (amszmidt@mastodon.social)'s status on Wednesday, 16-Apr-2025 02:54:49 JST Alfred M. Szmidt

     in reply to

     • screwlisp
     • Glitzersachen.de
     • DougMerritt (log😅 = 💧log😄)

     @dougmerritt Lisp compilation was quite advanced already back in the 70s and 60s ... I'd even go as far that overall, Lisp has been close to "C" performance for the last 40 years... which is what is surprising me here. The Lisp Machines did back peddle on performance, the compiler is naive (mostly peephole optimizations, and nothing else); but MACLISP did crazy things.

     @screwtape @glitzersachen @mark

   • Embed this notice
     DougMerritt (log😅 = 💧log😄) (dougmerritt@mathstodon.xyz)'s status on Wednesday, 16-Apr-2025 02:54:50 JST DougMerritt (log😅 = 💧log😄)

     in reply to

     • screwlisp
     • Glitzersachen.de
     • Alfred M. Szmidt

     @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.

   • Embed this notice
     Alfred M. Szmidt (amszmidt@mastodon.social)'s status on Wednesday, 16-Apr-2025 03:02:36 JST Alfred M. Szmidt

     in reply to

     • screwlisp
     • Glitzersachen.de
     • DougMerritt (log😅 = 💧log😄)

     @dougmerritt Hard disagree, and that is from experience. Lisp Machine Lisp (aka ZetaLisp), Spice Lisp, NIL and S-1 Lisp all were very performant, for system programming and other things. CMUCL ran really good as well back in the later parts of the 1980s, so did KCL

     @screwtape @glitzersachen @mark

   • Embed this notice
     DougMerritt (log😅 = 💧log😄) (dougmerritt@mathstodon.xyz)'s status on Wednesday, 16-Apr-2025 03:02:37 JST DougMerritt (log😅 = 💧log😄)

     in reply to

     • screwlisp
     • Glitzersachen.de
     • Alfred M. Szmidt

     @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.

   • Embed this notice
     Alfred M. Szmidt (amszmidt@mastodon.social)'s status on Wednesday, 16-Apr-2025 03:03:47 JST Alfred M. Szmidt

     in reply to

     • screwlisp
     • Glitzersachen.de
     • DougMerritt (log😅 = 💧log😄)

     @dougmerritt C compilers totally where under performing for much of the languages history, and only started getting usable only in the 1990s with GCC, before that .. it was much worse than Lisp compilers.

     @screwtape @glitzersachen @mark

   • Embed this notice
     Alfred M. Szmidt (amszmidt@mastodon.social)'s status on Wednesday, 16-Apr-2025 03:34:17 JST Alfred M. Szmidt

     in reply to

     • screwlisp
     • Glitzersachen.de
     • DougMerritt (log😅 = 💧log😄)

     @dougmerritt The compilers I listed ran on 32-bit, and 16-bit, none of them were mainframes. BASIC was also more performant on lesser machines too, not sure what your point there is ..

     > C is a much, much easier language to compile efficiently.

     Absolute garbage nonsense.

     > And to this day, Lisp has constructs that do not have simple fast machine code equivalents.

     More aboslute nonsense. Maybe you should look at modern C programs ...

     @screwtape @glitzersachen @mark

   • Embed this notice
     DougMerritt (log😅 = 💧log😄) (dougmerritt@mathstodon.xyz)'s status on Wednesday, 16-Apr-2025 03:34:18 JST DougMerritt (log😅 = 💧log😄)

     in reply to

     • screwlisp
     • Glitzersachen.de
     • Alfred M. Szmidt

     @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.