Paying homage to Doug Englebart rather than Steve Jobs.
Stephen
In message <44F8494F.7080808@gmail.com>, James Britt <james.britt@gmail.com> writes
Where would be but for Not Invented Here?
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
It is very easy, though, for even simple queries on a simple, optimized DB schema on a well tuned engine to be the single largest bottleneck for a dynamic web site or web based application.
Take, for example, a site that I am working on today.
It is dynamically generated using data from a simple db, but it is ok for there to be a short latency between changes to db data and changes appearing on the site pages.
Querying everything from the db for every request was netting around 35 pages per second -- a little under 3 hundredths of a second per page generation. Changing the code so that it queries no more than twice a minute, operating off of cached data between queries, dropped the page generation to around 5 or 6 thousandths of a second -- about 170ish a second. For comparison, on my development server I get about 620 page loads a second from a static version of the content.
The database presents a significant bottleneck that I can fortunately work around through a little bit of caching. If, for whatever reason, I could not employ this caching, that db bottleneck could be a much more significant issue than any Ruby speed issues.
Kirk Haines
BTW, just for comparison, a version of this content rendered and delivered through CakePHP on PHP4, with no db data caching, renders about 17 pages per second.
On Sat, 2 Sep 2006, M. Edward (Ed) Borasky wrote:
5. Database "bottlenecks": Most of the "industrial strength" databases
-- Oracle, PostgreSQL, MySQL, SQL Server 2005, DB2, etc. -- are
co-optimized with the operating systems and the platform hardware.
They've done their homework; they've done their performance engineering,
profiling and micro-benchmarking.As good as they are, a poorly engineered database schema can make the
RDBMS work much harder than it needs to, requiring more hardware than is
necessary.
James Edward Gray II wrote:
On Sep 1, 2006, at 9:20 AM, Rob Sanheim wrote:
> I find it amusing that he says Rails is too risky and new, yadda
> yadda, but then he goes on to talk about their in-house language,
> "Wasabi":I too found that beyond ironic.
James Edward Gray II
Do you know what ironic means?
I didn't. Depending on what the language needs to do it, would be easy to
write a lanuage. From what he wrote, it sounds like wasabi was written to
his specific domain, and so of course he would trust it more then some other
general purpose language write by some one else. Now, I'm not saying that
other should trust wasabi. I know I would not, but that's just me trusting
what I know, more then just blanking trusting Jole.
On 9/1/06, James Edward Gray II <james@grayproductions.net> wrote:
On Sep 1, 2006, at 9:20 AM, Rob Sanheim wrote:
> I find it amusing that he says Rails is too risky and new, yadda
> yadda, but then he goes on to talk about their in-house language,
> "Wasabi":I too found that beyond ironic.
James Edward Gray II
At the risk of talking to a wall ... give me a break.
Ruby's a very nice language. Rail's an amazing framework.
But. They are neither dominant nor even close to universally
appropriate. They have things they do well, and they have things
they don't do well, and they have things they don't do at all.
And they have design foci which make them appropriate for some
tasks, and not appropriate for others.
All of which should be completely obvious.
Here's the sermon: Pretending that decisions you don't understand
were made entirely for political reasons, or because the people making
the decision are stupid, is a sure-fire way to prevent yourself from
ever learning anything. Instead of indulging in free-form bile, why
not ask "What would have to be true for that to be the right decision?"
You'd be surprised how much insight such a simple question can
generate.
William Grosso
Chad Perrin wrote:
On Sun, Sep 03, 2006 at 07:15:32AM +0900, Alvin Ryder wrote:
As for developing major sites with Rails, most managers don't have the
balls. They'd rather pay millions to get a java solution, it isn't
their money on the budget so they gutlessly pour it down the java hole
and hope for the best. If the project fails they blame the team or
throw more money and bodies at the problem, of course it's not java's
fault or theirs.Anyway I don't hold prejedice again java or c# but they are in no way a
safe bet.Sure it is. You'll (almost) never have to fear for your job based on a
decision to go with Java or a Microsoft "solution", even if it is
entirely the WRONG decision. You could cost the company millions, end
up getting dozens of people laid off, and tank the entire project, but
if the language by which you did so is Java or C# you may still have job
security (as long as you haven't made other high-profile bad decisions).
The problem with job security in that circumstance only really arises if
there was a bitter power struggle over whether to go with Java or .NET,
and your side "won", then the project tanked at a cost of millions. The
opposing "side" might just blame the language/framework decision.On the flipside, even where from a technical standpoint it's almost
impossible to avoid thinking something like Ruby on Rails, or Perl's
Catalyst, or Python's Django, is the best option, you may well find
yourself losing a job even if you made the right decision and the
project was well on its way to being a howling success. All it takes is
a poorly-timed change in management structure, and they may junk all the
work that has already been done at a cost of millions to rewrite
everything in Java or C# (or, God forbid, VB.NET), and fire you and all
your buddies for doing great work very quickly in the "wrong" language.Corporate politics. Whee.
David Vallner wrote:
Utter pants. I mean, you used the word "bloat", which should make people lose any debate by default.
Alvin Ryder wrote:
Java and C# are no guarantee for success.
Neither is Ruby / Rails. *No technology* is a guarantee for success, no technology ever was, and I'll bet a gold bar against a plastic spoon no technology ever will. Technology used is a very important decision to make, but it never single-handedly moves you from doable to undoable or vice versa.
That's the wrong argument to pick. Try calculating the full dynamics of a modern metropolitan water supply network with just pen and paper. Technological advances *do* move us from undoable to doable, and it's specific technologies that do it.
you seem to need 10 instead of 3 people and 5 times as long.
Pure, unadulterated shite. Give me numbers. Credible statistics and real research, not random anectodal success stories that are too pathethic to sell Herbalife diet pills.
I'm not going to address this - research on this level is heavily funded, and heavily trend-driven. The answers you get depend too heavily on what questions you ask.
Also, initial development cost isn't a very important factor. Recalls your uni software lifecycle charts about how much of a project's life is maintenance. For a successful project, the numbers are very much true. With a successful product comes the responsibility of supporting it and keeping it successful, and in some cases this responsibility creates ongoing costs that dwarf the initial development horribly.
No argument there whatsoever.
Ok, sure Java's OO may be nicer than Perl 5's but once you brew
HTML/Javascript/JSP/JSTL/EL/tags/JSF or Struts together the result
isn't exactly what I'd call pretty. Java is in no way a safe bet.Noone cares about pretty. It's also a completely irrelevant issue when deciding on implementation language if you're at least remotely responsible.
Actually, pretty does matter. The comfort of a problem solver directly impacts his/her approach to a problem. That's just human nature.
Speaking purely theorethically, Ruby can not be made as performant as Java or C# could be made if they had ideally performing implementations. Latent typing makes it almost impossible to do certain optimizations as static typing does. That's pure fact.
I remain unconvinced by this - and it's mainly JIT optimisation that keeps me on the fence. Dynamic optimisations can beat static - but not in all cases. I believe this is what one calls an "open research" question.
--
Alex
David Vallner wrote:
How about C#, well it runs in Windows and without serious and expensive
firewalls you just can't go anywhere near the Internet.You need to tighten off Unix-based servers too. Heck, there are even
serious and expensive firewalls for Linux around too, because not
everyone has an in-house iptables guru.
But everybody *should* have a *certified* Cisco engineer if they use
Cisco routers, for example. It's one of the costs of doing business.
Speaking purely theorethically, Ruby can not be made as performant as
Java or C# could be made if they had ideally performing implementations.
Latent typing makes it almost impossible to do certain optimizations as
static typing does. That's pure fact.
I'm not sure I agree with you here. First of all, while latent typing
may prevent you from optimizing (and I'm writing in Perl, not Ruby)
$j=0;
for ($k=0; $k<100000; $k++) {
$j++;
}
to
$j=$k=100000;
that kind of optimization is a trick used by compilers to get good
performance on trivial benchmarks, rather than something with a more
wide-ranging real-world payoff.
Second "compiled languages", like Java, C#, C++ and even C have
extensive optimized run-time libraries to do all the lower-level things
that a "true optimizing compiler", if such a thing existed, would do
automatically. Over the years, compilers have improved to the point
where they generate optimal code for things like LINPACK and the
Livermore Kernels.
In short, I don't see why a Ruby interpreter *and* run time can't
compete with a Java, C# or C++ compiler *and* run time! As long as you
have to have the same number of bits around to keep track of the
program's data structures, objects, etc., "optimization" becomes a
matter of implementing the operations on the data structures efficiently.
David Vallner wrote:
Noone cares about pretty. It's also a completely irrelevant issue when deciding on implementation language if you're at least remotely responsible.
*Everyone* cares about pretty. Taste for Makers
Pretty means understandable, maintainable, clean (and what the heck does clean mean? reduced duplication?). Pretty means fewer LOC, which is about the only objective measure of maintainability we know. (Cyclomatic complexity being another, I suppose..) Pretty means fun, which we all know means productive.
Speaking purely theorethically, Ruby can not be made as performant as Java or C# could be made if they had ideally performing implementations. Latent typing makes it almost impossible to do certain optimizations as static typing does. That's pure fact.
Irrelevant. In many cases, the fact that Ruby has latent typing is an *implementation detail*. Ruby has *no type declarations*, but in many cases static type inference can be applied to get the same optimizations of which Java and C# implementations avail themselves. (Disclaimer: that's about as much as I know about this subject.)
That's not to say that I expect the current CRuby maintainers to add such optimizations. They seem not to care, and that's just fine by me.
Devin
David Vallner wrote:
Utter pants. I mean, you used the word "bloat", which should make people
lose any debate by default.
I don't like bloated software, it is unnecessary.
Alvin Ryder wrote:
> Java and C# are no guarantee for success.Neither is Ruby / Rails. *No technology* is a guarantee for success, no
technology ever was, and I'll bet a gold bar against a plastic spoon no
technology ever will. Technology used is a very important decision to
make, but it never single-handedly moves you from doable to undoable or
vice versa.
There are many factors required for success and I don't believe any one
factor guarantees it but interestingly it can take so much as one
element gone wrong to ruin everything.
> you seem to need 10 instead of 3 people and 5 times as long.
Pure, unadulterated shite. Give me numbers. Credible statistics and real
research, not random anectodal success stories that are too pathethic to
sell Herbalife diet pills.
The "10 to 3" ratio wasn't meant to be taken literally surely you don't
think otherwise? And can you tell me where can I get such "credible
statistics and real research" from?
Are you saying all languages yield the same level of productivity? If
they aren't equally productive then how much more productive is Java
over C++ or VB over assembler? Do you need "credible statistics and
research" to answer the question?
Also, initial development cost isn't a very important factor. Recalls
your uni software lifecycle charts about how much of a project's life is
maintenance. For a successful project, the numbers are very much true.
With a successful product comes the responsibility of supporting it and
keeping it successful, and in some cases this responsibility creates
ongoing costs that dwarf the initial development horribly.
I disagree, the initial cost is vital. Most projects get approved or
not approved based on that initial cost and if that money is drained on
developers trying to tame an unwieldly platform instead of building the
actual system then we have a problem don't we?
> Ok, sure Java's OO may be nicer than Perl 5's but once you brew
> HTML/Javascript/JSP/JSTL/EL/tags/JSF or Struts together the result
> isn't exactly what I'd call pretty. Java is in no way a safe bet.Noone cares about pretty. It's also a completely irrelevant issue when
deciding on implementation language if you're at least remotely responsible.
I care about pretty.
> How about C#, well it runs in Windows and without serious and expensive
> firewalls you just can't go anywhere near the Internet.You need to tighten off Unix-based servers too. Heck, there are even
serious and expensive firewalls for Linux around too, because not
everyone has an in-house iptables guru.
True, no platform is 100% impervious to attack but some are less secure
than others.
> Ruby and Rails just get straight to the point. They make common things
> easy and elegant.Sometimes things aren't so common. Ruby and Rails DO have faults. Just
google around, I'm not going to go namecall out of respect and out of a
sense of realism - every technology has flaws and any mudslinging would
only lead to a pointless flamewar. Sometimes they are uneducated rants
and / or whining, but some of them are valid.
Yes I know all platforms have faults and wish lists, I didn't think
otherwise.
And if you do NOT go out and learn about these flaws, and what impact
they could have, and be fully aware of them when making the
implementation technology decision on a project to consider the severity
of their impact under the circumstances of your project, then your
decision may cause a lot of trouble.
Fair enough, I agree. I think software should be published with
specifications and limits as they do in other industries. This is a 100
ohm resister +/- 2%, capable of running in these temperators, it
handles this much power ... but in software its just "blah" you have to
discover the limits yourself (ouch).
> If execution speed really is a problem then I reckon
> it'll get fixed.Speaking purely theorethically, Ruby can not be made as performant as
Java or C# could be made if they had ideally performing implementations.
Latent typing makes it almost impossible to do certain optimizations as
static typing does. That's pure fact. Of course, it's not saying Ruby
can't be fast enough - but there have been people with more experience
at the performance side of software development that talked much better
about that
I'm not sure how fast or slow Ruby is but if it's as fast as Perl I'll
be happy enough. Yes I know C is faster but I need fast development
times too.
> As for developing major sites with Rails, most managers don't have the
> balls.I advise you go on throught freshman year on a management school. It's
the managers' job to "not have balls" and risk when there's apparently
nothing to be had from taking it. If you want to be a Ruby advocate, you
need to be able to persuade them, not yourself, of the advantages or
using it.
I've worked with Harvard level managers, they seemed to think it *was
their job to have balls*, which is the opposite of what your saying? I
prefer to work with managers that have knowledge, intelligence, energy
and conviction to back up their decisions.
Besides that the choice of language is usually mine, that's why I
gravitate to the more productive ones. In my experience run-time
performance is rarely an issue but development time is.
> They'd rather pay millions to get a java solution, it isn't
> their money on the budget so they gutlessly pour it down the java hole
> and hope for the best. If the project fails they blame the team or
> throw more money and bodies at the problem, of course it's not java's
> fault or theirs.That's because it's not. Since projects never fail purely on a
technology solution - they fail on results of bad project planning more
often than not (assigning novice programmers to large projects that will
probably go over their heads), mistaken business objectives as whoever
contracted the software finds he isn't really interested in what the
tech demos had to show at all.And the stereotype of lazy management that never gets punished is good
to make Dilbert strips from - in real life, it probably doesn't hold
No, I've seen it hold in real life too many times, the "pointy haired
boss with the corner office" still brings a chuckle out of me.
true outside of a select few huge moloch companies, or on the opposite
side of the spectrum small short-lived hick-led shops where the bosses
kids and nephews gets all sort of crap assigned to get better allowance.
In a well-led company with working internal management processes, when
the shit hits the fan, everyone gets the stink.David Vallner
Cheers 
Thats a great line.
Stephen
In message <44FAFC36.70004@vallner.net>, David Vallner <david@vallner.net> writes
research, not random anectodal success stories that are too pathethic to sell Herbalife diet pills.
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
Really? I trust you a lot more than me, at least as far as designing languages goes.
James Edward Gray II
P.S. I've used Spolsky's software and read his books and it just so happens that I trust you more than him too.
On Sep 1, 2006, at 9:36 AM, Yukihiro Matsumoto wrote:
Hi,
In message "Re: Joel Spolsky on languages for web programming" > on Fri, 1 Sep 2006 23:28:09 +0900, James Edward Gray II > <james@grayproductions.net> writes:
>On Sep 1, 2006, at 9:20 AM, Rob Sanheim wrote:
>
>> I find it amusing that he says Rails is too risky and new, yadda
>> yadda, but then he goes on to talk about their in-house language,
>> "Wasabi":
>
>I too found that beyond ironic.That indicates that he trusts himself, and not me (Ruby). And I think
he's right.
I suspect the 'fun' thing is a bit of a stab at the frequency of the
word 'fun', as well as the 'programmer happiness' thing in Ruby and/or
Rails evangelism. I myself don't like such terms too much when used to
describe what I do.
I love my work, and some of it now involves ruby, but 'fun', in written
english, has connotations that perhaps do not suit the way myself and
like-minded people describe how we feel about our work. I would use it
in conversation, but I would not use it in a banner advertising my
working environment.
--
Posted via http://www.ruby-forum.com/.
ironic |īˈränik| |aɪˌrɑnɪk| |ʌɪˌrɒnɪk|
adjective
using or characterized by irony : his mouth curved into an ironic smile.
• happening in the opposite way to what is expected, and typically causing wry amusement because of this : [with clause ] it was ironic that now that everybody had plenty of money for food, they couldn't obtain it because everything was rationed.
On Sep 1, 2006, at 6:10 PM, Squeamizh wrote:
James Edward Gray II wrote:
On Sep 1, 2006, at 9:20 AM, Rob Sanheim wrote:
I find it amusing that he says Rails is too risky and new, yadda
yadda, but then he goes on to talk about their in-house language,
"Wasabi":I too found that beyond ironic.
James Edward Gray II
Do you know what ironic means?
-=-=-=-=-=-
My usages of the term seems OK to me.
Joel bashed Ruby for being unproven, then went on to say that they were using a custom language they invented. By his own definition, that is unproven. That's "happening in the opposite way to what is expected" because of his earlier statements and it also causes me "wry amusement."
Did this attack on my grammar serve some purpose?
James Edward Gray II
Squeamizh wrote:
James Edward Gray II wrote:
I find it amusing that he says Rails is too risky and new, yadda
yadda, but then he goes on to talk about their in-house language,
"Wasabi":I too found that beyond ironic.
James Edward Gray II
Do you know what ironic means?
After gem install MerriamWebster, ri irony outputs:
3 a (1) : incongruity between the actual result of a sequence of events and the normal or expected result (2) : an event or result marked by such incongruity b : incongruity between a situation developed in a drama and the accompanying words or actions that is understood by the audience but not by the characters in the play -- called also dramatic irony, tragic irony
In this case, "tragic irony" seems apt.
...Just another Joel
On Sep 1, 2006, at 9:20 AM, Rob Sanheim wrote:
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
At the risk of talking to a wall ... give me a break.
Ruby's a very nice language. Rail's an amazing framework.
But. They are neither dominant nor even close to universally
appropriate. They have things they do well, and they have things
they don't do well, and they have things they don't do at all.
And they have design foci which make them appropriate for some
tasks, and not appropriate for others.
Who said otherwise? And why are you top-posting?
All of which should be completely obvious.
Here's the sermon: Pretending that decisions you don't understand
were made entirely for political reasons, or because the people making
the decision are stupid, is a sure-fire way to prevent yourself from
ever learning anything. Instead of indulging in free-form bile, why
not ask "What would have to be true for that to be the right decision?"
Perhaps you should read what I said a second, and maybe even third,
time. In paraphrase, it was (summarized):
Regardless of how good or bad a decision a given language is for a
given task, Ruby is more likely to get you fired that Java.
You'd be surprised how much insight such a simple question can
generate.
You might be surprised by how much actually reading and trying to
understand makes, as opposed to jumping to conclusions about someone's
malicious intent regarding a discussion of the corporate politics of
language and tool choice.
Despite the fact it got this far via top-posting, a no-no here at
ruby-talk/comp.lang.ruby, I'll leave the text you quoted at the bottom
so you can more easily peruse it again at your leisure.
On Sun, Sep 03, 2006 at 09:45:54AM +0900, William Grosso wrote:
Chad Perrin wrote:
>On Sun, Sep 03, 2006 at 07:15:32AM +0900, Alvin Ryder wrote:
>>As for developing major sites with Rails, most managers don't have the
>>balls. They'd rather pay millions to get a java solution, it isn't
>>their money on the budget so they gutlessly pour it down the java hole
>>and hope for the best. If the project fails they blame the team or
>>throw more money and bodies at the problem, of course it's not java's
>>fault or theirs.
>>
>>Anyway I don't hold prejedice again java or c# but they are in no way a
>>safe bet.
>
>Sure it is. You'll (almost) never have to fear for your job based on a
>decision to go with Java or a Microsoft "solution", even if it is
>entirely the WRONG decision. You could cost the company millions, end
>up getting dozens of people laid off, and tank the entire project, but
>if the language by which you did so is Java or C# you may still have job
>security (as long as you haven't made other high-profile bad decisions).
>The problem with job security in that circumstance only really arises if
>there was a bitter power struggle over whether to go with Java or .NET,
>and your side "won", then the project tanked at a cost of millions. The
>opposing "side" might just blame the language/framework decision.
>
>On the flipside, even where from a technical standpoint it's almost
>impossible to avoid thinking something like Ruby on Rails, or Perl's
>Catalyst, or Python's Django, is the best option, you may well find
>yourself losing a job even if you made the right decision and the
>project was well on its way to being a howling success. All it takes is
>a poorly-timed change in management structure, and they may junk all the
>work that has already been done at a cost of millions to rewrite
>everything in Java or C# (or, God forbid, VB.NET), and fire you and all
>your buddies for doing great work very quickly in the "wrong" language.
>
>Corporate politics. Whee.
>
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The first rule of magic is simple. Don't waste your time waving your
hands and hopping when a rock or a club will do." - McCloctnick the Lucid
Gautam Dey wrote:
> I find it amusing that he says Rails is too risky and new, yadda
> yadda, but then he goes on to talk about their in-house language,
> "Wasabi":I too found that beyond ironic.
James Edward Gray II
I didn't. Depending on what the language needs to do it, would be easy to
write a lanuage. From what he wrote, it sounds like wasabi was written to
his specific domain, and so of course he would trust it more then some other
general purpose language write by some one else. Now, I'm not saying that
other should trust wasabi. I know I would not, but that's just me trusting
what I know, more then just blanking trusting Jole.
And another point is that quite a few Ruby frameworks do come to defining a domain-specific language in Ruby - cf. Og data definition, Puppet, rake. There's a (maybe not quite fine) line between a very specific framework and a DSL that just gets crossed, and I don't believe rubyists are the innocents to throw the first stone.
Then again, if Ruby is to be accused of being too much of an unsafe toy, might as well go the full way 
David Vallner
On 9/1/06, James Edward Gray II <james@grayproductions.net> wrote:
On Sep 1, 2006, at 9:20 AM, Rob Sanheim wrote:
David Vallner wrote:
>Utter pants. I mean, you used the word "bloat", which should make people
>lose any debate by default.
>
>Alvin Ryder wrote:
>>Java and C# are no guarantee for success.
>
>Neither is Ruby / Rails. *No technology* is a guarantee for success, no
>technology ever was, and I'll bet a gold bar against a plastic spoon no
>technology ever will. Technology used is a very important decision to
>make, but it never single-handedly moves you from doable to undoable or
>vice versa.
That's the wrong argument to pick. Try calculating the full dynamics of
a modern metropolitan water supply network with just pen and paper.
Technological advances *do* move us from undoable to doable, and it's
specific technologies that do it.
. . . and in any case, I don't think anyone was saying Ruby was any kind
of guarantee of anything. The point is that Joel Spolsky's
characterization of ultraconservative technology choices as necessarily
"right" is chaff and nonsense. Despite Joel's usually intelligent and
well-reasoned commentary, he dropped the ball on this one, effectively
saying that Ruby is a guarantee of failure.
Bollocks, I say.
>Also, initial development cost isn't a very important factor. Recalls
>your uni software lifecycle charts about how much of a project's life is
>maintenance. For a successful project, the numbers are very much true.
>With a successful product comes the responsibility of supporting it and
>keeping it successful, and in some cases this responsibility creates
>ongoing costs that dwarf the initial development horribly.
No argument there whatsoever.
I have a caveat to add:
It's true that initial development is often one of the cheaper parts of
a "successful" project, cost of initial development is still critically
important. If your initial development is too costly, you never get to
maintenance. Additionally, if you think middle managers think ahead
enough to just ignore initial development costs (even when they can
afford to do so) in favor of long-term cost savings, you probably
haven't dealt with middle managers as much as I have. CxO-types are
even worse, because their job success metrics are more tied to quarterly
stock prices and market shares than anything more long-term (generally
speaking).
>>Ok, sure Java's OO may be nicer than Perl 5's but once you brew
>>HTML/Javascript/JSP/JSTL/EL/tags/JSF or Struts together the result
>>isn't exactly what I'd call pretty. Java is in no way a safe bet.
>
>Noone cares about pretty. It's also a completely irrelevant issue when
>deciding on implementation language if you're at least remotely
>responsible.
Actually, pretty does matter. The comfort of a problem solver directly
impacts his/her approach to a problem. That's just human nature.
. . . and how much more do you think it costs in the long run to
maintain code that is a nasty, overly complex, ugly mess? Pretty
matters.
>Speaking purely theorethically, Ruby can not be made as performant as
>Java or C# could be made if they had ideally performing implementations.
>Latent typing makes it almost impossible to do certain optimizations as
>static typing does. That's pure fact.
I remain unconvinced by this - and it's mainly JIT optimisation that
keeps me on the fence. Dynamic optimisations can beat static - but not
in all cases. I believe this is what one calls an "open research" question.
Unfortunately, JIT implementations haven't been subjected to the same
long-term scrutiny and advancement as more traditional persistent binary
executable compiling implementations. As a result, I don't think the
state of the art is there yet -- leaving JIT implementations effectively
slower by nature until they get some more advancement over the years to
come. I really believe that gap will be closed rapidly in the near
future. Only time and experience will tell whether it can be made as
fast or faster, though I have no doubt that it can at least be made
close enough that most of us won't care.
On Mon, Sep 04, 2006 at 02:13:24AM +0900, Alex Young wrote:
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The first rule of magic is simple. Don't waste your time waving your
hands and hopping when a rock or a club will do." - McCloctnick the Lucid
Frankly, iptables is easier to learn effectively than most proprietary
firewalls -- and then there's stuff like IPCop, which makes things even
easier.
On Mon, Sep 04, 2006 at 11:26:18AM +0900, M. Edward (Ed) Borasky wrote:
David Vallner wrote:
>> How about C#, well it runs in Windows and without serious and expensive
>> firewalls you just can't go anywhere near the Internet.
>
> You need to tighten off Unix-based servers too. Heck, there are even
> serious and expensive firewalls for Linux around too, because not
> everyone has an in-house iptables guru.
But everybody *should* have a *certified* Cisco engineer if they use
Cisco routers, for example. It's one of the costs of doing business.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The ability to quote is a serviceable
substitute for wit." - W. Somerset Maugham
Alvin Ryder wrote:
Are you saying all languages yield the same level of productivity? If
they aren't equally productive then how much more productive is Java
over C++ or VB over assembler? Do you need "credible statistics and
research" to answer the question?
*He* may not be saying all languages yield the same level of
productivity. But I'll say something similar: the productivity of
programmers depends more on their knowledge of the application area and
their *familiarity* with the development environment than it does on the
environment and language.
There are tools that can drag down an otherwise productive team, but
they tend to get discarded fairly quickly.
Devin Mullins wrote:
David Vallner wrote:
> Speaking purely theorethically, Ruby can not be made as performant as
> Java or C# could be made if they had ideally performing implementations.
> Latent typing makes it almost impossible to do certain optimizations as
> static typing does. That's pure fact.
Irrelevant. In many cases, the fact that Ruby has latent typing is an
*implementation detail*. Ruby has *no type declarations*, but in many
cases static type inference can be applied to get the same optimizations
of which Java and C# implementations avail themselves. (Disclaimer:
that's about as much as I know about this subject.)
You're absolutely right.
Look to Haskell for a good example a _statically typed_ language
almost free of type annotation of any kind - type information is almost
exclusively added by the compiler (though you can add type
annotations).
While Ruby has features that make it impossible for an implementation
to use strict static typing everywhere, a lot of a typical Ruby
application could be statically typed by an implementation using type
inference fairly easily by doing some relatively simple flow analysis
combined with marking up the parse tree.
Doing it for a pure interpreter would be easy, but the advantages would
be relatively limited. Doing it for a JIT compiler would also be quite
straightforwards and does have the potential of very significant
speedups.
For a full fledged compiler it would be tricky without some
restrictions - the main problem is Ruby's introspective features and
various eval mechanisms, which means the type inference valid at
compile time might not hold at runtime. Add a few restrictions on the
use of load/require etc. and the use of eval's and/or some way of
adding some basic type annotation to guide the compiler for "extension
points" (classes/methods that will be affected by runtime changes) and
it would be doable without significant changes.
Vidar