This embodies why I don't like Prolog. Prolog's philosophy is that you should just write the predicates without thinking about how the engine works. But as soon as you do something actually complicated, you realize that the different optimization modes of the engine give different results, and shortly after that you'll find yourself in the "exhaustively try every possible combination until we get one that satisfies the predicates" mode, and your code will go from taking 1 second to run to taking 8 days.
And because you don't control the engine (you're not supposed to think about it, after all), there's nothing you can do but rewrite the whole thing in a traditional programming language.
> as soon as you do something actually complicated, you realize that the different optimization modes of the engine give different results
The same is true of SQL query planners. You can perform basic queries without understanding how your SQL engine of choice works under the hood, but if you want performance, you must understand how your DB works. SQL is just the interface.
This is different in kind from imperative programming languages (which are much closer in abstraction to the underlying machine architecture), but we rub along with SQL ok; why not Prolog?
I somewhat disagree that you shouldn't be aware of how the engine works. The mechanics are quite simple. Prolog's horn clauses are combined in depth first search manner trying to proof that the negated goal is false.
However, most prolog books focus on rooting the declarative mindset because programmers are generally more familiar with imperative programming. But just as with SQL or lisp there are definitely good ways, bad ways and plain mistakes you can make when approaching a problem.
How is this different from other programming languages though?
One example I often think about is from Ken Silverman: "sub eax, 128" → "add eax, -128". So equivalent ways to write the same program may have different performance characteristics also depending on the tools that are applied. How many people could tell without trying which way to write this example is preferable?
The same phenomenon will be encountered in all kinds of languages, where engine and compiler improvements make existing code faster or slower.
I think this is very well phrased, and I would argue the same holds for Prolog too.
In my opinion, a key difference between Prolog and other languages in that regard is one of degree, not kind: Compared to other languages, addressing performance problems in Prolog engines tends to have far greater effects on Prolog programs, because so much is implicit (i.e., left to the engine).
If the performance problem is not in the engine, but in the program itself, then we will face the same questions with Prolog as with other languages: How to formulate the program better, is there a better approach altogether?
For example, earlier today an interesting question regarding performance was posted in the Scryer discussions:
The comparison in this case is between Gecode and Scryer on a seemingly simple but nontrivial combinatorial task. What is the problem here? Most likely the Scryer engine itself can be improved. And also very likely, there are better ways to model the task, and also better search strategies, and these tend to have far greater performance impact than the base language, and these questions remain also if we change the base language.
In my opinion, these questions regarding different kinds of formulations tend to be more frequently associated with Prolog than with other languages because Prolog is more frequently used for complex tasks where it is not a priori clear how to even approach the problem.
> The origin of the corporation as we know it is as a vehicle for moving funds out of productive enterprises to asset-owners.
It doesn't fill me with confidence that they got this completely backwards. The advantage of the corporate form is that the wealthy owners can cash out without moving any wealth out of the productive enterprises. The whole point of a corporation as opposed to a partnership or joint-stock venture is that wealthy corporate owners can sell their stock to other wealthy people without interfering with the productive enterprise at all!
This article is a reminder to all of us programmers that there is a belief that is common among non-programmer intellectuals (especially the above-average-intelligence-but-not-genius types) but completely non-existent among skilled software engineers:
Abstraction is inherently dishonest.
If you're a good software engineer, you quickly build an understanding that abstractions are vital for detailed understanding of complex systems, but can leak or even fail entirely. Less quickly, software engineers build very good instincts at how to tell when an abstraction is leaking/failing (that's what debugging is, after all).
Outside software engineering, this is not a skill that is consistently practiced. As a result, you end up getting takes like this one, in which the authors figure out that "money" is an abstraction over "all productive work and assets" and that this abstraction sometimes leaks.
But because the authors aren't used to dealing with abstractions, they assume that the fact that the abstraction "money" leaks sometimes means that it's worthless and should be removed. In fact, the opposite is true: the abstraction "money" does leak (which can cause real serious problems), but in the cases it doesn't, it's essential to human flourishing in any economy more complex than "exchange bread for pelts"
The first author is a professor of economics who seems to be some kind of socialist, but they readily admit that money is very useful. They're trying to get to grips with the nature of it. They're saying that some abstractions about money are better than others.
To come up with better abstractions, sometimes you need to strip away the abstractions and study what's being abstracted.
Apparently both authors would develop a better way to explaining and separating these things if they took some Systems Dynamics[1] courses. Everyone who has taken college level economics was taught that money isn't real (I mean the first money was owning a very large rock on a ledger where that rock might be at the bottom of the ocean. [2]) But what is absolutely real is a contract of labor or materials. Using numbers to allow you to trade contracts for wood and carpenters for a house and using tokens to represent those numbers is sufficient to create a more flexible market than just straight up barter.
Well, not in a simplistic way. He kind of fudges it:
> The title Against Money is trying to do a few different things. First, it highlights the distinction between the network of money payments and values, on the one hand, and on the other hand the concrete social and material reality that exists apart from them, and often in tension with them. In this sense, we mean “against” in the same way one might distinguish a figure against a background; by writing about money, we seek to clarify our vision of the social world that exists around, outside and in opposition to it. Second, the title announces our criticism of familiar ways of thinking, our challenge to the dominant view of money within economics. Finally, the title links the book to a political project that seeks to transcend markets and property rights as the organizing principles of society, and to imagine a future in which money no longer defines the scope and possibilities of our collective existence.
> Finally, the title links the book to a political project that seeks to transcend markets and property rights as the organizing principles of society, and to imagine a future in which money no longer defines the scope and possibilities of our collective existence.
Yeah, the part where he says is goal is for society to transcend the concept of money is what got me to think that his goal was for society to transcend the concept of money.
Browsers briefly tried that in the early 00s. It turns out that, from a user perspective, that's an incredibly stupid question- the user has no way of knowing how well the page works until they click "yes"!
I had a chuckle at your comment and felt it was true. But wonder if the commenter is younger. Ted Turner was much more of a household name and public figure in the 20th century. He became less involved in the cable empire by the mid 90s. Younger millennials and onwards probably heard people talk about him a lot less.
Ps. Another memorable media portrayal of Turner, he was clearly the basis for the boss character in the 1994 cartoon The Critic.
I don't think anyone else with the name Obama has been president of anything that confers a library (let alone a presidential library), your answer seems a bit needlessly derisive. I suspect you're just insecure about your personal level of useful knowledge and are trying to lord over someone with your trivia fact.
All of my employers have let me specify my personal projects are mine. Maybe I've been lucky but I wouldn't work at a place that doesn't allow me my own life.
This is also something I try to ask for - generally I get the "that's fine" from the hiring manager and HR, but both times I've then had to push back and get it added to the actual supplied contract. And that was very much not easy.
And even then there's normally a "Sufficiently Different Sector" requirement for those personal projects - which makes sense, but it is inevitably worded vague enough that it would likely require going to court for pretty much any project to show it's not directly related. And that would be near prohibitively expensive for me as an individual if the relationship actually became adversarial.
"Creating a Wikipedia page" is a weird suggestion. In 2026, it's actually not possible to create a Wikipedia page unless you're already a deep expert in Wikipedia culture.
(Wikipedia nerds often say "No, anyone can create a page as long as they follow the 137 guidelines!" This is a prank- Wikipedia admins will delete your article no matter how many guidelines it follows)
Even some 15y ago it was impossible to add web links to communities, even though other web links to similar communities were already in the web links section, because some people weaponized wiki as a moat.
These fake-time environments let you set the time, so you can test how the code will behave in 2039 without waiting for 13 years. For Go's synctest, 1-1-2000 is just the default initial value for now().
And because you don't control the engine (you're not supposed to think about it, after all), there's nothing you can do but rewrite the whole thing in a traditional programming language.
reply