31–40 of 107 posts
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!
That algorithms can be simplified by slightly lifting the constraints?
Since 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.
While later on, he does gripe about language quality, I think this is the most salient point of that letter. It touches upon IMO one of the most misunderstood things about Computer Science- it's a science curriculum, not a vocational school. The best (only?) way to build practical skills is doing practical things and learning through experience. Computer Science is more about rigorous reasoning about programs and their mathematical properties.
While learning about practical things like building web apps is fine and well, universities are not well equipped for this sort of vocational curriculum. They are primarily institutions optimized for performing scientific research.
Earlier 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…
I thought the moral was going to be that accommodating toiletless cars cost more than simply building all cars with toilets.
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!
I feel like the actual moral of the story should be "don't underestimate how trying to scrimp on a vital resource can result in horrible logistical complexities and a nightmare UX".
Earlier 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…
Either one. But certainly not "Java Programming".
Good thing, too -- I doubt many of the UT Austin students Dijkstra was teaching back in the day ended their careers still pounding out punch cards...
Is 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.
Haskell is not that hard to get into: there are hard parts but they are totally optional and avoidable.
Also for newcomer who want to get in fp but find Haskell intimidating, you can try Elm, it's tailored to cater to beginners.
Rolling stock needs maintenance, and if you keep units permanently paired you can easily run out of units.
In fact there is no easy solution given realistic business constraints. You can either put toilets in every car, which has a cost because it reduces available seating. In the best case you’ll lose money because of the lost seats. In the worst case overcrowding will make the toilets ineffective.
Or you can buy enough spare units to allow for maintenance, which has a larger up front cost, and continuing costs in terms of stabling, and possible issues with shunting yard size.
Working out the most efficient answer given real trains, real passenger loads, likely future passenger loads, and shunting yard constraints, is not a trivial problem.
Unlike Dijkstra, some of the managers in his audiences will have understood this. It’s no wonder they found his glib hand-waving annoying.
The actual lesson of the parable is the opposite of the one Dijkstra is making: the real world is hard, and if you think a solution fits neatly into a trivial software construct, you’re almost certainly wrong.
Earlier quoted context omitted.
I never did alpinism, I guess Everest would be a good place to start with...
it's not even in the Alps!
"Mountaineering is often called Alpinism, especially in European languages"