221–230 of 289 posts
Earlier quoted context omitted.
What do you mean by LISP as a siren call? I’ve just started learning clojure and besides the lack of static types (which is pretty harsh for me), it seems like a fun and practical language.
Clojure is probably the most beautiful language I've ever worked with. Nothing is perfect, but Clojure is very simple and elegant.
Prolog, and Constraint Programming especially are great to have in your toolbox. I’ve done research in the field for years, and my job in the industry today is writing Prolog. There are real issues with Prolog: - no proper module nor package system in the modern sense. - in large code bases extra-logical constructs (like cuts) are unavoidable and turn Prolog code into an untenable mess. SWI prolog has single-sided un…
I'd advise to not use Prolog as general-purpose programming language, but as an embedded DSL or as a service for the part it's really suited for (if your app involves exploration and search over a large combinatorical space in the first place, such as in discrete optimization in industry, logistics, and finance). You really don't need yet another package manager and pointless premature modularization for modelling yo…
To be clear what I'd like is to be able to fire up a thread hosting a Prolog runtime and stick predicates into it and query it using an API in the host language's syntax. Instead the best I could do was munge strings together and parse result out, sort-of. And that was after a bunch of time spent trying to reverse-engineer Scryer's API.
I would love to embed a Prolog to host my application's business rules and knowledge. I could see it super useful in a game even (think of the myriad of crazy rules and interactions and special cases in a game like Dwarf Fortress...)
Earlier quoted context omitted.
I acknowledge that you also included your nice talking point in a paper you published on arXiv. Citing yourself doesn't convince me any more of the credibility of this argument. > is there even the slightest doubt about the importance of standards when building and operating giant particle accelerators The particle accelerator application is a checker for existing JSON config files. The accelerator is already running…
> CLP(Z), which does not have an ISO standard CLP(FD/Z) is a candidate for inclusion in the Prolog standard: Several Prolog systems provide it with notable commonalities in features, it fits perfectly into the existing language, and it follows the logic of the standard including its error system. It can even be implemented within Prolog, provided a few basic features are present in a Prolog system. For instance, the…
Agreed, but also minor as you can and should set the double_quotes flag, otherwise your program doesn't have portable semantics even among ISO Prolog systems.
> Even though it may sound easy to say "as long as that dialect has a reliable specification and implementation", I know no such system that exists, and what I see from systems that do not adhere to the Prolog standard makes me doubt that such a thing is possible.
Of course it is possible to program against the quirks of a given implementation. That's what you yourself are doing with your CLP libraries. As you note, your main target has different quirks from other targets.
More broadly, Scryer itself demonstrates that it's possible to program against a programming language that doesn't have an ISO standard but does have a good enough specification and an implementation that adheres to that specification.
> The systems that do not follow the standard often have elementary syntactic problems, such as reading a Prolog term that they themselves emit into a different Prolog term, a recipe for disaster and unacceptable in every domain I know.
You're painting with a very broad brush here. What implementations, and what kinds of terms? If your examples involve infix dot, that would be the kind of term nobody uses and nobody should use in modern Prolog, as you well know. Some of these syntactic problems only appear if you go looking for them. Minor syntactic annoyances will be caught in testing.
I agree that such things are bad, but they are knowable, controllable, and quite probably much less relevant in practice than you suggest.
Very very tangentially: The company I work for is very serious about its software supply chains. If we want to use external software for development, we must apply for permission. For that permission, actual programmers and lawyers trawl through the code and licenses and documentation. Scryer's license file lists one copyright holder, and there are many source files without copyright headers, and then there are many source files with copyright headers that name another copyright holder. Our lawyers would not allow us to touch such a system. If you're serious about promoting Scryer as a serious Prolog for serious use, you might want to consider cleaning this up.
Earlier quoted context omitted.
The more nightmarish thing about Clojure is realizing that, in truth, you have no idea what all these dicts you are passing around the terse, nil-punning functions of your codebase hold at any given time.
That was the case for me. I went all in drinking the Clojure koolaid and wrote some small internal CLI tools with it. If I came back to that code a month or two later I could only properly understand it if I opened up a REPL to debug it. I ported those tools to Java and they were dead simple to comprehend.
One of the reasons Golang has had a use case in today's age is there is a need for a programming language with just functions, loops and if/else statements.
Earlier quoted context omitted.
So SWI appears to be more performant, it has an open license, so as per the GGP's claim regarding Scryer in the post above, it must not be ISO-compliant?
A key performance attraction of Scryer Prolog is its space efficiency for representing lists of characters, yielding a 24 times (!) more compact representation than a naive implementation would. With Scryer Prolog and other recent systems that implement this representation, such as Trealla Prolog, we can easily process many GBs of text with DCGs, arguably realizing the full potential of the originally intended use ca…
Earlier quoted context omitted.
I'd advise to not use Prolog as general-purpose programming language, but as an embedded DSL or as a service for the part it's really suited for (if your app involves exploration and search over a large combinatorical space in the first place, such as in discrete optimization in industry, logistics, and finance). You really don't need yet another package manager and pointless premature modularization for modelling yo…
I've tried casually to take this approach and what I've found is that basically none of the Prologs out there are really designed to be properly embeddable. Even Scryer Prolog, written in Rust, isn't really set up to linked into a Rust program and run this way. I was able to "sort-of" make it happen, but it wasn't a workflow that had been optimized for. To be clear what I'd like is to be able to fire up a thread host…
Earlier quoted context omitted.
Clojure is probably the most beautiful language I've ever worked with. Nothing is perfect, but Clojure is very simple and elegant.
What makes Clojure a non-starter for me is that it runs on the JVM.
Logic programming is overrated, at least for logic puzzles (2013) https://news.ycombinator.com/item?id=36154011
Earlier quoted context omitted.
What makes Clojure a non-starter for me is that it runs on the JVM.
Could you expand why? It's not immediately obvious why would that be, my understanding is that the general consensus around here is that the JVM is a superb piece of tech with a bad rap due to java the language.
Earlier quoted context omitted.
This is a great quote and sadly true. What text is this from?
For me this kind of criticism is very familiar. It comes from theoretical computer scientists who have these purist ideological convictions about how a declarative language should look and behave, that are as unrealistic, because impossible to implement on a real-world computer, as they are uninteresting for practicing programmers because strictly a matter of aesthetics. Such critics have never made anything useable…