<br><br><div class="gmail_quote">On Mon, Feb 1, 2010 at 11:24 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;">
On 2/1/2010 11:04 AM, Bob Kline wrote:<br>
> One could throw in parallel programming.<br>
<br>
As what? You didn't intersperse your reply, so I don't know what this is<br>
in reply to.<br></blockquote><div><br></div><div>Is interspersing top posting, bottom</div><div>posting, or just common sense posting?</div><div>Just asking. </div><div><br></div><div>OK, this is getting a little tedious, if </div>
<div>not fruitless, so to wind down, the </div><div>point was in regard to your list </div><div>of ways to speed things up:</div><div><br></div><div>**********************</div><div>><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<br>> langauge<br>
> * Change your execution environment.</div><div>***********************</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
><br>
> But what emerges is that someone<br>
> has to decide how to balance cost,<br>
> performance, and who can do what.<br>
> Knowing the strengths and weaknesses<br>
> of most platforms and languages today<br>
> is probably beyond any one person, so<br>
> the decision is inherently difficult.<br>
<br>
One doesn't need to know everything, or even most things, in order to<br>
have a broad enough toolkit to know when to pull out a screwdriver<br>
instead of a claw hammer. It's good to be passably proficient in<br>
multiple languages, so you know when one tool is likely to be better<br>
than another.<br></blockquote><div><br></div><div>I would argue that with some many</div><div>languages, one's personal toolkit </div><div>might miss the mark. One could get</div><div>in to the marginal utility of using yet</div>
<div>another language as opposed to </div><div>ensuring, say, maintainability. i.e.,</div><div>a little COBAL piece might not be </div><div>good for long term maintainability.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
> Individuals<br>
> often argue for what they know - both in the<br>
> hardware and software side of things.<br>
<br>
I don't understand how this is relevant.<br></blockquote><div><br></div><div>It's relevant because people will often</div><div>choose what they know because they</div><div>are limited by that perspective. Only </div>
<div>people with broad knowledge and-or experience</div><div>can choose what is by some measure best.</div><div>And of course anything that becomes </div><div>commercially important will likely be</div><div>overhauled at some point anyway. Often</div>
<div>ideas and concepts transcend any actual</div><div>implementation.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
> Having<br>
> to come up to speed on something new<br>
> guarantees that amateurs will be doing the<br>
> job, and the results will reflect this.<br>
<br>
A proficient programmer needs to be at least passably familiar with<br>
multiple tools. Otherwise, he's not much better the guy who gets hired<br>
because he's good with a sledgehammer.<br></blockquote><div><br></div><div>By definition of proficient programmer.</div><div>And of course multiple tools can mean</div><div>a lot of tools today. Are many people</div>
<div>actually like that? And of course if you</div><div>need a person good with a sledgehammer,</div><div>that changes things too. Management is</div><div>a tough business when done right.... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
It's also true that in the computing fields, the cost equation for how<br>
to get the best computing bang for the hardware buck leads to constant<br>
shifting around in the hardware and network architecture. Twenty years<br>
ago, it was thick-client software. Ten years ago, it was the gigahertz<br>
race. Recently, it's been the multicore race. Soon, it's going to be a<br>
split between breaking problems into massively parallel work sets and<br>
making things run on processors without some of the in-CPU optimizations<br>
we've come to depend on.<br>
<br>
And, certainly, things will shift in a different direction within the<br>
next fifteen years.<br></blockquote><div><br></div><div>This mostly says there is some kind</div><div>of progress on the technology front.</div><div>If past performance is any guarantee</div><div>of future performance (...) there will</div>
<div>indeed be more changes, just by</div><div>extrapolation. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
All of this leads to new languages, new libraries, and new requirements<br>
for how one thinks about a problem.<br></blockquote><div><br></div><div>Yes, assuming some kind of metric</div><div>shows things are better, as opposed</div><div>to just different. That happens too.</div><div>Every field has elements of fashion,</div>
<div>and fad bandwagons. Mostly temporary,</div><div>and devoid of substance. The new thing</div><div>on the block is almost always better. For</div><div>a while.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
> If<br>
> engineering departments could get around<br>
> these points, then one would have demonstrated<br>
> the intelligence of a mob. But any working<br>
> person knows that a camel is a horse designed<br>
> by a committee.<br>
<br>
I don't know where you're going with this, unless you're trying to say<br>
that langauges like PHP try to be too many things to too many people.<br>
However, that would seem to conflict with your implied argument that<br>
C/asm should be enough for everyone. If that were the case, what other<br>
features could a language designed by committee possibly pick up?<br></blockquote><div><br></div><div>It's not going anywhere - it's for discussion's</div><div>sake. The issue is how get things done in</div>
<div>the most cost effective way over the longer</div><div>run, and what factors go in to that. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
><br>
> Perhaps the proliferation of "languages" has<br>
> simply complicated everything. Each new one<br>
> is supposed to be the greatest thing since<br>
> sliced bread - one's thesis said that. But it<br>
> rarely works out that way.<br>
<br>
Ech...You're only hearing about the languages that are trumpeted and get<br>
a lot of chatter. There's more than just those out there, believe me.<br>
I was surprised to hear that someone on this list uses R. I've seen<br>
plenty of R code, but I hadn't noticed anyone talk about it outside<br>
Rosetta Code.<br>
<br>
><br>
> In the not so distant past it was clear that<br>
> if you wanted a program to execute 10X faster,<br>
> buy hardware that went 10X faster. Concepts<br>
> like caching have been around a long time,<br>
> but only recently has the hardware been<br>
> cheap enough to routinely support them.<br>
><br>
> I'll agree that speed is both program and<br>
> context dependent, and that one usually<br>
> only has control over a few of the factors.<br>
<br>
It's perfectly plausible to have control; It's a matter of managing your<br>
environment.<br>
<br></blockquote><div>True. But that depends on how big</div><div>your project is, and of what commercial</div><div>importance. A single person working on</div><div>a solution to local, if important, problem</div><div>
can get away with a lot of mix and match.</div><div>A big project - say new avionics for an</div><div>F-18 fighter - has other constraints. It all</div><div>has to work right, and a lot of people have</div><div>to be proficient with the tools used.</div>
<div><br></div><div>It's a management issue all right, and</div><div>it's easy to see that approaches often</div><div>do not scale well. </div><div><br></div><div>//endjob</div><div><br></div><div> -- Bob</div><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
> On Mon, Feb 1, 2010 at 10:36 AM, Michael Mol <<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a><br>
> <mailto:<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a>>> wrote:<br>
><br>
> On Mon, Feb 1, 2010 at 10:01 AM, Bob Kline <<a href="mailto:bob.kline@gmail.com">bob.kline@gmail.com</a><br>
> <mailto:<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>
> 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>
><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>
> No. Speed improvements usually occur in a few stages (in no<br>
> 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<br>
> 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>
><br>
> > As in an order of magnitude and more?<br>
> > 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>
> 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>
><br>
> > They are relatively slow. You never get<br>
> > it all.<br>
><br>
> 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>
><br>
> --<br>
> :wq<br>
> _______________________________________________<br>
> grlug mailing list<br>
> <a href="mailto:grlug@grlug.org">grlug@grlug.org</a> <mailto:<a href="mailto:grlug@grlug.org">grlug@grlug.org</a>><br>
<div><div></div><div class="h5">> <a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<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>
<br>
_______________________________________________<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>