No kidding. For one thing, while it's possible that in some
pathological edge-case it might require five LAMRoR servers to equate
one WS2k3 .NET server, the level of system resources required just to
run each individual server is rather greater for WS2k3/IIS systems than
for Linux/Apache systems. Additionally, there are more options
available for scaling up with Linux than Windows solutions -- better
load balancing, effective clustering, et cetera (Microsoft promised a
clustering version of Windows last year -- the result being that once
they achieved something testworthy, nobody bothered to use it except for
academic demonstration purposes because, of course, the cost of
licensing would be far greater than any return on investment, especially
considering the artificial technical limitations imposed because of the
MS business model).
There's a sweet spot for vertically integrated Microsoft solutions. If
you stay inside that sweet spot, it's cheaper to use a .NET solution
than certain other solutions. Your project, whatever it may be, may or
may not lose to .NET inside that sweet spot -- in fact, I'll go so far
as to say that .NET is almost certainly a net (ha ha) win. The term
"scalability", however, refers to the mobility of the economics of your
solution, and in that sense one of the standard Linux-based solutions
will probably scale better.
···
On Tue, Sep 12, 2006 at 11:30:59AM +0900, Carl Lerche wrote:
Also, yes, there are some extreme cases... such as the google search
engine. However, scaling is not linear. Hypothetically, IF at a
certain point a .NET web-application takes 5 servers and a similar
ruby web-application takes 25 servers (this already sounds a bit
ridiculous, but allow me to continue...). This does NOT mean that
when this .NET application requires 50 servers to run that the
similar ruby web-app will require 250.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The measure on a man's real character is what he would do
if he knew he would never be found out." - Thomas McCauley
More generally, the economic bottleneck tends to be skilled personnel --
sysadmins, developers, et cetera. That's why increased productivity
(from tools like Ruby, Python, Perl, Lisp, et cetera) and decreased
administrative overhead (from platforms like Linux, Solaris, et cetera)
are so important. There is, however, a point of diminishing returns,
which is where technologies like .NET, J2EE, and so on are valuable.
···
On Tue, Sep 12, 2006 at 12:43:37PM +0900, Marc Heiler wrote:
The same what can be said about Ruby here can also be said about
Python, even if Python would be a tiny bit faster. However I feel
that Python - with all its quirks - is "more advanced" in terms of
being used or accepted in companies.
The world isn't a monoculture, different qualities (of technologies)
can coexist for a long time.
The bottleneck for the money part still seems to be the
sysadmin no matter which language or? =)
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts." - Paul Graham
can we avoid Python vs. Ruby in this argument... please?
I don't think that arguments about this are helpful. A fine
pythonista will do better in python than in ruby, and likely, vice
versa.
···
On 9/11/06, Marc Heiler <shevegen@linuxmail.org> wrote:
The same what can be said about Ruby here can also be said about
Python, even if Python would be a tiny bit faster. However I feel
that Python - with all its quirks - is "more advanced" in terms of
being used or accepted in companies.
I accept that those scripts will definitely depend on CPU. Those
aren't the types of scripts I envision as "sysadmin scripts", though.
In my brain (which could easily be wrong, since I've never been a
sysadmin), programs consume resources and the sysadmin -- and his
scripts -- are meant to manage the resources so that they *can* be
consumed by other programs.
Jacob Fugal
···
On 9/12/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
On Tue, 12 Sep 2006, Jacob Fugal wrote:
> As others have mentioned, the scripts used by sysadmins aren't really
> CPU intensive nor too dependent on the host language speed. So it's a
> moot point.
i wouldn't agree with that. we just started a trio of ruby scripts running
across three machines which coordinated processing of 30 satellite years of
data. they are going to peg the machines near 50% for 3-5 months. it may not
be common but, where huge data sets are involved, something as trivial as
'unpacking and moving some data' may take a considerable amount of logic and
cpu.
On 9/12/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
On 9/12/06, Jacob Fugal <lukfugl@gmail.com> wrote:
> My purpose was never to propose that certain values of X or Y are
> correct, but rather to provide a framework equation inside which
> different values of X and Y can be examined.
This is interesting as far as it goes, but the challenge I have with
it is that I'm not sure the things you propose to measure are
necessarily that important in the economics of many projects (and
"economics" appears in your thread title).
We programmers tend to fantasize that what we do is the most important
part of any effort that involves software development but in many
organizations that's far from true. In particular I would guess that
there is more sensitivity to machine requirements since they tend to
involve capex and often represent a variable cost component in any
project. You may find this bizarre, but many companies view
programmers as human resources, which carry a wide range of
incremental costs going far beyond their variable contributions to any
particular project. If you make the commitment to hire a person as an
employee, it's very difficult for a whole range of reasons to let the
person go. From that point of view, a programmer is a lot like a fixed
cost. Their availability may constrain the number of projects you
attempt but not necessarily their direct cost, as it impacts your
choice of development platform. Outsourcing or using consultants
changes this calculus, but you still have to provision maintenance and
support programmers.
I would guess (though I have no data to back this up) that Ruby finds
far more acceptance in projects where the developers themselves are
the ones making the financial (or time) commitment. Under those
circumstances it's a no-brainer to use a development system that 1)
you dearly love, and 2) you are convinced will save you a lot of time,
and 3) you're convinced will let you get the job done with fewer
people. Many people who fund corporate projects couldn't care less
about 1), and think that 2) and 3) are mutually exclusive.
These people, who think 2 and 3 are mutually exclusive, have clearly not
read Mythical Man-Month -- but they should. Actually, just reading a
thorough review, or perhaps even the back of the book, might suffice (if
these people are reasonable enough to absorb the information).
When programmers advocate practices that involve hiring fewer of them,
it's a good damned idea to listen.
···
On Tue, Sep 12, 2006 at 11:26:21PM +0900, Francis Cianfrocca wrote:
I would guess (though I have no data to back this up) that Ruby finds
far more acceptance in projects where the developers themselves are
the ones making the financial (or time) commitment. Under those
circumstances it's a no-brainer to use a development system that 1)
you dearly love, and 2) you are convinced will save you a lot of time,
and 3) you're convinced will let you get the job done with fewer
people. Many people who fund corporate projects couldn't care less
about 1), and think that 2) and 3) are mutually exclusive.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Brian K. Reid: "In computer science, we stand on each other's feet."
I don't see how Python is even relevant, except in saying "If so-and-so
works for Python, it should work for Ruby too, as they fill very similar
niches in the programming ecosystem," or something like that. They
differ, for purposes of this discussion, mainly in terms of popularity,
and that difference varies depending on the specific sub-niche you're
addressing. So . . . what exactly was the point of bringing it up in a
discussion of the economies of Rails vs. .NET in the enterprise (or
whatever)?
···
On Tue, Sep 12, 2006 at 01:33:20PM +0900, Gregory Brown wrote:
On 9/11/06, Marc Heiler <shevegen@linuxmail.org> wrote:
>The same what can be said about Ruby here can also be said about
>Python, even if Python would be a tiny bit faster. However I feel
>that Python - with all its quirks - is "more advanced" in terms of
>being used or accepted in companies.
can we avoid Python vs. Ruby in this argument... please?
I don't think that arguments about this are helpful. A fine
pythonista will do better in python than in ruby, and likely, vice
versa.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Ben Franklin: "As we enjoy great Advantages from the Inventions of
others we should be glad of an Opportunity to serve others by any
Invention of ours, and this we should do freely and generously."
. . . or, put another way, sysadmin scripts are for administration of
the system, and not for churning data sets from production operations.
As far as I'm concerned, if a "sysadmin script" is eating up significant
system resources during working hours, you've either mislabeled it when
you called it a "sysadmin script" or failed to do your job as a sysadmin
properly. As Jacob indicated, the job of the sysadmin and his/her
scripts is to manage resources, not consume them. The sysadmin scripts
should be pretty much invisible to the people whose work is meant to be
enabled by them.
···
On Tue, Sep 12, 2006 at 11:51:22PM +0900, Jacob Fugal wrote:
On 9/12/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
>On Tue, 12 Sep 2006, Jacob Fugal wrote:
>> As others have mentioned, the scripts used by sysadmins aren't really
>> CPU intensive nor too dependent on the host language speed. So it's a
>> moot point.
>
>i wouldn't agree with that. we just started a trio of ruby scripts running
>across three machines which coordinated processing of 30 satellite years of
>data. they are going to peg the machines near 50% for 3-5 months. it may
>not
>be common but, where huge data sets are involved, something as trivial as
>'unpacking and moving some data' may take a considerable amount of logic
>and
>cpu.
I accept that those scripts will definitely depend on CPU. Those
aren't the types of scripts I envision as "sysadmin scripts", though.
In my brain (which could easily be wrong, since I've never been a
sysadmin), programs consume resources and the sysadmin -- and his
scripts -- are meant to manage the resources so that they *can* be
consumed by other programs.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The measure on a man's real character is what he would do
if he knew he would never be found out." - Thomas McCauley
It's the darnedest thing. I know plenty of managers who have read
Brooks, and yet when the crunch comes they still pile on the
resources. But I realize you're talking about the design/specification
phase. But don't underestimate the power and importance that managers
get simply by having larger teams and bigger budgets. Saving money in
activities that are cost centers often makes a manager less
influential, not more so. And in turn, it makes the manager's manager
less influential. Ruby's productivity argument is not too likely to
have much impact in these shops.
···
On 9/12/06, Chad Perrin <perrin@apotheon.com> wrote:
> These people, who think 2 and 3 are mutually exclusive, have clearly not
read Mythical Man-Month -- but they should. Actually, just reading a
thorough review, or perhaps even the back of the book, might suffice (if
these people are reasonable enough to absorb the information).
...under my experience what is almost never considered are these
intangibles...
1.) Under Ruby your maintenance costs will be lower (if it's well
written Ruby)...and because of #1...Since a new systems is never perfect
modifications must be made....and this is where Ruby really shines...any
other language will produce an inertia to change that will continue to
make your system diverge from the users wants and the reality of what
your staff can absorb no matter what the current costs etc....NOBODY...
thinks about this...until the premature end of life of your shiney new
system....
Its is, but you have to come at it from a different angle. That manager doesn't reduce his budget, but they do get a lot more done.
Same budget, more useful work done => more kudos.
Stephen
···
In message <3a94cf510609121051g709ff1c0m45d8c948c68990d9@mail.gmail.com>, Francis Cianfrocca <garbagecat10@gmail.com> writes
get simply by having larger teams and bigger budgets. Saving money in
activities that are cost centers often makes a manager less
influential, not more so. And in turn, it makes the manager's manager
less influential. Ruby's productivity argument is not too likely to
have much impact in these shops.
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
I guess there have to be shops that obstinately do things wrong, if only
to make the rest of us look good by comparison.
···
On Wed, Sep 13, 2006 at 02:51:40AM +0900, Francis Cianfrocca wrote:
On 9/12/06, Chad Perrin <perrin@apotheon.com> wrote:
> These people, who think 2 and 3 are mutually exclusive, have clearly not
>read Mythical Man-Month -- but they should. Actually, just reading a
>thorough review, or perhaps even the back of the book, might suffice (if
>these people are reasonable enough to absorb the information).
It's the darnedest thing. I know plenty of managers who have read
Brooks, and yet when the crunch comes they still pile on the
resources. But I realize you're talking about the design/specification
phase. But don't underestimate the power and importance that managers
get simply by having larger teams and bigger budgets. Saving money in
activities that are cost centers often makes a manager less
influential, not more so. And in turn, it makes the manager's manager
less influential. Ruby's productivity argument is not too likely to
have much impact in these shops.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The ability to quote is a serviceable
substitute for wit." - W. Somerset Maugham
You and I must be hanging out in different companies. Most IT
departments I see are being asked to do more with less, and managers
don't usually get extra credit for doing what they are chartered to
do. But in companies that match your experience rather than mine, I
would expect to see a lot of interest in Ruby.
···
On 9/12/06, Stephen Kellett <snail@objmedia.demon.co.uk> wrote:
I disagree rather strongly with your use of the phrase "any other
language". There is a fair number of other languages that will serve
roughly as well as Ruby, give or take a little. The truth remains that
most other languages would not serve as well in circumstances where Ruby
excels best.
···
On Wed, Sep 13, 2006 at 01:29:21AM +0900, Dave Rose wrote:
...under my experience what is almost never considered are these
intangibles...
1.) Under Ruby your maintenance costs will be lower (if it's well
written Ruby)...and because of #1...Since a new systems is never perfect
modifications must be made....and this is where Ruby really shines...any
other language will produce an inertia to change that will continue to
make your system diverge from the users wants and the reality of what
your staff can absorb no matter what the current costs etc....NOBODY...
thinks about this...until the premature end of life of your shiney new
system....
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Ben Franklin: "As we enjoy great Advantages from the Inventions of
others we should be glad of an Opportunity to serve others by any
Invention of ours, and this we should do freely and generously."
You and I must be hanging out in different companies. Most IT
departments I see are being asked to do more with less, and managers
don't usually get extra credit for doing what they are chartered to
do.
Indeed, but they do get extra credit for exceeding what they are chartered to do, coming in under budget and ahead of schedule or on time (since most projects overrun both budget and schedule).
But in companies that match your experience rather than mine, I
would expect to see a lot of interest in Ruby.
I've been fortunate enough to work in environments where they have cared a lot about what got done and how (and if at all possible the managerial politics would be sidelined). I've worked in other places where they didn't care. I got to use Java in a large UK telco in 1996 (when it was months after the public release) despite a corporate ruling that you couldn't. My managers wanted to test the technology and chose an internal project that the senior managers wouldn't be able to see. The project was a success.
More recently I worked at a large CAD corporation R&D office in Cambridge, UK. They were interested in results above anything else. All main project work done in C++. Personal helper utilities written in what you personally wanted to use. Result: C++/Perl/Python in use by different people, all with good results. I think they would be very amenable to Ruby.
After I left, I discovered Ruby. I now use C++, assembler and Ruby depending upon the task. I don't get anywhere near enough chance to use Ruby though, which is a shame, but that is the nature of the job.
Stephen
···
In message <3a94cf510609121155l7b6e8452ga1b81d12dc216f4e@mail.gmail.com>, Francis Cianfrocca <garbagecat10@gmail.com> writes
On 9/12/06, Stephen Kellett <snail@objmedia.demon.co.uk> wrote:
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
