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.