Slashdot Mirror

although i have just learned about erlang. i went to the trusty computer language shootout, and behold, it covered erlang!

http://www.bagley.org/~doug/shootout/lang/erlang/

This doesnt mean much as far more qualitative arguments exist. You can also browse over the code. :-)

Or perhaps Objective CAML. I don't know as much about it as I'd like, but looks very interesting. Supports both functional and imperative programming, objects, etc. You can run code interactively, compile machine independant bytecode, or for speed, architecture specific binaries.

And check out it's position on this performance shootout.

Or maybe because its slower than Ruby, Perl, Python, Java, and multiple ML variants.

Good threading support compared to what?

C, C++, Ada, perl, I dunno, what are you looking for?

Why should a language be designed around maximizing speed?

Because when you design a language, you are setting performance absolutes. A program *cannot* run faster than whatever your language is limiting it to. No hacks or tricks later on can avoid this limitation.

Far less bad is missing functionality, or even imperfect APIs. You can introduce new APIs. You can add new libraries. If the language's native API is too raw for you, you can slap a layer of software on top of it (as much C++ code does with C APIs).

However, there is no way to "fix" bad performance at the language level.

That being said, there are some times that peformance just isn't a big deal. That's okay. The problem is that *everyone* has taken this approach -- there isn't just one or two rapid development languages. Modern, *fast* languages are almost nonexistent (the closest things were the ones I posted above...eiffel and ML).

And everyone says that Moore's law makes performance unnecessary. Fine, but people *upgrade* to a computer that's two or four times as fast. And it's pretty easy, once you throw out the goal of maximizing speed in your language, to lose a factor of two, then four, then ten.

How many apps that are running on your desktop at this minute are in Java? Ten? Five? For me and most others, it's zero. Because Java sucks down RAM and CPU time. It *works*, yes, but it's much slower than a C equivalent is. So there are lots of Java programs, but software that actually gets used is usually written in C or C++. Not because these languages are somehow magically better, but because they have far less overhead. Java has its place, but it's not competitive as a horizontal-market application language.

There are other design goals than speed which are much higher in priority to me.

But those can always be added later. You're setting a bound on the *fastest* an application can run when you design your language. Any tradeoffs you make then impact a horde of developers and users.

Premature optimization is the root of all evil.

This saying, which certainly true, doesn't apply in this case. It's intended to refer to application development. It doesn't say "optimization is bad", it says "optimization without testing -- premature optimization -- is bad". Java has been well tested, and it has a handful of nasty bottlenecks that are well known. You're saying that "optimization is the root of all evil.", which I don't agree with at all.

Beautiful and slow is better than ugly or broken and fast.

In theory, yes.

However, we're talking about a language here, not an application.

C is not broken, though it could be said that it's ugly. Yet most horizontal-market apps are written in C or C++, despite this ugliness. Users *value* performance.

Java's threading support sucks -- it depends on pthreads

[double take] What? That doesn't make sense -- no it doesn't.

Your first alternative is Erlang
Umm...Erlang is possibly the slowest major language out there. It's far slower than Java. Look at the The Great Computer Language Shootout.

First, Ocaml is one in a loooooong line of lanugage that claiming to be safer than C/C++ while simultaneously claiming to be faster. I have not seen one new language in the last five years NOT claim to (in "some cases") be faster than C/C++, yet they never can back this claim up in the average case.

Can't measure up in the average case? Take a look at this.

Ah good, someone got in before me :) It is definatly a good idea to separate out the GUI part when dealing with cross-platform applications, since a lot of portability problems reside there.

In all honesty, I don't recommand Qt or wxWindows - they are great toolkits, but you lose out heavily on productivity compared to visual development environments with GUI builders. While both of these have associated builder tools, I don't consider them very mature of capable compared to VB or Delphi/C Builder. There is also a write-once-debug-and-tweak-everywhere concern (just getting wxWindows looking good on Windows and Solaris takes some effort).

Java is a great choice as it is supported on many platforms, has powerful GUI classes, a couple of builder products, and has several means for client/server support, including CORBA. But for UI applications it isn't hugely productive (strangely enough).

Some of your other options include ParaGUI and SDL, gTk, GraphApp, V, Mozilla's XPToolkit and XUL, and WideStudio.

I have grappled with exactly this question (legacy C/C++ needing to go cross platform with GUIs), and the best answer I've come up with so far is to keep your main code in C/C++ (since you have the legacy code AND the skills), define a clear UI abstraction layer, and create the UI in a scripting language such as Tcl or Python. Use SWIG to tie the script to native C functions.

I have more experience with Tcl/Tk, and believe it is more widely portable (especially the GUI consistency), but it is slower and arguably more difficult to program than Python. Still, this depends on what skills you can acquire, and what your UI requirements are.

Prechelt has an empirical comparison of some languages, including C/C++, Python, Tcl and Perl, and most importantly he has productivity figures! Keith Waclena has a Language Crisis page of comparisons, and Doug Bagley hosts the Great Computer Language Shootout. There are all invaluable resources for determining a balance between portability, functionality and productivity.

There most definitely are Lisp implementations (both Common Lisp and Scheme) that compile to machine code. Two examples are CMUCL and Bigloo. It seems clear from some benchmarks that they easily outperform the likes of Perl, Python, and Java. Note that the previous link won't work if you just click on it, but if you copy it, then put it in the location bar of a new window, it will. It seems the author of the page doesn't much like Slashdot.

You're absolutely right about the power of being able to generate source at runtime and evaluate (run) it. That's one of the things I like about Python as well. In fact, I don't think any language can be considered high-level if it doesn't have that. Guess where this concept originated? In the early implementation (around 1960) of Lisp, a function called "eval" was invented to be the definition of the Lisp interpreter. The details are in "The implementation of LISP".

The nice thing about the compiled lisps is that you also have the compiler available at runtime, which means that you can generate source code dynamically, then compile it. You are no longer bound by the traditional code/compile/run cycle.

I don't know of compilers/interpreters that can make such high level decisions about when to bind and evaluate, but I believe that Lisp allows a lot more flexibility in that area than C-like languages. Also, it looks like Self might offer something in that area. Another class of languages I have yet to explore, but may be far superior on these issues is that of pure functional languages, especially the lazily evaluated ones. I plan to learn one of the ML's eventually, like OCaml.

Unfortunately, as you pointed out, the best tools can't always be used because of external requirements like programmer or user familiarity. In fact, that's the main reason I haven't really gotten into using Lisp yet: I'm comfortable with languages I already know. But, I'm determined to try new things, especially when there's evidence that there are better tools available.

Tcl isn't the slowest thing out there:

shootout

even though it certainly isn't the fastest. One of the nice things about Tcl is that it's much easier to write C code to use from Tcl, or vice versa, which makes it very easy to speed up slow portions of your code with C.

With a good, clean interface, it's a lot of fun to write two-tiered applications, in addition to being an extremely powerful way of doing things. Look at any large enough app, and you are bound to find a scripting language of some kind, be it VB, Tcl, Lisp, Lua, elastiC, or something else...

You are a complete idiot and ignorant. O'caml is fast, very fast, very very fast. I mean it. It has nothing to do with the total crap that are the VMs/JIT implementation Java, Python, Perl or Scheme. It is nearly as fast as C, and maybe faster than C++. It compiles directly to machine code. That's why O'caml wins most of the time.

I bet the O'Caml winner would have taken _days_ to complete a large board.

No. You will see.

If you read the methodology of that performance comparison, you will notice that the author says:

"All artificial language performance benchmarks, mine included, do not measure real-world performance." (authors emphasis).

The performance of various languages varies greatly in different situations, and factors other than speed play a part in the choice of a scripting language for an application.

How is Slashdot a large site that "doesn't require a huge amount of processing/code"? How is Kuro5hin? Show me a community site that is larger than Slashdot or even K5 and written in Java. There's a reason these sites run on mod_perl: It's fast, it's scalable, it's easy to code, it gets the job done. Slashdot and K5 are L/BAMP success stories. Face it, most J2EE sites will never have Slashdot's load.

If you take a look at Scoop, the K5 Perl code, you'll see that it is very much possible to write high quality, maintainable Perl. On the other hand, I've seen many projects fail simply because they used Java, which proved to be too slow for the job. In my opinion, Java is an overhyped technology that is adopted by those who don't know better and has contributed to many project failures of both hobbyists and companies. It's a resource hog, and while OOP is a helpful mechanism to structure code (you can create OOP programs in Perl as well), its importance for creating maintainable projects is overrated -- most Linux applications are written in plain old C, for a good reason.

I'd much rather use Python or Perl than Java. Java is for those who don't know better. (also see Doug's comparison)

Try O'Caml (caml.inria.fr); it's a modern language that's compiled very efficiently (independent benchmarks) and is suitable for heavy crunching. O'Caml has lots of features that you won't find in many languages, like algebraic data types, higher order functions, etc., but is intended for real general purpose programming. Most importantly, it's type-safe (statically) so you probably won't spend as much time tracking down bugs unrelated to the problem at hand. (That has certainly been my experience with SML, a language from the same family.)

At low level, pointers are everything, and low level is what you want to teach when you're teaching basic data structures and algorithms.

Conceptually and from a computer science perspective, the object references present in languages like Python, Java etc. are equivalent to pointers in all the ways that matter for representation of data structures and algorithms. In the academic community and elsewhere, it's generally considered beneficial to teach such things without reference to the machine pointers which you're referring to, since machine pointers carry a lot of baggage that's unrelated to the abstractions involved in data structures and algorithms.

There's simply no point in demonstrating list implementation with an interpreted language that has very efficient native lists, dictionaries, etc.

To refute this, let me offer a tutorial: A Gentle Introduction to ML. If you work through this tutorial, you'll very soon begin implementing functions in the ML language for basic list operations and the like - functions that already exist in the language. And guess what: the implementations that the beginner typically comes up with in that tutorial are very close to the actual implementations that ML uses - the tutorial gives some examples of actual implementations for comparison.

This high-level operation doesn't even cost much -languages in the ML family, including OCaml, regularly are top performers - see e.g. Doug Bagley's language shootout. They can perform on par with languages like C because their type systems allow sophisticated compile-time optimizations to be performed, and their high-level abstraction features are supported by optimizations such as tail recursion.

C/C++ or Pascal are much better for that; with them you can teach real implementations, not toy ones.

If you believe that C/C++ and Pascal are good languages for teaching computer science, you don't know much about modern computer science. All three of those languages have very weak type systems and lack basic features that allow the construction of high-level abstractions.

Pascal is all but a dead language in the CS community nowadays. The primary use for C is as a decent portable assembler. Learning C has very little to do with computer science, and absolutely nothing to do with teaching computer science concepts.

Though it's not (yet =) one of the "major" languages, but it's pretty awesome. Here are some things I've learned and resources I've discovered.

What is OCaml? In a sentence, "fast modern type-inferring functional programming language." But not only does it support the functional programming paradigm, but also imperative and object-oriented models. (These can be mixed in a single program.) OCaml is type-safe and garbage collected. (But even though it's garbage collected, it runs at speeds comparable to C and C++.)

Why use OCaml? Here are some good reasons:

• It's fast! It scores very high (second only to C) on Doug Bagley's computer language shootout
• Very compact code
• Interoperates very easily with C
• Was used by at least one of the top 3 entries in each ICFP Programming Contest between 1998 and 2001. Won 1st prize in 2000 and 1999.
• It's a functional programming language - you can use functions as arguments to other functions.
• It's garbage collected - you don't have to worry about cleaning up memory and can focus on the problem to solve.
• OCaml includes libraries for complex data structures, graphics, regular expressions and string processing, and more.
• Compiles to native code or bytecode.

What kind of things have been implemented in OCaml? Check out the Caml Hump.

OCaml was developed in France, so the "bible" of the language (O'Reilly's Développement d'applications avec Objective Caml - the camel book) is written in French, but a translation of the work by volunteers has been created. Check out Developing Applications with Objective Caml.

The language's official page at INRIA in France.

Another good OCaml page

Yay OCaml!

What a wussy response. So what you're saying is that those languages are all good, except when they're not.

I love Intercal because it destroys all the "they're all very nice" language relativity arguments. Here's a language that's specifically designed to be as annoying as possible. I dare you to advocate Intercal in the same way you did above.

Both the PHP language and its implementation have significant problems. Regular users of PHP already have their own list of language design annoyances ("it has to be a global??") and you can see some of the implementation problems here. You will note PHP's implementation getting beaten by Tcl, gawk, xemacs, and njs. :-(

PHP would have been better off if the implementors had used an existing language like Lua (80k of x86 code for standalone interpreter+core libraries!) and focused on the embedding features unique to the application area.

The short story is, even though the combinaison of C++-to-C compatibility and C++ templates should make C++ faster, the numerous implicit memcpy's and copy constructor calls behind C++'s syntax makes the promess painstaking to realize in all but very small programs. Thus, even the dedicated and competent programmer that created the gcls could not get to C's speed.

Take a look at this guy's page, some interesting benchmarks between a number of computer languages for a number of well known algorithms.

It integrates seemlessly with MySQL, compared to ASP-MSSQL/Access where I had to define a dsn connection with several lines of code

set myConnection = server.createobject("adodb.connection")
myConnect ion.open "dsn_name"

There are reports taht PHP runs faster than ASP, but I haven't ran my own tests.

The good folks at www.php.net give a full documentation of the language, as well as a tutorial. Try finding that on M$ website
Gee, okay. Try the microsoft scripting page. Wow, full docs and tutorials.

If you are going to migrate over to the non-microsoft side of web development, go with Ruby or Python. They are faster and more robust than PHP (and VBScript, for that matter), and are far easier on the eyes (call me crazy, I like my variables names to resemble actual words... whats wrong with you php/perl people?).

All of those are much slower than the equivalent C code.

Proof? Of course, there cannot be one, but if you like benchmarks, compare the Great Computer Language Shootout. Though C "wins", I wouldn't exactly call it "much slower".

They all use byte-code or generate C code, then compile the C code.

Wrong. For all languages I mentioned there are native compilers available. For all (AFAIK, not sure about Standard ML), there are also bytecode compilers available, for some also compilers to C.

BTW, nobody would ever be so stupid to first generate bytecode, then C out of this (At least I hope so). Oh, and assembly isn't what you compile to in the end, thats why there are assemblers.

None that I know of generate assembly language directly.

If you talk of generating native binaries directly, you surely should try to get to know more. Here are a few:

• OCaml
• Standard ML of New Jersey
• MLton
• The Glasgow Haskell Compiler
• NHC 98
• CLisp
• CMUCL
• Stalin

If you want fast 5000x5000 matrix multiplication, you're better use assembly and Pentium III+ SIMD instructions. The difference between assembly and C will likely be greater than between C and SML. See also Matrix multiplication test, which shows OCaml (SML derivative) is about 30% ("The OCaml solution is just as fast as the C/C++ solutions, until we add the -funroll-loops optimization option to our gcc/g++ programs, which naturally gives them a small advantage.").

My point is only that SOME applications need that extra speed (of course, since I tend to do mathematically programming I see it more often than most) that c gives.

Why not use assembly then? And you are assuming also other languages than C are noticeably slow, which is wrong at least for OCaml, one of the faster implementation of a ML-type of language [it compiles directly to machine code, and has support for Itanium, among other things]. Also no one prevents you to write subfunctions in C or in assembly.

There is no pratical difference. Whenever one of these language will be too slow, the others will be too, compared to the x10-x100 that could be won by switching to C/C++ (or fast JIT VMs Java). See The Great Computer Language Shootout

It's called The Slash Hole, and has been done before. Though I can currently reach imaclinux.net. They either used something different, or they've already changed their settings back to normal.

It that isn't your primary concern (and frankly, it seldom is), there are lots of interesting FPLs, like Erlang, which has support for parallel, distributed, fault-tolerant computing as a primary design goal.

However, as for the "critical mass", it's a chicken and egg problem. There are way less useful libraries for FPLs, and the documentation you get is mostly not quite written for the "pragmatic programmer".

However, I also would recommend a FPL if you want to write good code quickly and have fun doing so - I agree with the OCaml-Team chosing "The programming tool of choice for the discriminating hacker" as a motto for the language.

Actually java, compiled JIT, is place #9 in the CPU ranking, slower than all other major compiled languages. If you add the memory multiplier, which is a more realistic measurement than CPU time alone, java falls to place #16, well below perl, python and ruby (in memory ranking alone, java is almost at the complete bottom). Mind you, this is for non-graphical applications. You can imagine how java would rank for swing stuff.

You said Java and fast in the same sentence. That is incorrect.

If you've really only been programming in Lisp for a week or so then you really haven't had time enough to appreciate what its strengths and weaknesses are. It sounds to me as though you have acquired a disease that is all too common amongst programmers - the desire to want to specialise in one language too early on.

I simply cannot emphasise enough how valuable it is to learn as many programming languages as possible. Even if you don't really like it at first, a language can grow on you in ways you would have never imagined. No language is perfect, so knowing a selection of different languages will give you the opportunity to choose a tool that is appropriate to the job in hand. If the only tool you have is a hammer, then every problem you come across starts to look like a nail.

By keeping your horizons broad, most especially by learning languages that might seem strange, counter-intuitive or even downright annoying at first, I can assure you othat you will become a much, much better programmer in the long run. The ways in which languages differ can often give you an insight into the ways that different programmers might solve the same problem.

FWIW, the presence of closures and eval are not the only things that make Lisp distinctive from other languages. The one truly unique (not to mention incredibly powerful) feature of Lisp is macros. You will not be able to find these in Perl. Also, in Perl the standard way to solve problems is with an iterative, procedural style, where Lisp more often employs recursion and an applicative programming style, both of which are techniques well worth the effort to learn about.

Whether Lisp is better than Perl for AI is debatable. I'd argue in favour of Lisp for the following reasons: one is the fact that Lisp is extremely good at knowledge representation (and the subsequent manipulation of that knowledge), but more important is Lisp's ability to generate code with macros, effectively meaning that you can write programs to write other programs. It's also probably worth noting that Lisp is quite a lot faster than Perl, given a decent enough compiler. See The Programming Language Shootout if you don't believe me. Lisp is also a very mature language, with an ANSI standard, so unlike Perl you can be certain that it won't be pulling any carpets out from underneath your feet any time soon.

If I haven't done a enough good job of convincing you that learning Lisp is worthwhile (and I probably haven't) then try checking out Paul Graham's Beating the Averages. Also, be sure to check out Richard Gabriel's Good News, Bad News and How to Win Big. And have a read of Paradigms of Artificial Intelligence Programming by Peter Norvig for some more specific examples of Lisp as an AI programming language. Particularly relevant might be the section in the preface entitled Why Lisp?.

And when you're done with Lisp, I'd recommend a look at Ocaml, SML, Ruby and Smalltalk (particularly the delightful Squeak)!

http://www.bagley.org/~doug/shootout/editorial.sht ml The programming language shootout gives some more reasons why ocaml is good.

Startup time is almost negligible if you do it frequently? I'm afraid that's a load of hogwash. Yes, it's faster than the first time, but it's still unbelievably slow. Check out the Hello World benchmark in Bagley's language shootout. It just runs a hello world program in each language from a shell script to measure the relative startup times of languages. Java comes in dead last because it's startup time is pathetic.

The Great Computer Language Shootout is what you are looking for...

Awright, soapbox time!

Redhat, or someone who makes a user-oriented linux distribution, should put together standard internet services which are written in a higher-level language than C. Perhaps they will not be super high-performance, or perhaps they will not have the advanced features of sendmail or bind that most users don't use. But if they're written in a safe language like Java or O'Caml (or, to a lesser extent, scripting languages like Python) we will see the largest class of security holes vanish overnight -- buffer overflows. (Also, format-style bugs, too!)

Though I don't necessarily think this would slow them down -- even if it did, I am guessing that most people would take security over speed any day. I certainly would; hardware is cheap but my time patching and responding to incidents isn't!

I know that C is highly regarded as a systems programming language; it has many useful features in this respect. But it happens to encourage some idioms which are entirely inappropriate for network or security-critical applications. It's really not that hard to do systems programming in other languages. I kept saying this and people kept arguing with me, so I rewrote ftpd in SML . It only took me a few days; maybe a bigger team or better programmers could crank these out even faster. Here is the source code . (Also identd and fingerd ). These are not as featureful as their standard counterparts, but they are much much shorter, and buffer-overflow free.

If they can't do that because it seems like too much work (I believe moving to a more modern language would be worth it anyway), why aren't they at least compiling their default installs with stackguard ? This is so easy to use, and makes exploiting buffer overflows so much more difficult. The speed loss is imperceptible and existing code carries over.

Let's leave the last 30 years of the last century behind us and move to a world without buffer overflows! If we do this, we can perhaps spend less time worrying about security (our current practices are NOT WORKING, by the way) and start worrying about more important things!

(Yes, it's true that the sshd problem is just dumb coding and is not C's fault. However, most of the rest of this year's, and last year's big security holes come from buffer overflows. Viz: Code Red worm, BIND exploits, wu_ftpd exploits, etc...)

If you specifically check out The great language shootout you will see that in most cases Python does come out ahead of Ruby not by a huge amount but ahead, and in many cases ahead of Perl as well.

Check out this link for what might be some interesting benchmarks. Ruby seems to do quite well against Perl and Python (and in some cases better), but in other cases it is downright awful (look at the recursion problems). Ruby is not as mature as Perl or Python, so there are definitely some places where it could be optimized better.

One thing you may want to consider is that Ruby has many different ways of doing loops; some of them open a new scope (which takes time), and others just iterate in the current scope. So where you may have:

• j = 0
• 
  1..1000000.each do |i|
  j = j + 1
  end
  

You may want to rewrite as:

• j = 0
• 
  for i in 1..1000000 do
  j = j + 1
  end
  

or even:

• j = 0
• 
  1000000.times do
  j = j.succ # faster than j = j + 1
  end
  

Or why not learn Caml? It's fast! Yay.

I highly recommend this page. The results aren't conclusive, but it's interesting nonetheless The Great Computer Language Shootout. They have ALOT of languages benchmarked.

-----
"Goose... Geese... Moose... MOOSE!?!?!"

As long as we are posting language performance comparison sites, The Great Computer Language Shootout should be mentioned. You can specify your own weightings for the various tests in the shootout, and the page's author is always looking for ways to improve his tests.

I picked up Lua after reading this article about it in Dr. Dobb's Journal for use in Grim Fandango. (It has since advanced and yet simplified in tremendous ways... The article is about version 2.5, and it's now at version 4.0.) In addition to being a beautifully simple yet expressive language, Lua also has one of the cleanest codebases I've had the fortune to hack around in. The compiler/interpreter are all easily navigable... Comments are sparse, but well-placed and thoughtful; there need not be more because most of the code clearly explains itself. It's all written in straight ANSI C, and is instantly portable to just about everywhere without even any configuration macros. It's extensible in clean, logical ways... and oh yeah, it's BLAZINGLY FAST.