Computer Science vs. Computing Science (1999) | Hacker News Reader

Computer Science vs. Computing Science (1999)

cs.utexas.edu

42 pointstosh44 comments

> The latter, not surprisingly, turned programming from an intuitive activity into a formal one in which the program is derived by symbolic manipulation from its functional specification and the chosen form of correctness proof.

> The idea of a formal design discipline is often rejected on account of vague cultural/philosophical condemnations such as ”stifling creativity”; this is more pronounced in the Anglo-Saxon world where a romantic vision of ”the humanities” in fact idealizes technical incompetence. Another aspect of that same trait is the cult of iterative design.

> Industry suffers from the managerial dogma that for the sake of stability and continuity, the company should be independent of the competence of individual employees. Hence industry rejects any methodological proposal that can be viewed as making intellectual demands on its work force. Since in the US the influence of industry is more pervasive than elsewhere, the above dogma hurts American computing science most. The moral of this sad part of the story is that as long as computing science is not allowed to save the computer industry, we had better see to it that the computer industry does not kill computing science.

Typical Dijkstra. You do it his way or you're not only wrong, but also stupid. But "his way" is to have a correct formal specification that you can operate on using mathematical logic. We have learned, from bitter experience, that that's asking quite a lot, and even when you can get it, it's a recipe for building systems that are obsolete on the day they are completed. But Dijkstra is content to pronounce the system produced to be "correct". That approach may cut it in academia, but in the real world it has been tried and found to be sorely wanting.

Then you get to aspects that really are a combination of art and science. Would Dijkstra's approach have produced, say, the iPhone user interface? I strongly doubt it.

I used to think like you, until one day i read D.L.Parnas' paper "A Rational Design Process: How and Why to Fake it" (http://users.ece.utexas.edu/~perry/education/SE-Intro/fakeit...). I then could understand Dijkstra's pov. He was advocating for rigor in Programming and that the very effort reqd. to hew to his ideal would result in better Software. That is the gist of his argument.

Unfortunately, Humans are heuristic, pattern-matching, infinitely adaptable organisms and hence absolute rigor is very difficult. The fact that programming languages are so evolved that one can easily code-up any incoherent stream of consciousness and still have the system-as-a-whole work in some fashion is what has contributed to both the boom (anybody can contribute) and mess (quality sorely lacking) in the industry.

PS: Never ever dismiss pioneers like Dijkstra, Hoare, Wirth and others offhand. They built up the Fundamental Theory, Science and Tools which directly led to today's Computer Industry and its effect on Society.

> In the early days, John von Neumann has looked at the problem of constructing a reliable computer out of unreliable components but the study stopped as von Neumann died and transistors replaced the unreliable valves. We are now faced with this problem on a global scale and it is not a management problem but a scientific challenge.

Wow, John von Neumann is my man! I need to get more exposure to his intellectual legacy. I couldn't articulate why my POC of parallel computation surviving asynchronous loss of threads [0] would be of any interest (I don't see any practical value in it myself and treat it as a piece of art). I think the man would find more than two words to respond to it.

[0] https://github.com/OlegMazurov/Robusta

You might be interested in David Ackley's work on robust-first, best-effort computing. Here's a relevant paper: https://www.usenix.org/legacy/events/hotos11/tech/final_file...

He's working on a pertinent hardware project called the T2 Tile and is documenting it all on YouTube: https://www.youtube.com/channel/UC1M91QuLZfCzHjBMEKvIc-A

Thank you so much! From the first look it's right on the money.

> Our strategy is to entice smart people to play with programming robust, indefinitely scalable computations by lowering barriers to entry, and as idioms, motifs, and best practices emerge from such explorations, we believe opportunities for wise optimization will arise.

I believe I have unknowingly contributed to that strategy.

Thank you so much. Love hackernews sometimes. I saw this man’s videos many years ago and the various ideas always kinda stuck. While wanting to spin up a new project I attempted to find him and his videos again, but it was very hard to find such a niche topic. I’m am absolutely ecstatic I have this resource for my week off coming up.

> LISP had its serious shortcomings: what became known as “shallow binding” (and created a hacker’s paradise) was an ordinary design mistake; also its promotion of the idea that a programming language should be able to formulate its own interpreter (which then could be used as the language’s definition) has caused a lot of confusion because the incestuous idea of self-definition was fundamentally flawed.

Would any Lisp expert care to comment on this?

Modern terminology is "dynamic" vs "lexical" scope[1][2]. Lexical scope makes it very easy to reason about closures[3]. Dynamic scoping is slightly easier for language authors to implement. Terrible languages like ColdFusion[4] and MUMPS[5] use dynamic scoping, although lexical scoping constructs were bolted on later. LISP has both[6], at least it does now. Dynamic scope makes it possible to do certain kinds of code re-use not possible with lexical scope[7]; these are often called "macros" but what exactly is meant by this varies from language to language; in general, only an "unhygienic" macro requires dynamic scope to implement, while hygienic macros generally require a pre-processor but no access to dynamic scope[8]. Because dynamic scope leads to all kinds of unexpected side-effects, makes closures difficult to implement, and is only really useful for writing the worst and least useful kinds of macros, the programming language world has come down hard in favor of lexical scoping, which is now ubiquitous; almost every modern language you've heard of exclusively uses lexical scope.

[1]: https://en.wikipedia.org/wiki/Scope_(computer_science)

[2]: https://stackoverflow.com/questions/1047454/what-is-lexical-...

[3]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Clos...

[4]: https://en.wikipedia.org/wiki/ColdFusion_Markup_Language

[5]: [https://en.wikipedia.org/wiki/MUMPS

[6]: https://www.emacswiki.org/emacs/DynamicBindingVsLexicalBindi...

[7]: https://en.wikipedia.org/wiki/Scope_(computer_science)#Macro...

[8]: https://en.wikipedia.org/wiki/Hygienic_macro

So, if I understand all this correctly, Lisp originally had dynamic scope only (which was Dijkstra's criticism), and later came to rely mostly on lexical scoping?

And, would you also comment on Dijkstra's "self-definition" comment?

The self-definition comment is a reference to the common LISP exercise of writing a "meta-circular evaluator"[1] - that is, writing a LISP interpreter in LISP. This is famously done[3] in "Structure and Interpretation of Computer Programs", which is a very popular textbook and MIT course which uses LISP as a teaching language[2]. This can be found for example, in lecture 7 of the SICP lecture series on Youtube[4].

Dijkstra's comment on this is quite acerbic, isn't it? Here is the full quote for easy reference:

> [LISP's] promotion of the idea that a programming language should be able to formulate its own interpreter (which then could be used as the language’s definition) has caused a lot of confusion because the incestuous idea of self-definition was fundamentally flawed.

I agree to the extent that the exercise of writing a LISP interpreter in LISP is indeed often a very confusing exercise for beginner, partly because writing any interpreter (or compiler) is fairly arcane for a beginner, and partly because keeping track of which parts are in implementation and which parts are in the target language can be made more difficult; also because it's easy to "cheat" and rely on outside language in inappropriate ways. I would recommend using a language you already know well and implementing a moderately simple language as a first exercise to a student. But on the whole the exercise of writing an interpreter in its own language - or alternatively writing a self-hosting compiler[5] - is rewarding and does teach you a great deal about how programs work.

I also can't agree the so-called "incestuous idea of self-definition" is "fundamentally flawed:" it is in fact fairly interesting and related to important meta-mathematical concepts like Godel numbering[6], reductions[7], and the Church-Turing thesis[8]. Writing a meta-circular evaluator seems like a reasonably concrete way to start building intuition towards these important ideas. Perhaps Dijkstra has in mind such problems as Curry's Paradox[9] or Russel's Paradox[10], both of which are paradoxes arising from self-reference? In my view a meta-circular evaluator is much closer in spirit to Godel numbering (which is valid and useful) than these paradoxes.

[1]: https://en.wikipedia.org/wiki/Meta-circular_evaluator

[2]: https://en.wikipedia.org/wiki/Structure_and_Interpretation_o...

[3]: http://www.sicpdistilled.com/section/4.1/

[4]: https://www.youtube.com/watch?v=0m6hoOelZH8

[5]: https://en.wikipedia.org/wiki/Self-hosting_(compilers)

[6]: https://en.wikipedia.org/wiki/G%C3%B6del_numbering

[7]: https://en.wikipedia.org/wiki/Reduction_(complexity)

[8]: https://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis

[9]: https://en.wikipedia.org/wiki/Curry%27s_paradox

[10]: https://en.wikipedia.org/wiki/Russell%27s_paradox

Interesting as expected of Dijkstra. I found this part funny:

> "That name ['programming languages'] was unfortunate because very soon the analogy with natural languages became more misleading than illuminating. It strengthened the school of thought that tried to view programming primarily as a communication problem, it invited the psychologists in, who had nothing to contribute, and it seriously delayed the recognition of the benefits of viewing programs as formulae to be derived. It was the time of Edmund C. Berkeley’s “Giant Brains or Machines that Think”, it was the time of rampant anthropomorphism that would lead to the false hope of solving the programming problem by the verbosity of COBOL and would seduce Grace M. Hopper to write a paper titled “The Education of a Computer”. Regrettably and amazingly, the habit lingers on: it is quite easy to infuriate computing scientists by pointing out that anthropomorphizing inanimate objects is in science a symptom of professional immaturity."

This school of thought that Dijkstra decried is the one that eventually triumphed in our industry, and nowadays it is widely held that a general-purpose programming language "succeeds" primarily when it enables communication with/between programmers. Armies of consultants and bloggers and Uncle Bobs make a living out of this idea. The whole "languages are first for programmers to read, and second for computers to run" shtick.

I'm not sure which is my own position, but we do know which was Dijkstra's and that he would not be happy today.

Computers don't run languages though, they run code. And readability of the language for humans is a communication problem - there is no way around it. That's a different topic from using a language to communicate with the computer itself.

Are you debating this with me or with Dijkstra?

I didn't make up that aphorism myself. There is very much a design contradiction between "this language should make things easier for the computer (or compiler, or whatnot)" and "this language should be easy to read for humans, even if this makes it worse for the computer". This is widely acknowledged and not the point of contention; whether the former or the latter is more important is.

I was just commenting on your remark. I think Dijkstra was picking on the "language to communicate with computers" topic, not on language as a tool of communication between people.

I mean, readability of any language for humans is an issue, but I'm not sure what readability for computers means exactly in this context. How easy it is to make an optimizing compiler? Modern languages use zero cost abstractions approach to improve readability for humans, while targeting well optimized code.

Very possibly I misunderstand both you and Dijkstra. What else could he be referring to when he claims "[the name of 'programming languages'] invited the psychologists in, who had nothing to contribute, and it seriously delayed the recognition of the benefits of viewing programs as formulae to be derived."?

The fact he specifically picks on COBOL -- exclusively formulated to communicate well to humans, not computers -- seems to favor my interpretation.

I could be mistaken, of course. He does speak of "anthropomorphizing inanimate objects", which does favor your interpretation. Or maybe it's mixed?

May be I misunderstood him, but his focus on "Giant Brains or Machines that Think" and “The Education of a Computer” sounds like the topic of languages as a tool of communication with computers. I didn't understand the focus as being better communication between programmers.

Hmm, I think you're right!

> This school of thought that Dijkstra decried is the one that eventually triumphed in our industry ... The whole "languages are first for programmers to read, and second for computers to run" shtick.

If that was the case, I think we'd just end up using literate programming systems, which get both the "human-focused" and "computer" parts right.

BTW, running executable code is only one small part of what computers do with programming languages; what about things like performing static analysis to detect errors within the code, and providing language-specific support for IDE's and/or CASE systems? These things just seem to be a lot more important in programming language design than either the "communicate to humans" or the "run executable code" part.

I agree with you on all counts. I suppose I was thinking more of the Uncle Bob's and similar consultants' school of thought. If I dig deeper, it's not true that even this small subset has triumphed in the industry, either -- I know plenty of places where they don't even write tests. A few years ago, a software department in a major US-based oil company "discovered" unit testing and introduced it in a workshop as a big deal (note: they weren't practicing it, just talking about it, in its most bare-bones "hey, look this thing I found!" sort of way). In this context, literate programming is a pipe dream.

I suppose I should amend my statement to: "this view has triumphed in the blogs, articles and papers that some programmers like to read, and self-styled gurus like to write, if not actually practice" :)

It's incongruous that Dijkstra, in a paragraph decrying anthropomorphism, anthropomorphizes anthropomorphism (via saying that it seduced Hopper).

I saw that and suspected it was intended as humor on his part. That or he actually missed it when writing that letter.

Computers cannot program themselves, so makes sense to optimize computer languages for those who actually do the programming.

Dijkstra was very much interested in keeping programs cognitively manageable. I can’t imagine he’d object to a program being readable. He’d see it as mathematical elegance.

That said, for readers untrained in the predicate calculus, his work can be impenetrable. Fortunately anyone smart enough to program is smart enough to learn the predicate calculus. I use it regularly in real work. I don’t bother constructing fully formally correct programs, but I use invariants to write all but the most trivial loops.

Yes, true. But my guess is that what Dijkstra considered elegant and manageable would be very different to what Uncle Bob would.

I'd much rather go with Dijkstra than with Uncle Bob, FWIW

Computing Science is a lot better name. I prefer to use that term to "Computer Science".

I think Oxford still calls it Computation, which makes the most sense to me - it's the computation that we're interested in, and the computer is incidental.

Yeah, Computation Science is a good term too.

In Europe it's usually called Informatics, even in some Universities in the UK i believe, but it's totally absent from US literature it seems.

On the one hand yes, but I think Computer science (as a superset) is the better name due to the added focus on learning how computers "actually" work.

The focus should be on computing, but understanding the machine is very important

I agree with your observations, but reached the opposite conclusion and prefer Computing Science as a name. I take this as evidence that it’s not really important what we call it so long as we’re clear on what’s being studied.

We are doing more with software now than ever before so I think we need to move away from the word 'compute'

>would seduce Grace M. Hopper to write a paper titled “The Education of a Computer”.

I'm one of the least likely people to start screaming sexism at the drop of a hat but does this turn of phrase seem a bit, well, sexist?

On the nomenclature topic, it's interesting to note that Georgia Tech and many others have a School of Computing so it's not that unusual of a term.

I don't see it. What part seems sexist to you? The sentence is relevant because Grace Hopper's work was the precursor to COBOL, and COBOL is the embodiment of what Dijkstra was complaining about.

It's a bit odd to use the word "seduce" there.

Fair enough. It doesn't seem odd to me (one is seduced by dangerous but superficially appealing ideas, and this has little to do with one's sex), and more importantly, look at the whole sentence:

> "It was the time of Edmund C. Berkeley’s “Giant Brains or Machines that Think”, it was the time of rampant anthropomorphism that would lead to the false hope of solving the programming problem by the verbosity of COBOL and would seduce Grace M. Hopper to write a paper titled “The Education of a Computer”. Regrettably and amazingly, the habit lingers on: it is quite easy to infuriate computing scientists by pointing out that anthropomorphizing inanimate objects is in science a symptom of professional immaturity."

Like another comment here points out, this use of "seduce" is akin to "being seduced by the Dark Side of the Force". Anakin Skywalker was a man!

Also, this was Dijkstra's (slightly vitriolic) way of speaking. If you've read other [0] stuff [1] by him [2], you'll instantly recognize his style. And he isn't singling Grace out either; in any case, he seems to refer to her as another computer scientist, sharing the "professional immaturity" with Edmund Berkeley, a man.

[0] "Go To Statement Considered Harmful" http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T...

[1] "On the cruelty of really teaching computing science" https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...

[2] "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."

"FORTRAN, 'the infantile disorder', by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use."

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

https://en.wikiquote.org/wiki/Edsger_W._Dijkstra

Good points - I don't think this is a case of egregious sexism or anything.

But I think greed can seduce a person, I think power can seduce a person, I think fame can seduce a person.

I've never heard of "false hope" or "rampant anthropomorphism" as seductive, though.

Do you think it was odd that in Star Wars, Obi Wan Kenobi said, "Vader was seduced by the dark side of the Force"? Is this any different?

No - being seduced by power makes sense. Being "seduced to write a book" is odd.

His point is that the term "computer language" lured people into anthropomorphizing the process of creating software. In his mind, writing a book called "The Education of a Computer" is a result of falling into that trap.

It isn't the writing of the book he thinks she was lured into. It was the error in thinking that (he believed) the book contained.

(Note: I've included a lot of stuff like "he believed" and "his point" to emphasize that I don't really buy his thesis. I'm not in his corner when it comes to the idea he's presenting, but I don't see anything wrong with the words he used to present it.)

By your standards, in 2019. That says nothing about whether it was odd when Dijkstra wrote it. You'd have to compare it to what he and people like him wrote in the past.

It is perfectly reasonable to use the term "seduce" when one definition is "entice (someone) to do or believe something inadvisable or foolhardy".

Just because popular language may only use one meaning of seduce does not mean that a writer with a strong vocabulary may not use it with a valid but less common meaning.

Reply on news.ycombinator.com