So why is it called "ur"?
The seven programming ur-languages (2021)
121–130 of 326 posts
Re: The seven programming ur-languages (2021)
#122Earlier quoted context omitted.
Erlang is a nice and unique language, but I feel at its core it falls into the object-oriented/message-passing paradigm, very much in the vein of Smalltalk. Consider these paragraphs from Smalltalk's Wikipedia entry [1]: > A Smalltalk object can do exactly three things: > 1. Hold state (references to other objects). > 2. Receive a message from itself or another object. > 3. In the course of processing a message, send…
Joe Armstrong talked about that in the past, and I can sort of see it if I squint, but at the end of the day, there are a lot of things in Erlang that are not processes, like most of your basic data types, so I'd just say Erlang is good at borrowing, like a lot of practical real world languages are, and in doing so, came up with a niche where it's pretty good. It takes things from the FP world, its syntax from Prolog…
Fair point! It definitely is a mishmash of good ideas. I think the message passing / OO aspect stands out to me as most distinct from other languages, even if it's not as pervasive in the language as in Smalltalk.
Re: The seven programming ur-languages (2021)
#123I think reactive/synchronous languages [1] deserve a category of their own. They share little/no overlap with any of the others. My background in electrical engineering biases me to Verilog, VHDL, and LabVIEW as exemplars, but there are many others. The distinguishing characteristic of the category is that programs are effectively declarative functions of time and can be composed as such, much like electronic circuit…
Verilog/VHDL isn't so much a programming language as a hardware definition language and woe to anyone who conflates the two. Verilog/VHDL is it's own class of thing and sits outside of software languages.
They're languages for descriptions of reactive dataflow. That they happen to specialize in dataflow which is synthesizable as hardware doesn't change that they're programming languages.
(Yes, it's easy to accidentally write unsynthesizable code in them -- but similar issues hold true for many declarative languages.)
Re: The seven programming ur-languages (2021)
#124An 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…
There is no difference between expressions and statement in Ruby (a descendent of the Agol Family). Everything evaluates to a value so everything is an expression.
(to be fair, it took a lot of inspiration from Smalltalk and LISPs)
Re: The seven programming ur-languages (2021)
#125Years of bitter personal experience have taught me that FORTRAN is the real ur-language in the sense that a suitably determined programmer can write FORTRAN code in just about any language. I have certainly had to debug this code all over the place.
Does this make Perl a FORTRAN?
I have unFORTRANned thousands of lines of perl code in my time.
Re: The seven programming ur-languages (2021)
#126Earlier quoted context omitted.
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...
Re: The seven programming ur-languages (2021)
#127Earlier quoted context omitted.
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.
Re: The seven programming ur-languages (2021)
#128Earlier quoted context omitted.
Erlang is a nice and unique language, but I feel at its core it falls into the object-oriented/message-passing paradigm, very much in the vein of Smalltalk. Consider these paragraphs from Smalltalk's Wikipedia entry [1]: > A Smalltalk object can do exactly three things: > 1. Hold state (references to other objects). > 2. Receive a message from itself or another object. > 3. In the course of processing a message, send…
Joe Armstrong talked about that in the past, and I can sort of see it if I squint, but at the end of the day, there are a lot of things in Erlang that are not processes, like most of your basic data types, so I'd just say Erlang is good at borrowing, like a lot of practical real world languages are, and in doing so, came up with a niche where it's pretty good. It takes things from the FP world, its syntax from Prolog…
It's funny to me. OTP Processes have a ton of similarities to Agents, but from what I recall it sounds like those two things were developed almost entirely independently and it wasn't until way after the fact when people outside of Ericsson started using Erlang that people started noticing and commenting on that.
Re: The seven programming ur-languages (2021)
#129Where does TLA+ and PlusCal fit in? They do not match any of the listed families, do they?
TLA+ and PlusCal are specification languages, not programming languages. Spec languages have their own ur-languages: TLA+ is from the LTL dynasty, Alloy and Event-B are from Z, PRISM is CSP I think?
Respectfully (you having literally wrote the book!) I disagree that there's a strong difference between specification and programming languages -- and specifically I feel that the "gap" between verification and implementation can be filled by recognizing this.
To take TLA+ as an example -- I've certainly written (short!) programs in both TLA+ and PlusCal -- both imperative (typically an implementation of something that I'm modeling) and declarative (to solve logic problems in the same manner I would use Prolog).
And there's nothing privileged about TLC's capabilities and limitations -- one could equally imagine a TLA+ interpreter which disallows cross-state nondeterminism or use of temporal predicates but allows interaction with the environment via a special variable or predicates, without needing to augment the language, thus allowing "normal" programs to be written and executed. Or a TLA+ interpreter which permits full nondeterminism via a SMT backend, which can act as a richer version of Prolog.
Imagine writing correctness-critical code snippets in TLA+, verifying them, then compiling and linking them into an application written primarily in another language! I don't believe there is anything about TLA+-the-language which would need to change for such a tool to exist.
There are of course language elements specific to verification in TLA+ -- namely the temporal operators pose a challenge to "synthesizing" an executable program. But I don't think this makes TLA+ any less a programming language than the existence of, say, Haskell's type language makes Haskell a programming language.
Verilog sits in a similar space, where it was designed for verification, and is full of constructs usable only for verification, but also has a "synthesizable" subset which can be and is used expressly for implementation without involving verification of any sort. Although one can argue Verilog is a hardware description language rather than a programming language, I haven't seen anyone argue Verilog is a specification language rather than either of those.
Re: The seven programming ur-languages (2021)
#130Earlier quoted context omitted.
Probably because they aren't programming languages in the sense you won't produce a program = executable with it, but rather a proof.
And yet Agda, which is a proof language, was included (in the ML family). Looking at some TLA+ examples, I’d say, squinting a bit… somewhere around Prolog ? I’d love to hear someone chip in !
Yes, having used both TLA+ and Prolog extensively, they share many similarities (both having roots in first-order logic). In practice -- TLA+ code is often a bit more "imperative" owing to the fact that unbounded existential quantification isn't implemented in the TLC interpreter (whereas in Prolog, it is a core aspect of any interpreter).
And of course, TLA+ has a suite of temporal operators used exclusively for declaring contracts in service of its role for verifying specifications. Which (as @hwayne points out elsewhere) stem from mathematics -- Linear Temporal Logic specifically -- and not programming.