Maybe it's just me but the terminology used in "halting problem" didn't age well.
A lot of modern programs never terminate and thus to me "halting" means no longer able to compute, i.e it's hung/deadlocked.
A lot of modern programs never terminate and thus to me "halting" means no longer able to compute, i.e it's hung/deadlocked.
Computer Science historically being seen as a gateway to software development has done a large disservice to both fields.
A heck of a lot. Your professor clearly does not know much about astronomy.
The same can be said about computers and computer science. I don't think I fully agree with that, but it's interesting to think about.
For example if you have a whole bunch of Hydrogen the gravity its exerting on itself is negligible... Unless it's a lot of Hydrogen because eventually instead of being negligible the gravity adds up to where the Hydrogen atoms undergo nuclear fusion and that's how you get stars.
Similarly, Oceanography does have boats and a large building next to the sea, but although some of them are capable sailors, a lot of what they're interested in is theoretical and doesn't require you to even be able to smell the sea, let alone go out on it.
The reason we know anything about the composition of stars, the distance to galaxies, their relative speed etc. is because we use a telescope and study spectral lines.
Your comparison of oceanography and boats is a poor analogy. The a analog to telescopes would be sonar (and maybe seismographs?). The analog to boats would be spaceships/rockets. This makes my point.
- Computer science is about extending our understanding what can be done with computers (including what can be done efficiently). The computer scientist in this story exactly does that: he sees that the usage of the poster is a special case of a much more general pattern, and tries to understand this pattern, so that a solution that is developed for the general case can be applied to all of them, without having to develop a novel solution for every new case, which can save an insane amount of money.
- The kind of requirement analysis, and process orientation is rather untypical for computer scientists, but rather for what is called in German "Wirtschaftsinformatiker" (i.e. people who are business process analysts first and programmers second). These are people who are deep in love with such analysis paralysis, not the typical programmer or computer scientist who is often quite suspicious of such concepts.
In other words: if your toilet is clogged, you call a plumber, and not an expert in fluid dynamics.
This was in the early-ish days of OOP, when people were saying that, to design software, you were to "write a story" on how you want it to go. The nouns were objects, the modifiers, functions, and the verbs, program flow (or something like that. I never used it, as I thought it was silly).
That kind of thing was very attractive to upper managers, who dreamed of firing all the filthy engineers, and writing the code, themselves.
Sort of like now, with vibe-coding.
> plus ça change, plus c'est la même chose
I thought managers typically feel "above" writing code themselves. :-)
> I believe that Dijkstra's quote should be attributed to Mike Fellows, since it is fairly clear that Dijkstra heard it from him. Although the earliest appearance in print appears to be in our 1993 article, in my opinion Mike deserves sole attribution. He made up the part that is quoted so widely. I simply tacked on a bit at the end that nobody bothers to quote. Here it is again, correctly attributed for posterity.
Says this guy: ianparberry.com/research/cseducation/
But that's 1993, and MIT 6.001 Structure and Interpretation, 1986 has an extremely similar quote (though doesn't actually mention telescope + astronomy).
I'm writing this comment live, and I just found this! https://quoteinvestigator.com/2021/04/02/computer-science/
Variations of this has been said by many people, over a fairly long period of time. Fascinating :-).
La Palma - Gateway to the Universe (November 9, 2026)
The team journey to La Palma, where giant new telescopes and cutting-edge science are opening extraordinary new windows on our universe.
Roque de los Muchachos Observatory - https://en.wikipedia.org/wiki/Roque_de_los_Muchachos_Observa...
And an astronomer should absolutely have understanding of those, their intricacies, the optical equations involved, and how to operate them (usually with automated software, but astronomers are the ones writing that software).
Now an astrophysicist has less to do with telescopes, especially if your field is theoretical cosmology, although they still require familiarity with telescopes, practicalities, how observations are made etc. because that is the basis of their theory. So, a cosmologist vs. an astronomer might be a better analog for a computer scientist vs. a software engineer.
And I know that despite doing my own thesis in cosmology, my studies involved a lot of knowledge and teaching about telescopes, including at least one night of observations (it's pretty boring, things are very automated).
Doing a brick layer training doesn't make one a construction builder.
Disagree about what? You've certainly recognized that professional engineers have tried to usurp the term for their own devices, but that was already called out earlier. There was never a disagreement there. The word "engineer" predates societies of engineers by several hundred years or more so there is no claim that those societies came up with it, so there is nothing to disagree about there either.
> Doing a brick layer training doesn't make one a construction builder.
If someone goes to a bootcamp and then, following that, sits on the couch watching TV until their end of days then you're right that they would not be an engineer. But I have never seen anyone claim that they are something when they aren't doing it. Someone who worked at McDonalds when they were 14 years old and never again don't still call themselves a fast food worker when they are a 50 year old CEO, so I am not sure this take logically follows. It was implied that there is associated action.
In the case of software engineering, source code occupies roughly the same position as a schematic, with all the "production" completely automated and highly reproducible. Yes, the toolchain can make decisions about the emitted machine code, but we expect the output to be stable, in all consequential ways, for a given input and constant optimization settings. (Even in manufacturing, there is allowance for variation due to process, and untold money has been spent variously trying to exorcise or neutralize it. We have it easy.) Importantly, while no single person can know everything about the operation of modern toolchains, we know that there exist people with the education and the inclination to understand anything about them. Compilers and linkers and analyzers are not mysterious black boxes that defy investigation.
That is a reasonable take, but software engineers don't work at such a low level. They start the agent and their job is to make sure that the agent doesn't go off the rails. It is like driving a train. Hence why we call them engineers.
Then we have the whole team of engineers, architects, solution architects, that lay down the work for the coders, more often than not, some offshoring team.
Engineering is principally a design discipline, with a small fraction actually doing the hands-on building of their designs at least once they hit a certain scale of manufacture or get past prototyping. Technicians, skilled and unskilled labor, and machines do the vast majority of the building of those designs.
We can and do design at higher levels, too.
In fact, it's generally considered a harder problem to include the second boolean "does it halt successfully?" Does it stop at all is a hard enough question before asking if it stops with a success or a failure/crash. In practice this is often the easier problem to debug: once it stops we generally know if it was successful or failed. But that doesn't help to answer the questions like "will it always stop successfully?" or "will it 'forever' run successfully without ever stopping for a failure/crash/hang/deadlock?"
If you choose an answer to this question at random what is the chance you will be correct?
A) 25% B) 50% C) 0% D) 25%
Maybe I'm wrong but I believe this problem and the halting problem are versions of Gödel's incompleteness theorem. In the realm of probability theory and computing science respectably. Basically, I see it as the inability of a set of rules to reason (or be applied) to themselves.
The terminology of the "halting problem" is a very specific term of computer science, and it didn't age badly. This is like saying a reactor "going critical" hasn't aged well because non-physicists don't understand what "critical" means: it's not meant for them. Or about "prime numbers" because non-mathematicians don't know what "prime" means. Or what a "continuous function" is, etc, etc. You get the idea.
Modern programs are still composed of functions, and those functions are subject to the halting problem, in the sense that they get inputs and provide outputs. If they don't, they did not "compute" in precisely the sense you meant it. So let's say your videogame or whatever is waiting for input (the joystick or mouse) and you don't provide it, and because it's a turn-based game, nothing else happens. Has it "halted" in the sense we're discussing? Nope. It would be subject to halting if, once you provide input, the program cannot produce the intended result for your input (move a sprite, display "game over", start another round, play an animation, modify internal game state, etc).
In other words, Computer Science talks of "programs" but it's really any computation that takes an input and produces an output, and modern programs are made of them, so the problem applies to them.
My favourites are "normal" and "almost all". Almost All real numbers are Normal.