Language wars

Posted Nov 17, 2009 18:16 UTC (Tue) by keithp (subscriber, #5140)
In reply to: The notmuch mail client by epa
Parent article: The notmuch mail client

The big performance issue is in adding new messages to the database; Xapian isn't terribly zippy, but I was able to average about 80 messages/sec for 700000 messages using notmuch while sup managed only about 20; profiling showed that most of that delay was in running the ruby message parsing code.

The Ruby UI is also sluggish when presented with a long list of messages or a large message to display; sitting there for seconds much of the time.

For me, it was the Apple Newton that demonstrated why I never want to write any 'mission critical' applications in an interpretive language. The Newton shipped with most of the applications running in an interpreter. I'm sure it was easier to develop them as a result, but the end product was mocked in large part due to poor performance.

My other complaint about Ruby/python/perl/misc is fairly simple -- I expect the computer to detect and complain about my programming errors as soon as possible. Static typing errors can be detected during compilation and need not wait until execution time. Any language which passes the burden of this mechanical process on to the programmer is one where programs will have numerous latent bugs, and sup is no exception -- it crashed many times each day with various type errors. Yes, I know, dynamic typing is all the rage; I guess I'm just old fashioned.

In any case, I program in a lot of different languages as I believe that one should choose the tool appropriate to the job at hand. It may be that sup was best written in Ruby, I don't frankly know as notmuch is *not* a sup clone -- the bulk of sup is the UI, which is really quite good and notmuch tries to present a clone of that through emacs while re-implementing the Xapian glue code in a much faster (and type safe) language.

Language wars

Posted Nov 17, 2009 22:06 UTC (Tue) by epa (subscriber, #39769) [Link] (1 responses)

Thanks for the explanation. I agree with your point about dynamically typed languages; I would also like the compiler to do more work for me, and I enjoy hacking things in languages like Haskell (and occasionally C# or even C++) and getting that solid 'clunk' sound when all the code compiles successfully into an object file with no possibility of runtime type errors. And yet my preferred language for hacking something up in a hurry remains perl.

Language wars

Posted Nov 24, 2009 20:35 UTC (Tue) by Baylink (guest, #755) [Link]

I call your attention to the Go! wars, in another thread.

Language wars

Posted Nov 17, 2009 22:34 UTC (Tue) by NAR (subscriber, #1313) [Link] (1 responses)

I expect the computer to detect and complain about my programming errors as soon as possible. Static typing errors can be detected during compilation and need not wait until execution time.

Don't forget that you have to execute the code anyway to test it. Now the real question is that which is faster: compile (and compile and compile...) C/C++/Java source and execute, or compile a perl/python/ruby/erlang/etc. source, execute, compile, execute, etc. It depends on the problem domain, but the later could be faster in the long run.

Type errors are probably found earlier with C (although the automatic numeric conversions could be tricky), but program logic errors might be found later. I work with a dynamically typed language and sometimes miss the compiler help with types - but certainly don't miss the "type make, then go for a coffee" days of C++ programming.

And I haven't even mentioned buffer overflows plaguing C programs since forever, where the compiler won't help much.

Smoke test

Posted Nov 18, 2009 21:49 UTC (Wed) by man_ls (guest, #15091) [Link]

To get the best of both worlds you just run an integrated test suite instead of or in addition to compiling. This way you can catch both type errors and other functional errors. It's not that hard to do, really, and it often takes less than compiling a lot of code. Just be sure to make it run real fast.

Interpreted and compiled languages

Posted Nov 18, 2009 8:47 UTC (Wed) by mjthayer (guest, #39183) [Link] (1 responses)

> My other complaint about Ruby/python/perl/misc is fairly simple -- I expect the computer to detect and complain about my programming errors as soon as possible. Static typing errors can be detected during compilation and need not wait until execution time.

This is probably a really silly thought, but more often than not, Python code is compiled (into pycode, but still compiled). Sometimes on the fly, usually in advance for distributed packages. I can picture Python scripts containing additional type information for variables, perhaps as specially formatted comments or docstrings, and the compiler printing warnings at compile time, lint-style, when something looked fishy - perhaps not for on-the-fly compiles, but only for advance compiles, or then again perhaps for all.

I don't know if Python has any other special issues (apart from the white space thing and the global namespace).

Interpreted and compiled languages

Posted Nov 22, 2009 23:56 UTC (Sun) by rwmj (subscriber, #5474) [Link]

Python is a really poor example. It's slow and uses loads of memory.

Look at a real, static, compiled language with type inference. The current leaders in this area are all
functional languages. FWIW I started writing something similar to notmuch/sup in OCaml (a few
months ago, and without knowing about sup -- I'll probably abandon it for something better
supported now like notmuch).

Rich.