Re: Perl, Python, Ruby, PHP, C, C++, Lua, tcl, javascript and Java comparison

["NU-g.lister" <g.lister@...>]

I personally use this page to make some vague abstract conclusions about what is a good language to use:
http://benchmarksgame.alioth.debian.org/

note that it explicitly says a  benchmarksgame and there are no hard headed opinions to weed through. I do write Java code for a living ... yep ... and I often detest waiting for another workspace rebuild or recompile, and the mountains of abstractions etc. etc. (Which is Ooh more than Java), but I find Java still a competent tool for certain tasks. I find that the more one knows the more all languages seem the same, you just mix the soup (recompile/parse/tockenize/convert to binary etc. Etc.) many times to go back to assembly and massive amounts of caching complex schedulers and special purpose hardware. Speed is a concern, memory too maintainability you bet etc. etc. But things like complexity and maintainability are pretty big opposites once you start pushing both to the max and what your team knows now beats all other arguements ... Just try converting a Java dev to Java script (this benchmark is headed there it seems)

I find that a small sword could be quite a weapon in skillful hands, being an expert in any of these languages is hard - bordering impossible for someone doing the same thing over-and-over (web apps) just check the java-docs and see how many classes one use day-in-day-out. Last but not least a complex tool in incompetend hands is quite dangerous/funny (mood dependend) too watch. There are too many Google Search Copy Paste Certified (GSCPC) brothers and sisters out their and falling the trap is a necesity at times, easy and enticing at others.

Did I miss something or there are really no summaries for all languages.. Reading on a phone :(
Cheers and thanks for the read :)

----- Original message -----
> On Tue, Jul 16, 2013 at 12:22 AM, oliver <oliver.schoenborn@gmail.com>
> wrote:
> > On Mon, Jul 15, 2013 at 1:25 PM, Andrew Wilson <agrwagrw@gmail.com>
> > wrote:
> > > 
> > > These benchmarks assume naive programmers for the languages, making
> > > them useless.
> > 
> > 
> > They are useless for advanced Lua programmers; they're actually quite
> > representative for novice Lua programmers, and somewhere in between for
> > intermediate :) Granted, use of "local" is so simple, and well
> > documented (wiki, gem) that there is little excuse not to use it. But
> > only advanced Lua users have time/interest to learn such intricacies
> > as the idiom gstr= table.concat({gstr}, str), which is an optimization
> > at the expense of clarity.
> > 
> > Actually I couldn't understand that line and sure enough, it is not
> > equivalent to gstr=gstr..str. The intended expression was likely
> > table.concat({gstr, str}), showing again how optimization has a price
> > (clarity, which in this case led to a typo which still compiled fine).
> > 
> > So I ran some tests on stock lua 5.1 running in a virtual machine. It
> > shows that the table.concat({gstr, str}) is in fact slower. This is
> > (surely, but I'm no expert) because that algorithm creates a new table
> > every time through the loop, which is if I'm not mistaken the second
> > optimization discussed by Roberto in his gem article. So I moved the
> > table creation out of the loop:
> > 
> > ...
> > local tt={gstr,str}
> > 
> > while i < imax+1000 do
> > i=i+1;
> > tt[1]=gstr; gstr=table.concat(tt) -- was gstr=gstr..str
> > ...
> > 
> > These are the timings that I obtained, I hope the formatting doesn't
> > get clobbered:
> > 
> > str.length |             exec.tm.sec
> > |       A             B               C
> > -----------|-------------------------
> > 256kb           |   48sec     56sec       47sec
> > 512kb           | 194sec     225sec     189sec
> > 768kb           | 451sec     473sec     436sec
> > 
> > A: using "gstr=gstr..str"
> > B: using "table.concat({gstr, str})"
> > C: using "tt[1]=gstr; table.concat(tt)" (and tt={gstr,str} before the
> > loop)
> > 
> > A good example of how that optimization seemed clever but is probably
> > a bad idea: A) a hurried implementation of the table.concat trick
> > required unclear code, leading to a typo, and even once fixed, was in
> > fact 15% slower than the original technique; B) even once "properly"
> > applied, the trick provided a 2% improvement only, clearly not worth
> > the significant decrease in maintainability.
> > 
> > Oliver
> > 
> > 
> 
> My first encounter with table.concat was when a looping string
> concatenation was taking wall-clock time. Then it took me a second to
> remember that I read that sort of thing was slow and then I've never
> had a problem with it.
> 
> My point is that you're a novice or intermediate Lua programmer, right
> up until the point the wrong way bites you. Then in about 5 seconds,
> you're a super-smart-advanced Lua programmer that knows everything
> there is to know about the immutability of strings (they are
> immutable) and how to do it "the right way."
> 
> So, the benchmark is useless and says nothing about how Lua performs
> in the wild. IMHO, of course.
> 
> -Andrew
>