Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
Interesting that this is mostly a rewrite of Sup in C (rather than Ruby),
except with no UI. I'd be quite amused if Sup just adopted notmuch as its
The notmuch mail client
Posted Nov 17, 2009 16:21 UTC (Tue) by epa (subscriber, #39769)
'waiting for ruby is not on my list of desired activities' is a reasonable sentiment, but they haven't shown any examples where sup is too slow; since the heavy lifting of search and database storage is done with C and C++ libraries, performance of the thin Ruby layer on top is unlikely to be a problem. So why the prejudice?
Posted Nov 17, 2009 16:39 UTC (Tue) by rfunk (subscriber, #4054)
But I mostly left C and its memory-management issues behind years ago, and
have preferred Ruby for the past few years, so I could be accused of my own
Posted Nov 17, 2009 18:16 UTC (Tue) by keithp (subscriber, #5140)
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.
Posted Nov 17, 2009 22:06 UTC (Tue) by epa (subscriber, #39769)
Posted Nov 24, 2009 20:35 UTC (Tue) by Baylink (subscriber, #755)
Posted Nov 17, 2009 22:34 UTC (Tue) by NAR (subscriber, #1313)
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.
Posted Nov 18, 2009 21:49 UTC (Wed) by man_ls (subscriber, #15091)
Interpreted and compiled languages
Posted Nov 18, 2009 8:47 UTC (Wed) by michaeljt (subscriber, #39183)
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).
Posted Nov 22, 2009 23:56 UTC (Sun) by rwmj (subscriber, #5474)
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).
Posted Nov 17, 2009 17:04 UTC (Tue) by tzafrir (subscriber, #11501)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds