> You begin to suspect that a problem you are having is due to a hardware problem, where the processor is not conforming to its specification.
What is the probability of that happening?
The last time this happened in any significant way was the FDIV bug on the original Pentium. That was 1994. It was extremely rare in practice. That's a ridiculous question and completely irrelevant to 99%+ of software development.
I agree with sofal that reading all these "you should think and work exactly the way I do or else you're stupid" pieces I see get really fucking old.
Fucking around with disassemblers and assembly language instead of just running on AMD chips instead of Intel until the problem gets resolved is a massive waste of time.
I have worked with more than one microcontroller in the last few years that was not operating to spec. On top of that, in one case we couldn't even do a work around due to compiler error. I think the problem is a lot more prevalent than you think.
Was that some random product from some 3rd party outfit, or a flagship CPU from a major manufacturer that's installed on tens of millions of computers?
I think you're missing the point. He's not looking for hardware hackers. He's looking for people who know how a computer works. God job candidates should have no trouble answering that question regardless of whether they've actually ever seen a CPU bug.
"You begin to suspect that a problem you are having is due to a hardware problem, where the processor is not conforming to its specification. How would you track this down? How would you prepare a bug report for the chip manufacturer, and how would you work around the problem?"
Actually he's looking for people who know how to track down a processor bug, report it appropriately to a manufacturer, and work around it. Would it demonstrate complete incompetence and a failure of my CS education to answer: "I would learn how to track it down, learn how to submit a report, and then figure out how to work around it."?
It's one thing to expect job candidates for AdaCore to be experienced embedded-system developers, but it's another thing to expect university CS departments to throw their resources into that small corner of computer science so that he can hire new grads without having to bring them up on embedded systems work. I'm sure that CS departments with tons of resources can provide an embedded-systems track for undergraduates.
IMO the most pragmatic way to deal with the question as posed requires no knowledge of computer hardware.
If you want hardware knowledge, ask about pointer arithmetic and memory hierarchies, which is still mostly irrelevant to what most developers spend most of their time doing.
Before someone launches into a jihad about memcached and load balancing and super high-scale stuff, most people never have to do that.
Why can't they teach both - the high level reality of today, but also down to the metal (its how I did it, although the "high level" back then was miranda and pascal !).
It really depends on the context of your products. If you are working on embedded systems, your have to know when your compiler and hardware has problems. And not all software products works like web based software. Web based software has its problem domain like scaling, security, which is very different to other area of software systems,
Another case is for programmers working in Operating Systems. I remember like this url http://marc.info/?l=openbsd-misc&m=118296441702631 was mentioned a while ago when OpenBSD group found a lot of hardware bugs in Core 2 Duo.
The danger is the misplaced blind faith on the reliability of the system that we are using. And teaching only Java to students is a sin for computer science to build such a blind faith.
I am the last one to defend using Java as a teaching language.
The professor in the OP seems to be angry that there are people who spend their time doing things other than making toys for the Pentagon, and I say I don't give a hoot about his Ada silliness.
I was in fact a student who took his compiler class 12 years ago in NYU. A lot of students didn't like his classroom presentation because he would rather talk topics that was not covered inside textbooks (books are for reading at home for homeworks and project). And his class is a project based so in fact the only factor for the grade is the project. I had to write a code generator for GCC AST tree to x86 assembly in the subset of Ada that I chose. In fact, the only exciting part is to write this backend, which is beyond descriptions unless you did that.
He just belongs to a very old school in this discipline that holds the belief that you need to know what are you building from the lowest level components. You don't need to be an expert unless you work in that domain. But at least you are not clueless.
My recollection may be wrong. But I thought his Ph.D. was in fact in Chemistry. And he built and sold Cobol compilers before he worked on SETL language and Ada.
You are correct. Like I mentioned in this comment stream, I also took his class. This was 5 years ago. I have to say that I learned a ridiculous amount of low level systems stuff from his classes, and very much enjoyed his classroom presentation - I completely agreed with his view that a professor is there to present his expert opinion on the topic that may very well be different or tangential with the curriculum that gets covered by you doing the reading.
I was more attracted to project based courses when I was there in graduate school. Other professors that I liked very much, one is Ken Perlin and another is Denis Zorin. It was the real learning experience to build graphic stuffs from scratch.
I didn't take Dennis Shasha's class. But his heuristic learning and distributed computing are also project based.
Although he has an odd way of expressing his opinion (and mostly appears mistaken ) I think his teaching would be very interesting and I would definitely listen to it if I had a chance.
I wonder how much of this is headline grabbing (which is fair enough, it will help enrollments perhaps of the smarter students I think).
I don't think he is active teaching now. He holds emeritus now so he has no duty to teach unless he wants. He probably spends most his time working on AdaCore and its spinoff. I suspect his attitudes is due to his father's influence, who was a very famous organic chemistry researcher Michael J. S. Dewar.
In fact you can learn the similar experience just by doing a project yourself. I learned most stuffs in my life from projects. A course just gives a pressure to finish something before deadline. PG and YC are using the demo day to push applicants to finish something and with a potential payoff for finishing it. (Why? because of human nature tends to procrastinate!)
So maybe you just pick a non-trivial but not too difficult problem (Unless you aim for Turing Award and wants to be the first one to prove/disprove P = NP), find some friends/comrades who wants a challenge. Set up a deadline and payoff and go for it. You learn by doing it and the more you do it, the easier it will be.
So I guess that kinda shows that uni teaching should not be too vocational, other then for team/assignment/project work. Sounds reasonable. I pretty much had to learn C in that context, of projects etc, (we weren't initially taught it, we were taught other languages, and when it came time for C they threw the K&R book at us and said "off you go").
The Pentium has 70-something errata, each of which had to be found and worked around by somebody. Now consider the range of microprocessors and microcontrollers used in handheld devices, appliances, and other electronic equipment.
I personally have run into compiler issues for Lattice FPGAs where it was outputting incorrect binaries. And I couldn't run on another chip until the problem got resolved, because hardware was being developed in tandem with the firmware and we had already progressed beyond the point of component selection.
I understand that this is beyond your experience. These are obviously not the droids you are looking for.
What is the probability of that happening?
The last time this happened in any significant way was the FDIV bug on the original Pentium. That was 1994. It was extremely rare in practice. That's a ridiculous question and completely irrelevant to 99%+ of software development.
I agree with sofal that reading all these "you should think and work exactly the way I do or else you're stupid" pieces I see get really fucking old.
Fucking around with disassemblers and assembly language instead of just running on AMD chips instead of Intel until the problem gets resolved is a massive waste of time.