I'm new to this newsgroup, having come here from many years with 
another scripting language (Tcl/Tk; in fact in about 2hrs I'll be on  my 
way to  New Orleans for Tcl 2007).  I'm going to spout a slightly 
different belief than most of the respondents.

There are cases where speed is almost completely irrelevant.
What is important is completion of a functioning application that
satisfies the customer (internal or external).  For many many 
applications this can be done, on modern computers without any
attention to the speed of the application.  If my program takes
100ms to execute and yours takes 1usec, I contend that most users
will not notice, or care about the difference.

I also contend that while there >are< cases where performance is
important (much of my work is doing soft real-time data taking systems
for a national nuclear physics research lab... performance for the
data taking parts of those systems is critical), for a great deal of 
software it is not.  For responsiveness to a GUI element, you can pretty
well work in the 100-500ms range of performance...for all but 
graphically intensive games where you have to get down to about 16ms. 
Whatever language works in that performance range for your application 
is suitable.

So what I would say is rather closed minded is the statement:

 > I prefer to be agnostic about programming languages.  I choose those
 > that perform the best and I ignore the rest.

If that's true, start learning assembly.  That's going to give you the
absolute best performance...for a specific machine.  And that points to
the real issues.  For me, choosing a programming language is
a set of engineering compromises. The compromises are usually a result
of the dynamic tension between the need to hit specific performance 
goals, the portability of software written in the language, the 
expressive power of the language in the problem domain in which I'm 
working, and the availability of mature, low defect libraries in the
problem domain in which I'm working.  What drove me to Ruby, for 
example, is a new project to do laboratory administrative data 
processing that requires us to show a specification of the underlying 
business process and demonstrate that the code faithfully executes it, 
and the existence of John Metraux's OpenWfeRu and the densha example of 
how to host it on rails, as a tool to solve this problem....and about 
2-3 weeks evaluating this tool for suitability as a partial solution to 
this problem.

I _am_ programming language agnostic.  As such I write and have written
in Assembler, Forth, Fortran, C, C++, Tcl/Tk, Ruby, Perl, Python, 
Pascal.. I've even developed application specific languages and then 
used them.  None of these languages is a silver bullet.  Each has 
advantages and disadvantages, and the wise programmer will weigh them 
carefully when selecting which ones to use to solve any given problem.

Ron Fox
National Superconducting Cyclotron Lab
Michigan State University
East Lansing, MI 48824-1321


Ruby Maniac wrote:
> I welcome any corrections anyone might be able to make since I am new
> to Ruby with less than 3 months experience under my belt.
> 
> Ruby 1.8.6 is an interpreted langauge that does not have a byte-code
> driven VM at this time.
> 
> Python 2.5.1 is an interpreted language that does have a byte-code
> driven VM.
> 
> I have been able to make Ruby code run 5% faster or more simply by
> removing nothing but comments - the more comments I remove the faster
> the code runs up to no more than 6% or 7%.
> 
> Ruby syntax seems to favor the notion that fewer characters is better
> than more characters.  Lexically interpreted langauges would want this
> to be the case since it takes more effort to lex more characters.
> 
> Python runtimes are not affected by the number of characters one uses
> such as extra whitespace or comments - removing comments does not make
> Python code run faster simply because the comments have been removed.
> 
> Python has a very powerful JIT (Just In Time compiler) known as Psyco
> with which certain Python expressions such as LC (List Comprehensions)
> and others can be made to run 20x to 100x faster at runtime.
> 
> Recently as a test I wrote a rather simple Python program that
> processed all characters of a 20 MB file by setting the MSB to 1. The
> original Python code I began with executed in 65 seconds before I
> began to optimize the code.  After the code was fully optimized it ran
> in just under 3 secs. After Psyco was used the runtime for the same
> problem was less than 1 second.
> 
> The Ruby code I wrote before any optimizations were applied ran in
> about 65 seconds or no faster than Python with no optimizations.  The
> most optimized Ruby code I could find for this problem was able to
> execute in just under 22 seconds using techniques that were not
> necessary when optimizing the Python code.
> 
> Given the best Ruby is capable of doing versus the best Python is
> capable of doing Ruby ends up being more than 20x slower than Python
> and I think I know why.
> 
> It is just not possible to make Ruby 1.8.6 execute any faster than the
> Ruby interpreter is capable of executing the code due to the lack of a
> byte-code driven VM.  Maybe someday YARV will make Ruby code run 2x
> faster than Ruby 1.8.6 but that day has not arrived yet and may never
> arrived.
> 
> Even if YARV proves to be 2x faster than Ruby 1.8.6 the resulting Ruby
> code will still be 10x slower than the fastest Python code.
> 
> The only way YARV will get faster than Python is whenever someone
> codes a JIT compiler for YARV that provides the same performance boost
> to Ruby that Psyco provides to Python.  As far as I can tell nobody is
> working on any such JIT for YARV and since YARV has been under
> development for at least the last 14 to 18 months one can only surmise
> a JIT for YARV would take a significant amount of time to produce and
> release to the Ruby community.
> 
> The bottom line is that Python can be made to run as fast as machine
> code but Ruby cannot.
> 
> I know some people want to try to use Ruby for every single problem
> they are faced with but doing so would be less than wise since there
> are no tools that work for all problems.
> 
> Some problems lend themselves nicely to Ruby such as Open Source
> products where giving away the source code is not a business
> problem.
> 
> Python is useful for problems that require fast runtimes such as 3D
> modelling or video game programming.
> 
> Ruby would not be fast enough for the kinds of problems where people
> are using Python.
> 
> I have not been able to find any references to Ruby being used for 3D
> realtime video game programming but I have been able to find many
> references to Python being used for 3D realtime video game
> programming.
> 
> I don't expect those who read this to applaud my efforts to discuss
> this in this forum however I feel we need to discuss this so that some
> may choose to take actions to make Ruby run faster at runtime just as
> work was done to make Python run faster at runtime.
> 
> Believe it or not I actually like Ruby 1.8.6 but I would hesitate to
> try to use Ruby for situations where runtime performance was an issue
> or whenever I did not want to release the source code.
> 
> When I write code I want to know I am using tools that give me the
> best performance for the effort that I can possibly get as opposed to
> tools that guarantee no matter how hard I work performance will always
> be lacking.
> 
> The same comments could be made about Rails.  Rails emits SQL
> statements that have a lot of "*" characters.  Those of us who have
> been coding SQL long enough know the use of "*" characters makes SQL
> statements run slower than when fully qualified column names are used
> rather than the "*".  I coded a simple benchmark that demonstrated
> this very clearly; whenever "*" was used rather than a list of column
> names the resulting SQL statements ran 10% to 880% slower than when
> the "*" was replaced with a list of column names even when the list of
> column names was quite long.
> 
> Oddly enough I quite easily found more powerful Database Frameworks
> for Python that did not emit SQL code that used "*" characters and I
> was even able to find some interfaces for those SQL Frameworks that
> would allow seasonsed Rails developers use Rails statements when
> describing their database relationships.
> 
> I know of some Ruby developers who rejected the idea that the use of
> "*" in SQL statements would be slower than long lists of column
> names.  From the perspective of a Ruby on Rails developer who has not
> coded anything but Rails or Ruby it might seem logical that fewer
> characters is better than more characters and so the use of "*" in SQL
> statements must be optimial because this is how Ruby works, right ?!?
> Wrong !
> 
> Even when some RoR developers are faced with benchmarks that
> demonstrate the use of "*" in SQL statements can be 10% to 880% slower
> than not using "*" characters they still chose to reject the
> benchmarks and deny the benefits of not using Rails because Rails is
> not able to automatically replace "*" with lists of column names,
> apparently.
> 
> When people choose to make their choices of languages a religious
> issue they can become rather short-sighted in how they choose to
> resolve programming problems.
> 
> I prefer to be agnostic about programming languages.  I choose those
> that perform the best and I ignore the rest.
> 
> Ruby is a cute language that may someday become useful but this won't
> happen unless the Ruby community becomes interested in making Ruby
> perform better at runtime.  In the meantime, I will use Ruby only when
> I must as for the rest I will most-likely use Python unless the
> problem suggests another language may be more useful.
>