The main thing about prolog isn't the algorithms. In fact, the actual depth-first search isn't even part of the standard.

The nice thing about prolog is that you write logical rules, and they can get used in whatever order and direction that is needed. By direction, I mean that if you define "a grandparent is the parent of a parent", you can now use that rule not just to evaluate whether one person is a parent (or to find all grandparents) but also to conclude that if you know someone is a grandparent, and they are the parent of some one, then that person is someone's parent. Ok, it can also do recursion, so if you define an ancestor as a parent or the parent of an ancestor it will recurse all the way up the family tree. Neat.

You could write some kind of runtime that takes c code and brute-forces its way from outputs to inputs, except that regular imperative code allows for all kinds of things that make this impossible (e.g. side-effects). So then, you'd be limited to some subset, essentially ending up with a domain specific language again, albeit with the same syntax as your regular code, rather than those silly :- symbols (although LISP looks much sillier than prolog IMHO).

What the article is getting at is that if you use some features specific to a language, it's hard to embed your code as a library in another language. But is it? I mean, DLLs don't need to be written in the same language, there's stuff like JNI, and famously there's stuff like pytorch and tensorflow that runs CUDA code from python.

The syntax of Prolog is basically a subset of the language of First Order Logic (sans quantifiers and function symbols), it doesn't get any more minimal than that. What's special in Prolog compared to imperative languages including functional languages is that variables aren't "assigned" but implicitly range over potential values until satisfying the context, like in math formulas for sets. Yes you can express that awkwardly with tons of type annotations and DSL conventions so that you never have to leave your favourite programming language. But then there's the problem of a Prolog "engine" doing quite a bit more than what could be reasonably assumed behind a synchronous library call, such as working with a compact solution space representation and/or value factoring, parallel execution environment, automatic value pruning and propagation, etc.

The integration of a Prolog backend into a mainstream stack is typically achieved via Prolog code generation (and also code generation via LLMs) or as a "service" on the Prolog side, considering Prolog also has excellent support for parsing DSLs or request/responses of any type; as in, you can implement a JSON parser in a single line of code actually.

As they say, if Prolog fits your application, it fits really well, like with planning, constraint solving, theorem proving, verification/combinatoric test case enumeration, pricing models, legal/strategic case differentiation, complex configuration and the like, the latter merely leveraging the modularity of logic clauses in composing complex programs using independent units.

So I don't know how much you've worked hands on with Prolog, but I think you actually managed to pick about one of the worst rather than best examples ;)

By that same logic, we don't need object oriented features in a language, because we have closures and can get the same functionality with a library.

Sometimes, having a language with a distinct syntax is nicer.

The only languages I know that can do prolog-like-constructs as-a-library are lisps, or at least langs that have reasonable symbol constructs. Usability is way way worse if you can’t talk about variables as first class objects.

I was talking to Bob Harper about this specific issue (context was why macro systems are important to me) and his answer was “you can just write a separate programming language”. Which I get.

But all of this is just to say that doing relational-programming-as-a-library has a ton of issues unless your language supports certain things.

Speaking of prolog, any recommendations for resources learning it at a stage somewhere between "draw three circles" and "draw the rest of the owl"

I don't have real work I need prolog for, but I find it an interesting subject, My personal learning goal, the point where I can say I know prolog reasonably well is when I can get it to solve this mit puzzle I found, a sort of variant of soduku. I found a clever prolog solver for soduku that I thought could teach me more in this domain, but it was almost to clever, super optimized for soduku(it exploited geometric features to build it's relationships) and I was still left with no idea on how to build the more generic relationships I need for my puzzle(specific example if soduku cells were not in a grid how could they be specified?), in fact I can find very little information on how to specify moderately complex, ad hoc relationships. One that particularly flummoxed me was that some rules(but you don't know which) are wrong.

https://www.swi-prolog.org/pldoc/man?section=clpfd-sudoku

Prolog is great because when it works it feels like magic. You give it some pragmas and it tells you the answer. The downside is when it doesn't work it also feels like magic. It's not easy to reason about the amount of work it needs to do. If your Prolog program is taking a long time to run it is hard to figure out if it is going to take 2 hours or 4,000 millennia.

Disclaimer: I've no idea what I'm talking about. :)

But I have heard repeatedly that the good thing of prolog is the compiler, that takes information and queries that would be awful inefficient, and convert them in something that actually works. So I'm not sure... of course, you can convert virtually any language in a kind of library with some API that basically accepts source code... but I'm pretty sure is not what you meant.

I think the examples others have highlighted show the problem with just making it a library. They’re all lacking a lot of features from Prolog, particularly in terms of optimization. Just use Prolog if you need its features and invoke SWI-Prolog like you’d call any other language’s interpreter.

Are there any particularly excellent examples of prolog implemented as a library you could point us to?

    # ya don't really care how this works
    prolog.consult("diabetes_risk.pl")

    # ...but you can query into it!
    query = "at_risk_for_diabetes(Person)"
    results = list(prolog.query(query))

   valid_config = consult("rules.pl")
      + consult("parts_data.pl")
      + python.choice_so_far(...)

   rules.pl: only_one_cpu, total_watts < power_supply(watts)
   parts_data.pl: cpu_xyz: ...; power_supply_abc: watts=1000
   choices: cpu(xyz), power_supply(abc), ...

Think of Prolog the language as just a serialization of a Prolog AST. The AST could be constructed in any programming language as a library. But what if we want to share and store these ASTs? We can serialize them to Prolog the language! The language has value even if it’s a library.

Prolog admittedly mystifies me even more than the Haskell family. How do you do anything effectful, like read from a file, or output arbitrary data to standard out, or set up a loop to process keyboard events every 1/n seconds? How do you make system calls?

Prolog is a contrived example. It's small and simple enough to be implemented as a DSL embedded in another language, reusing most of the parser and leaningn its execution logic.

Now try to produce a library that adds compile-time features: static types, lifetimes, the notion of const and constexpr, etc. You can, of course, write external tools like mypy, or use some limited mechanism like Java annotations. But you have a really hard time implementing that in an ergonomic way (unless your language is its own metalanguage, like Lisp or Forth, and even then).

Creating a library that alters the way the runtime works, e.g. adding async, is not entirely impossible, but usually involves some surgery (see Python Twisted, or various C async libs) that results in a number of surprising footguns to avoid.

Frankly, even adding something by altering a language, but not reworking it enough to make the new feature cohesive, results in footguns that the source language did not have. See C#'s LINQ and exceptions.

But why should it be though? You haven’t really addressed that. It’s like saying “Haskell shouldn’t be its own language, it should just be a couple of features like lambdas integrated into a JavaScript library”. Well if you do that you get some nice features in JavaScript but you’ve done away with the whole value proposition of pure functional programming. That’s an actual loss, there’s something to be said for maintaining a pure set of features that gives languages different properties and guarantees you can’t get with “everything is just a lib to an imperative language”

How many Prolog programmers does it take to change a lightbulb?

false.

https://www.j-paine.org/dobbs/prolog_lightbulb.html

I always wanted to write a compiler whose front-end consumes Prolog and back-end emits PostScript, and call it "PrologueToPostscript".

prologue: a separate introductory section of a literary, dramatic, or musical work.

postscript: an additional remark at the end of a letter, after the signature and introduced by ‘PS’.

Except when implemented as library it doesn't take advantage of WAM and related JIT.

i treat it like i treat SQL.

That's the main issue I found with Scala, and as I grow older also with certain libraries (especially in unit testing land) that try to add a language / DSL on top. Not only do you need to learn Scala, you need to learn various DSLs on top of that depending on what you use or want to achieve. Some egregious examples here and there.

I'm sure there's good use cases for it - one impressive example at the time was using functional programming to create Hadoop map / reduce jobs, a oneliner in Scala was five different files / classes in Java. But for most programming tasks it's overkill.

You can write boring code in Scala, but in my (limited) experience, Scala developers don't want to write boring code. They picked Scala not because it was the best tool for the job, but because they were bored and wanted to flex their skills. Disregarding the other 95% of programmers that would have to work with it.

(And since these were consultants, they left within a year to become CTOs and the like and ten years on the companies they sold Scala to are still dealing with the fallout)

> I lost my enthusiasm when the community decided they wanted to use it as Haskell on the JVM

It's not the whole community, not by a long shot. Don't judge Scala by the Scala subreddit.

Most new things you'll see written about Scala are about solving difficult problems with types, because those problems are inexhaustible and some people enjoy them, for one reason or another. Honestly I think this shows how easy and ergonomic everything else is with Scala, that the difficulties people write about are all about deep type magic and how to handle errors in monadic code. You can always avoid that stuff when it isn't worth it to you.

The type poindexters will tell you that you're giving up all the benefit of Scala the moment you accept any impurity or step back from the challenge of solving everything with types, and you might as well write Java instead, but they're just being jerks and gatekeepers. Scala is a wonderful language, and Scala-as-a-better-Java is a huge step up from Java for writing simple and readable code. It lets you enjoy the lowest hanging fruit of functional programming, the cases where simple functional code outshines OO-heavy imperative code, in a way that Java doesn't and probably never will.

Haskell is usually used as a DSL. I believe Haxl is used at Meta and TidalCycles is a good example of another DSL built in Haskell.

Although I agree the usual lens, optics, machines, pipes or other higher kinded libs are completely unnecessary, solving problems you do not want to have and have dire performance implications, but are at least correct and allow you to throw code at problems quickly, even though that code sucks in all ways except correctness.

Have you tried Clojure(Script)? It could be just what you need, bottom-up programming in a Lisp-like language essentally means extending the langauge in order to solve the problem at hand.

Or, as Paul Grahmam put it in his 1993 book On Lisp: "a bottom-up style in which a program is written as a series of layers, each one acting as a sort of programming language for the one above"

https://paulgraham.com/progbot.html

https://www.paulgraham.com/onlisptext.html

Here is a talk that explains the concept in Clojure, titled Bottom Up vs Top Down Design in Clojure:

https://www.contalks.com/talks/1692/bottom-up-vs-top-down-de...

I recently started to learn Scala and I love it, also for it's functional aspect. Regarding your comment, it feels like scala is generic enough to be used also in other ways, and definitively for DSLs. What do you think it's missing?

Hopefully project Panama will see better interoperability with libraries using the C memory model however migration does not appear to be easy. Arrow Java still uses sun.misc.Unsafe for native memory access.

Reminds me of a joke.

I have a problem.

Right, I'll design a DSL.

Hmm. Now I have two problems.

Doing fancy things with types used to interest me, now it's the last thing I want to touch, after being burned too many times by libs trying to be clever.

I used Scala a few times when it was semi popular, just seemed like Java but with lots of redundant features added. Not sure what the aim was.

Scala is a fantastic language and in fact I'd say it's the language that proves the article wrong.

Java was the language where "write libraries instead" happened, and it became an absolute burden. So many ugly libraries, frameworks and patterns built to overcome the limitations of a simple language.

Scala unified the tried-and-tested design patterns and library features used in the Java ecosystem into the core of its language, and we're better off for it.

In Java we needed Spring (urghh) for dependency injection. In Scala we have the "given" keyword.

In Java we needed Guava to do anything interesting with functional programming. FP features were slowly added to the Java core, but the power and expressivity of Java FP is woeful compared what's available at the core of Scala and its collections libraries.

In Java we needed Lombok and builder patterns. In Scala we have case classes, named and default parameters and immutability by default.

In the Java ecosystem, optionality comes through a mixture of nulls (yuck) and the crude and inconsistently-used "Optional". In Scala, Option is in the core, and composes naturally.

In Java, checked exceptions infect method signatures. In Scala we have Try, Either and Validated. Errors are values. It's so much more composable.

There's so much more - but hopefully I've made the point that there's a legitimate benefit in taking the best from a mature ecosystem and simple language like Java and creating a new, more elegant and complete language like Scala.

Have you seen nushell? It lets me one-liner so many things that would have previously taken breaking out a "real" language to do

Contrived example:

  ls | where type == 'file' | sort-by size | take 4  | each {|f| {n: $f.name, s: ($f.size | format filesize MB) }} | to json

outputs

  {
    "n": "clippy.toml",
    "s": "0.000001 MB"
  },
  {
    "n": "README.md",
    "s": "0.000009 MB"
  },
  {
    "n": "rustfmt.toml",
    "s": "0.000052 MB"
  },
  {
    "n": "typos.toml",
    "s": "0.00009 MB"
  }

    E = Struct.new(:name, :size, :type)
    def ls = Dir.children('.').map{ s=File::Stat.new(_1); E.new(_1, s.size, s.file? ? 'file' : 'dir') }

    ls.find_all{_1.type == 'file'}.sort_by(&:size).take(4).map{ {n: _1.name, s: _1.size } }.each { puts JSON.pretty_generate(_1) }

  ls -l --sort=size | head -n 5 | tail -n 4 | awk '{print $5 " = " $9}' | numfmt --to iec | jq --raw-input --null-input 'inputs | gsub("\r$"; "") | split(" = "; "") | select(length == 2) | {"s": (.[0]), "n": .[1]}'

    find -maxdepth 1 -type f -printf '%s %f\n' | sort -n | head -n 5

   ruby -rjson -nae ' puts(JSON.pretty_generate({n: $F[1], s: "%.5f MB" % ($F[0].to_i / 10e6) }))'

  gci -file | sort-object size | select name, size -first 4 | % { $_.size /= 1MB; $_ } | ConvertTo-Json

You can use various programming languages with shebangs.

C#: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...

Java: https://dev.to/toliyansky/scripting-with-java-3i9k

Go: https://golangcookbook.com/chapters/running/shebang/

https://github.com/igor-petruk/scriptisto will let you generate shebang scripts for pretty much any language

OCaml is a scripting language in this sense. No need to compile an executable ahead of time, just have a `#!/usr/bin/env ocaml` shebang (or more realistically: `#!/usr/bin/env -S ocaml -I +unix unix.cma`) at the top of a source file.

Though, I don't think it has the capability for single-file scripts to declare 3rd-party dependencies to be automatically installed.

There's a trick shared here days ago to add a kind of shebang to Go that may interest you: https://lorentz.app/blog-item.html?id=go-shebang

Discussion: https://news.ycombinator.com/item?id=46431028

Two interesting options for everyday scripting are Python and Powershell.

  import ...foo.bar

Have you considered PowerShell? It's open-source, and typed, and definitely usable from the command line with lots of resources for.

https://github.com/PowerShell/PowerShell

  #!/usr/bin/dotnet run

If you just wait a few months, then that program will be written in a typed language. The type checker for Elixir is coming along nicely and every release brings more checks.

Suggest you take a look at https://raku.org for a strongly (but gradual) typed scripting language.

    print 42 + 99;          # 141
    print &print.file ;     # ...src/core.c/io_operators.rakumod
    print &infix:<+>.file;  # ...src/core.c/Numeric.rakumod
    print ?CORE::<&print>;  # True 

Babashka (https://babashka.org/) is an interesting tool for scripting. It's Clojure, so dynamic typing, but it's data orientation makes it a great fit for something like your example.

I wanted to say Haskell with shh[^1] and stack's or nix's shebangs[^2][^3], but interpreted haskell is not particularly fast.

Also I think a Python script is reasonable if you use a type-checker with full type annotations, although they are not a silver bullet. For most scripts I use fish, which is my preferred interactive shell too.

[1]: https://hackage.haskell.org/package/shh

[2]: https://docs.haskellstack.org/en/v3.9.1/topics/scripts/

[3]: https://wiki.nixos.org/wiki/Nix-shell_shebang. On a side note, if you were to use nix's shebang for haskell scripts with dependencies, you should be using https://github.com/tomberek/- instead of impure inputs, because it allows for cached evaluation. I personally cloned the repo to my personal gitlab account, since it's small and should never change

It probably is perl or Python.

@dev_l1x_be: The answer isn't a new typed scripting language. It's recognizing what the interpreter already is.

LLMs are eval(). Skills are programs. YAML is the motherboard.

@unkulunkulu nails it -- "library as the final language", languages all the way down. Exactly. Skills ARE languages. They teach the interpreter what to understand. When the interpreter understands intent, the distinction dissolves.

@conartist6: "DSL is fuzzy... languages and libraries don't have to be opposing" -- yes. Traditional DSL: parse -> AST -> evaluate. LLM "DSL": read intent -> understand -> act. All one step. You can code-switch mid-sentence and it doesn't care.

The problem with opinionated frameworks like ROR and their BDFLs like DHH is that one opinion is the WRONG number!

The key insight nobody's mentioned: SPEED OF LIGHT vs CARRIER PIGEON.

Carrier pigeon: call LLM, get response, parse it, call LLM again, repeat. Slow. Noisy. Every round-trip destroys precision through tokenization.

Speed of light: ONE call. I ran 33 turns of Stoner Fluxx -- 10 characters, many opinions, game state, hands, rules, dialogue, jokes -- in a single LLM invocation. The LLM simulates internally at the speed of thought. No serialization overhead. No context-destroying round trips.

@jakkos, @PaulHoule: nushell and Python are fine. But you're still writing syntax for a parser. What if you wrote intent for an understander?

Bash is a tragedy -- quoting footguns, jq gymnastics, write-only syntax. Our pattern: write intent in YAML, let the LLM "uplift" to clean Python when you need real code.

Postel's Law as type system: liberal in what you accept. Semantic understanding catches nonsense because it knows what you MEANT, not just what you TYPED.

Proof and philosophy: https://github.com/SimHacker/moollm/blob/main/designs/stanza...

> This looks to me like partly a false dichotomy

Wasn't that the point of the article? That you need both?

There's so many languages out there, I reject Raku out-of-hand simply since IMO the type should follow the variable name.

    my $a of Int = 42;
    say $a;  # 42

    my $a of Int = "foo";'       
    # Type check failed in assignment to $a; expected Int but got Str ("foo")

?

  int number;

 … you choose Pascal style

  number : Integer;

I would go so far as to say the rise of Rails and the downfall of J2EE being concurrent was not entirely accidental. I have/had no particular affiliation for Rails, but it demonstrated how to write simple, opinionated backend code, and that inspired a flurry of Java/JVM web frameworks that tried to follow a similar pattern and eventually gave us libraries like DropWizard, Javalin, SparkJava, even Spring Boot to some extent.

> years ago a senior developer close to me said

What was the senior's stack?

I couple of years ago I would ask to collect your coworker’s garbage bin :)

Not as easy to find in my vicinity, at least good ones, which is of course true for any language and profession in general.

I have RoR on my resume and very fond of it.

If one is looking for Java developers, it only makes sense to throw rails resumes in the trash. It will save time for both parties.

One side of my brain agrees that's a dumb way to judge anyone but then when I think about the accepted filtering mechanism they really aren't any better or any worse. You cannot interview everyone and ultimately you're looking for some combination of competence, alignment, drive and social fit. Filtering on where you worked previously or where you went to school or whether you can pass some coding challenge only partially fills in the matrix. And the size and shape of the organization can drive how much people in the hiring loop look at each data point. This senior engineer's ideal for alignment and social fit probably favored people who think like them or their department's head.

To be fair, years ago Rails was what all the "bootcamp" programmer mills were pushing. Only you have the full context, but absent of that it is likely that Rails was truly found to be associated with poor applicants. Not because of anything about Rails itself, but because of those "bootcamps" not developing quality people. The culling has to occur at some point. If you throw some great developers out with the bathwater, so be it. There isn't enough time in the day to worry about them.

On the one hand, that obviously filters out many qualified candidates.

On the other, you only have so much time in the day. It'd take me 3-6 months to give phone screens to every resume that comes in the door for any one engineering role, 8x that for a full 4-hour interview. I have to filter through them somehow if it's my job to hire several people in a month.

You'll obviously start with things that are less controversial: Half of resumes are bot-spam in obvious ways [0]. Half of the remainder can easily be tossed in the circular filing bin by not having anything at all in their resume even remotely related to the core job functions [1].

You're still left with a lot of resumes, more than you're able to phone screen. What do you choose to screen on?

- "Good" schools? I personally see far too much variance in performance to want to use this as a filter, not to mention that you'd be competing even more than normal on salary with FAANG.

- Good grades? This is a better indicator IME for early-career roles, but it's still a fairly weak signal, and you also punish people who had to take time off as a caretaker or who started before they were mature enough or whatever.

- Highest degree attained? I don't know what selection bias causes this since I know a ton of extremely capable PhDs, but if anything I'd just use this to filter out PhDs at the resume screening stage given how many perform poorly in the interviews and then at work if we choose to hire them.

- Gender? Age? ... I know this happens, but please stop.

If there's a strong GitHub profile or something then you can easily pass a person forward to a screen, but it's not fair to just toss the rest of the resumes. They have a list of jobs, skills, and accomplishments, and it's your job to use those as best as possible to figure out if they're likely to come out on top after a round of interviews.

I don't have any comment on rails in particular, but for a low-level ML role there are absolutely skills I don't want to see emphasized too heavily -- not because they're bad, but because there exists some large class of people who have learned those skills and nothing else, and they dominate the candidate pool. I used to give those resumes a chance, and I can't accept 100:1 odds anymore on the phone screen turning into a full interview and hopefully an offer. It's not fair to the candidates, and I don't have time for it either.

And that's ... bad, right? I have some things I do to make it better in some ways (worse in others, but on average trying to save people time and not reject too many qualified candidates) -- pass resumes on to a (brief) written screen instead of outright rejecting them if I think they might have a chance, always give people a phone screen if they write back that I've made a mistake, revisit those filtering rules I've built up from time to time and offer phone screens anwyay, etc -- hiring still sucks on both sides of the fence though.

[0] One of my favorites is when their "experience" includes things like how they've apparently done some hyper-specific task they copy-pasted from the job description (which exists not as a skills requirement but as a description of what their future day-to-day looks like), they did it before we pioneered whatever the tech in question was, they did it at several FAANG companies, and using languages and tools those companies don't use and which didn't exist during their FAANG tenure. Maybe they just used an LLM incorrectly to touch up their resume, but when the only evidence I should interview you is a pack of bold-faced lies I'm not going to give the benefit of the doubt.

[1] And I'm not even talking about requiring specific languages or frameworks, or even having interacted with a database for a database-adjacent role. Those sorts of restrictions can often be too overbearing. Just the basics of "I need you to do complicated math and program some things that won't wake me up at night" and resumes that come in without anything suggesting they've ever done either at any level of proficiency (or even a forward or a cover letter stating why their resume appears bare-bones and they deserve a shot anyway).

I agree. c# and asp.net core also co-developed. Interestingly in both direction, towards users (tons of type inference, removing boilerplate, ...) and system (writing highly optimized web servers with low level paradigms)

I don't understand, what's Express? As for libraries and Java, I'd argue Java became a well established enterprise language and platform exactly because it makes such highly effective use of libraries.

See C#'s asp.net core minimal apis (a express clone). So it is definitely possible but you need to co-develop the language. I think as you point out.

It’s possible to have something like Express, take a look at Javalin.

But Java problem is not the mechanics, it’s that the community doesn’t want nice things.

I think you stretch this library thought a bit too far :)