• Re: Resources to learn common lisp?

    From Lawrence D?Oliveiro@3:633/10 to All on Fri Aug 14 02:47:00 2026
    On Thu, 13 Aug 2026 12:25:55 -0300, Anton Antimo wrote:

    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

    On 2026-08-13 04:18, Lawrence D?Oliveiro wrote:

    Perl was a major advance on, I would say, two counts: it
    popularized regular expressions, and it popularized hash tables.

    Regexps were popular from many Unix tools before Perl came up.

    It was Ken Thompson who first put them in such practical use. And I
    would guess it was in ed. And from ed, grep sprung as an executable.

    And hash tables were popular from Awk, which influenced Perl as
    well.

    Notice what?s missing: putting the two together into a common, much more powerful tool.

    Awk was a precursor of this: but Perl does everything Awk can do, just
    as concisely, and a lot more besides.

    The rich syntax of Perl has never been too kind on me, but I always
    wrote Perl happy (unlike Java, which always had the same fate of
    Basic [to me]).

    I did use Perl a lot for a while. But I always got the feeling that
    there were things going on I never quite fully understood. Looking at
    frequent examples of ?obfuscated Perl? just confirmed that impression.

    Then I discovered Python. Maybe not quite as concise (i.e. cryptic) as
    Perl in some ways, but actually just as powerful, and in a more
    digestible form.

    It is not a coincidence that the Python community attracts the best
    minds to keep building on it nowadays.

    And the reason I don't use Perl myself: if the program gets larger,
    I choose Common Lisp.

    People say ?Common Lisp?, but no vanilla implementation of that would
    be worth using nowadays.

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Anton Antimo@3:633/10 to All on Fri Aug 14 08:27:44 2026
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

    On 2026-08-13 17:25, Anton Antimo wrote:
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

    On 2026-08-13 04:18, Lawrence D?Oliveiro wrote:
    On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

    On the subject of Common Lisp, I find it more than disturbing when >>>>>> a codebase lacks the basic usage of hash tables.

    https://www.sbcl.org/manual/#hash-table-extensions

    unless you find some code base that use hash table all over the place. >>>>> :)
    Perl was a major advance on, I would say, two counts: it popularized
    regular expressions, and it popularized hash tables.

    Regexps were popular from many Unix tools before Perl came up.
    It was Ken Thompson who first put them in such practical use. And I
    would guess it was in ed. And from ed, grep sprung as an executable.

    Yes, and add all the grep variants, then sed, awk, pager programs,
    ex/vi, expr, and more (tcl, m4, lex may be amongst them but I'm not
    sure they had regexps from the beginning).

    And there was a C-library available, so one could easily add regexp
    functions to own tools!

    And hash tables were popular from Awk, which influenced Perl as well.
    And the reason I don't use Perl myself: if the program gets larger,
    I
    choose Common Lisp. The rich syntax of Perl has never been too kind on
    me, but I always wrote Perl happy (unlike Java, which always had the
    same fate of Basic [to me]).

    Oh, I've never seen Java and Basic mentioned in one sentence before.

    Lol. Don't take it seriously. I've never really used Basic and while I
    tried dove into Java with a lot of enthusiasm (as I did with C++ after
    feeling I was very good with C), I really couldn't continue---too much bureaucracy, I felt.

    At least we have got some nice abbreviated forms for regex elements
    from Perl; mostly syntactic sugar, maybe, but very useful, IMO. Good
    that they spread also into other regexp supporting tools so that you
    don't have to buy Perl just for the accommodating regexp formulations.

    In ``Let Over Lambda'', Doug Hoyte guides you into implementing this
    side of Perl in Common Lisp. In the prerequisites, he shows very neat
    ideas in macro writing.

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Dan Cross@3:633/10 to All on Fri Aug 14 12:17:29 2026
    In article <115jbp0$189sr$1@dont-email.me>,
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
    On 2026-08-13 04:18, Lawrence D?Oliveiro wrote:
    On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

    On the subject of Common Lisp, I find it more than disturbing when
    a codebase lacks the basic usage of hash tables.

    https://www.sbcl.org/manual/#hash-table-extensions

    unless you find some code base that use hash table all over the place.
    :)

    Perl was a major advance on, I would say, two counts: it popularized
    regular expressions, and it popularized hash tables.

    Regexps were popular from many Unix tools before Perl came up.
    And hash tables were popular from Awk, which influenced Perl
    as well.

    Hash tables for fast lookups had been known for decades before
    awk was written, and regular expressions applied to text
    processing predate Unix by some years. Thompson's paper
    described a technique (what has come to be known as "Thompson's
    Construction") used on the IBM 7090 computer, predating Multics.

    To bring this back to C, the expression of Thompson's
    construction in C is rather straight-forward and elegant, and an
    early example in K&R and K&R2 is implementing a hash table, with
    closed addressing and chaining for collision resolution.
    (Comparing the algorithms used between the two editions is
    constructive).

    - Dan C.


    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Dan Cross@3:633/10 to All on Fri Aug 14 12:20:49 2026
    In article <8733wijb3w.fsf@safunu.org>, Anton Antimo <anton@safunu.org> wrote: >Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

    On 2026-08-13 04:18, Lawrence D?Oliveiro wrote:
    On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

    On the subject of Common Lisp, I find it more than disturbing when
    a codebase lacks the basic usage of hash tables.

    https://www.sbcl.org/manual/#hash-table-extensions

    unless you find some code base that use hash table all over the place. >>>> :)
    Perl was a major advance on, I would say, two counts: it popularized
    regular expressions, and it popularized hash tables.

    Regexps were popular from many Unix tools before Perl came up.

    It was Ken Thompson who first put them in such practical use. And I
    would guess it was in ed. And from ed, grep sprung as an executable.

    Ken certainly popularized their use, though not in ed: it was in
    QED, which predated ed by some number of years, and was used on
    CTSS. Thompson's CACM paper on NFA simulation predated Unix
    (and thus ed) by a year or so:
    https://dl.acm.org/doi/10.1145/363347.363387

    - Dan C.

    (I think I said he targeted the 7090 in another post; it was the
    7094, which was an upgraded 7090)

    And hash tables were popular from Awk, which influenced Perl as well.

    And the reason I don't use Perl myself: if the program gets larger, I
    choose Common Lisp. The rich syntax of Perl has never been too kind on
    me, but I always wrote Perl happy (unlike Java, which always had the
    same fate of Basic [to me]).



    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Michael S@3:633/10 to All on Fri Aug 14 15:30:01 2026
    On Thu, 13 Aug 2026 02:18:14 -0000 (UTC)
    Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

    On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

    On the subject of Common Lisp, I find it more than disturbing when
    a codebase lacks the basic usage of hash tables.

    https://www.sbcl.org/manual/#hash-table-extensions

    unless you find some code base that use hash table all over the
    place. :)

    Perl was a major advance on, I would say, two counts: it popularized
    regular expressions, and it popularized hash tables. Putting those two features together made for an extremely useful high-level language,
    which is what I think finally killed BASIC.

    I would not call popularizing regular expression an advance.
    IMHO, their popularity is rather unfortunate fact of computing life.
    They are major attractor of mistakes and major source of surprize.




    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Janis Papanagnou@3:633/10 to All on Fri Aug 14 16:31:59 2026
    On 2026-08-14 14:17, Dan Cross wrote:
    In article <115jbp0$189sr$1@dont-email.me>,
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
    On 2026-08-13 04:18, Lawrence D?Oliveiro wrote:

    Perl was a major advance on, I would say, two counts: it popularized
    regular expressions, and it popularized hash tables.

    Regexps were popular from many Unix tools before Perl came up.
    And hash tables were popular from Awk, which influenced Perl
    as well.

    Hash tables for fast lookups had been known for decades before
    awk was written, and regular expressions applied to text
    processing predate Unix by some years. Thompson's paper
    described a technique (what has come to be known as "Thompson's Construction") used on the IBM 7090 computer, predating Multics.

    Yes, sure. (And I didn't claim that Unixes were where they first
    appeared.) But above we spoke about their popularization.[*]

    Would you also say that these appearances made Regexps "popular"?

    With the dissemination of the Unixes they certainly became widely
    popular; this is at least my observation.

    Concerning hash tables, I haven't the whole historic picture here
    (i.e. where they were implemented, their grade of dissemination
    and popularity) beyond that they're comparably old as concept; my
    point was just that Perl was not the "popularizing factor". In
    (standard-)Awk they are actually the only non-primitive data type
    available (as opposed to Perl or early Shells, the latter even with
    only severely restricted arrays).

    Janis

    [*] I'm not sure you meant your post as addendum or corrigendum.

    [...]


    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Janis Papanagnou@3:633/10 to All on Fri Aug 14 16:45:58 2026
    On 2026-08-14 14:30, Michael S wrote:
    On Thu, 13 Aug 2026 02:18:14 -0000 (UTC)
    Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

    On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

    On the subject of Common Lisp, I find it more than disturbing when
    a codebase lacks the basic usage of hash tables.

    https://www.sbcl.org/manual/#hash-table-extensions

    unless you find some code base that use hash table all over the
    place. :)

    Perl was a major advance on, I would say, two counts: it popularized
    regular expressions, and it popularized hash tables. Putting those two
    features together made for an extremely useful high-level language,
    which is what I think finally killed BASIC.

    I would not call popularizing regular expression an advance.

    Thanks for your opinion.

    IMHO, their popularity is rather unfortunate fact of computing life.
    They are major attractor of mistakes and major source of surprize.

    Yes mistakes can happen everywhere, even when writing of posts
    ("surprize"). :-) And surprises appear where ignorance rules.

    Regexps, OTOH, while appearing cryptic to the uninitiated, allow
    in a compact way powerful search and match expression. Emulating
    them by code is IME much more error-prone, though. They actually
    help to reduce programming errors; this is my experience. (YMMV.)

    Personally I used and appreciated them from the beginning. And
    whenever I came in system contexts where they were not available
    (back then typically in MS contexts) I cursed these systems for
    their outdated primitive concepts that just made ones live hard.

    You may be too old to learn or master them now but for the younger
    folks around I strongly suggest to learn the concept of Regular
    Expressions and identify where they can advantageously be used. It
    certainly pays!

    Janis


    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From David Brown@3:633/10 to All on Fri Aug 14 17:15:21 2026
    On 14/08/2026 16:45, Janis Papanagnou wrote:
    On 2026-08-14 14:30, Michael S wrote:
    On Thu, 13 Aug 2026 02:18:14 -0000 (UTC)
    Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

    On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

    On the subject of Common Lisp, I find it more than disturbing when
    a codebase lacks the basic usage of hash tables.

    ÿÿ https://www.sbcl.org/manual/#hash-table-extensions

    unless you find some code base that use hash table all over the
    place. :)

    Perl was a major advance on, I would say, two counts: it popularized
    regular expressions, and it popularized hash tables. Putting those two
    features together made for an extremely useful high-level language,
    which is what I think finally killed BASIC.

    I would not call popularizing regular expression an advance.

    Thanks for your opinion.

    IMHO, their popularity is rather unfortunate fact of computing life.
    They are major attractor of mistakes and major source of surprize.

    Yes mistakes can happen everywhere, even when writing of posts
    ("surprize"). :-)ÿ And surprises appear where ignorance rules.

    Regexps, OTOH, while appearing cryptic to the uninitiated, allow
    in a compact way powerful search and match expression. Emulating
    them by code is IME much more error-prone, though. They actually
    help to reduce programming errors; this is my experience. (YMMV.)

    Personally I used and appreciated them from the beginning. And
    whenever I came in system contexts where they were not available
    (back then typically in MS contexts) I cursed these systems for
    their outdated primitive concepts that just made ones live hard.

    You may be too old to learn or master them now but for the younger
    folks around I strongly suggest to learn the concept of Regular
    Expressions and identify where they can advantageously be used. It
    certainly pays!

    Janis


    While I think it is reasonable to learn the ideas of regular
    expressions, and a little of the simplest and most common types, I don't
    think it is practical for anyone to learn to "master" regexs. For one
    thing, there are a dozen different variations. And while a lot of
    people find them useful on occasion, few need them regularly enough to
    be confident in writing them (or reading them, which can often be harder).

    Fortunately, there is no good reason for mastering them unless you
    really do have a lot of use of them. There are countless online
    "generator" sites for them, as well as for testing them or interpreting existing ones (when you are faced with the "fun" of debugging someone
    else's regex).

    Like most things, they can be a useful tool, but some people get overly
    smart about them and produce monstrosities that no one understands and
    are impossible to debug or maintain. Keep them reasonable, and they are
    fine.



    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Janis Papanagnou@3:633/10 to All on Fri Aug 14 19:51:24 2026
    On 2026-08-14 17:15, David Brown wrote:
    [...]

    While I think it is reasonable to learn the ideas of regular
    expressions, and a little of the simplest and most common types, I don't think it is practical for anyone to learn to "master" regexs.

    Mastering them comes from alone once you make an informed start
    (and not pause in stasis).

    (To me it appears like mathematics in real life; the majority of
    folks in my country regularly says things like "it's confusing",
    "it's complicated", "we don't expect that understand that (as I
    don't)", "it's normal that one cannot understand that", "math is
    just difficult", and so on. Children get systematically repelled
    to listening and learning maths, they quit at the first obstacle
    they encounter. - I'm recognizing the same discussion mechanics
    in our IT domain with Regexps. - Here in this thread that they'd
    "attract mistakes".)

    As with many things we start with "the simplest and most common
    types" (as you formulated it). But there's no reason to stop if
    you want to get more productive.

    (Reminds me how some folks using the Vi editor; and completely
    missing the power it evolves when getting past 'i' and 'Esc'.
    If you are modest and feel comfortable with that it's okay, as
    it's okay if you use only primitive elements of Regexps. But if
    you use it for editing power you should continue learn not only
    the concept but also the non-trivialities, and you'll observe
    that your skill will not get twice as fast but magnitudes. That
    is not much different from other areas; including Regexps.)

    For one thing, there are a dozen different variations.

    This is true; certainly for different applications. But so what?
    Are you saying that you have no problems switching to other tools
    but the differences between the advanced regexp implementations
    is an issue? If that is so for you, fair enough.

    (BTW, for me it's at most only half a dozen that I occasionally
    use.)

    But at least we have a couple _common classes_ to distinguish.
    POSIX standardized BRE and ERE or the pleasing PCRE (from Perl),
    are the historically widely spread ones.

    I observe that especially the basics (that you focused on above)
    are widely the same. The details and differences come when you get
    into it; in one tool the + meta-symbol isn't supported at all, in
    another it needs an escape \+ . - Yes, that's what mastering may
    mean, to know that. But you can also just try, in case you didn't
    want to read the manual first. - Myself, in case of doubt, I just
    try it, and I test my regexps, as I test my other program code.

    And while a lot of
    people find them useful on occasion, few need them regularly enough to
    be confident in writing them (or reading them, which can often be harder).

    Well, I cannot speak for "lot of people"; I can speak for myself,
    friends with IT (or CS) background, and the people from the areas
    I worked in during the past decades. - Where Regexps were sensible
    to use those people just used them.

    I mentioned in my previous post already that they may be "appearing
    cryptic to the uninitiated". So I'd like to emphasize again that at
    least some engagement is necessary to learn them. Otherwise you're
    completely lost of course.

    (Imagining a similar uninformed approach to some uninitiated "C"
    programmers; and things like *p--, or C's declaration syntax.
    "Here are a set of symbols, now go compose your C-programs!".
    The Regexps are compared to the C-language like a piece of cake!)

    At some (early point) of learning writing them is okay but reading
    third-party Regexps may be a problem; in complex cases. - That is
    correct. But no one prevents you from *commenting* complex Regexps
    where they appear (as you should comment complex code). In case of
    undocumented code decomposition helps; this method is as well not
    restricted to Regexps. And some tools that support Regexps allow
    composing them (like a BNF specification; very readable, been there
    done that).

    (If I imagine the bulk of code I'd have to write to replace a Regexp
    I'm shuddering, and I'm pity for those who have been repelled from
    learning them by the spread commonplace myths and FUD.)


    Fortunately, there is no good reason for mastering them unless you
    really do have a lot of use of them.

    It's a personal choice whether you want to master them or just know
    the concepts deeply enough to judge its application value. (Or if
    you decide to abstain in advance, because they "attract mistakes"
    or are "too difficult", or there are "too many subtle differences"
    to even start using them.)

    Yes. If you have no reason to use them you not only have no need to
    master them but also not use them in the first place. - It's just a
    pity if one cannot recognize where their applications would benefit.

    There are countless online
    "generator" sites for them, as well as for testing them or interpreting existing ones (when you are faced with the "fun" of debugging someone
    else's regex).

    Well, this I consider a counterproductive statement, but certainly
    in the company of other "don't learn them" statements quoted above.

    In this vein let me add to let an AI formulate (and analyze) your
    Regexps. </sarcasm>


    Like most things, they can be a useful tool, but some people get overly smart about them and produce monstrosities that no one understands and
    are impossible to debug or maintain.ÿ Keep them reasonable, and they are fine.

    I've seen monstrosities of Regexps as I've seen monstrosities of "C"
    (or other) code. The problem there were always the programmers, not
    "C", not Regexps.

    What are the alternatives to Regexps (or Regexp-monstrosities)?

    If you can answer that question the "problems" vanish into thin air.

    Janis


    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Keith Thompson@3:633/10 to All on Fri Aug 14 12:05:17 2026
    David Brown <david.brown@hesbynett.no> writes:
    [...]
    While I think it is reasonable to learn the ideas of regular
    expressions, and a little of the simplest and most common types, I
    don't think it is practical for anyone to learn to "master" regexs.
    For one thing, there are a dozen different variations. And while a
    lot of people find them useful on occasion, few need them regularly
    enough to be confident in writing them (or reading them, which can
    often be harder).
    [...]

    My own experience is very different. I won't comment further, since
    this is not about C.

    --
    Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    void Void(void) { Void(); } /* The recursive call of the void */

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Lawrence D?Oliveiro@3:633/10 to All on Sat Aug 15 03:18:02 2026
    On Fri, 14 Aug 2026 08:27:44 -0300, Anton Antimo wrote:

    I've never really used Basic and while I tried dove into Java with a
    lot of enthusiasm (as I did with C++ after feeling I was very good
    with C), I really couldn't continue---too much bureaucracy, I felt.

    ?Bureaucracy? is absolutely a good word to sum up Java.

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Anton Antimo@3:633/10 to All on Sun Aug 16 15:37:37 2026
    cross@spitfire.i.gajendra.net (Dan Cross) writes:

    In article <8733wijb3w.fsf@safunu.org>, Anton Antimo <anton@safunu.org> wrote:
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

    On 2026-08-13 04:18, Lawrence Dƒ??Oliveiro wrote:
    On Wed, 12 Aug 2026 10:16:25 +0200, bixbox wrote:

    On the subject of Common Lisp, I find it more than disturbing when >>>>>> a codebase lacks the basic usage of hash tables.

    https://www.sbcl.org/manual/#hash-table-extensions

    unless you find some code base that use hash table all over the place. >>>>> :)
    Perl was a major advance on, I would say, two counts: it popularized
    regular expressions, and it popularized hash tables.

    Regexps were popular from many Unix tools before Perl came up.

    It was Ken Thompson who first put them in such practical use. And I
    would guess it was in ed. And from ed, grep sprung as an executable.

    Ken certainly popularized their use, though not in ed: it was in
    QED, which predated ed by some number of years, and was used on
    CTSS. Thompson's CACM paper on NFA simulation predated Unix
    (and thus ed) by a year or so:
    https://dl.acm.org/doi/10.1145/363347.363387

    - Dan C.

    [...]

    Thank you so much for the reference.

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Johann 'Myrkraverk' Oskarsson@3:633/10 to All on Mon Aug 24 19:38:57 2026
    On 24/08/2026 4:46 PM, tfb wrote:
    Paul Rubin <no.email@nospam.invalid> wrote:
    tfb <tfb@work.it.out> writes:
    No single language has 1% of constructs anyone might ever want.

    If I can code fluently in a language, that is, I can think entirely
    about the application-level problem I'm trying to solve and not putting
    much effort into choosing language constructs, then it's supplying 100%
    of what I want at least at that moment. That's great.


    Here's the thing: you are one person. There are, shockingly, other people
    in the world who might want to write programs. You may also have noted
    that more than one programming language exists. Although you are clearly happy with whatever language it is you use and never inclined to look at anything else, perhaps some if these other languages might exist because other people might want a different set of constructs, don't you think?


    Dear tfb,

    I have no idea what you're talking about. To me, Paul is absolutely
    correct. Being fluent in a programming language means I don't have to
    look things up constantly, such as figuring out what the various &
    symbols mean in Rust -- that's a recent adventure of mine, so I'm in-
    cluding comp.lang.misc until we have comp.lang.rust -- and it does get
    old fast.

    Working in an unfamiliar programming means I'm not fluent, and I cannot
    just write whatever I want -- I mean, the Rust compiler explicitly does
    not allow me to just /inline "Common Lisp"/ if I may speak in C++
    tokens; the equivalent Rust would probably be something like /inl Lisp {
    /* Common Lisp goes here */ }/, using AWK matching syntax for emphasis
    -- so I'm resorting to actually have to read the book, because constant-
    ly looking things up got old several days ago.

    This of course delays my chapter one project of /Writing a C Compiler/
    by Nora Sandler; so I'm including comp.lang.c in this discussion as
    well, for obvious reasons.


    So my question to you, dear tfb, when exactly do you not know a pro-
    gramming language, and when was the last time this happened to you?
    --
    Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
    I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From tfb@3:633/10 to All on Mon Aug 24 12:22:13 2026
    Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:


    I have no idea what you're talking about.

    You really don't, no.

    Hint: I am not talking about whether you know the language you are using
    well enough, but whether the language you are using provides the constructs
    you need to address the problem you are solving in it succinctly.

    --
    tfeb.org/computer/

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Johann 'Myrkraverk' Oskarsson@3:633/10 to All on Mon Aug 24 21:04:43 2026
    On 24/08/2026 8:22 PM, tfb wrote:
    Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:


    I have no idea what you're talking about.

    You really don't, no.

    Hint: I am not talking about whether you know the language you are using
    well enough, but whether the language you are using provides the constructs you need to address the problem you are solving in it succinctly.


    Dear tfb,

    In that case, I believe you owe Paul an apology, because what you wrote
    was completely incongruent with what he was talking about, or at least,
    that's how I understand it -- and of course, I simply define myself as
    having better reading comprehension than you -- but then, Paul really
    should be able to speak up for himself, so there's no reason for us to
    argue about it.

    I simply accuse you of having poor reading comprehension, and even worse writing comprehension.


    Have a nice day!
    --
    Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
    I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From tfb@3:633/10 to All on Mon Aug 24 13:18:29 2026


    I simply accuse you of having poor reading comprehension, and even worse writing comprehension.

    Do you really think that a thread about language extensibility and whether
    any given language could have enough co structs to satisfy all posdible
    users of that language had suddenly changed topic to how familiar an
    individual was with a given language? Really? Oh well.

    --
    tfeb.org/computer/

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Johann 'Myrkraverk' Oskarsson@3:633/10 to All on Mon Aug 24 22:16:15 2026
    On 24/08/2026 9:18 PM, tfb wrote:


    I simply accuse you of having poor reading comprehension, and even worse
    writing comprehension.

    Do you really think that a thread about language extensibility and whether any given language could have enough co structs to satisfy all posdible
    users of that language had suddenly changed topic to how familiar an individual was with a given language? Really? Oh well.


    Yes, because that's how human to human real world conversations work.
    Being strictly /on topic/ without any deviation is a social construct
    invented by psychopaths for psychopaths. It's because they can't deal
    with real human to human interactions, and have to /hide themselves/,
    and pretend.

    All. The. Time.

    You are being dangerously close to expose yourself as a psychopath, so I suggest you stop replying to me, and /touch grass/ or something.

    Side note, for people unfamiliar with the term psychopath in technology,
    please read this VICE article, and weep.


    https://www.vice.com/en/article/the-careers-that-attract-the-most-psychopaths-one-job-is-the-clear-winner/

    I have negative respect for psychopaths, for good reasons.


    Have a nice life outside of Usenet!
    --
    Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
    I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From tfb@3:633/10 to All on Mon Aug 24 20:10:08 2026
    Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:

    Yes, because that's how human to human real world conversations work.
    Being strictly /on topic/ without any deviation is a social construct invented by psychopaths for psychopaths. It's because they can't deal
    with real human to human interactions, and have to /hide themselves/,
    and pretend.

    All. The. Time.

    You are being dangerously close to expose yourself as a psychopath, so I suggest you stop replying to me, and /touch grass/ or something.


    I must admit to being pretty amused by how quickly some random internet buffoon, who very obviously is not a native English speaker, has moved from accusing me of poor English reading comprehension ? and 'writing comprehension', which as a native English speaker I assume must mean 'comprehensible writing', but I dunno ? to saying I'm about to expose
    myself as a psychopath because I 'can't deal with human to human
    interactions' (which is ... funny). (I half expect the same person is now wondering whether I'm using an LLM because of the spaced dashes. Hint:
    no.)

    And now, because I admit to laughing at you, it will no doubt confirm
    whatever pop-psychology rubbish you want to believe about people you've
    never met and never will. No: quite ordinary people laugh at fools, it
    turns put: there's a whole genre of comedy based on that.

    So be it.

    --
    tfeb.org/computer/

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Paul Rubin@3:633/10 to All on Mon Aug 24 17:10:51 2026
    tfb <tfb@work.it.out> writes:
    Do you really think that a thread about language extensibility and whether any given language could have enough co structs to satisfy all posdible
    users of that language had suddenly changed topic to how familiar an individual was with a given language?

    Fluency does matter.

    If fluency in a language lets me do most of my daily tasks with at most occasional inconvenience, I'd call the language satisfactory. Stuff
    like macros make inconvenient things convenient. They don't make the impossible possible. And if the language makes enough everyday things convenient, it's ok with me if some inconvenient ones are left over.

    So I haven't felt lack of macros to be a serious shortcoming of non-Lisp languages. There are usually alternate mechanisms offered, like
    function decorators in Python.

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Johann 'Myrkraverk' Oskarsson@3:633/10 to All on Tue Aug 25 10:34:47 2026
    On 25/08/2026 4:10 AM, tfb wrote:
    Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:

    Yes, because that's how human to human real world conversations work.
    Being strictly /on topic/ without any deviation is a social construct
    invented by psychopaths for psychopaths. It's because they can't deal
    with real human to human interactions, and have to /hide themselves/,
    and pretend.

    All. The. Time.

    You are being dangerously close to expose yourself as a psychopath, so I
    suggest you stop replying to me, and /touch grass/ or something.


    I must admit to being pretty amused by how quickly some random internet buffoon, who very obviously is not a native English speaker, has moved from accusing me of poor English reading comprehension ? and 'writing comprehension', which as a native English speaker I assume must mean 'comprehensible writing', but I dunno ? to saying I'm about to expose
    myself as a psychopath because I 'can't deal with human to human interactions' (which is ... funny). (I half expect the same person is now wondering whether I'm using an LLM because of the spaced dashes. Hint:
    no.)

    And I must admit being pretty amused by people whose only claim to
    language skills is to be /born in a country/. You may laugh, you may
    cry, I don't give a shit. The thing is, people with poor reading
    comprehension don't know it. They always, always, accuse the other
    person of being /poor at communicating/, and often cannot be corrected
    because they don't believe they can possibly be in the wrong.

    Thank you for proving my point about your poor reading comprehension.

    And just like Lewis Carrol when he wrote Alice in Wonderland, or Through
    the Looking Glass -- I don't care which book had this quote -- I use my
    words to mean what I mean, and not what you decide it means.

    And now, because I admit to laughing at you, it will no doubt confirm whatever pop-psychology rubbish you want to believe about people you've
    never met and never will. No: quite ordinary people laugh at fools, it
    turns put: there's a whole genre of comedy based on that.

    So be it.


    Fools laugh at people wiser than them, that's true. Thank you for prov-
    ing to me you're a fool.
    --
    Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
    I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Johann 'Myrkraverk' Oskarsson@3:633/10 to All on Tue Aug 25 10:41:57 2026
    On 25/08/2026 8:10 AM, Paul Rubin wrote:
    tfb <tfb@work.it.out> writes:
    Do you really think that a thread about language extensibility and whether >> any given language could have enough co structs to satisfy all posdible
    users of that language had suddenly changed topic to how familiar an
    individual was with a given language?

    Fluency does matter.

    If fluency in a language lets me do most of my daily tasks with at most occasional inconvenience, I'd call the language satisfactory. Stuff
    like macros make inconvenient things convenient. They don't make the impossible possible. And if the language makes enough everyday things convenient, it's ok with me if some inconvenient ones are left over.

    So I haven't felt lack of macros to be a serious shortcoming of non-Lisp languages. There are usually alternate mechanisms offered, like
    function decorators in Python.

    Thank you Paul. Now, if we're in the realm of impossible, there's very
    little that can be said to be truly /impossible/ in Common Lisp. This
    is because compilers like Steel Banks Common Lisp not only compile to
    pure binary code, they also offer Lisp syntax to just write the function
    in assembly. This is apparent to anyone who's delved into the inner
    guts of the compiler.

    Now, when we can just casually switch over to the assembly language, the /impossible/ is limited by the capabilities of the machine, and our
    patience to get whatever we want done.

    I mean, we can -- with enough patience and understanding, and reading of
    the code -- just overwrite the Common Lisp compiler, and the binaries it generates.

    I believe that's impossible in Python, so again I invite Lawrence D'Oli-
    veiro to correct me.

    And on the subject of macros, we can always template program like it's
    1976, and create our own textual code generator like Yacc. Though we
    don't have to create one in the context of parsing. This trick works
    equally in Python, and Common Lisp, but is for some reasons hardly ever
    used in practice today. Everyone seems to be hell bent on having the programmability of the programming language itself embedded in the de-
    fault compiler. Why is that?

    --
    Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
    I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From tfb@3:633/10 to All on Tue Aug 25 09:22:44 2026
    oPaul Rubin <no.email@nospam.invalid> wrote:

    Fluency does matter.

    Absolutely so. Interestingly it's possible to not be fluent in languages
    (or language constructs) that you've designed: after Zyni and I wrote ?tar
    (an iteration construct for CL), it took me months to become comfortable
    enough in it to use it to the exclusion of most of the standard ones. Some
    of this was worry about how large the support for it was (entirely silly on modern systems) and performance (we had benchmarks, but somehow these
    didn't help convince me), but part of it was just 'how do I get it to do
    that, erm ...'.


    If fluency in a language lets me do most of my daily tasks with at most occasional inconvenience, I'd call the language satisfactory. Stuff
    like macros make inconvenient things convenient. They don't make the impossible possible. And if the language makes enough everyday things convenient, it's ok with me if some inconvenient ones are left over.

    So I haven't felt lack of macros to be a serious shortcoming of non-Lisp languages. There are usually alternate mechanisms offered, like
    function decorators in Python.


    And that's fine. There are people for whom Fortran (I mean FORTRAN,
    probably, because modern Fortran is a large and flexible language only
    really related to anything older than Fortran 90 by some backward compatibility) is a language in which they are fluent and who feel no need
    for any other language. There is absolutely nothing wrong with that.

    But if I asserted that nobody should want a language other than FORTRAN,
    that would probably be something quite a lot of people would take issue
    with. And they would be right.

    If I asserted that *any single* programming language should be something
    every person is comfortable with then I think people would take issue with that, as well. There would probably be some extremists who would say,
    well, if only everyone saw and understood the blinding light of (Python|Ruby|Lisp) then they would achieve true happiness. But those
    people are pushing what is essentially a cult. And empirically those
    people are just wrong: if they were right, why are there so many
    programming languages? Why are there both Python cultists and Ruby
    cultists if there is more than one true language? Do we need some kind of purge of the nonbelievers?

    Well, perhaps there is some finite and fairly small set of languages that
    would meet everyone's requirements for comfort? If that were so, why do
    people endlessly invent new ones? If there is a finite set, we're clearly
    not close to reaching it yet.

    I suggest that the set of languages which would mean *everyone* was
    comfortable is not usefully finite. If hardware architecture was
    unchanging and there was a fixed set of problem domains it conceivably
    might be, but neither of those things is true. Modern Fortran has grown
    all sorts of new constructs designed to deal with what modern
    supercomputers look like, for instance.

    Language exploration and modification therefore matters. It may not matter
    for you, or for me: we may be fluent in and comfortable with our fixed languages (they might even be the same language). But *that means
    nothing*: it still matters.

    And (this is the contentious bit): I think that, since it matters, removing barriers to it also matters. It will never be easy, but it shouldn't
    require designing a whole new language to explore one idea. It should be possible to write functions in an existing language which map constructs expressing that new (or borrowed) idea into the existing language. Those functions have a name: macros. You may not want to use them: that is not
    an argument that they are not useful to other people, and to pretend it is would be as grotesquely arrogant as if I was to say that because *I* have
    no use for a church it should be demolished.


    --
    tfeb.org/computer/

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Paul Rubin@3:633/10 to All on Tue Aug 25 22:13:06 2026
    tfb <tfb@work.it.out> writes:
    There would probably be some extremists who would say, well, if only
    everyone saw and understood the blinding light of (Python|Ruby|Lisp)
    then they would achieve true happiness.

    The Blub fallacy. Yes it applies to CL just like to anything else.

    It should be possible to write functions in an existing language which
    map constructs expressing that new (or borrowed) idea into the
    existing language. Those functions have a name: macros.

    Meh, if the old language can express the new idea at all, then the new
    idea isn't that big of a change. Like try implementing Scheme
    continuations as macros in CL.

    There's a theoretical paper by Felleisen about what really adds
    expressive power to programming languages. Sadly, I don't understand
    it, but maybe someday.

    https://www2.ccs.neu.edu/racket/pubs/scp91-felleisen.pdf

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Anton Antimo@3:633/10 to All on Wed Aug 26 15:43:38 2026
    Paul Rubin <no.email@nospam.invalid> writes:

    tfb <tfb@work.it.out> writes:
    There would probably be some extremists who would say, well, if only
    everyone saw and understood the blinding light of (Python|Ruby|Lisp)
    then they would achieve true happiness.

    The Blub fallacy. Yes it applies to CL just like to anything else.

    It should be possible to write functions in an existing language which
    map constructs expressing that new (or borrowed) idea into the
    existing language. Those functions have a name: macros.

    Meh, if the old language can express the new idea at all, then the new
    idea isn't that big of a change. Like try implementing Scheme
    continuations as macros in CL.

    Doug Hoyte does it in Let Over Lambda. But even if we have here a case
    where things don't work out so well, one case won't break the efficacy
    of all other cases.

    There's a theoretical paper by Felleisen about what really adds
    expressive power to programming languages. Sadly, I don't understand
    it, but maybe someday.

    https://www2.ccs.neu.edu/racket/pubs/scp91-felleisen.pdf

    Care to share what you don't understand about the paper? I suppose the
    subject is still interesting to the newsgroups addressed here, though it
    leans more towards comp.lang.misc and comp.theory and sci.logic.

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Paul Rubin@3:633/10 to All on Wed Aug 26 18:23:24 2026
    Anton Antimo <anton@safunu.org> writes:
    Like try implementing Scheme continuations as macros in CL.
    Doug Hoyte does it in Let Over Lambda.

    I don't see how that is possible, other than by using the Turing
    completeness of CL macros to implement Scheme, more or less.
    Continuations automatically give you stackful coroutines and that
    requires runtime support that's not built into CL. I haven't read that
    book though.

    https://www2.ccs.neu.edu/racket/pubs/scp91-felleisen.pdf
    Care to share what you don't understand about the paper?

    It's written in the academic language of PL theory, which I haven't
    studied enough to make sense of what the paper is saying.

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Anton Antimo@3:633/10 to All on Fri Aug 28 17:29:26 2026
    Paul Rubin <no.email@nospam.invalid> writes:

    Anton Antimo <anton@safunu.org> writes:
    Like try implementing Scheme continuations as macros in CL.
    Doug Hoyte does it in Let Over Lambda.

    I don't see how that is possible, other than by using the Turing
    completeness of CL macros to implement Scheme, more or less.
    Continuations automatically give you stackful coroutines and that
    requires runtime support that's not built into CL. I haven't read that
    book though.

    I got that wrong. It turns out TFB posted in

    Message-ID: <116ndfj$st1q$1@dont-email.me>

    two days ago that Paul Graham does in ``On Lisp''.

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)