One could throw in parallel programming.<div><br></div><div>But what emerges is that someone</div><div>has to decide how to balance cost,</div><div>performance, and who can do what.</div><div>Knowing the strengths and weaknesses</div>
<div>of most platforms and languages today</div><div>is probably beyond any one person, so</div><div>the decision is inherently difficult. Individuals</div><div>often argue for what they know - both in the</div><div>hardware and software side of things. Having</div>
<div>to come up to speed on something new </div><div>guarantees that amateurs will be doing the</div><div>job, and the results will reflect this. If </div><div>engineering departments could get around</div><div>these points, then one would have demonstrated</div>
<div>the intelligence of a mob. But any working</div><div>person knows that a camel is a horse designed</div><div>by a committee.</div><div><br></div><div>Perhaps the proliferation of "languages" has</div><div>
simply complicated everything. Each new one</div><div>is supposed to be the greatest thing since</div><div>sliced bread - one's thesis said that. But it</div><div>rarely works out that way.</div><div><br></div><div>
In the not so distant past it was clear that</div><div>if you wanted a program to execute 10X faster,</div><div>buy hardware that went 10X faster. Concepts</div><div>like caching have been around a long time,</div><div>but only recently has the hardware been </div>
<div>cheap enough to routinely support them.</div><div><br></div><div>I'll agree that speed is both program and</div><div>context dependent, and that one usually</div><div>only has control over a few of the factors.</div>
<div><br></div><div> -- Bob</div><div><br></div><div><br><div class="gmail_quote">On Mon, Feb 1, 2010 at 10:36 AM, Michael Mol <span dir="ltr"><<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Mon, Feb 1, 2010 at 10:01 AM, Bob Kline <<a href="mailto:bob.kline@gmail.com">bob.kline@gmail.com</a>> wrote:<br>
> Uhmmm, isn't execution speed and<br>
> coding speed the usual tradeoff with<br>
> high level languages? A shell script<br>
> can get small things done in a hurry.<br>
> No one expects it to execute fast. Or<br>
> should anyway.<br>
<br>
</div>True, to an extent, but some will perform better than others when<br>
given the exact same instructions. Keep in mind is that different<br>
languages have different ways to let you reach the same end<br>
efficiently. Taking advantage of language idioms will go a long way in<br>
making a "slow" work better.<br>
<br>
I won't pretend to be able to back up the point with specific<br>
examples, though. I'd have to be an expert in each language.<br>
<div class="im"><br>
> Isn't it usually the case that one<br>
> needs a compiled version of high<br>
> level code before the speed improves?<br>
<br>
</div>No. Speed improvements usually occur in a few stages (in no particular order):<br>
<br>
* Throw more/better hardware at the problem.<br>
* Take advantage of caching in more places<br>
* Refactor the code to meet different design requirements.<br>
* Refactor the code because you learned how to better write to the langauge<br>
* Change your execution environment.<br>
<br>
There's a *lot* of gain that can be gained from those first four, and<br>
by the time you can refactor to write to the language, your market<br>
value probably doubled compared to when you first started writing in<br>
that language professionally.<br>
<div class="im"><br>
> As in an order of magnitude and more?<br>
</div><div class="im">> High level languages keep people<br>
> from having to learn things like assembly<br>
> language and "C," reduce expensive<br>
> labor costs, and exploit cheaper, faster<br>
> hardware, but I'd of thought that it was<br>
> clear what the price of them is.<br>
<br>
</div>Writing in a more expressive ("higher level") language improves labor<br>
costs because it allows you to decrease your iteration time in<br>
development.<br>
<div class="im"><br>
> They are relatively slow. You never get<br>
> it all.<br>
<br>
</div>You never get it all with any language. It's a matter of looking at<br>
the task at hand, and choosing the right tool for the job. Would you<br>
write a wiki in C, much less assembler? I wouldn't even *try* it in<br>
C++ (the language I'm most proficient in) until I had a few more years<br>
of professional development under my belt, and I'd probably be smart<br>
enough to know better by then.<br>
<font color="#888888"><br>
--<br>
:wq<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
grlug mailing list<br>
<a href="mailto:grlug@grlug.org">grlug@grlug.org</a><br>
<a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug</a><br>
</div></div></blockquote></div><br></div>