Moral: The engineer who conceived of the innovation was forgotten and not compensated for it, and the train owners made the bulk of the money. Sounds like software engineering to me!
The more things change, the more things stay the same.
A Parable by Dijkstra (1973)
11–20 of 107 posts
Re: A Parable by Dijkstra (1973)
#12I don't quite understand why 'true mathematicians' fail to get the point. Any ideas?
Because you get to the solution and you say, "But that's just the same thing..."
It's like the joke with boiling the pot of water and just dumping out the water; reducing it to the previous problem with a known solution ... or something like that...
Re: A Parable by Dijkstra (1973)
#13Is Haskell still a preferred introductory language to enter the Functional Paradigm with? Or do you think other alternatives do a better job at that than Haskell ? I'm learning Scheme with the SICP Book ATM, and am confused where to go next to get better at Functional thinking(and programming).
Re: A Parable by Dijkstra (1973)
#14I thought the moral was going to be that accommodating toiletless cars cost more than simply building all cars with toilets.
I feel like that's still the point irrespective of Dijkstra's apparent view on the parable. Creating exceptional cases is the best way to increase costs.
Re: A Parable by Dijkstra (1973)
#15Since we're talking about Dijkstra, thought I'd bring up the letter he wrote to the University of Texas when they replaced Haskell with Java in their introductory programming course: https://chrisdone.com/posts/dijkstra-haskell-java https://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Bud...
Great letter (2001). It predictably focuses on language quality and side-steps practicality-- the assumption being practicality isn't as important as learning a high-quality language in an introductory course.
Depends on what you think you're teaching. Are you teaching computer science, or are you teaching software engineering?
Hint: Of your graduates, probably 95% will work as software engineers, and only 5% will be computer scientists. But CS departments think they're computer science departments, even though they mostly are located in the college of engineering. (I accidentally typed "enginerring", which I thought was amusing...)
Re: A Parable by Dijkstra (1973)
#16Since we're talking about Dijkstra, thought I'd bring up the letter he wrote to the University of Texas when they replaced Haskell with Java in their introductory programming course: https://chrisdone.com/posts/dijkstra-haskell-java https://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Bud...
Great letter (2001). It predictably focuses on language quality and side-steps practicality-- the assumption being practicality isn't as important as learning a high-quality language in an introductory course.
In a sense, those two are not conflicting, but reinforcing - practicality in software "engineering" usually means lowest-common-denominator, cheapest-workforce technology. It's good to have exposure to more powerful tools and ways of thinking, and the industry isn't likely to give you one unless you actively come looking.
Re: A Parable by Dijkstra (1973)
#17Since we're talking about Dijkstra, thought I'd bring up the letter he wrote to the University of Texas when they replaced Haskell with Java in their introductory programming course: https://chrisdone.com/posts/dijkstra-haskell-java https://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Bud...
[deleted]
Re: A Parable by Dijkstra (1973)
#18When the shunting person persuaded everyone to imagine the two-car units as if they were symmetrical, the passengers still complained. Toilets can break, and when they did the doubly unlucky passenger would be forced to walk four car lengths to get to the nearest toilet.
Also, those helpful arrows would be guiding the passenger the wrong direction for two of those car lengths.
So we have comments that go out of sync with the running program, a spec that lies about reality, and an implementation that doesn't match the spec. Yep, that sounds like programmers to me.
Legit parable.
Edit: just realized the least lucky passenger would have to walk six car lengths. If the passenger is already at the wrong end of the "symmetrical" two-car unit with a broken toilet, the arrow will point them in the direction of the broken toilet. If the broken toilet is the last car, then they must walk back two car lengths to get where they started. Now if the next two-car unit is turned the wrong direction they must walk two more car lengths.
So add to this a spec that's difficult to reason about.
Again, legit programmer parable.
Re: A Parable by Dijkstra (1973)
#19Is Haskell still a preferred introductory language to enter the Functional Paradigm with? Or do you think other alternatives do a better job at that than Haskell ? I'm learning Scheme with the SICP Book ATM, and am confused where to go next to get better at Functional thinking(and programming).
Haskell. If programming languages were mountains, Haskell is Everest. Conquer it and other languages can be mastered in your sleep.
Go further.
Re: A Parable by Dijkstra (1973)
#20Earlier quoted context omitted.
Great letter (2001). It predictably focuses on language quality and side-steps practicality-- the assumption being practicality isn't as important as learning a high-quality language in an introductory course.
Depends on what you think you're teaching. Are you teaching computer science, or are you teaching software engineering? Hint: Of your graduates, probably 95% will work as software engineers, and only 5% will be computer scientists. But CS departments think they're computer science departments, even though they mostly are located in the college of engineering. (I accidentally typed "enginerring", which I thought was a…
> Depends on what you think you're teaching. Are you teaching computer science, or are you teaching software engineering?
> But CS departments think they're computer science departments, even though they mostly are located in the college of engineering.
I used to think this is true in the form you presented, but now I feel it's really a more relaxed form that's true - CS departments in universities think they're still in universities, not in glorified vocational schools. They try to teach you more than the immediate needs of your likely job, so that you understand the context of what you're working with, and are exposed to more powerful ways of thinking.
(I mean, 99% of the time, your typical JavaScript-slinger doesn't need to know what an "algorithm" is and what can be solved with one. These days, a popular language, StackOverflow and open-source libraries are enough to do acceptable levels of work. However, some extra theoretical knowledge will help tackle more complicated problems, solve them better, and will enable one to do something more challenging if they want to leave the web/CRUDsphere.)
Related: we now have "vocational schools" for programming too. They're called "bootcamps", for some reason.
Tangential: there's a feedback loop between workers, universities and employees in every industry. Progress of the "industry standard" must come from somewhere. If all the new people are being exposed to is Java(Script), the industry will forever keep being stuck on Java(Script). So I feel it's good that at least some people in some universities try to teach above the level required by the industry.