GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Embed Notice

HTML Code

Corresponding Notice

  1. Embed this notice
    DougMerritt (log😅 = 💧log😄) (dougmerritt@mathstodon.xyz)'s status on Wednesday, 16-Apr-2025 03:34:18 JSTDougMerritt (log😅 = 💧log😄)DougMerritt (log😅 = 💧log😄)
    in reply to
    • screwlisp
    • Glitzersachen.de
    • Alfred M. Szmidt
    • Mark T. Tomczak

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

    In conversationabout a month ago from mathstodon.xyzpermalink
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.