Slashdot Mirror

Oh, I have no doubt that Lua runs much faster than Python or Perl. That wasn't the comparison I was drawing. Lua runs much slower than C, C++, Java... compiled system languages are going to be much faster than scripting languages in almost every case.

Here's a nice blog entry visually benchmarking various programming languages that was posted on Slashdot maybe a year ago. It might be a bit dated; doubtless we've seen more improvements in the past year to relatively new programming languages, compared to those which have been around for decades. Still, it is pretty immediately apparent that with scripting languages, you're often trading performance for much less verbose code.

Man, revisiting that article makes me want to pick up Haskell. Everything I've seen makes it out to be a wonder-language.

Anyway, why Ruby? Not that I have anything against it but really why did they pick Ruby?

Maybe they wanted to emulate that nice slow ka-CHUNK action of the lever-pull voting machines? For that they'd need the absolute slowest popular programming language available. Hence, Ruby.

>How does that help? Java runs on Windows, as on pretty much everything else.
>Explain to me how Microsoft's monopoly makes .NET a better choice than anything
>else that targets the Windows platform.

Because of the interoperability between apps is a lot more robust, and what I did NOT know is that you claim that OpenOffice was created by Sun and therefor should be able to tie into Java nicely..
if this is the case, I thank you for at least informing me of one new tidbit I did not know, this might change my point of view a little bit, giving Java a much longer lifespan then I first thought
however, I still think they are too far behind and might go semi-extinct in 5 years...with a few harcode fans still using it..

>Calling it a scam isn't just insulting, it's dishonest, and you know it
I wasnt calling Java a scam, I was calling the fact that it states it is cross platform a scam,
and still is, because you need to download the VM for each type of environment, might as well just download wine and the linux framework, and can port all my .NET apps over to linux !

Citation for benchmarks here
http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html
and here to start
http://www.osnews.com/story/5602/Nine_Language_Performance_Round-up_Benchmarking_Math_File_I_O/page3/

but I do not have the time to be showing you all the listings, this is something that takes research and long hours to accumulate, as you can see these are very extensive benchmarks,
and need to be done properly.

The best performance data I could find was this - it does show that you will run into at least a few cases where the compiler is being quite dumb.

Actually, that's the coder, not the compiler. The worst cases there were for code that was apparently not written with performance in mind at all. From what I saw, there was only one "gotcha" that arguably was the compiler or JVM's fault having to do with lack of optimization in certain types of static initializer code, and even then it only came up because the coder tried to save a dozen or so characters in the code.

Yes, it's fairly complicated, but then all languages tend to become that as they move from academia or design-by-committee stage into real world - witness Java.

Java is an extremely simple language; it has a large library and a lot of auxiliary APIs - which do often tend toward overnegineering - but the language syntax is quite a bit simpler than Scala. It's an important distinction, ignoring libraries you don't need takes a lot less effort than language features you don't need.

And yes, I do tend to like statically typed languages as well.

You probably aren't. It's been a big thing in .NET land ever since C# 3.0 appeared, and grows even bigger now with F#. It's a pragmatic approach - it gives you both OO and FP tools, and lets you mix and match freely to get the optimal balance for the task at hand.

I understand the concept, I'm just not sold on The Scala Way in practice (hey, just a personal opinion). Actually, the C# way seems like a much quicker win - I would love to have a subset of Scala's functional features in Java (certainly would make adoption easier).

Funny how you speak about performance hit, and then immediately mention Clojure... Anyway, where did you see the "huge" perf hit there? Examples?

Fair enough, "huge" is an overstatement, let's go with "significant". The best performance data I could find was this - it does show that you will run into at least a few cases where the compiler is being quite dumb - good benchmarks are hard to come by, though. And yes, Clojure has the same problem, but hard data is even sparser for Clojure.

I'm a big Basic fan, and love how FreeBasic is like one of the top languages in terseness and execution speed at http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of-v1.html. (The updated version doesn't even mention the word "basic.") Unfortunately there seems to be a massive campaign against assembler and basic these days in favor of bytecode compiler languages, simply because the heavy extra layers that are placed between the user and the cpu, layers that can be claimed as intellectual property and the whole computing world sort of blackmailed into paying for a rental fee for living on top of it. Assembler is difficult to work with, but cheap. Basic is so simple anyone can do it. The drive towards dotnet/java or other so called "professional" languages is like having to use Latin in the middle ages for both religious ceremony and scientific writing. This kept the bulk of the population who didn't speak latin clueless. These days very little official discourse is in latin, and knowledge is more freely accessible to the general public. You could argue that the general public doesn't know how to write proper programs just like hillbillies don't know how to properly spell and create written text that monks properly trained in Latin would cringe at. So what? That's not a good enough reason to deny them the right to write anyway.

It's been a few years since 2005 when I was looking at a replacement for VB6 to bangup a quick and dirty db interface for SQL Server to manage some lab samples. I simply can't stand dotnet and java bloat and slowness, and even interface reaction time - I can't zip through the menus with the speed of light in the newer Visual Studios, and the test programs were similarly sluggish. I almost settled on programming in C++ and wxWidgets, which had decent speed, it it weren't for the codesize - DevCpp static linking minimal programs were well over 1 MB, for a previous VB exe app that used VBRUN600.dll was less than 64 KB. Win32 C apps were just too verbose to write and debug compared to VB. I ended up sticking with VB6 even to this day, which pretty much has both feet in the grave by now and a few nails driven into the coffin, but I still couldn't find anything better than VB6/Excel VBA that would be officially supported by MS, so my ass is covered when I give it to a large corporation. I'm quite tempted to go for unofficially supported things like sqlite in the future with a simple file access protocol, because even ADO/SQL Server is becoming ridiculous compared to old ADO classic/MS SQL Server 2000 version that was quick and dirty and flying like a breeze. I set up this VB6 frontend/ADO/SQL Server 2000 backend db app in 2002 to replace an old file-access based Foxpro app that was very slow, but the daily security patches sometimes break the whole show, with ADO getting messed up with an MDAC update, and good luck trying to fix that. Going back to a slow file access based db where all the data is pulled across a network to be locally sorted seems retarded, but in view of the heavy layer of moving targets in an officially supported server-client setup, something simple that relies on Win32 API with sqlite and simple file access is starting to seem like a breath of fresh air.

By the way I never really knew what i386 registers were, and these days I'm learning assembler programming, starting with http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html and http://asm.sourceforge.net/intro/hello.html . Jeebus, assembler is hard, but it's so sexy, supersmall, superfast, with all middle man libraries out of the way. Libraries are like having someone else do a repair job on your car that you don't know how to do. Knowing assembler is like knowing how to repair it yourself, and when you take your car in for repair, you don't get shafted, because if t