Hacker News Reader

Comment by OskarS | Hacker News Reader

Pretty excellent summary, this is roughly the taxonomy I have in my head.

I would maybe add SQL as an ur-language as well. It's not quite general purpose like most of these, but it should have a place in this list, I think. It has some kinship with Prolog and the declarative style, but it's really it's own thing.

You could also maybe argue for something like LabView. Many programmers look down on purely graphical programming languages, but with Houdini, Unreal's Blueprints and the various node-based shader/material systems in gamedev, I think it probably deserves it's own little branch of this family tree.

View on HN

SQL is on the same group as Prolog. In fact, it is a simpler and purer implementation of a constraint-solving language, so it is probably a better option for learning the group than Prolog.

For the signal transformation ones, there are also the hardware definition languages on the same category as LabView and animation languages.

To your point, Berkeley's intro-level CS class, CS61A, used to use teach Prolog as an example of logic programming. They use SQL now instead.

I can't really attest to whether that's a better choice for learning logic programming, though. It's easier to "run programs" in Prolog. SQL wants to be a cog in a machine where Prolog is more freestanding.

I definitely did a bunch of Prolog in my CMPT216 class back in undergrad and I hadn't really thought of SQL as an alternative until today. I agree with you it's easier to "run programs" in Prolog, and a lot of the concepts from the class would have been more difficult to map to SQL than Prolog (e.g. writing a Sudoku solver in Prolog was mind-melting in a good way, writing a Sudoku solver in SQL would probably be mind-melting in a bad way). The one thing that SQL does have going for it though is that there's a ton of tooling for getting practical real-world data into it.

I would absolutely love to take a set of logic/set-oriented problems and solve them both in Prolog and SQL, just to see which ones are ergonomic in each language. Maybe this summer at the cabin...

The tooling thing goes both ways. I remember classmates struggling with homework because they were trying to use a different flavor of SQL than the SQLite we ran for class. This stuff is obvious to engineers, but very confusing to someone whose first hello-world was 8 weeks ago.

SQL has no recursion. I would argue that's a pretty fundamental aspect of Prolog, so I don't think SQL is a representative replacement.

Yes it does. It’s a fun problem to make a sudoku solver

https://technology.amis.nl/it/solving-a-sudoku-with-one-sql-...

Ok fair enough. I suspect that's a pretty non-standard/rarely-used feature though. If you learn SQL you likely won't encounter this and I still contest the idea that SQL is a good entry into the logic paradigm.

SQL and Prolog are both relational. That's very unique to both. But SQL is all about querying databases. Prolog can also be used and understood as a database querying language but it's also very strong for

- parsers

- interpreters

- expert systems

- solving combinatorial problems

If you really want to you can probably use SQL for that too. Or any language for that matter. But going out and learning SQL won't naturally expose you to these applications and how well the logic paradigm lends itself to them.

> I suspect that's a pretty non-standard/rarely-used feature though. If you learn SQL you likely won't encounter this

Recursive common table expressions are part of the SQL standard (since 1999) and are quite frequently used to traverse hierarchical data (aka "adjacency list").

It is part of basically all (good) SQL tutorials - at least in the "advanced" part.

I don't remember using recursion in a real project, but I built a HN clone on top of Postgres, with the following query:

    WITH RECURSIVE thread(id, parent_id, user_id, post_id, timestamp, text, depth) AS (
      SELECT id, parent_id, user_id, post_id, timestamp, text, 0
      FROM comments
      WHERE user_id = 1
        AND parent_id IS NULL
      UNION ALL
      SELECT c.id, c.parent_id, c.user_id, c.post_id, c.timestamp, c.text, t.depth + 1
      FROM comments c
      JOIN thread t ON c.parent_id = t.id
      WHERE c.user_id != t.user_id
    )
    SELECT * FROM thread ORDER BY timestamp ASC;

I wrote a recursive CTE to do a tree traversal on a parent-child “relationship” table a few weeks ago at work.

They do come up!

Oh, it's certainly not a "type specimen". It does actually have recursion and matching-like behavior, but those are convoluted and not really used, so it is not very suitable for general programming.

But lacking those general features makes it an even purer "learning example" of the group.

Not to mention the various graphical programming languages used in industrial control - ladder logic, continuous function chart, and sequential function chart. Ladder in particular is incredibly widespread, as it was a direct descendant of the diagrams used to document and debug relay logic, and was adopted in some of the first PLCs (programmable logic controllers) in the late 60s/early 70s.

Programming PLCs sometimes feels like going to, say, Australia or New Zealand, and being immersed in an environment which went down a different evolutionary tree very on in its development.

SQL might be in its own category or not, but it shares a trait that languages in other categories ended up with: "I know, we'll make it kind of like writing English so that people who aren't experts can program!".

This is one of those things that seems to keep coming back - recently in the Ruby world with Cucumber.

I suspect that idea is now dead. Anything new that accepts something that looks like natural language now needs to be at least as smart as ChatGPT. Stuff that sort of looks like a natural language but is really a formal language now comes across badly.

There have been very few non-English programming languages. There was a French version of COBOL once. I'm surprised that something hasn't come out of China. There's a Chinese dialect of Python. Does anyone use that?

Interesting point about AI... that really could be a game changer, although to me it doesn't feel like it's as precise as we often ask code to be. Yet.

SQL is based on Relational Algebra a mathematical foundation for modeling, factoring and joining data. In this it’s probably unique. Other languages may be based on other mathematical models such as pure functional languages being based on lambda calculus etc.

Articulating your specification in precise language is the hard part. Learning syntax is easy.

I always like to think of Captain Kirk speaking SQL to the computer in Star Trek:

    COMPUTER, SELECT COURSE WHERE MINIMAL PROBABILITY OF KLINGON ENCOUNTER

> recently in the Ruby world with Cucumber.

Way to age yourself old man.

I think you’re first instinct is correct given libraries like Linq and GQL in Groovy. The relational algebra is decidedly different versus say map, filter and reduce.

Sql is accidentally general purpose. Recursive queries, a feature present in all implementations since the 90s, put it just over the line of turing completeness.

> SQL

And, not to put too fine a point on it, being extremely proficient will give you a massive competitive edge in the industry.

Reply on news.ycombinator.com