Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The seven programming ur-languages (2021)

madhadron.com

Post reply on HN
Print view View original

141–150 of 326 posts

Re: The seven programming ur-languages (2021)

#141

Post by lispm »

School-Cotton wrote: post #61

> Lisp is about a year younger than Fortran, which makes it the second oldest language still in use today I disagree with this line since Lisp is not really a "language", but a family of them. If we consider Clojure and original Lisp to be the same language, we should also consider that to be true of Algol and Rust.

The original LISP was a language and its implementation. It was also documented - see for example the LISP 1 manual and other publications about it. From that a series of languages evolved, which shared the original core (syntax, data structures, operators, ...) That's what I would consider the core Lisp language family. Most of these languages will have 'Lisp' in its name.

Re: The seven programming ur-languages (2021)

#142

Post by castorp »

ngruhn wrote: post #127
curiousllama wrote: post #120

Earlier quoted context omitted.

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 - p…

> 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.

Re: The seven programming ur-languages (2021)

#143

Post by yellowapple »

felixgallo wrote: post #7

IMO the eighth ur-language is Erlang (with cousin Elixir), which brings the ultra-scaling actor model, an abstract operating system designed for high reliability and low latency, and a bunch of nice rare features like builtin binary structuring/destructuring and pattern matching. While it had its origins in prolog, it's now sufficiently far away from prolog's inner machinery that it only has syntactical similarity. L…

I disagree that Erlang is an ur-language (it's too close to the Self and Prolog ur-languages to be its own, IMO), but I do agree that OTP/ERTS could be a sort of ur-framework or ur-runtime, for exactly the reasons you describe: even explicit attempts to implement "Erlang-style concurrency in $LANGUAGE" routinely only cover some superficial "yeah we've got actors that pass messages and maybe supervise one another" without covering preemptive multitasking, hot-reloading of functions, distribution across nodes, and the myriad other features that give Erlang its reputation for extreme fault-tolerance.

Re: The seven programming ur-languages (2021)

#144

Post by jgilias »

codeflo wrote: post #35
gumby wrote: post #5

An article like this is hard to write. This is a good one. I have a few quibbles, but they are just quibbles. IMHO* a distinguishing feature of Algol like languages (aka "procedural" languages) is the distinction between expressions and statements. Though personally I've never seen the appeal, that distinction seems to be popular for some reason. * this isn't even a quibble -- the article is fine without it. Just som…

I'm not sure I fully agree with that characterization. Many people would intuitively classify assignment as a statement, yet it's an expression in C, which is fully in the Algol tradition. And Rust is certainly a descendant of C, but blurs the lines a lot further with loops being expressions.

Rust is certainly a descendant of ML. It just adopted curly braces to make it more palatable to C-ish people.

https://doc.rust-lang.org/reference/influences.html

Re: The seven programming ur-languages (2021)

#146

Post by ucarion »

tonyarkles wrote: post #126
ucarion wrote: post #81

Earlier quoted context omitted.

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…

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.

Re: The seven programming ur-languages (2021)

#147

Post by blowski »

davidw wrote: post #109
OskarS wrote: post #9

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 pro…

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.

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

Re: The seven programming ur-languages (2021)

#148

Post by turndown »

pulvinar wrote: post #112
t-3 wrote: post #77

Earlier quoted context omitted.

Macro/concatenative languages should replace the Forth line. The author is off-base in thinking RPN or stacks are important to Forth rather than concatenativity. RPN is just an easy way to make interpretation simple, an implementation detail, not a functional requirement. It would be like defining APL as being evaluated right-to-left.

The stack is important to Forth, but equally so is its threaded-subroutine-call nature, which isn't present in other early languages that I know of. That puts Forth halfway between assembly and higher-level (and easier to read) languages. I never saw it as a macro language. At least that's the viewpoint I'm familiar with from back when we heavily used it.

What do you mean by threaded here?

Re: The seven programming ur-languages (2021)

#149

Post by mikevin »

turndown wrote: post #148
pulvinar wrote: post #112

Earlier quoted context omitted.

The stack is important to Forth, but equally so is its threaded-subroutine-call nature, which isn't present in other early languages that I know of. That puts Forth halfway between assembly and higher-level (and easier to read) languages. I never saw it as a macro language. At least that's the viewpoint I'm familiar with from back when we heavily used it.

What do you mean by threaded here?

> What do you mean by threaded here?

Here's a good explanation.

https://www.bradrodriguez.com/papers/moving1.htm

Re: The seven programming ur-languages (2021)

#150

Post by davidw »

blowski wrote: post #147
davidw wrote: post #109

Earlier quoted context omitted.

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.

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
Post reply on HN