18
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 01 Feb 2024
18 points (100.0% liked)
SneerClub
1012 readers
5 users here now
Hurling ordure at the TREACLES, especially those closely related to LessWrong.
AI-Industrial-Complex grift is fine as long as it sufficiently relates to the AI doom from the TREACLES. (Though TechTakes may be more suitable.)
This is sneer club, not debate club. Unless it's amusing debate.
[Especially don't debate the race scientists, if any sneak in - we ban and delete them as unsuitable for the server.]
founded 2 years ago
MODERATORS
Oh, I don't know, maybe that reasonable notions of "reasoning" can include things other than mechanistic search through a rigidly defined type system. If Prolog is capable of reasoning in some significant sense that's not fairly reasonably achieved with other programming languages, how come we didn't have AGI in the 70s (or indeed, now)?
You're not alone. I like Prolog and I feel your pain.
That said I think Prolog can be a particularly insidious Turing tarpit, where everything is possible but most things that feel like a good match for it are surprisingly hard.
oh absolutely! I’ve been wanting to go for broke and do something ridiculous in Prolog like a game engine (for a genre that isn’t interactive fiction, which Prolog excels at if you don’t mind reimplementing big parts of what Inform provides) or something that touches hardware directly, but usually I run into something that makes the project unfun and stop.
generally I suspect Prolog might be at its best in situations where you really need a flexible declarative language. I feel like Prolog might be a good base for a system service manager or an HDL. but that’s kind of the tarpit nature of Prolog — the obvious fun bits mask the parts that really suck to write (can I even do reliable process management in Prolog without a semi-custom interpreter? do I even want to juggle bits in Prolog at all?)
one of the most recent things I've seen in this space is https://www.biscuitsec.org/, which is built on datalog and aims to solve a problem in a fairly interesting domain. I still mean to try it out on a few things, to see how well it maps to use in reality
that seems very cool! I’ve been frustrated in the past by rules-based auth libraries implementing half-baked but complex declarative DSLs when Datalog is right there, so I’m hoping it works well in practice because I’d love to use it too
what, you don't like the 10~15y old pattern of someone slapping together a DSL in a weekend because they read a blogpost about it last week, and then having to deal with the evolving half-restricted half-allows-eval mess in [ruby,erlang,...] with its syntax denoted in some way that isn't equivalent between operating languages? sheesh. what kind of modern web engineer are you?!
lukewarm take: the fact that "yaml engineer" exists as a joking self-deprecating referential description of what so many people do is both an indictment of their competencies (so, so many of these people would rather twiddle variables than even think of learning to write a small bit of programming), but also of the tools that claim to provide more abstractions and an "easier way" to do things
(yes I have a whole rant about this bullshit stored up)
one day the things we do with yaml will correctly be seen as a crime, but very likely only after yaml is replaced by something significantly worse, cause our field stubbornly refuses to learn a damn thing. it’s probably not a coincidence that the only declarative languages I know that aren’t monstrosities are from academia, and they’re extremely unpopular compared to the approach where a terrible heap of unreadable yaml is made worse by shoving an awful macro language into every field