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/link switches to set based on the characteristics of the build and run-time environments.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 into account. A package may be cross platform, but you download and install a 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).
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's learned 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, for instance.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 all kinds of issues regarding install time dependencies, dynamic linking to various kernel modules and drivers, etc., etc., etc.
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 Google shows 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 since 2003, which in turn has a 1-page, relatively content-free web site talking about the benefits of homes with simple automation systems.
Pretty vaporous. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra