Jerry Stuckle wrote:
On 10/18/2013 11:00 PM, Miles Fidelman wrote:Jerry Stuckle wrote:On 10/18/2013 6:11 PM, Miles Fidelman wrote:Jerry Stuckle wrote:On 10/18/2013 11:48 AM, Miles Fidelman wrote:Jerry Stuckle wrote: In the REAL world, program behavior is very much driven by the properties of underlying hardware. And... when actually packaging code for compilation and/or installation - you need to know a lot about what tests to run, and what compile/linkswitches to set based on the characteristics of the build and run-timeenvironments.Only if you're distributing source code. Look at the number of programs out there which DON'T have source code available. Outside of the Linux environment, there is very little source code available (other than scripting languages, of course). And even in Debian, most of the packages you get are binaries; sure, you can get the source code and compile it yourself - but it's not necessary to do so.In which case the installers/packages take machine dependencies intoaccount. A package may be cross platform, but you download and installa DIFFERENT package for Windows, Macintosh, Solaris, AIX, various flavors of Linux (or you have an install CD that has enough smarts to detect its environment and install appropriately).Ok, please tell me - if the program is hardware dependent, how does an installer change the machine code to support different hardware? I don't argue that the same program requires recompilation for different OS's, but that's not what we've been talking about. The discussion is how the code can work on different hardware.What? Are you kidding me? What do you think package managers do when they reconcile dependencies, and load additional packages - dynamically linked libraries, kernel modules, and so forth - to put all the pieces in place that are necessary for a particular application package to run in a particular environment? And there's also the matter of setting up configuration files based on the specific run-time environment.You still haven't told me how I can load exactly the same binaries on different machines with different hardware, and make them work. After all, it is you who claimed the code was dependent on hardware configuration.Please explain in detail.
Huh? I am precisely claiming that it's impossible to load exactly the same binaries on different machines, with different hardware, and expect them to work.
I WOULD expect my installer (or package manager) to:1. install a collection of binaries that are specific to the machine I'm installing on 2. configure my installation based on the hardware environment (and software environment)
and then I would expect my code to: 3. adapt its behavior to its runtime environmentSince you're the once who claims it's possible to write completely platform-independent code, how about if YOU explain, in detail, how to write a piece of code that can run anywhere, without knowing anything about its run-time environment (be that knowledge being implicit, as a function of compilation, linking, and configuration; or run-time adaptation).
No, it is completely dependent on the compiler being used, as noted above.Bulltwaddle. It also depends on the linker, the libraries, compile-time switches, and lots of other things.Given what you have to say, I sure as hell wouldn't hire anybody who'slearned programming from one of your classes.All of which depends on the compiler. Compile-time switches are dependent on the compiler. So are the libraries supplied with the compiler. And the linker only has to worry about pointers and such;it doesn't care if you're running 16, 32 or even 128 bit integers, forinstance. You can take a COBOL compiler and libraries, develop a program with 100 digit packed decimal numbers. The linker doesn't care. The OS libraries don't care. The only thing outside of the compiler which does matter is the libraries supplied with the compiler itself.And as soon as you write something that does any i/o you get into allkinds of issues regarding install time dependencies, dynamic linking tovarious kernel modules and drivers, etc., etc., etc.Not at all. As I said above - your claim has been different HARDWARE requires different compilation options. Not different OS's. Please don't try to change the subject.Huh? Of course different hardware requires different compilation options - starting with the option specifying the target CPU architecture.Nope. When I'm compiling for X86 on an X86 machine, I use a set of options. When I'm compiling the same program for ARM on an ARM machine, I use exactly the same set of compiler options.You obviously have never done anything other than X86 programming.
Let's see, when I'm compiling on X86, I would probably start by telling gcc to compile with one of -march= one of i386 i486 i586 i686 corei7 etc.
If I were compiling for ARM, I'd probably specify -mcpu= armXXX And then I'd get into options that optimize for various hardware options. Actually, I'd probably let autotools do most of the work.Though, by the way, back when I did active programming, very little of it was for x86. There was a period when most of my coding was in z80 assembly language (now there's a sweet little chip that's still in widespread use). A lot of higher-level language work (mostly Fortran, which dates me a bit). A bunch of stuff in various scripting languages (perl, PHP, some python). Some JavaScript. More recently in Erlang.
Probably spent more time on SPARCs and 68000-based Macs, than on x86 machines, until the last few years.
And if my teaching is so bad, why have my customers (mostly Fortune 500 companies) kept calling me back? Maybe because my students come out of the class knowledgeable and productive? And my customers (mostly Fortune 500 companies) keep calling me back because the programmers I train are productive.Kind of hard to vet that. You're JDS Computer Training Corp., right? Now web site, no mention in any journals - pretty much all the Googleshows is a bunch of business listings on sites that auto-scrape business registration databases. And when I search on Jerry Stuckle, all I find are a LinkedIn page that lists you as President of SmarTech Homes since2003, which in turn has a 1-page, relatively content-free web site talking about the benefits of homes with simple automation systems. Pretty vaporous.No public website, no. And no, I don't have to advertise in journals. It's too expensive and I don't need it. As for the SmarTech homes - that's something I've played around with a bit - but that's really all. It's why you don't see much on the website. And my LinkedIn profile has nothing to do with my training. Not at all vaporous. But then when all else fails, trolls have to try to attack the messenger because they can't refute the facts. (They also try to change the subject).No. I'm just asking you to back up your claim that Fortune 500 customers keep calling you back.No, you're the one who started the attacks. I don't have to back up ANYTHING to trolls.But now it's time to <plonk> the troll. Jerry
Go plonk yourself - you're the troll here. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra