Live data from Hacker News

A Science of Concurrent Programs [pdf]

lamport.azurewebsites.net

21–30 of 34 posts

Re: A Science of Concurrent Programs [pdf]

#21
post #6
post #3

Earlier quoted context omitted.

People often mistake software engineering, or IT with computer science. Those are not science.

Is computer science even science? It feels like we should have called ourselves computationally-applied mathematicians.

I'm reminded of the first lecture in SICP[0] :)

[0] https://www.youtube.com/watch?v=2Op3QLzMgSY

Re: A Science of Concurrent Programs [pdf]

#22
post #7

Earlier quoted context omitted.

There's a line between the discovered stuff and the invented stuff. I always love to see it spelled out in different ways. I tell my students that you can understand And rediscover the science part by understanding basic principles, by applying mathematical logic. While the engineering part you need to learn , as the engineering decisions are full of conventions and constraints of the time of invention and the people…

Is there? When it comes to math and abstract concepts such as these I can see no such line. To me it seems e.g. the real numbers were invented about as much as they were discovered. Same goes for the semaphore. (Of course the exact syntax and semantics of let’s say semaphores in POSIX belong to a different category. But I’m not sure I’d want to call it an “invention”.)

Well, the examples so do fall more under the abstractly provable side of things when it comes to their behavior.

But take the Sieve algorithm that was posted yesterday[0], or Powersort[1] (Timsort with its bugs fixed). To some degree those are more engineering discoveries about which algorithm behaves best with real-world data. Although Powersort actually involves a lot of formal maths to prove it does not have degenerate edge-cases, so maybe I should have stuck with Timsort.

[0] https://news.ycombinator.com/item?id=38850202

[1] https://www.wild-inter.net/publications/munro-wild-2018

Re: A Science of Concurrent Programs [pdf]

#23
post #6
post #3

Earlier quoted context omitted.

People often mistake software engineering, or IT with computer science. Those are not science.

Is computer science even science? It feels like we should have called ourselves computationally-applied mathematicians.

Funny you ask this question, since yesterday there was a HN post about Herbert Simon.

Here is Allen Newell, Alan Perlis, and Herbert Simon's response (1967) to your question about whether computer science is even science. For context, the three of them are Turing Award winners and early pioneers of computer science. https://www.cs.cmu.edu/~choset/whatiscs.html

Professors of computer science are often asked: "Is there such a thing as computer science, and if there is, what is it?" The questions have a simple answer:

Wherever there are phenomena, there can be a science to describe and explain those phenomena. Thus, the simplest (and correct) answer to "What is botany?" is, "Botany is the study of plants." And zoology is the study of animals, astronomy the study of stars, and so on. Phenomena breed sciences.

There are computers. Ergo, computer science is the study of computers. The phenomena surrounding computers are varied, complex, rich. It remains only to answer the objections posed by many skeptics.

...

Re: A Science of Concurrent Programs [pdf]

#24
post #3
post #2

This is Science. Computer Science. From one of the greatest alive. "This is a preliminary version of a book. If you have any comments to make or questions to ask about it, please contact me by email. But when you do, include the version date. I expect there are many minor errors in this version. (I hope there are no major ones.) Anyone who is the first to report any error will be thanked in the book. If you find an e…

People often mistake software engineering, or IT with computer science. Those are not science.

Computer science is not a science; it's a form of math (which is not science).

Re: A Science of Concurrent Programs [pdf]

#25
post #7

Earlier quoted context omitted.

There's a line between the discovered stuff and the invented stuff. I always love to see it spelled out in different ways. I tell my students that you can understand And rediscover the science part by understanding basic principles, by applying mathematical logic. While the engineering part you need to learn , as the engineering decisions are full of conventions and constraints of the time of invention and the people…

Is there? When it comes to math and abstract concepts such as these I can see no such line. To me it seems e.g. the real numbers were invented about as much as they were discovered. Same goes for the semaphore. (Of course the exact syntax and semantics of let’s say semaphores in POSIX belong to a different category. But I’m not sure I’d want to call it an “invention”.)

This is a much-debated question in the philosophy of mathematics.

One of the stronger arguments that the real numbers were discovered, rather than invented, is their “unreasonable effectiveness” in aiding our exploration and understanding of the physical world.

The same can’t be said for equally abstract but clearly invented concepts such as the rules of chess.

Re: A Science of Concurrent Programs [pdf]

#26
post #14

It's appropriate that this is appearing at the death of Niklaus_Wirth. He really was the first to get serious about formalizing concurrency. P and V, and all that. This feels very retro. I used to work on this sort of thing, but that was back in the early 1980s. This reads like something from back then, when people were first figuring out how to think about concurrency.[1] That's how people thought about this back th…

One person I rarely hear mentioned did similar work: Per Brinch Hansen. He built OS’s with Concurrent Pascal and Edison. His papers are below for those curious:

http://brinch-hansen.net/papers/

Re: A Science of Concurrent Programs [pdf]

#27
post #3
post #2

This is Science. Computer Science. From one of the greatest alive. "This is a preliminary version of a book. If you have any comments to make or questions to ask about it, please contact me by email. But when you do, include the version date. I expect there are many minor errors in this version. (I hope there are no major ones.) Anyone who is the first to report any error will be thanked in the book. If you find an e…

People often mistake software engineering, or IT with computer science. Those are not science.

The main exception might be high-assurance systems. They require clear description of requirements, formal specification of design + goals, proof one embodies the other, test cases that show it empirically, replication by third parties, and hostile review (pentesting) of all of that.

Praxis’ method was a practical application of these concepts used in industry:

https://www.anthonyhall.org/Correctness_by_Construction.pdf

If the design is the hypothesis, would you count that as science?

Re: A Science of Concurrent Programs [pdf]

#28

Earlier quoted context omitted.

Is there? When it comes to math and abstract concepts such as these I can see no such line. To me it seems e.g. the real numbers were invented about as much as they were discovered. Same goes for the semaphore. (Of course the exact syntax and semantics of let’s say semaphores in POSIX belong to a different category. But I’m not sure I’d want to call it an “invention”.)

This is a much-debated question in the philosophy of mathematics. One of the stronger arguments that the real numbers were discovered, rather than invented, is their “unreasonable effectiveness” in aiding our exploration and understanding of the physical world. The same can’t be said for equally abstract but clearly invented concepts such as the rules of chess.

I think it’s a mixture of both, but using its ability to explore the physical world as the benchmark seems myopic because math can be used to describe universes other than our own. Our universe just happens to be the one we focus on because that part of mathematics is particularly interesting, but if anything it means the structures we put in place to manage that aspect are invented not discovered.

Re: A Science of Concurrent Programs [pdf]

#29
post #14

It's appropriate that this is appearing at the death of Niklaus_Wirth. He really was the first to get serious about formalizing concurrency. P and V, and all that. This feels very retro. I used to work on this sort of thing, but that was back in the early 1980s. This reads like something from back then, when people were first figuring out how to think about concurrency.[1] That's how people thought about this back th…

> He really was the first to get serious about formalizing concurrency. P and V, and all that. The computer science of concurrency began with Dijkstra, not Wirth. And it was Dijkstra who introduced the P and V semaphore operations [1]. [1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD01xx/E...

Oops, right.
Post reply on HN