Why is not knowing things so fashionable these days? Especially in a community of people I'd think would be taking things apart just to learn how they work.
> Why should you know how an internal combustion engine works in order to drive a car?
Easy—so when you go to a mechanic with an exhaust blockage and he tries to sell you a new transmission, you know enough to tell him where to stick his transmission.
Yes, this actually happened to me. Thankfully, I knew enough about cars to know I needed another mechanic.
Obviously not every driver needs to be an automotive engineer or even a technician, but it's a little silly to throw up your hands and give up on knowing anything when the basics aren't that hard to understand.
> What's the point in knowing the effects of compiled and interpreted code on portability when so many other factors could make that basic knowledge irrelevant?
At first, I thought "the effects of compiled and interpreted code on portability" was an absurd thing to talk about. Compiled vs. interpreted is a pretty fuzzy distinction (Java is compiled, but only to bytecode that's then interpreted, but that interpreter just just-in-time compiles to native code anyway), and a compiled language doesn't inherently mean you're stuck on one CPU or OS until you rewrite your whole application—sometimes you just need to recompile it. But then I have the basic knowledge that "compiled" often means "compiled to and shipped as native binaries," which matters a lot if I'm trying to run Jim Bob's Digital Accountant on my SPARC workstation running LunarOS 2.7. If that software's only distributed as a Windows binary, I'm pretty much out of luck (unless I happen to have an emulator handy that interprets Windows binaries, but there's that fuzzy distinction again), but if it's a Java application there's a chance it'll just work, as long as Java's been ported to LunarOS on SPARC.
The moral of this story: you should know this stuff so when people talk about it it's not all nonsensical babbling and you don't have to just smile and nod. And, so you can reason about things and know when someone's feeding you a load of BS.
Or, so you don't go off and, say, write an article on how Apple is going to switch to ARM so they don't have to maintain two separate versions of their applications for phones and tablets vs. laptops because you don't know code doesn't have to be rewritten from scratch for each, but that you do need a different UI on a phone than you do on a laptop.
In general, know more things so the world makes more sense, and so you make more sense interacting with the world.
> In general, know more things so the world makes more sense, and so you make more sense interacting with the world.
No disagreement there. It's good to know things. But it's petty to label people as stupid because they don't know <random fact, skill or theory that you happen to know about> and that's what I was railing against.
> Why should you know how an internal combustion engine works in order to drive a car?
Easy—so when you go to a mechanic with an exhaust blockage and he tries to sell you a new transmission, you know enough to tell him where to stick his transmission.
Yes, this actually happened to me. Thankfully, I knew enough about cars to know I needed another mechanic.
Obviously not every driver needs to be an automotive engineer or even a technician, but it's a little silly to throw up your hands and give up on knowing anything when the basics aren't that hard to understand.
> What's the point in knowing the effects of compiled and interpreted code on portability when so many other factors could make that basic knowledge irrelevant?
At first, I thought "the effects of compiled and interpreted code on portability" was an absurd thing to talk about. Compiled vs. interpreted is a pretty fuzzy distinction (Java is compiled, but only to bytecode that's then interpreted, but that interpreter just just-in-time compiles to native code anyway), and a compiled language doesn't inherently mean you're stuck on one CPU or OS until you rewrite your whole application—sometimes you just need to recompile it. But then I have the basic knowledge that "compiled" often means "compiled to and shipped as native binaries," which matters a lot if I'm trying to run Jim Bob's Digital Accountant on my SPARC workstation running LunarOS 2.7. If that software's only distributed as a Windows binary, I'm pretty much out of luck (unless I happen to have an emulator handy that interprets Windows binaries, but there's that fuzzy distinction again), but if it's a Java application there's a chance it'll just work, as long as Java's been ported to LunarOS on SPARC.
The moral of this story: you should know this stuff so when people talk about it it's not all nonsensical babbling and you don't have to just smile and nod. And, so you can reason about things and know when someone's feeding you a load of BS.
Or, so you don't go off and, say, write an article on how Apple is going to switch to ARM so they don't have to maintain two separate versions of their applications for phones and tablets vs. laptops because you don't know code doesn't have to be rewritten from scratch for each, but that you do need a different UI on a phone than you do on a laptop.
In general, know more things so the world makes more sense, and so you make more sense interacting with the world.