Assume some-other-language is 10x faster than Ruby.
If a project implemented via some-other-language
requires 5 dedicated systems @ $2,000/each
($10,000 total), then Ruby requires 50 dedicated
systems and $100,000 worth of equipment to accomplish
the same task.
Now assume a Ruby programmer is 3 times more efficient
than some-other programmer and assume a programmer salary of
$80,000/year (including overhead). And assume that the
programming task will take three man-years to develop
in some-other-language.
So this hypothetical project implemented via Ruby costs:
$80,000 in labor and $100,000 in equipment for $180,000.
The same project implemented in some-other-language costs
$240,000 for labor and $10,000 in equipment for $250,000 total.
So Ruby is 10 times slower than some-other-language but
you've got $70,000 more in your pocket when your done.
So Ruby is 10 times slower than some-other-language but
you've got $70,000 more in your pocket when your done.
Moral: Hardware is cheap, people aren't.
You forgot the cost of maintaining 50 dedicated systems also energy
resources and other things. Also it is not sure that it scales well
- easy for web applications but maybe difficult to impossible for other
application domains.
Moral: We need a faster language implementation.
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
You forgot a _lot_ of costs - network (switches, cabling, punch downs),
racks, colocation space, power, air conditioning, etc.
And programming is largely an initial cost, whereas administration,
monitoring and maintenance are on going concerns.
···
On Wed, 2005-06-22 at 12:06 +0900, gwtmp01@mac.com wrote:
Assume some-other-language is 10x faster than Ruby.
If a project implemented via some-other-language
requires 5 dedicated systems @ $2,000/each
($10,000 total), then Ruby requires 50 dedicated
systems and $100,000 worth of equipment to accomplish
the same task.
Now assume a Ruby programmer is 3 times more efficient
than some-other programmer and assume a programmer salary of
$80,000/year (including overhead). And assume that the
programming task will take three man-years to develop
in some-other-language.
So this hypothetical project implemented via Ruby costs:
$80,000 in labor and $100,000 in equipment for $180,000.
The same project implemented in some-other-language costs
$240,000 for labor and $10,000 in equipment for $250,000 total.
So Ruby is 10 times slower than some-other-language but
you've got $70,000 more in your pocket when your done.
Or moral: Every language has its own application domain.
Kent.
···
On 6/22/05, Lothar Scholz <mailinglists@scriptolutions.com> wrote:
Hello gwtmp01,
> So Ruby is 10 times slower than some-other-language but
> you've got $70,000 more in your pocket when your done.
> Moral: Hardware is cheap, people aren't.
You forgot the cost of maintaining 50 dedicated systems also energy
resources and other things. Also it is not sure that it scales well
- easy for web applications but maybe difficult to impossible for other
application domains.
Moral: We need a faster language implementation.
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
savings)
B: For applications that really need speed, code the critical
parts in C and use Ruby to control it all (i.e. more savings)
C: $2000/headless system is pretty generous.
D: My Ruby employees are happier than the other-language employees.
E: I probably have the application finished sooner which opens
up more opportunities (time is money).
F: Once you've figured out how to maintain 5 systems efficiently, you've
solved the hard part. The remaining 5, 10, or even 45 systems are
much cheaper to maintain per/unit.
G: I've still got $70,000 to spend on other things, even if you don't
like A, B, C, D, E, and F.
I tried to fudge the numbers in my example away from Ruby or for that
matter any language X being compared to language Y based on some perceived
run-time performance factor.
What I was trying to point out with my simplistic example is that
using a raw runtime performance metric to argue in favor of this language
or that language is naive when building a system in which language
performance is just one part of the cost consideration. Performance issues
can be addressed with hardware. Development time can only be addressed
with better people or better tools.
Of course any project needs to consider all these things including the things
that you mentioned. But assuming a priori that the ability to compute prime
numbers is the *critical* factor it just a waste of time.
And of course, I think better Ruby implementations would be a good thing.
Gary Wright
···
On Jun 22, 2005, at 12:33 AM, Lothar Scholz wrote:
> So Ruby is 10 times slower than some-other-language but
> you've got $70,000 more in your pocket when your done.
> Moral: Hardware is cheap, people aren't.
You forgot the cost of maintaining 50 dedicated systems also energy
resources and other things. Also it is not sure that it scales well
- easy for web applications but maybe difficult to impossible for other
application domains.
Moral: We need a faster language implementation.
A: I don't think Ruby is 10x slower for most applications (i.e more
You forgot a _lot_ of costs - network (switches, cabling, punch downs),
racks, colocation space, power, air conditioning, etc.
And programming is largely an initial cost, whereas administration,
monitoring and maintenance are on going concerns.
All good points.
You know with all this discussion of Ruby's performance problems as of
late, I wonder what people will find to complain about once those issues
are solved?
Hmmm: "Hi, I'm a software contractor who recently switched to Ruby, and it
is killing my profit margins. Previously when using Java it would take be
days to produce a solution that Ruby allows me to do in hours! Now I have
to find more clients and more jobs to get the same profits I had before.
What can be done about this?"
You forgot a _lot_ of costs - network (switches, cabling, punch downs),
racks, colocation space, power, air conditioning, etc.
...but a lot of those costs are one-time costs, or they scale well. It
does not cost 10x to administer 50 boxes vs 5 (unless they're Windows
boxes... *:o ).
And programming is largely an initial cost, whereas administration,
monitoring and maintenance are on going concerns.
Programming also includes upgrades and software maintenance, and the
time involved with those. The simpler language platform will cost less
to do this than the more complex language platform.
···
On 6/22/05, Matthew Berg <galt@gothpoodle.com> wrote:
If you're doing more work in less time, your rates should go up, no?
···
On 6/22/05, Ryan Leavengood <mrcode@netrox.net> wrote:
Matthew Berg said:
>
> You forgot a _lot_ of costs - network (switches, cabling, punch downs),
> racks, colocation space, power, air conditioning, etc.
>
> And programming is largely an initial cost, whereas administration,
> monitoring and maintenance are on going concerns.
All good points.
You know with all this discussion of Ruby's performance problems as of
late, I wonder what people will find to complain about once those issues
are solved?
Hmmm: "Hi, I'm a software contractor who recently switched to Ruby, and it
is killing my profit margins. Previously when using Java it would take be
days to produce a solution that Ruby allows me to do in hours! Now I have
to find more clients and more jobs to get the same profits I had before.
What can be done about this?"
<snip>
> You forgot a _lot_ of costs - network (switches, cabling, punch downs),
> racks, colocation space, power, air conditioning, etc.
...but a lot of those costs are one-time costs, or they scale well. It
does not cost 10x to administer 50 boxes vs 5 (unless they're Windows
boxes... *:o ).
Power, cooling, and leased space are a huge cost. Especially if you
want an kind of reliability; i.e. conditioned power (preferably multiple
battery backed circuits) and redundant cooling systems.
And I never said administration was 10x higher. I don't quantify
that sort of thing without knowing the specifics of the deployment.
When we're talking about _that_ much of a discrepancy in hardware
requirements, though, the requirements are almost certainly going to be
significant. Five machines may be enough for an existing administrator
to absorb, whereas fifty new machines is likely to require additional
staffing.
(Personally, I think both the 10x and 3x are both somewhat exaggerated
from what you'd see in the real world, anyways.
Programming also includes upgrades and software maintenance, and the
time involved with those. The simpler language platform will cost less
to do this than the more complex language platform.
Oh, certainly. This would also be variable from project to project, of
course. It seems like a lot of developers subscribe to the idea that
"hardware is cheap" without really understanding the costs involved.
···
On Thu, 2005-06-23 at 02:04 +0900, Corey Lawson wrote:
On 6/22/05, Matthew Berg <galt@gothpoodle.com> wrote:
If you're doing more work in less time, your rates should go up, no?
True, but try explaining to a client that your rate is higher than Jimmy
the Java Contractor because you are smart and use Ruby. So your better off
just using the extra time solving more customer problems.
Ryan
P.S. I'm not yet a Ruby contractor or consultant (but am seriously
considering it), so I may be completely off-base here. But it makes sense
logically. I'm sure some of the real Ruby contractors out there can shed
some more light on this.
Joe Van Dyk said:
>
> If you're doing more work in less time, your rates should go up, no?
True, but try explaining to a client that your rate is higher than Jimmy
the Java Contractor because you are smart and use Ruby. So your better off
just using the extra time solving more customer problems.
Say that you get stuff done three times faster than Jimmy the Java
Contractor.
···
On 6/22/05, Ryan Leavengood <mrcode@netrox.net> wrote:
Ryan
P.S. I'm not yet a Ruby contractor or consultant (but am seriously
considering it), so I may be completely off-base here. But it makes sense
logically. I'm sure some of the real Ruby contractors out there can shed
some more light on this.
If you're doing more work in less time, your rates should go up, no?
True, but try explaining to a client that your rate is higher than Jimmy
the Java Contractor because you are smart and use Ruby. So your better off
just using the extra time solving more customer problems.
Ryan
P.S. I'm not yet a Ruby contractor or consultant (but am seriously
considering it), so I may be completely off-base here. But it makes sense
logically. I'm sure some of the real Ruby contractors out there can shed
some more light on this.
If you charge for the solution, not the hour, the comparison is stark, and in your favour. (And the taxman can't argue your an employee).
Regards
Ian
···
In message <44808.206.157.248.34.1119459597.squirrel@www.netrox.net>, Ryan Leavengood <mrcode@netrox.net> writes
--
Ian - posting to a Newsgroup. Please remove everything to reply.
