[GRLUG] sysadmin job opening

[Bob Kline]

One could throw in parallel programming.

But what emerges is that someone
has to decide how to balance cost,
performance, and who can do what.
Knowing the strengths and weaknesses
of most platforms and languages today
is probably beyond any one person, so
the decision is inherently difficult.  Individuals
often argue for what they know - both in the
hardware and software side of things.  Having
to come up to speed on something new
guarantees that amateurs will be doing the
job, and the results will reflect this.  If
engineering departments could get around
these points, then one would have demonstrated
the intelligence of a mob.  But any working
person knows that a camel is a horse designed
by a committee.

Perhaps the proliferation of "languages" has
simply complicated everything.  Each new one
is supposed to be the greatest thing since
sliced bread - one's thesis said that.  But it
rarely works out that way.

In the not so distant past it was clear that
if you wanted a program to execute 10X faster,
buy hardware that went 10X faster.  Concepts
like caching have been around a long time,
but only recently has the hardware been
cheap enough to routinely support them.

I'll agree that speed is both program and
context dependent, and that one usually
only has control over a few of the factors.

   -- Bob


On Mon, Feb 1, 2010 at 10:36 AM, Michael Mol <mikemol at gmail.com> wrote:

> On Mon, Feb 1, 2010 at 10:01 AM, Bob Kline <bob.kline at gmail.com> wrote:
> > Uhmmm,  isn't execution speed and
> > coding speed the usual tradeoff with
> > high level languages?  A shell script
> > can get small things done in a hurry.
> > No one expects it to execute fast.  Or
> > should anyway.
>
> True, to an extent, but some will perform better than others when
> given the exact same instructions. Keep in mind is that different
> languages have different ways to let you reach the same end
> efficiently. Taking advantage of language idioms will go a long way in
> making a "slow" work better.
>
> I won't pretend to be able to back up the point with specific
> examples, though. I'd have to be an expert in each language.
>
> > Isn't it usually the case that one
> > needs a compiled version of high
> > level code before the speed improves?
>
> No. Speed improvements usually occur in a few stages (in no particular
> order):
>
> * Throw more/better hardware at the problem.
> * Take advantage of caching in more places
> * Refactor the code to meet different design requirements.
> * Refactor the code because you learned how to better write to the langauge
> * Change your execution environment.
>
> There's a *lot* of gain that can be gained from those first four, and
> by the time you can refactor to write to the language, your market
> value probably doubled compared to when you first started writing in
> that language professionally.
>
> > As in an order of magnitude and more?
> > High level languages keep people
> > from having to learn things like assembly
> > language and "C,"  reduce expensive
> > labor costs, and exploit cheaper, faster
> > hardware, but I'd of thought that it was
> > clear what the price of them is.
>
> Writing in a more expressive ("higher level") language improves labor
> costs because it allows you to decrease your iteration time in
> development.
>
> > They are relatively slow. You never get
> > it all.
>
> You never get it all with any language. It's a matter of looking at
> the task at hand, and choosing the right tool for the job. Would you
> write a wiki in C, much less assembler? I wouldn't even *try* it in
> C++ (the language I'm most proficient in) until I had a few more years
> of professional development under my belt, and I'd probably be smart
> enough to know better by then.
>
> --
> :wq
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shinobu.grlug.org/pipermail/grlug/attachments/20100201/cd2ff2cc/attachment.htm