Live data from Hacker News

On the Design of Programming Languages (1974) [pdf]

web.cs.ucdavis.edu

21–30 of 48 posts

Re: On the Design of Programming Languages (1974) [pdf]

#21
post #2

I think the legend goes Wirth created the Pascal language to be the most easily compilable. To show my age, I recall a class used Modula-2 when I was in college, also from Wirth, very Pascal-like.

I seem to remember (but I can't find the source) that Wirth initially had three aims in designing Pascal:

1. To use it in teaching a structure programming course to new students. As in the late 60's all student programming was batch mode (submit your program to an operator to run, and pick up the printout the following day), this meant the compiler had to be single-pass and give good error messages.

2. To use it in teaching a data structures course involving new data structures worked out by Wirth and Hoare.

3. To use it in teaching a compilers course. This meant the compiler code had to be clean and understandable. Being single-pass helped in this.

Re: On the Design of Programming Languages (1974) [pdf]

#22

Who are Wirths, Dijkstras, Hoares, McCarthies and Keys of today? I mean - who represents current generation of such thinkers? Genuinely asking. Most stuff I see here and in other places is about blogposts, videos and rants made by contemporary "dev influencers" and bloggers (some of them very skilled and capable of course, very often more than I am), but I would like to be in touch with something more thoughtful and…

Contemporary PL designers who have inspired my programming language design journey the most are people like Chris Granger (Eve), Jamie Brandon (Eve/Imp/others), Bret Victor (Dynamicland), Chris Lattner (Swift / Mojo), Simon Peyton Jones (GHC/Verse), Rich Hickey (Clojure), and Jonathan Edwards (Subtext). My favorite researcher is Amy J. Ko for her unique perspective on the nature of languages. Check out her language "…

Thanks for pointers

Re: On the Design of Programming Languages (1974) [pdf]

#23

Who are Wirths, Dijkstras, Hoares, McCarthies and Keys of today? I mean - who represents current generation of such thinkers? Genuinely asking. Most stuff I see here and in other places is about blogposts, videos and rants made by contemporary "dev influencers" and bloggers (some of them very skilled and capable of course, very often more than I am), but I would like to be in touch with something more thoughtful and…

very hot and edgy take: theoretical CS is vastly overrated and useless. as someone who actively studied the field, worked on contemporary CPU archs and still doing some casual PL research - asides from VERY FEW instances from theoretical CS about graphs/algos there is little to zero impact on our practical developments in the overall field since 80s. all modern day Dijkstras produce slop research about waving dynamic…

[dead]

Re: On the Design of Programming Languages (1974) [pdf]

#25

Who are Wirths, Dijkstras, Hoares, McCarthies and Keys of today? I mean - who represents current generation of such thinkers? Genuinely asking. Most stuff I see here and in other places is about blogposts, videos and rants made by contemporary "dev influencers" and bloggers (some of them very skilled and capable of course, very often more than I am), but I would like to be in touch with something more thoughtful and…

very hot and edgy take: theoretical CS is vastly overrated and useless. as someone who actively studied the field, worked on contemporary CPU archs and still doing some casual PL research - asides from VERY FEW instances from theoretical CS about graphs/algos there is little to zero impact on our practical developments in the overall field since 80s. all modern day Dijkstras produce slop research about waving dynamic…

> theoretical CS is vastly overrated and useless

> as someone who actively studied the field,

Does not compute.

Your comment is mere empty verbiage with no information.

Re: On the Design of Programming Languages (1974) [pdf]

#26
post #16

It's also worth noting that statements like for (i = 1; i are just as bad since `break' (and `continue' and early `return') are a just gotos in disguise.

They are just gotos, but does that mean that they are bad (along with their friend try/catch, who is also a goto?), or does that mean that gotos can be useful when used with restraint?

Gotos get a bad rep because they become spaghetti when misused. But there are lots of cases where using gotos (or break/continue/early return/catch) makes your code cleaner and simpler.

Part of a programmer's job is to reason about code. By creating black and white rules like "avoid gotos", we attempt to outsource the thinking required of us out to some religious statement. We shouldn't do that.

Gotos can be useful and can lead to good code. They can also be dangerous and lead to bad code. But no "rule of thumb" or "programming principle" will save you from bad code.

Re: On the Design of Programming Languages (1974) [pdf]

#27
post #16

It's also worth noting that statements like for (i = 1; i are just as bad since `break' (and `continue' and early `return') are a just gotos in disguise.

Yes, break, continue, and return are all "just" gotos in disguise. But they restrict the power of the goto enough to not cause the problems that goto causes while providing a good deal of semantic power to users. Namely, all of these are essentially variations on early return (you can also throw in the logical && and || operators here, albeit they are slightly different in having two exit points rather than one--they're a fusion of if and break, essentially). And it sort of turns that there are a lot of cases where "return when any of these conditions, tested in a particular order, holds" turns out to be the most natural way to express an algorithm, and these goto-like constructs are the most natural way to write them.

(FWIW, this is essentially the argument that Knuth makes in his defense of goto paper)

Re: On the Design of Programming Languages (1974) [pdf]

#28
post #16

It's also worth noting that statements like for (i = 1; i are just as bad since `break' (and `continue' and early `return') are a just gotos in disguise.

Yes, break, continue, and return are all "just" gotos in disguise. But they restrict the power of the goto enough to not cause the problems that goto causes while providing a good deal of semantic power to users. Namely, all of these are essentially variations on early return (you can also throw in the logical && and || operators here, albeit they are slightly different in having two exit points rather than one--they…

The argument in the article was that the for loop is (potentially) "lying" and that is still true in my example. Niklaus Wirth's Modula-2 had a LOOP statement in which an EXIT statement could occur anywhere. That statement was at least not misleading. In Wirth's last revision of his last programming language Oberon the loop statement is removed and return is no longer a statement but a clause at the end of a function procedure. This makes Oberon a purely structured language.

https://miasap.se/obnc/oberon-report.html

Re: On the Design of Programming Languages (1974) [pdf]

#29

Who are Wirths, Dijkstras, Hoares, McCarthies and Keys of today? I mean - who represents current generation of such thinkers? Genuinely asking. Most stuff I see here and in other places is about blogposts, videos and rants made by contemporary "dev influencers" and bloggers (some of them very skilled and capable of course, very often more than I am), but I would like to be in touch with something more thoughtful and…

I can't claim to be equal to the greats, but I do run a Discord server where I think and talk a lot about both the philosophy and practice of language design while building tools that I hope will change the state of the art: https://discord.gg/NfMNyYN6cX

Re: On the Design of Programming Languages (1974) [pdf]

#30
post #17

Earlier quoted context omitted.

Inheritance has its uses, but is easily overused. In a sense, it’s like global variables. About every complex program [1] has a few of them, so languages have to support them, but you shouldn’t have too many of them, and people tend to say “don’t use globals”. [1] some languages such as classical Java made it technically impossible to create them, but you can effectively create one with class Foo { public static int…

> Inheritance has its uses, but is easily overused. This I can agree with, but it is far from being "worst pattern". Everything can be like salt.

Yes, but inheritance used to be like salt. That’s why it, like “goto” and global variables, got so much attention.
Post reply on HN