On Mar 28, 10:12 pm, Mark R. [email protected] wrote:
[Note: parts of this message were removed to make it a legal post.]
It does seem a somewhat inflammatory statement to make on this list.
Clearly it is a completely subjective argument but i think if you want
incredible performance, C is a pretty good option
I disagree. It’s too low-level and laden with pointers.
Use Pascal (FreePascal).
mutahhir hayat wrote:
Also, a lot of the books written by a lot of the greats were done at the
time where the hardware was limited, and the common developer required
certain ninja skills to do what they wanted. Now, its a little different.
You just can’t expect the philosophy of driving a moped to apply to driving
a ferrari. I’m not saying that you should just write crappy code as you
like, but just that you need to write good solid “code” and worry about the
language when it gives you a problem. As knuth said, “premature optimization
is the key to all evil (or atleast most of it) in programming”.
First of all, I’m not at all sure whether it was Knuth, Dijkstra, Hoare
or Wirth that first coined this “proverb”. It sounds to me more like
Wirth than the other three. Second, as I’ve already posted, in no way
does that proverb, even if you happen to believe in it, justify lack of
attention to performance at any point in the software development cycle.
And as a working performance engineer, I think that proverb is simply
nonsense.
mutahhir hayat wrote:
I would
agree upon your considering performance in ever step of the cycle, however,
a more pragmatic approach is to fulfill the requirements,
Yes … as you state below, if a project is defined by requirements,
performance requirements should be specified. They fall under the
general heading of usability, and there are (and have been for decades)
rather well known rules of thumb.
but if you’re making a digital calculator
that will run on a quad core server with at most 10 people using it at one
time, I’d hardly recommend performance as a major concern, and would rather
just fulfill the requirements as fast and economically possible.
This seldom happens in the real world. Nobody can create a significant
software project in total absence of any feedback from users or the
market.
First of all, I’m not at all sure whether it was Knuth, Dijkstra, Hoare
or Wirth that first coined this “proverb”. It sounds to me more like
Wirth than the other three.
Hoare is usually attributed to saying that first, and Knuth popularized
it,
in anycase, its irrelevant to the discussion.
Second, as I’ve already posted, in no way
does that proverb, even if you happen to believe in it, justify lack of
attention to performance at any point in the software development cycle.
And as a working performance engineer, I think that proverb is simply
nonsense.
That proverb does not relate to performance, although many relate that
to
mean “no need for optimization”. The operative word is “premature”. I
would
agree upon your considering performance in ever step of the cycle,
however,
a more pragmatic approach is to fulfill the requirements, if performance
is
one of them, sure, by all means, but if you’re making a digital
calculator
that will run on a quad core server with atmost 10 people using it at
one
time, I’d hardly recommend performance as a major concern, and would
rather
just fulfill the requirements as fast and economically possible. I don’t
mean to trivialize the matter by giving such a simple example, but any
design principle that is valid universally should fit in every case. And
in
my opinion, performance is a requirement, and should be treated as such,
no
more no less.
Yes … as you state below, if a project is defined by requirements,
performance requirements should be specified. They fall under the
general heading of usability, and there are (and have been for decades)
rather well known rules of thumb.
Are you saying that there are projects that have no requirements? 
I’m
sure that you don’t mean that, so please elaborate.
market.
Agreed, but please take the example in the context it was presented, and
that was that performance is nothing more than just “A” requirement.
There
are times, when it pays to consider it, other times, you just waste your
time and money after something that won’t even be apparent. Hence no
value
for time spent.
Eleanor McHugh wrote:
Many projects have requirements which are only loosely identified at the
time of inception, but one that tends to be there from the very
beginning is “should perform acceptably for users”. Ignore that
requirement at your peril
Actually, there are implicit performance requirements based on decades
of usability theory. The “prime directive”, as it were, is this:
Define “response time” as the time it takes from the moment that a
user sends a request to the moment when the system has returned its
response. There are application-dependent definitions as to when the
response is “complete”, but these are usually obvious from other UI
factors.
The ideal case is that the response time is under one second!
Anything over 10 seconds requires that the application notify the user
that it is busy. Between 1 and 10 seconds is kind of a “gray area”, but
in general, times over 1 second interrupt a user’s flow process and
should be avoided.
Users of a business application need faster response times than what
we consumers typically “tolerate” from web applications. For example, go
to your on-line credit card payment center and time how long it takes
from when you hit the “submit” button to when you get your confirmation
number back. It might be 10 seconds – in the “good old days” I remember
seeing times of about a minute. Times like that are “tolerable” for
someone who makes a payment once a month. But someone in a business
posting data will need that response in under a second.
On 30 Mar 2008, at 07:42, mutahhir hayat wrote:
Yes … as you state below, if a project is defined by requirements,
performance requirements should be specified. They fall under the
general heading of usability, and there are (and have been for
decades)
rather well known rules of thumb.Are you saying that there are projects that have no requirements?
I’m
sure that you don’t mean that, so please elaborate.
Many projects have requirements which are only loosely identified at
the time of inception, but one that tends to be there from the very
beginning is “should perform acceptably for users”. Ignore that
requirement at your peril 
Ellie
raise ArgumentError unless @reality.responds_to? :reason
On 30 Mar 2008, at 21:21, M. Edward (Ed) Borasky wrote:
Eleanor McHugh wrote:
Many projects have requirements which are only loosely identified
at the time of inception, but one that tends to be there from the
very beginning is “should perform acceptably for users”. Ignore
that requirement at your perilActually, there are implicit performance requirements based on
decades of usability theory.
I remember sitting through lectures on this stuff twenty years ago as
part of a control engineering course at uni and it’s stood me in good
stead over the years: in fact when I was writing interactive cockpit
systems the one second maximum response time requirement became so
ingrained that it’s now second nature.
Obviously with the web network latencies can make it difficult to
display meaningful state updates on that kind of time-scale, but it
still bugs me how many AJAX apps stall on large data transfers when
the interface could be doing something to keep users engaged. It’s a
good thing for most of these systems that user expectations are so
low…
Ellie
raise ArgumentError unless @reality.responds_to? :reason
On Sun, 30 Mar 2008 04:18:21 +0900, M. Edward (Ed) Borasky wrote:
In fact, Dijkstra, in A Discipline of Programming, explicitly calls
out that one must pay attention to the twin concerns of correctness and
efficiency. And, while the hardware is orders of magnitudes faster and
cheaper than it was when Dijkstra wrote that, throwing hardware at an
inefficient design is still not economically viable in the long run and
probably never will be.
This ignore’s Moore’s Law, and Java’s success. Microsoft as well is
going the VM route – which has inherent overhead.
-Thufir
I agree these discussions are moot.
Hopefully the one who started it will reply, so far it looks
suspiciously as if it only served 7stud as further opportunity for
writing some more anti-ruby propaganda.
The biggest problem here is that for any application where one chooses
Python for SPEED it is hardly a convincing issue at hand. I dare claim
that ruby fits EXACTLY the same niche in the ecosystem. Look at
Javascript - it is not a great language, but it had a huge growth -
simply because the www grew and Javascript was ubiquitous.
It never ceases to amaze me how people put speed of “scripting”
languages into the center of attraction - one should go with lua if
speed is such a concern.
Or maybe pure C if it needs to be faster!
On Sat, 29 Mar 2008 13:03:48 +0900, James G. wrote:
- It’s generally pretty easy to optimize the 10% of the code where speed
is actually critical, even if you need to drop down to something like C
for just that part
that’s an interesting point.
-Thufir
On Apr 1, 5:39 pm, Marc H. [email protected] wrote:
It never ceases to amaze me how people put speed of “scripting”
languages into the center of attraction - one should go with lua if
speed is such a concern.Or maybe pure C if it needs to be faster!
Pascal (FreePascal).
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
Bugger that!
You gotta encode using boards of switches… pure binary man… none
of this assembler junk. 
Julian.
Learn Ruby on Rails! CHECK OUT THE FREE VIDS (LIMITED TIME) NEW VIDEO
(#2) OUT 3rd APRIL
http://sensei.zenunit.com/
On 2 Apr 2008, at 08:25, Julian L. wrote:
Bugger that!
You gotta encode using boards of switches… pure binary man… none
of this assembler junk.
You are a Real Programmer and I claim my £5
Ellie
raise ArgumentError unless @reality.responds_to? :reason
On Sat, Mar 29, 2008 at 9:18 PM, M. Edward (Ed) Borasky
[email protected] wrote:
In fact, Dijkstra, in A Discipline of Programming, explicitly calls out
that one must pay attention to the twin concerns of correctness and
efficiency. And, while the hardware is orders of magnitudes faster and
cheaper than it was when Dijkstra wrote that, throwing hardware at an
inefficient design is still not economically viable in the long run and
probably never will be.
In my experience, this varies with the domain.
For the business apps I presently work on, I often do things that are
10x to 100x slower than they could be - because the hardware power
required to run them is so much cheaper than my time would be, and I
still get response times that are within my requirements. I presently
run the stuff we have over a distributed cluster of about 10 machines.
This could almost certainly have been reduced to two and possibly one
For games and embedded systems development which I’ve done before, the
millions units that’s produced has often made computer time much more
expensive than my programmer time, so optimizing made a lot of sense -
even at the cycle by cycle level.
You write that you’re a performance engineer by profession; in that
profession, you’ll mostly encounter the cases where performance IS an
issue, as nobody that has acceptable performance will throw a
performance engineer at the case. So, your sample will be skewed,
even though you’ll have hit a lot more performance cases than I have.
Eivind.
On Mar 28, 9:40 pm, “M. Edward (Ed) Borasky” [email protected]
wrote:
Well … I beg to differ. If you actually read Beautiful Code, you
will see beautiful code in many languages … even Fortran, IIRC.
The most beautiful piece of code, well…, it’s a tie – the two most
beautiful pieces of code I ever saw were both in assembly language.
The first, written in Univac 1108 assembler, performed a tree-
traversal over an AVL tree. It was astoundingly compact and
efficient.
The second, written in PDP-11 assembler, implemented a pattern-
matching algorithm that predated grep and regexps by several years
which was used to translate English text into IPA phonemes, then
translate IPA phonemes into Votrax phonemes, then translate Votrax
phonemes into ASCII codes. The same code with three different tables
of patterns. Efficient and beautiful.
A close third was a one-liner in APL that inserted a new item into a
doubly-linked list of them.
But, to bring this post on topic, I have to agree with some of the
others on this list that programming in Ruby makes me feel serenely
calm, and sometimes, happy. I find programming in ruby natural and
easy, once I made the jump over to the “everything is an object”
camp. This feeling exceeds any similar feelings that may
occasionally, and less frequently, occur when I program in sh, SQL,
Perl, or Python.
I like Python too, having written many thousands of lines of code in
it. Closures are very cool - I use them all the time. The lack of
explicit control structures is pretty, but the syntax causes
occasional problems with long expressions that require continuations.
And, I still have to think a little bit when I do simple operations,
like joining an array. Python got it backwards. The join method
should have been an Array method, not a String method. The object to
the join method should have been the array, not the delimiter.
Ruby got this right: join is an Array method, split is a String
method. Ruby should have had a closure expression, and kind of does
if you consider Array::map {}
The only problem I have with Ruby is the comparable difficulty of
finding and reading documentation from installed libraries. I have
been a Perl programmer since version 1 and think Larry made the Right
Choice when he integrated the Perl pods into the Unix “man” page
infrastructure.
How hard would it have been for Ruby and gem to publish their docs
into the “man” pages? This would have been the most Unix-compatible
way of sharing docs.
On Wed, Apr 2, 2008 at 1:23 AM, thufir [email protected] wrote:
This ignore’s Moore’s Law, and Java’s success. Microsoft as well is
going the VM route – which has inherent overhead.
This is not entirely obvious. I remember one case where HP got a
significant performance increase by emulating PA RISC on PA RISC
hardware, because they could do branch prediction etc better in real
time - with real data - than at compile time.
Eivind.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs