Slightly less flippant then... I *would* draw an analogy between someone being expected to crank-start a car, and someone expected to roll their own reference-counter / garbage collector.
Mechanics nowadays will begin on engines with a starter motor, the only difference compared to "mere drivers" is that they learn how the thing works so they can fix it if broken. Raw physical labour to turn over the engine is no longer an expected part of attaining that knowledge. Even as just a driver, there's a world of difference between what a stunt driver must learn and what a normal road user must learn. We certainly don't start people on a skid pan before progressing to teach the 3-point turn, knowledge of unusual circumstances is *always* taught after the first 99% of common driving use-cases. I consider advanced low-level work in C to be "stunt programming". Amazing cool and powerful, but too focused and dangerous for most programming needs. I'll just run off now to teach my kids how this abacus works. We'll be progressing to calculators next month :) On Thursday, 22 December 2011, Fabrizio Giudici wrote: > On Thu, 22 Dec 2011 10:07:32 +0100, Kevin Wright <[email protected]> > wrote: > > Total rubbish. We must start with a solid grounding in VLSI design and >> the >> core principles of modern processor architecture - paying particular >> attention to pipelining, branch prediction, virtual addressing and shared >> memory schemes in a multi-core design. Then progress onto raw machine >> code. >> >> Only after that should something as high-level as C be considered. >> >> Anything else is just a slippery slope, before you know it we'll have >> people expecting to be able to drive without having rebuilt so much as a >> single engine! >> >> </flippancy> >> > > Misused flippancy, I'd say. :-) I'm not expected to be the guy who builds > the car, but as the guy who drives it I should know what happens when I > drive it pushing to the limits, for instance using a lower gear than the > manual says (americans please find another appropriate example). In fact, > what's happening now with cars stuffed with technology is that people are > fine in 90% of cases, but get helpless in unusual conditions. If you answer > by pointing out the fucking manual, that's academia, because manuals won't > explain how to behave in very unusual (and maybe unexpected) conditions. > > In fact, I'm constantly seeing new generations of engineers that have been > only taught with fun high level languages being totally unable not only to > understand a trivial cause of a performance hit, but even lacking the > mental tools to investigate it (which is truly a disaster). Just because > they are unable to go under the hood for the required amount (which is not > of course understanding VLSI, but the basics such as machine instructions, > memory, caches, hits and misses, stacks, heap, compiler optimisations, > etc...). This is blatantly demonstrated by the more and more frequent blog > posts where people present a surprising result of a micro-benchmark, just > to be debunked in a few minutes when somebody points out that they just > understand nothing about how the JIT works... > > > -- Kevin Wright mail: [email protected] gtalk / msn : [email protected] quora: http://www.quora.com/Kevin-Wright google+: http://gplus.to/thecoda <[email protected]> twitter: @thecoda vibe / skype: kev.lee.wright steam: kev_lee_wright "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
