2026-09-16 01:13:46 <bjorkintosh > veltas: I'm sorry you feel that way about lisp, but no one is too dumb for it. Instead of starting with Guile, might I suggest Racket and the DrRacket environment first, only because there is a tonne of available tutorials and information for Racket.
2026-09-16 01:15:26 <xentrac     > well, no one who can write their own Forth for in assembly language is
2026-09-16 01:15:53 <xentrac     > I'm pretty sure I've met people who would get hopelessly muddled up very quickly
2026-09-16 01:16:05 <bjorkintosh > veltas: https://docs.racket-lang.org/quick/
2026-09-16 01:16:24 <xentrac     > I tried pot once and I don't think I could have written Lisp afterwards for a few hours
2026-09-16 01:17:00 <bjorkintosh > heh.
2026-09-16 01:17:04 <bjorkintosh > https://htdp.org/2003-09-26/
2026-09-16 01:17:10 <bjorkintosh > veltas ^
2026-09-16 01:17:31 <bjorkintosh > you can get up to speed very quickly with Racket.
2026-09-16 06:20:31 <iv4nshm4k0v > It's been years since I did any substantial Lisp coding, but to me, the natural starting point was Emacs Lisp - as I've been using GNU Emacs.  Never used Aubrey Jaffer's SCM much, but it seems a pretty no-nonsense implementation, too.  Then there's Scheme48 that's written mostly in itself, so also worth looking into.
2026-09-16 06:20:31 <iv4nshm4k0v > Then there's Maxima that's written in Common Lisp, so if you have ideas that make sense to implement as extensions for a CAS, it's worth checking out.  And there're of course several small and (or) embeddable implementations that can be interesting in their own way.
2026-09-16 06:31:21 <DKordic     > Lisp is fundamentally flawed.
2026-09-16 06:42:14 <deadmarshal > DKordic: why?
2026-09-16 09:17:49 <veltas      > xentrac: Maybe intelligence isn't a linear thing though, maybe I can be smart enough to pump out loads of assembly but not write Lisp
2026-09-16 09:18:06 <veltas      > bjorkintosh: I'll have a look later if I get time
2026-09-16 09:19:05 <veltas      > iv4nshm4k0v: I did learn a bit of elisp, but it didn't seem like a serious lisp.  I've only learned what I needed to fix people's emacs (I don't use emacs myself really)
2026-09-16 09:20:46 <iv4nshm4k0v > Emacs Lisp is somewhat focused on pushing bits around Emacs itself.  You can write, say, a newsreader in it, though, so I'd say it's serious in my book.
2026-09-16 09:24:07 <veltas      > I mean rather that it's not conventional lisp is the impression I got, rather than serious
2026-09-16 09:25:45 <iv4nshm4k0v > Not that I'm quite an expert in all matters Lisp, but my impression is that, like Forth, there's no such thing as "conventional Lisp."  Emacs Lisp certainly isn't Common Lisp.  But then again, Common Lisp itself isn't R5RS Scheme.  And Racket offers its own language alongside some of the standard dialects.
2026-09-16 09:35:14 <iv4nshm4k0v > For an example, though I haven't explored it much, SIOD didn't seem to care about /any/ standards, much less Scheme standards, even though it calls itself a Scheme implementation.
2026-09-16 09:38:49 <veltas      > This is one of the barriers for me, trying to figure out which lisp is even worth investing my time in
2026-09-16 09:38:54 <veltas      > Because they are so incredibly difficult
2026-09-16 09:40:14 <iv4nshm4k0v > The problem is to find a problem that you're interested in and that it makes sense to solve in a Lisp.
2026-09-16 09:45:48 <iv4nshm4k0v > To me, the main source of such problems for a long while was Emacs.  These days, I use Maxima, but not quite on daily basis (unlike my past Emacs usage.)  So I, too, am short of interesting problems that it'd make sense to solve in a Lisp.  Or in many other languages, even those I have some interest in.
2026-09-16 09:58:43 <veltas      > I think the first time I tried to rewrite my package manager in Lisp
2026-09-16 09:58:57 <veltas      > Because it seemed like a reasonable thing to port
2026-09-16 09:59:53 <veltas      > This is what I was gong to port https://github.com/Veltas/dcs-lua
2026-09-16 10:00:39 <veltas      > That or rewrite the basics of pacman (pacman is super simple re packages, the cryptography stuff is a bit more complicated)
2026-09-16 10:57:37 <iv4nshm4k0v > M-m.  Guix is in Lisp, IIRC.
2026-09-16 11:01:06 <veltas      > It's written in Guile.  The reason I was looking at Guile is it's treated as a sort of scripting 'extension' language, so in theory it should be easy to use or nobody would use it
2026-09-16 11:01:11 <veltas      > Yet loads of people use it and it's not easy to use
2026-09-16 11:01:47 <veltas      > If I needed some scripting extension thing for a C program I would use Lua personally
2026-09-16 11:13:09 <veltas      > Maybe I should read Guix
2026-09-16 11:20:22 <iv4nshm4k0v > Can't say I was impressed by Guile myself back in the day, either.  Anyway, these days, I mainly use POSIX languages (except for dc), Perl, Tcl, Ecmascript, assembly and Forth.  I have some familiarity with ISO Prolog, though less than with R5RS Scheme and Emacs Lisp, and I don't encounter problems often that it'd make sense to use Prolog for.
2026-09-16 11:20:22 <iv4nshm4k0v > I have some interest in Erlang - partly because I've used to run my own Ejabberd instance and might want to do it again, and partly so to familiarize myself with its "run forever" approach (mostly so I can implement it elsewhere.)  And then there's Lua that's part of NetBSD distribution, though I (still) have little idea of its capabilities there.
2026-09-16 12:55:01 <xentrac     > Emacs is a more conventional Lisp than Common Lisp or Scheme in a lot of ways.  For example, it still has dynamic scoping, and (lambda ...) evaluates to an S-expression (though it's no longer self-quoting like it used to be)
2026-09-16 12:56:59 <xentrac     > iv4nshm4k0v: wrt (c) doesn't perl compile with Emscripten?
2026-09-16 13:00:29 <iv4nshm4k0v > No idea, but even if so, I'm not sure it's something /practical./  Would there be a Perl module to access browser's DOM, for instance?  Would the performance of the code still be reasonable?
2026-09-16 13:31:40 <MrMobius    > What does Lisp usually compile to?
2026-09-16 13:36:01 <MrMobius    > I got curious when I saw someone had written an NES game in a dialect of lisp but never got beyond that
2026-09-16 13:39:45 <iv4nshm4k0v > Chicken and Stalin compile to C; Scheme48 is built around a byte compiler (and thus a VM to run the bytecode), and so is Emacs Lisp these days.  I believe there're some "classic" interpreters, as well as implementations based around ASTs.
2026-09-16 13:43:25 <iv4nshm4k0v > GNU Emacs has a JIT compiler to machine code, too, but that was added after I've stopped using it, so I know nothing of it besides that it exists.  (I think.)
2026-09-16 14:18:46 <xentrac     > generally Wasm things talk to JS to access the browser's DOM and other APIs, and the performance overhead of Wasm computation is typically in the tens of percent, so it's probably reasonable for anything you'd consider using Perl for in the first place
2026-09-16 14:19:51 <xentrac     > current Emacs compiles to machine code, yeah.  The most important Scheme is probably Chez Scheme, and the most important Common Lisp is probably SBCL, both of which compile to machine code
2026-09-16 14:20:23 <xentrac     > the most important Lisp overall, other than Emacs Lisp, is probably Clojure, which compiles to JVM bytecode, which gets JIT-compiled to machine code
2026-09-16 14:22:27 <xentrac     > Emacs still has the bytecode engine too, but I don't know what role it plays now
2026-09-16 14:23:20 <xentrac     > I think SIOD might be an AST-walking Lisp implementation, but generally those have terrible performance
2026-09-16 14:30:46 <xentrac     > Perl's interpreter is sort of an AST-walking implementation, but the AST has been augmented with next-operation pointers that get it to a usable level of speed
2026-09-16 14:53:15 <bjorkintosh > <DKordic> Lisp is fundamentally flawed.  <-- Really? So which language isn't fundamentally flawed?
2026-09-16 14:54:19 <bjorkintosh > <veltas> This is one of the barriers for me, trying to figure out which lisp is even worth investing my time in <-- Racket and the DrRacket environment. Nothing left to figure out.
2026-09-16 14:54:21 <bjorkintosh > Start there.
2026-09-16 14:55:26 <bjorkintosh > DrRacket is a fairly complete environment in that it comes with extra rechargeable batteries included with lots of nice features to boot.
2026-09-16 14:55:47 <bjorkintosh > Plus, as I mentioned, a number of very gentle intros to Racket.
2026-09-16 14:56:33 <bjorkintosh > so, pick Racket and be done with it. Or... rinse and repeat previous actions.
2026-09-16 15:07:12 <veltas      > Yes bjorkintosh I said I will check it out
2026-09-16 15:07:29 <bjorkintosh > (thumbs up emoji).
2026-09-16 15:07:36 <bjorkintosh > I think you'll have a lot of fun with it!
2026-09-16 15:16:49 <deadmarshal > Racket is the all in one scheme. It has everything which makes it suitable for beginners
2026-09-16 15:17:17 <deadmarshal > There's also a good compiler book for it: https://github.com/IUCompilerCourse/Essentials-of-Compilation
2026-09-16 15:17:27 <iv4nshm4k0v > xentrac: My point is, what do I "use", specifically, to interact with DOM from Perl?  Is there a ready-to-use module on CPAN, for instance?
2026-09-16 15:17:46 <iv4nshm4k0v > Beginners in Scheme, or beginners in programming?
2026-09-16 15:19:41 <xentrac     > I don't know at all.
2026-09-16 15:23:18 <bjorkintosh > iv4nshm4k0v: both.
2026-09-16 15:23:34 <bjorkintosh > I'd say it's the python of the lisp world.
2026-09-16 15:23:44 <iv4nshm4k0v > That's something that one will need to figure out to develop client-side webapps in Perl, though.  I understand that it is, in principle, possible to do it - much like how it's possible to webapps in Pygmy - but unless someone already did a bunch of such apps, and shared their experiences, it'll take quite some effort to figure out the details and pitfalls, etc.
2026-09-16 15:23:58 <iv4nshm4k0v > Heh; one language I'm most certainly not eager to learn is Python.
2026-09-16 15:24:00 <deadmarshal > yes both, cause most racket books start from the beginning
2026-09-16 15:24:47 <bjorkintosh > iv4nshm4k0v: it's not python. but python has its roots in SETL and ABC (which was designed as a beginner's language).
2026-09-16 15:24:52 <deadmarshal > iv4nshm4k0v: There's this new perl web framework I heard is good: https://punkperl.com
2026-09-16 15:25:24 <bjorkintosh > much like Logo and BASIC and other such languages.
2026-09-16 15:26:04 <bjorkintosh > point being that, Racket is excellent for children playing around in a terminal, to wherever else one needs to get to, because after all, it's a lisp.
2026-09-16 15:26:14 <bjorkintosh > anyway, enough of that from me. No further sales.
2026-09-16 15:28:27 <bjorkintosh > John Carmack (id, Doom etc) famously used it for VR scripting a decade ago https://github.com/jb55/vrscript-samples
2026-09-16 15:28:31 <bjorkintosh > the language has since grown up.
2026-09-16 15:30:37 <iv4nshm4k0v > deadmarshal: I've been researching Web frameworks for Perl for a bit a decade or so ago.  I frankly never quite "got" if they make sense for my uses.  The kind of API I'd design is like http://en.wikipedia.org/w/api.php (except likely much smaller) - I'm not sure frameworks help with that kind of thing.  (Does Wikipedia use any, BTW?)
2026-09-16 15:34:00 <iv4nshm4k0v > Plack was all the rage back then, I think.
2026-09-16 15:40:16 <xentrac     > iv4nshm4k0v: how much work the DOM interface is depends on what approach you use.  For example, I feel like it would be pretty easy to wire Perl up to React so that the Perl updates the screen by squirting out a string of XML that React then applies the usual virtual-DOM-diffing magic to
2026-09-16 15:43:09 <xentrac     > I did a deep dive into the origins of Python a couple of years ago and came up with https://news.ycombinator.com/item?id=40992191
2026-09-16 15:43:52 <iv4nshm4k0v > React would be one another moving part in this setup, then.  And depending on how much Perl code there will be, the resulting webapp might end up being "JavaScript with bits of Perl thrown in" rather than "written in Perl" proper.
2026-09-16 15:45:10 <iv4nshm4k0v > By the by, if Debian dependencies, http://packages.debian.org/sid/request-tracker5/ , are anything to go by, http://bestpractical.com/rt/ uses Plack.  And that application sees some heavy use, though probably not anywhere near Wikipedia.
2026-09-16 15:45:39 <xentrac     > yeah, if you just do `elem.innerHTML = stringFromPerl;` some things will be a bit clumsier than if you use React
2026-09-16 15:46:14 <xentrac     > ABC was based on SETL, but had strong unacknowledged influences from awk, and Python also drew heavily from awk, independently of ABC
2026-09-16 15:47:18 <xentrac     > I don't think Wikipedia uses any JS frameworks, and MediaWiki predates all the PHP frameworks like Laravel, unless you count PHP itself as a "framework"
2026-09-16 15:55:27 <iv4nshm4k0v > Wonder if that can be taken as an indication that it's possible to write performant /and/ maintainable server-side applications without relying on existing frameworks?
2026-09-16 16:14:46 <xentrac     > What do you mean?
2026-09-16 16:22:03 <MrMobius    > iv4nshm4k0v: why no Python? not saying you should. just curious
2026-09-16 16:27:50 <iv4nshm4k0v > I've been working as a lecturer at a university.  I've seen my share of badly-indented programs.  And yet I cannot agree it's a good idea to build a programming language's syntax around the idea of the code always being idented "right."
2026-09-16 16:27:51 <iv4nshm4k0v > xentrac: Suppose I want to develop a server-side application.  There're lots of frameworks for that.  Do I have to use any?  Are there specific cases where frameworks are likely, or not likely, to help?
2026-09-16 16:38:28 <xentrac     > you certainly don't have to use any
2026-09-16 16:39:41 <xentrac     > if your application is a simple CRUD application, it's likely to be easier to write it in Django or Rails or similar framework than to write it from scratch
2026-09-16 16:40:14 <xentrac     > but if it has a lot of internal logic, or not a very complex database schema, those frameworks gain you comparatively little (and may cost more)
2026-09-16 16:41:29 <xentrac     > also, if you don't mind writing SQL by hand, the comparative advantage of things like the Django admin console is smaller, though still IMHO nonzero
2026-09-16 16:42:10 <xentrac     > because you can just populate the database from the SQL prompt
2026-09-16 16:42:23 <xentrac     > and delete incorrect records, update them, etc.
2026-09-16 16:42:50 <xentrac     > whereas, if you're allergic to SQL, not just the Django admin console but the Django ORM (or Rails's ActiveRecord) is a huge advantage
2026-09-16 16:43:26 <iv4nshm4k0v > Makes me wonder if it's possible to tolerate Prolog and be allergic to SQL at the same time.
2026-09-16 16:43:44 <xentrac     > I think people who know Prolog are less likely to be willing to tolerate SQL
2026-09-16 16:43:50 <xentrac     > they know how much better things could be
2026-09-16 16:44:28 <xentrac     > on the HTML side you probably want some kind of template language that automatically escapes strings you interpolate into your HTML.  the frameworks have this out of the box, but it's only a few lines of code
2026-09-16 16:44:50 <xentrac     > or it can be enormous, depending on how much functionality your template language has
2026-09-16 16:45:52 <iv4nshm4k0v > A featureful template engine seems like something that a lot of problems will benefit from, indeed.
2026-09-16 16:46:20 <xentrac     > Django's is deliberately not too featureful so it's not too hard to debug
2026-09-16 16:46:26 <xentrac     > but it does have conditionals and iteration
2026-09-16 16:46:39 <xentrac     > well.  its iteration is map
2026-09-16 16:49:07 <xentrac     > Django eventually adopted Rails's approach to database schema upgrades, where your database schema is the end product of a sequence of "migrations".  This approach reduces the likelihood that you'll accidentally knock over the production server by changing the database schema by making the sequence of schema changes reproducible on a staging server.  Depending on how stringent your server-side
2026-09-16 16:49:13 <xentrac     > application's uptime SLA is, you may not care
2026-09-16 16:49:45 <xentrac     > it's slightly less work than just typing ALTER TABLE commands by hand, but much more testable
2026-09-16 16:51:12 <xentrac     > and that's about the size of it: server-side frameworks typically give you XSS-proof templates, a SQL ORM, reproducible schema migration, and a database admin view (which Rails eventually adopted from Django)
2026-09-16 16:51:16 <iv4nshm4k0v > I can see the importance of such a feature, but it's not readily apparent to me how a framework can /guarantee/ it.
2026-09-16 16:51:54 <xentrac     > the migrations don't guarantee that you won't have bugs where your code still depends on the old database schema, if that's what you mean
2026-09-16 16:52:23 <xentrac     > they just enable you to notice that on your staging server before you push to production, and have some confidence that what you push to production will behave the same as on your staging server
2026-09-16 16:54:50 <xentrac     > the main thing about these big four ideas is actually the idea rather than the implementation, I think.  They're like design patterns, in the sense that if you are facing problems like "how do I join tables for this list view" or "how do I write out HTML", there are a lot of ways to do it that you will regret later, and a few ways that seem to work pretty well
2026-09-16 16:58:05 <xentrac     > so you could very reasonably implement one of those ways in some other language, which is I think what Laravel and AdonisJS are
2026-09-16 17:05:51 <iv4nshm4k0v > I can agree that it's easy to do HTML (XML) escaping wrong (kinda-sorta stumbled on that myself, see recent news:comp.unix.shell discussion), but it's not that hard to do it right, either; there're just two to four characters to escape, after all.  In Perl, it can be as simple as s {[&<\042\047]}{${ \sprintf ("&#%d;", ord ($&)); }}g;.
2026-09-16 17:05:51 <iv4nshm4k0v > In POSIX shell, it could be xml_escape () { sed -e "s/&/\\&amp;/g; s/</\\&lt;/g; s/\"/\\&#34;/g; s/'/\\&#39;/g;" ; }.
2026-09-16 17:18:08 <xentrac     > Right, the issue is generally not that people do it wrong, but more that they don't do it at all
2026-09-16 17:18:34 <xentrac     > or, not everywhere they should have done it
2026-09-16 17:19:20 <xentrac     > I mean you can write a CGI shell script that just says
2026-09-16 17:19:24 <xentrac     > cat <<EOF
2026-09-16 17:19:40 <xentrac     > Welcome, $REMOTE_USER!
2026-09-16 17:19:40 <xentrac     > EOF
2026-09-16 17:19:45 <xentrac     > and you have an XSS hole
2026-09-16 17:20:08 <xentrac     > (following the Content-Type line of course)
2026-09-16 17:20:50 <iv4nshm4k0v > Even with cat <<EOF, you can still $(printf %s\\n "$VAR" | xml_escape) - or $(xml_print "$VAR") - you just need to keep in mind you're writing HTML, not plain text.
2026-09-16 17:21:11 <xentrac     > yes, but it's easier to do it wrong than right
2026-09-16 17:21:58 <xentrac     > whereas, with a template language that escapes by default, it's easier to do it right than wrong
2026-09-16 17:23:45 <iv4nshm4k0v > It can be argued it's easier to not check return values from standard C functions than to check them.  And a template language is ought to support writing things both escaped (like string values) and unescaped (like bits of HTML produced elsewhere.)
2026-09-16 17:24:00 <xentrac     > Yes, and that's why Python uses exceptions
2026-09-16 17:25:20 <iv4nshm4k0v > M-m.  Now I wonder why Go does pretty much the reverse.  (Or so I heard.)
2026-09-16 17:25:59 <xentrac     > it's fairly easy for a template language to support both, and most do (Django's has two different ways: https://docs.djangoproject.com/en/6.1/ref/templates/builtins/#autoescape)
2026-09-16 17:26:15 <xentrac     > well, in Golang it's not quite as easy to not check return values
2026-09-16 17:27:06 <xentrac     > but I think the main reason is that Go derives from imperative languages like C, while Python derives from functional languages like ABC
2026-09-16 17:29:20 <xentrac     > in imperative computation, it's crucial to finish what you start; if not, you're going to leak memory and maybe do worse things
2026-09-16 17:30:43 <iv4nshm4k0v > Yet Python itself isn't strictly functional.
2026-09-16 17:30:46 <xentrac     > functional languages are generally garbage-collected, so such problems are much rarer (opening files, say, rather than leaking memory, and finalizers can solve most of the remaining problems at some risk to soundness)
2026-09-16 17:31:12 <xentrac     > no, and, on the other side, Go has GC
2026-09-16 17:34:05 <xentrac     > Go also has `defer` for the other cases.  But the Go compiler started out as the Plan9 C compiler, and Ken Thompson was one of the language's designers
2026-09-16 17:46:10 <veltas      > I think exceptions are really decoupled from imperative vs functional
2026-09-16 17:46:19 <veltas      > Except maybe in some distant heritage
2026-09-16 17:47:21 <xentrac     > it sounds like you disagree with my reasoning above; I'm interested to hear why
2026-09-16 17:48:25 <veltas      > Well C++ has exceptions, and Python, and a ton of other imperative languages.  And logically I'd say it's more about whether you have a structured way to handle a sort of 'abort' or 'long jump'.
2026-09-16 17:49:01 <veltas      > And likewise many functional languages have exceptions too
2026-09-16 17:50:03 <xentrac     > it may be relevant here that exceptions are banned in Google C++, and that was already true when the Golang team started developing Go at Google
2026-09-16 17:50:54 <xentrac     > and that it took many years for the C++ STL to become exception-safe, precisely because it's written in an imperative style
2026-09-16 17:52:39 <xentrac     > so, while I agree that the exception mechanism isn't the same thing as being a functional language, I don't agree that they're thoroughly decoupled
2026-09-16 17:54:13 <veltas      > Your first point I don't think is relevant, your second point is tenuous given C++ was one of the earlier big attempts at exceptions in imperative and e.g. Java/Ada managed to get this right, C++ has never desired that level of exception safety so they've got the bed they've made
2026-09-16 17:54:40 <veltas      > C++ exceptions have never been that good but it's still arguably better than not having them at all
2026-09-16 17:55:19 <veltas      > My opinion is founded on imperative language design I've done and experience using exceptions in imperative languages, it feels extremely normal and natural to structure long jumps and cleanup that way personally
2026-09-16 17:55:32 <veltas      > But it's just an opinion, you are welcome to disagreee
2026-09-16 17:56:03 <veltas      > It fits neatly into Forth too... even though i hate the syntax they settled on
2026-09-16 17:56:58 <veltas      > Ultimately if you have a program subdivided into procedures or functions then it's natural to want a mechanism to handle the rarely used error/cleanup handling
2026-09-16 17:57:42 <veltas      > Without explicitly handling it by value and with the normal control mechanisms (i.e. with error return values)
2026-09-16 17:59:42 <veltas      > I guess a counterpoint is that it's hard to get exceptions right because mutating state you are always at risk of an exception firing and leaving something incorrect because of some implicit exception that wasn't clear in the code
2026-09-16 18:00:30 <skveery     > veltas I have the same issue - but the answer is much different for embedded systems.  Maybe Mecrisp or Mecrisp cube?
2026-09-16 18:00:46 <veltas      > What issue?
2026-09-16 18:01:10 <skveery     > Scripting language in C?
2026-09-16 18:04:48 <veltas      > xentrac: There's a clear movement away from exceptions anyway, i.e. Go, Rust, Zig, etc don't have exceptions.  Do you think this is a good thing or not?
2026-09-16 18:07:17 <veltas      > I'm on the fence about it
2026-09-16 18:34:09 <deadmarshal > exceptions are pretty expensive
2026-09-16 18:40:40 <iv4nshm4k0v > I guess I can see how exceptions are "easier" with a GC, and perhaps closures, though, well, if Forth has them, they're certainly doable without.  My experience with exceptions in Perl is limited, but has been positive so far; it's certainly a desirable feature in a language, if implemented correctly.
2026-09-16 18:40:40 <iv4nshm4k0v > I also can see how it can be confusing; but then again, from where I stand, things like dynamic scope, or C++ (optional) pass-by-reference function arguments, or C++ operator overloading, are confusing just as well.
2026-09-16 20:19:55 <veltas      > deadmarshal: In C++ because of not generating nearby code to unwrap
2026-09-16 20:20:46 <veltas      > Kind of a weird optimisation but intention is exception-throwing code shouldn't hurt optimisation / locality of normal runtime code