Forum: Ruby Sharp knives and glue

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-03 18:59
(Received via mailing list)
I have a friend that works in PHP all day and enjoys the language quite
a
lot. I have been
recommending that he try Ruby, but he is bent on moving to Java because
some
of the people he
works with are not good programmers and he thinks he needs a more
restrictive environment
in order to get some sanity in the code.

I have read some posts about Ruby being a sharp knife and shooting
yourself
in the eye and
I must admit, I have been burned by these things. My Rails project
worked
perfectly until
I uploaded it to Textdrive and since Glue had been installed, the basic
environment had been
altered. By chance, Glue had defined a class with the same name as one
of my
Models and
somehow it overrode my class when the project ran. They removed Glue
when I
asked and
everything worked again, but it took me two days to find the problem.

So I'd like to ask how many people out there use Ruby in teams - and how
well Ruby has stood
up with everyone doing their own thing. I'd especially like to know how
it
goes when members
of the team are not so experienced.

Les
D8fb06dfc08a477ecb0a76ffdbff3475?d=identicon&s=25 Chiaro Scuro (chiaroscuro)
on 2006-05-03 18:59
(Received via mailing list)
uhm.. I have never used it in teams, but unit tests would be paramount.
Truly *Unit* tests if you work in group, with mocks and everything.
9358cc96c46055cd68d4a76a9aefe026?d=identicon&s=25 Daniel Harple (Guest)
on 2006-05-03 18:59
(Received via mailing list)
On May 2, 2006, at 5:33 PM, Leslie Viljoen wrote:

> My Rails project worked perfectly until I uploaded it to Textdrive
> and since Glue had been installed, the basic environment had been
> altered. By chance, Glue had defined a class with the same name as
> one of my Models and somehow it overrode my class when the project
> ran. They removed Glue when I asked and everything worked again,
> but it took me two days to find the problem.

I wonder why Rails doesn't put your app in it's own top-level module
(MyApp::Page, etc.) -- it is bad design not to.

Glue can only alter your environment if you require it.

-- Daniel
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-03 19:00
(Received via mailing list)
> > in order to get some sanity in the code.
> of
> > up with everyone doing their own thing. I'd especially like to know how
> it
> > goes when members
> > of the team are not so experienced.
> >
> > Les
> >
> >



On 5/2/06, chiaro scuro <kiaroskuro@gmail.com> wrote:
>
> uhm.. I have never used it in teams, but unit tests would be paramount.
> Truly *Unit* tests if you work in group, with mocks and everything.


Truly you are correct, unit tests would be great for a team. Although
they
would not
have helped with my example problem, which is what bothered me about it.
I am wiser now to environmental issues though, and if I faced a similar
problem
in future I think I'd try changing Class.new to log each time an object
is
created.


--
E0ed615bd6632dd23165e045e3c1df09?d=identicon&s=25 Florian GroÃ? (Guest)
on 2006-05-03 19:00
(Received via mailing list)
Leslie Viljoen wrote:

> I have a friend that works in PHP all day and enjoys the language
> quite a lot. I have been recommending that he try Ruby, but he is
> bent on moving to Java because some of the people he works with are
> not good programmers and he thinks he needs a more restrictive
> environment in order to get some sanity in the code.

In Java even good programmers have hard time writing concise, readable
and clean code. Avoid it.
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-03 19:01
(Received via mailing list)
On 5/2/06, Daniel Harple <dharple@generalconsumption.org> wrote:
> I wonder why Rails doesn't put your app in it's own top-level module
> (MyApp::Page, etc.) -- it is bad design not to.
>
> Glue can only alter your environment if you require it.


I still don't understand how it happened. AFAIR it was my model object,
which
Rails generates using the database, so perhaps it was a one-time
side-effect
caused by Rails magic and I should not complain about it. I would have
done
more investigations but they removed Glue and everything worked so I
released the code and the client was happy.

Oh, I see there's plenty of complaining about Glue here:
http://comments.gmane.org/gmane.comp.lang.ruby.gen...
so let's not whip that dead horse any more. For all I know it's been
fixed
for
years.

Anyway, the real issue for me is that I'd like to say to my friend "hey,
all
this
dynamic stuff doesn't make team programming harder" - but I've never
done it so I can't say it.
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-03 19:01
(Received via mailing list)
On 5/2/06, Leslie Viljoen <leslieviljoen@gmail.com> wrote:
> > > of the people he
> > > I uploaded it to Textdrive and since Glue had been installed, the
> > > everything worked again, but it took me two days to find the problem.
> > > Les
>
> Truly you are correct, unit tests would be great for a team. Although they
> would not
> have helped with my example problem, which is what bothered me about it.
> I am wiser now to environmental issues though, and if I faced a similar
> problem
> in future I think I'd try changing Class.new to log each time an object is
> created.


Hmmm, I see also from other posts that $VERBOSE=true will report when
methods
are redefined, so there ya arr.

--
E3ca69382186f5bce8b43ff5f0cb2287?d=identicon&s=25 kate rhodes (Guest)
on 2006-05-03 19:02
(Received via mailing list)
having worked in perl and php and Java i have to say that when you're
working with inexperienced programers and / or programmers who just
don't
care about doing things the right way flexible languages like perl,
ruby,
and php are IMNSHO dangerous. It's far too easy to write crap code. When
there are 50 solutions to every problem people tend to use whatever
works
instead of the best solution. These languages are great in that they're
easy
to get started programming with...but they suck in that they don't
enforce
good habbits.

*IF* you can convince your team to actually use test driven development
i
think that these languages would probably be fine, but if the problem is
that you're dealing with people who aren't using best practices to begin
with then I would have to say "Yes, go for Java". There are far fewer
solutions to every problem and thus far fewer stupid options.

Of course if you REALLY want to enforce good practices you might want to
look into languages like Eiffel with its static typing and enforcement
of
design by contract. Then again... selling a project written in Eiffel to
a
client is probably even harder than selling Ruby one.

-kate / masukomi
8d16869783573d7ca80a676b65cf98e7?d=identicon&s=25 David Pollak (Guest)
on 2006-05-03 19:05
(Received via mailing list)
Yep... unit tests help, but don't cure everything.  Design by Contract
puts
the unit tests in the code rather than separating them out.  Ruby has a
DbC
module.  See my rant:
http://dppruby.com/dppsrubyplayground/show/Rant+ab...

I've never seen a project with more than 12 developers that didn't use
tools
like lint or compile-time type checking to help developers catch errors
early.  Strong typing allows IDEs to help developers write better code.
Yeah, once you know all the methods/attributes/etc. on
ActiveRecord::Base,
you don't need method completion, but until then, having an IDE to help
you
learn the environment is wicked nice.

Ruby is in fact a very sharp knife... much like C was/is.  C++ evolved
to
include lint-style compile-time checking because the complexity of
software
developed with C and team sizes required it.  Java evolved to include
garbage collection, code verification, and exception handling with DbC
(explicit declaration of exceptions) because of the complexity of the
systems built with Java.

See the following rant:
http://dppruby.com/dppsrubyplayground/show/Ruby+mu...

I totally love Ruby.  It's an awesome and amazing environment for me and
a
small team to build prototypes of cool software.  However, I've managed
the
development of large scale systems for financial institutions.  I would
not
swap Ruby for Java into these projects.  There are too many security and
stability issues that Ruby introduces (when I say "stability" I mean the
stability of a code base where the functionality of a class can be
changed
out from under the class.)

Ruby is great, but it needs some tools and mechanisms to allow it to
scale
to enterprise sized projects and teams.
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2006-05-03 19:06
(Received via mailing list)
Yeah, but ...

There actually *is* a language designed more or less from the ground up
for extensive compile-time error checking, package management, enforcing
good programming habits and just in general making the discipline of
software engineering a reality. That language is Ada, and it's still
around.

So ... why hasn't it dominated software engineering? Is it just because
programmers are mostly undisciplined creative cowboys who refuse to
program in languages that hold them accountable to some kind of
discipline? Why, when Ada has been around so long, is there a need for
Java, Perl, C++, Ruby, Javascript, Visual Basic, Python, PHP, etc.?

David Pollak wrote:
> like lint or compile-time type checking to help developers catch errors
> developed with C and team sizes required it.  Java evolved to include
> managed the
> to enterprise sized projects and teams.
>> there are 50 solutions to every problem people tend to use whatever
>> that you're dealing with people who aren't using best practices to begin
>> -kate / masukomi
>>
>>
>
>
> --
> --------
> David Pollak's Ruby Playground
> http://dppruby.com
>

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-03 19:06
(Received via mailing list)
I broadly agree with most of this, inlcuding your rants on stability.
But
are we missing something more fundamental?

I came to Ruby three years ago from many years of C++, C and assembler,
including large commercial systems. As far as Java is concerned, it's
obviously been validated by the marketplace and your experience (among
others) proves its value for critical systems. But I've never been
convinced
by Java and have generally avoided it for my own development teams.

Java incrementally improves on C/C++ in many ways. But fundamentally, it
has
a very dangerous tendency to encourage sloppy thinking among
less-experienced programmers, because the language takes care of so many
things for you. Well, that comment can be read two ways, can't it? You
have
to be a lot more careful with a straight razor than with a Norelco, but
having deep experience with dangerous and powerful shaving systems isn't
necessarily all that valuable from a business point of view. In other
words,
the Norelco represents progress precisely because it lets you be
somewhat
sloppy, without getting a bloody mess.

Now with Ruby the perception is that we're going back to the straight
razor.
You're arguing for tools and mechanisms to scale to enterprise-sized
projects. I spent most of the last three years writing Ruby programs
that
looked very much like incrementally-improved C++ programs. It took me a
long
time to grok duck-typing, but when the penny finally dropped it really
changed everything. People coming to Ruby without the baggage of many
years
of commercial C/C++/Java experience don't seem to have this problem, nor
do
they have the mental blocks against metaprogramming that people like me
have. (I learned to avoid self-modifying code way back in the assembler
days.)

My point is that if we try to make Ruby fit into established large-team
methodologies, we may be throwing away what makes Ruby special in the
first
place. And we'll end up with an incrementally-better Java. And in a
corporate environment, there are always more reasons not to rock the
boat
than to do so. Which means that if we accept that model, Ruby will
simply
not succeed in the enterprise.

What I believe is happening, but has yet to fully emerge into
visibility, is
that Ruby is successfully extending the same kind of partitioned
development
model that has worked so well in the open-source world generally. If you
accept that Ruby may be revolutionary rather than evolutionary, then ask
yourself why that may be so. To me the value of metaprogramming and
duck-typing are that they permit a tremendously powerful way to
re-imagine
the mapping of elements from real-world problem domains to elements of
computer programs. They help us model the world better. And yes, that
can
mean changing the behavior of already-established and stable objects.
But to
many, that is exactly the problem!

What are "large systems," really, and why is Java perhaps the better
tool
for them? Well, one model is to think of a large system as a relatively
large collection of fine-grained, domain-specific elements. Problems
arise
both because of the size of the set (and the number of interactions) and
the
fact that they are domain-specific, which means they only matter to a
small
number of organizations, perhaps no more than one. So in turn, they
don't
benefit from the evaluation of a broad community. Well, if you think of
a
large system that way, you are really facing an essentially
insurmountable
design challenge. There are too many moving parts. So people respond
with
ideas like "Design by Contract," which seek to automate and "freeze" the
interactions among various system components. Well, the rigor which with
this is done may actually be part of the reason that large systems get
large
in the first place! You end up adding more components because you have
no
ability to modify the existing ones in a context that won't arbitrarily
break their existing contracts. There may in fact be a tipping point at
which system size starts to conflict directly with constructability. But
we
know from real-world experience that this is not true in other
engineering
disciplines, so the question becomes: is there a different way to do
this?
And Ruby may be part of the answer.

If I sound like an advocate for enterprise SOAs, well I am. But I have a
long background in large distributed systems, and what I see with SOA
today
is first-generation thinking, focused primarily on transport protocols
rather than on finding a more organic way for large ordered systems to
spontaneously emerge, which is what should be happening. And the way we
think about traditional large-systems development may be the stumbling
block.

I've been thinking a lot about building a distributed object framework
in
Ruby. Two of biggest (and least-appreciated) technical reasons why this
hasn't worked in the past are the "fragile superclass" problem and the
"destruction at a distance" problem. Ruby potentially relaxes both of
these
problems. I think the "aspect-oriented" stuff that Java people love so
much
really doesn't work in any other context, because it tries to
established
horizontal levels across large chunks of code that have direct textual
visibility to all the other chunks. It's just not natural to the way
Ruby
should work at large scales.

Anyway I don't have the answers (yet) and there is a long way to go. But
I
don't think Ruby should be "improved" to fit traditional large-system
methodology. I think the reverse (somehow) is closer to true.
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-03 19:06
(Received via mailing list)
Thanks for the reply!

On 5/3/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
>
>
> Anyway I don't have the answers (yet) and there is a long way to go. But I
> don't think Ruby should be "improved" to fit traditional large-system
> methodology. I think the reverse (somehow) is closer to true.



Perhaps something as dynamic as Ruby requires a team methodology as
dynamic
as XP. I think pair programming is (at least partially) intended to
limit
the damage
caused by not-so-experienced programmers. Then the remaining problem
would be trying to convince management that pair programming is actually
worth
it, and trying to convince programmers to put aside their egos to the
extent
where they all are willing to accept constant advice and input from a
partner.
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-03 19:07
(Received via mailing list)
I like pair programming a lot. But for every time I've seen it work,
I've
heard many more times that "it won't work for us." And you've already
given
some of the reasons. That tells me that pair programming alone is not
the
answer. (I won't get into all the rest of XP, which can disturb the
managers
of large enterprise projects as much as dynamic typing does.)

Something about what you said struck me funny, though. If we're trying
to
limit the damage caused by less-experienced programmers (in one way or
another), then shouldn't we rather be trying to reduce our need to
deploy
less-experienced programmers in the first place? As you said, not that
many
people have the temperament for pair-programming, so that becomes yet
another quality constraint that we're placing on our people.

I write a lot of C++ and a lot of Ruby. Whenever I go back to C++, I
heave a
sigh of relief and think, "oh good, now I can stop worry about
mispelling
variable names and getting argument counts wrong, because the compiler
will
check all that for me, so I can go back to worrying about memory
management!" I'm just as careful writing Ruby as C++, but I'm careful
about
different things.

Programming well isn't very easy. Programming exceptionally well is...
exceptional. So if our methodologies are constructed with an inherent
dependence of a certain level of quality from our people, then we won't
be
successful at very many of our very large projects. And that indeed is
what
happens. Going to the opposite extreme and trying to attenuate the human
factor altogether through automatic constraints doesn't really achieve
scalability either. Or at least it does so by adding huge costs.

It bothers me a lot that we keep trying to invent large-scale
development
methodologies to solve the problems that arise when a huge number of
components have built-in visibility to a lot of other components. Above
a
certain problem size, you may as well try to boil the ocean, and many
large
projects I've seen look just like that.

Java typifies this approach by making so much of the system statically
checkable, and allowing so little to be dynamic. We know this approach
works, because there is any number of large enterprise systems built in
Java. But then you end up with exactly the kind of large system that
everyone has and everyone hates: too brittle to adapt to changing
requirements. "If it ain't broke don't fix it" turns into "let's define
all
new requirements as nice-to-haves, so we can keep saying that System X
ain't
broke." From this point of view, as I've said, Java isn't fundamentally
better. It's only incrementally better.

Is Ruby fundamentally better? I think it is, but we may have to invent a
completely different large-system methodology to take advantage of it.
And
"completely different" isn't a concept that most IT managers understand.
There will always be a thousand good-sounding reasons why "that'll never
work here," the first and most important of which is "no one else does
it
that way." (And candidly, this attitude keeps a lot of people from
making
big mistakes and getting fired!)

Another thing that troubles me is the convention that you have to pick a
language before you start coding a large system. You'll hear people say
"We're going to do our new account-allocation system in J2EE." I think
that
puts far too much pressure on the programming language, and I suspect
the
underlying motivation is to take pressure off a far more difficult
problem,
which is design. Whenever I see a one-off enterprise system with 1000
KLOCs
and a hundred maintenance programmers, I think there is something very
wrong
with this picture. Someone started coding too soon. Intuitively,
wouldn't it
better, cheaper and easier to have 5 or 10 systems with far
better-defined
and smaller requirements interacting through standard protocols? That
way
your choice of methodology doesn't constrain your choice of programming
language, and vice versa. Something like this is exactly how the
open-source
world works, and it works incredibly well. Large-systems methodology has
yet
to incorporate these insights. And people seem to be talking about this
less
today than they were three years ago.
8d16869783573d7ca80a676b65cf98e7?d=identicon&s=25 David Pollak (Guest)
on 2006-05-03 19:07
(Received via mailing list)
Ed,

I love Ruby.  I love it.  I totally, totally love the language!!!

The Ruby community is totally awesome.  It's full of some of the
brightest
people I've met in a computing community!!

Perhaps most importantly, Ruby is not a religion, but a philosophy of
computing.  Think about that and think about why it's important.

I am not arguing for turning Ruby into a strongly typed static piece of
dog
poop.  I'm not arguing that Ruby should make a binary switch from what
it is
to what Java/C++, etc. are.

I am arguing that there are constructs that have worked for building
large
scale systems.  There are constructs that have worked for building
systems
that need to be created and maintained by geographically and temporally
distributed teams.

There are ways known today (e.g., the DbC MixIn for Ruby) that can
improve
Ruby's development team scalability.  For all you DbC deriders, just
think
of it as unit tests written right into the code rather than living in
separate files.  It's easier unit tests.

Ruby also needs better package name enforcement so there's not namespace
pollution.  Ruby needs multiple protected execution spaces so that a
Ruby
application server can exist (FastCGI is not good enough.)  Ruby needs
ways
of protecting private methods and data (obj.send(:my_private_method) is
bad... private methods are private for a reason.)  Ruby needs a way to
say,
"only the following classes may modify the functionality of my classes
and
the following methods cannot be changed" so I can protect myself from an
over-exurberant third-party modules.

I think there are other ways to improve Ruby... not by forcing Ruby to
change but by "Mixing In" tools/code/etc. that incrementally improve
Ruby
for large scale system.

This sort of liquid scripting to slushy programming, but not rigid C++
style
programing might just allow Ruby to be better.

And if Ruby gets better, then I get to recommend Ruby to some big
companies
and I get to do my projects in Ruby rather than prototyping in Ruby and
converting to Java before I deliver stuff to my clients.

I want Ruby to succeed the way Java succeeded.  I want Ruby to be a
force
across computing the way Java is.  That's why I want to make Ruby a
better
language and a better programming system.
8d16869783573d7ca80a676b65cf98e7?d=identicon&s=25 David Pollak (Guest)
on 2006-05-03 19:07
(Received via mailing list)
Francis,

I think we see many things the same way.  It's most excellent to hear
your
perspectives.

On 5/2/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
> to be a lot more careful with a straight razor than with a Norelco, but
> having deep experience with dangerous and powerful shaving systems isn't
> necessarily all that valuable from a business point of view. In other
> words,
> the Norelco represents progress precisely because it lets you be somewhat
> sloppy, without getting a bloody mess.


I agree that Java promotes some bad programming habbits by hiding the
impact
of these habbits until late in the process.  Moving developers farther
away
from the "metal" and dealing with programmers who don't know assembler
and
don't know Java byte-code and don't understand that computing resources
are
not infinite leads to less than optimal code and much less than optimal
coding practices.  I don't think Ruby is any better from this
perspective.
I find it worse in some ways because I can't review the source code of
the
method I'm calling to see what it's doing under the covers.

"What... David... Ruby is open source and a scripting language... how
can
you not be able to see what's happening?!?"  In Java I know what class
is
being called.  I can open that class if the source code is available.  I
can
decompile that class to see the Java source code (Paul Martino from
http://ahpah.com mathematically proved a 1-to-1 correspondence between
Java
byte-code and Java source code.)  Ruby with mixins, etc. makes it much
more
difficult to track down where the code that's going to execute came
from.

Now with Ruby the perception is that we're going back to the straight
razor.
> have. (I learned to avoid self-modifying code way back in the assembler
> days.)


I love Meta-Programming.  I gave a presentation about it at the Silicon
Valley Ruby Conference.  I've used it to develop a domain specific
langage
for web site navigation ( http://rubyforge.org/projects/sitemap )

Duck-typing is very helpful/useful.  NextStep (now OS X my first true
love
in operating systems/development environments) was built on Objective-C.
Objective-C was duck-typed (although the concept of 'Protocols' was
introduced into the language which is much like Java interfaces.)

IMHO, code blocks are the most powerful part of Ruby.  Passing code that
will be called inside another method (iterators are the best example of
this) is the big mind-shift and the huge chunk of power that Ruby has
over
Java.  With that being said, I've written a meta-programming system in
Java
that generates byte-code at runtime and spoon-feeds the byte-code to the
JVM... but I digress.

One of the challenges that I've seen with MetaProgramming in Ruby is
that
there are few examples of using it for good.  ActiveRecord is a very
good
example of MetaProgramming and why MetaProgramming is so excellent (in
Java,
we created intermediate super-classes for each OR mapped class.)  Most
of
the other examples of MetaProgramming (e.g., the stuff in Why's Poinent
Guide) just makes up for the lack of certain things in the Ruby langauge
(
e.g., class constants that work as expected.)

MetaProgramming can be very bad when MixIns muck with and change the
behavior of my existing methods.  This is even worse when 'gem update'
changes the behavior of the MixIn such that when I do a normal update of
my
production system, my app stops working because some clever guy changed
the
behavior of one of my classes.

My point is that if we try to make Ruby fit into established large-team
> methodologies, we may be throwing away what makes Ruby special in the
> first
> place. And we'll end up with an incrementally-better Java. And in a
> corporate environment, there are always more reasons not to rock the boat
> than to do so. Which means that if we accept that model, Ruby will simply
> not succeed in the enterprise.


I disagree.  I think we can add things... optional things... to the Ruby
language (we can even add them via MixIns a la the DbC MixIn and the
type-checking MixIn) that allows Ruby to be a liquid experience for
building
small apps/scripts, but allows Ruby to have more hospitable to
Enterprise
use (e.g., a update Module to enforce packages/Module names for all code
that's not loaded from /usr/lib/ruby/*... etc.)

What I believe is happening, but has yet to fully emerge into
visibility, is
> many, that is exactly the problem!
I think you're on to something.  The combination of Rails/Gems/Engines
is a
very excellent way of creating software components that can be shared
across
teams.  The Login Engine seems to me to be a better piece of software
than
many login/authentication Enterprise Java Bean implementations that I've
seen.  Plus the ability to "subclass" the Login Engine just by putting
properly named files in your part of the project is wicked cool.  I
think
Engines may be the first step down a new and better path of large-scale
component delivery.

What are "large systems," really, and why is Java perhaps the better
tool
> ideas like "Design by Contract," which seek to automate and "freeze" the
> And Ruby may be part of the answer.
Yes... Ruby is part of the answer.

Another part of the answer may be Engines.

I think a third part of the answer is Domain Specific Languages.  I've
been
working on DSLs for 15 years.  My first Domain Specific Language was a
spreadsheet called Mesa.  Wait... think... yes... a spreadsheet is a
Domain
Specific Language for expressing a wide variety of financial and
business
logic.  More formally, in 1999/2000/2001, I wrote a series of domain
specific languages (workflow, O-R mapping, Object-HTML-multi-page form
mapping, web site navigation.)  The syntax of these DSLs was XML.  The
semantics (the words used) was specific to the domain.  A business
person
could look at the logic in these DSLs in an XML editor and understand
the
logic that was expressed.  That's pretty important... the original
business
intent was preserved in the expression that the computer could execute.
It's very, very rare to see a computer program written in any language
that
preserves the original intent in such a way that a non-programmer could
understand it.  What was unique about these DSLs was that they could
include
snippets of Java code that could call out to other parts of the system.

The net-net is that Ruby is excellent glue for building systems.  It's
an
exellent platform for building DSLs (SiteMap
http://rubyforge.org/projects/sitemap was ~ 800 LOC in Ruby vs. 6,000
LOC in
Java.)

Ruby is in my opinion, has the potential for being the next step in the
evolution of enterprise development systems.  It, however, has to
respect
the systems and methodologies that have evolved in the enterprise and it
can
shape and change those methodologies just as Java has.

If I sound like an advocate for enterprise SOAs, well I am. But I have a
> long background in large distributed systems, and what I see with SOA
> today
> is first-generation thinking, focused primarily on transport protocols
> rather than on finding a more organic way for large ordered systems to
> spontaneously emerge, which is what should be happening. And the way we
> think about traditional large-systems development may be the stumbling
> block.


Discrete islands of logic that may or may not be in the same address
space
is a most excellent perspective.

I've been thinking a lot about building a distributed object framework
in
> Ruby. Two of biggest (and least-appreciated) technical reasons why this
> hasn't worked in the past are the "fragile superclass" problem and the
> "destruction at a distance" problem. Ruby potentially relaxes both of
> these
> problems. I think the "aspect-oriented" stuff that Java people love so
> much
> really doesn't work in any other context, because it tries to established
> horizontal levels across large chunks of code that have direct textual
> visibility to all the other chunks. It's just not natural to the way Ruby
> should work at large scales.


NextStep had Distributed Objects that worked really, really well back 12
years ago.  Ruby, taking a lot of its ideas from SmallTalk, as did
Objective-C, is a great candidate for distributed systems.  Getting back
to
my love of code blocks... they make writing asynchronous code much, much
easier.  Just pass the "do" block to the distributed call and it gets
executed when the call finishes.

Anyway I don't have the answers (yet) and there is a long way to go. But
I
> don't think Ruby should be "improved" to fit traditional large-system
> methodology. I think the reverse (somehow) is closer to true.


Perhaps Ruby should be enhanced... it's enhancements will lead to more
adoption... so it can change the way people think... so the world is
more
Ruby?
8d16869783573d7ca80a676b65cf98e7?d=identicon&s=25 David Pollak (Guest)
on 2006-05-03 19:07
(Received via mailing list)
I am a fan of agile programming, but it has its places.

XP is not good for product development, although it excels for projects
(e.g.,
professional services companies building a web site for a client.)

By and large, XP focuses groups away from domain expertise... this is a
problem when the key differentiator is having domain experts (e.g., most
financial services companies make their money by having domain experts
in
particular types of financial instruments that can write programs very
quickly to model the behavior of those instruments.)

Pair programming doesn't solve any of the enterprise issues because
teams of
500 people over a 10 year lifespan of an enterprise project don't get to
pair with each other.  In fact less than 30% will be working for the
company
at any given time.

Finally, the issue I raised was about third party modules mucking with
the
behavior of my code.  Ruby encourages this.  Folks patch other people's
modules/classes all the time.  This is dangerous.  It means that every
single time I run gem update, I have to re-validate all my code.  This
does
not lead to predictability in code execution.  This leads to disaster.
E3ca69382186f5bce8b43ff5f0cb2287?d=identicon&s=25 kate rhodes (Guest)
on 2006-05-03 19:07
(Received via mailing list)
Just want to point out that a secondary issue has been introduced to
this
conversation that makes it much harder to answer the initial question.
People started talking about large scale development projects and
enterprise
this and that which are valid issues to address when comparing ruby to
other
languages BUT, the question at hand is should undiciplined, or just poor
quality, programmers be handed a language as dynamic and flexible as
Ruby or
something that limits their ability/options to do stupid things, like
Java
or Ada? Ada, as Ed pointed out, probably is a better choice than Java by
this criteria and it is alive and well in the defence industry.

-kate
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-03 19:07
(Received via mailing list)
In all candor, I wouldn't want to hand an undisciplined or poor-quality
programmer <i>any</i> kind of a tool, unless he works for one of my
competitors, in which case I want him to have the most powerful and
dangerous tools available! ;-) I suspect what you meant to say is:
should we
hand such tools to <i>inexperienced</i> programmers? My answer to that
would
be, absolutely positively. I don't believe in training wheels. I do
believe
in having the management discipline to invest in younger people while
keeping them off critical project paths until they prove themselves.
8d16869783573d7ca80a676b65cf98e7?d=identicon&s=25 David Pollak (Guest)
on 2006-05-03 19:08
(Received via mailing list)
I am a very, very good programmer.  I've written more than a dozen
commercial applications including Mesa which was used by Wall Street
traders
as part of a automated trading systems.

I am pretty diciplined... just talk to any of the coders that have
worked
for me over the years.  Talk to the folks at P&L Systems that took Mesa
over
and only filed 2 support requests with me as they migrated Mesa for
NextStep
to OpenStep to Mac OS X.  The code was very well laid out and very
unstandable.

Recently, I dusted off Integer (the world first real-time collaborative
spreadsheet http://mesaonline.athena.com ) and over 2 days got the code
to
compile in Eclipse (the old build system used make because that's all we
had
in 1997) and wrapped some crude AJAX layers around it so it could be
used in
a browser.  I could not have done that if the code wasn't solid and the
code
wasn't written in a diciplined way.

But I used C++ and later Java to help keep order.  I used the machine
and
the tools to help me do the right thing.  After all, if you have tools,
why
not use them.  I can refactor the Java code using Eclipse because of
Java's
strong typing (e.g., migrating some of the code in Integer to use
generics
and enumerations.)

I would never have been able to write Mesa (95%+ of the code base came
from
my hands) or Integer (50%+ of the code base came from my hands) if not
for
the compiler tools.  They helped me write better code.

In the begining, Mesa was all Objective-C.  I found it increasingly
difficult to refactor code, etc. without the tools that C++ brought to
the
table (if I changed a method name, I'd do a compile and all the places
in
the code that called that method would be flagged, etc.)

Ruby forces the developer to do more work and think more.  This is okay
if
you've got a small team that has a mind-meld.  This is more and more
difficult when you have larger and larger teams.  It's not a question of
dicipline or quality of developers, it's a question of how much people
can
hold in their heads.  People can only remember so many naming
conventions,
code conventions, etc.  Using the machine rather than the developer to
deal
with these issues is why we have machines in the first place.

Sorry to go off on you, but your argument is the same argument that
people
used to claim that C++ was better because developers managed memory
rather
than having the machine manage memory.  Machines are better than
developers
at managing memory.  Machines are better than humans at enforcing rules.

In the begining of a coding project, it's better to worry about the
thing
one is building rather than worrying about the rules and structures of
what
one is coding.  But as a project evolves and grows beyond a few people,
it's
better to have the rules by which the code was written included in the
code... not mearly as comments, but as constructs that tools can
enforce.
This helps keep everybody in the same dicipline without some stupid
construct like "The Hungarian System" with managers at Microsoft losing
bonus if their developers weren't writing "Hungarian" code.

Guard rails are good.  Lines on the road are good.  If I was the only
driver
on the road and I knew the roads that I was driving or was blazing new
trails... sure... I'd prefer to have fewer obsticles.  But once you have
lots of drivers, even excellent drivers, driving over a well defined set
of
roads, keeping them driving in harmony is a lot better than letting them
go
willy-nilly all over the place.

Ruby would be better if I could put up guard rails around certain system
features so that one would have to be explicit about using those
features (
e.g., the #unsafe block modifier in C#.)  Ruby would be better if I
could
say, "only the following classes/modules can change the behavior of my
classes" so that some MixIn that I know nothing about changes something
in
my code.

This is not a binary argument (either Java or Ruby).  This is not a
"Java is
absolutely better than Ruby" argument.  This is a discussion about how
to
borrow from other systems to make an excellent system (Ruby) even better
for
an important class of developers.
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-05-03 19:08
(Received via mailing list)
On May 3, 2006, at 10:46 AM, David Pollak wrote:

> Ruby forces the developer to do more work and think more.  This is
> okay if
> you've got a small team that has a mind-meld.  This is more and more
> difficult when you have larger and larger teams.  It's not a
> question of
> dicipline or quality of developers, it's a question of how much
> people can
> hold in their heads.

Do you use unit tests?

> Ruby would be better if I could
> say, "only the following classes/modules can change the behavior of my
> classes" so that some MixIn that I know nothing about changes
> something in
> my code.

If some code you know nothing about is changing your code, they are
breaking the rules and should know to expect the consequences, in my
opinion.

James Edward Gray II
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-05-03 19:08
(Received via mailing list)
On 5/3/06, David Pollak <pollak@gmail.com> wrote:
> I am a very, very good programmer.  I've written more than a dozen
> commercial applications including Mesa which was used by Wall Street traders
> as part of a automated trading systems.

Commercial software is not necessarily the benchmark of *good*.  This
is not meant to reflect upon your capabilities, but I think it's sort
of pointless to mention this.

> But I used C++ and later Java to help keep order.  I used the machine and
> the tools to help me do the right thing.  After all, if you have tools, why
> not use them.  I can refactor the Java code using Eclipse because of Java's
> strong typing (e.g., migrating some of the code in Integer to use generics
> and enumerations.)

Yes, this helps.  It's too bad we don't have better refactoring tools
in ruby.  But I think a lot of refactoring that is necessary in
Java/C++ etc is not necessary in Ruby.

How do you make a method 'abstract' in Ruby?  One way would be to just
delete it from the class which things will inherit from.  Since the
refactoring patterns seem to be simpler, since the codebase is
substantially smaller, and the time to write this code is far less,
auomated refactoring is less of a life saver.  Don't get me wrong, i'm
not saying it wouldn't be a great thing... what i am saying is the
time saved by automated tools in Java would be hard to compare with
the time saved by not using Java.

> I would never have been able to write Mesa (95%+ of the code base came from
> my hands) or Integer (50%+ of the code base came from my hands) if not for
> the compiler tools.  They helped me write better code.

Is there anything a compiler did that a well written unit test
couldn't?  If so, what features of the compiler tools were most
essential to you?

> In the begining, Mesa was all Objective-C.  I found it increasingly
> difficult to refactor code, etc. without the tools that C++ brought to the
> table (if I changed a method name, I'd do a compile and all the places in
> the code that called that method would be flagged, etc.)

Sounds like exactly what happens when I change a method name in
Ruport, except it's my function by function unit tests which do this
for me.

> Ruby forces the developer to do more work and think more.  This is okay if
> you've got a small team that has a mind-meld.  This is more and more
> difficult when you have larger and larger teams.  It's not a question of
> dicipline or quality of developers, it's a question of how much people can
> hold in their heads.  People can only remember so many naming conventions,
> code conventions, etc.  Using the machine rather than the developer to deal
> with these issues is why we have machines in the first place.

Have you ever worked to implement code based on tests someone else has
written, or to extend code which is covered by another set of tests?
I may have totally missed the boat in Java / C++ as to how a compiler
will save my life here, but I'll tell you one thing, well written
tests tell me exactly what's amiss, and they even give me a little
insight into where and why.

It's great fun to work through the Test First Challenge for ruby  (or
the original Java version even ).  This might be a good example of how
someone else (or even yourself) can mold an interface and a set of
behaviors before implementation and ensure that the code will conform
to this.

> Sorry to go off on you, but your argument is the same argument that people
> used to claim that C++ was better because developers managed memory rather
> than having the machine manage memory.  Machines are better than developers
> at managing memory.  Machines are better than humans at enforcing rules.

You were right when you said that computers are better than developers
at memory management.  Luckily, Ruby is an excellent language as far
as handling dynamic typing, memory allocation, and all these things
that would be scary for us to do by hand...  Still, there is a human
component to all of this, and I'll trust myself to design a better API
than the computer, so a language that doesn't get in my way when I'm
doing this, is A Good Thing.  I also trust that I will understand the
behaviors of my software better than the computer will... this is
where test driven development really shines.

Machines are better at enforcing rules, without a doubt.  But machines
cannot understand rules, nor can they change them, nor can they know
when it's okay to break them.  That is uniquely human, and is
important to any creative process.

> In the begining of a coding project, it's better to worry about the thing
> one is building rather than worrying about the rules and structures of what
> one is coding.  But as a project evolves and grows beyond a few people, it's
> better to have the rules by which the code was written included in the
> code... not mearly as comments, but as constructs that tools can enforce.
> This helps keep everybody in the same dicipline without some stupid
> construct like "The Hungarian System" with managers at Microsoft losing
> bonus if their developers weren't writing "Hungarian" code.

Um.... unit tests?  Functional tests?   Acceptance tests?

> Guard rails are good.  Lines on the road are good.  If I was the only driver
> on the road and I knew the roads that I was driving or was blazing new
> trails... sure... I'd prefer to have fewer obsticles.  But once you have
> lots of drivers, even excellent drivers, driving over a well defined set of
> roads, keeping them driving in harmony is a lot better than letting them go
> willy-nilly all over the place.

I don't know.  Nice analogy, but to me, Ruby is not a road, but a wide
open space.  When you're working with wide open spaces, you don't need
to worry so much about crashing into each other.

> Ruby would be better if I could put up guard rails around certain system
> features so that one would have to be explicit about using those features (
> e.g., the #unsafe block modifier in C#.)  Ruby would be better if I could
> say, "only the following classes/modules can change the behavior of my
> classes" so that some MixIn that I know nothing about changes something in
> my code.

Sure, it'd be nice to see stuff like this.  But it's something that's
secondary to the design goals of the language, and in my experience,
doesn't come into practical necessity in ruby development.  There are
bound to be plenty of edge cases, and for those, things like this
would be nice.  But the power of this language is that it *doesn't*
get in your way.  If you're not using that power, you might be much
happier in a language with a lot more rules.  Some applications really
do need strictness like this, but many others do not.

> This is not a binary argument (either Java or Ruby).  This is not a "Java is
> absolutely better than Ruby" argument.  This is a discussion about how to
> borrow from other systems to make an excellent system (Ruby) even better for
> an important class of developers.

Yes, I think it's important to find ways for certain applications to
be written 'safely' in Ruby, but part of that is changing the way you
think about things when you are working in different languages.  What
works for Java is not necessarily good for Ruby.  It doesn't mean that
Java must be used for big applications and Ruby can't scale... it just
means that you have to design differently when you are using languages
which are very different philosophically.

That's not a bad thing, and with it in mind, if there are ways to
tighten things up optionally (and I do think that RAA has at least a
few libs that help), I say that's a great thing.

But it doesn't mean that the language should be changed to meet these
goals.  Ruby's not broken :)
8d16869783573d7ca80a676b65cf98e7?d=identicon&s=25 David Pollak (Guest)
on 2006-05-03 19:08
(Received via mailing list)
On 5/3/06, James Edward Gray II <james@grayproductions.net> wrote:
> > hold in their heads.
>
> Do you use unit tests?


Yes.  And they work just fine for small project, but the cross-product
of
methods that can pass parameters to other methods in other classes that
get
passed down the line, etc. cannot be confidently tested with unit
tests...
especially when delegates are introduced into the mix.

Unit tests are not a substitute for programmers defining the rules in
their
code and having a tool check/enforce those rules.

> Ruby would be better if I could
> > say, "only the following classes/modules can change the behavior of my
> > classes" so that some MixIn that I know nothing about changes
> > something in
> > my code.
>
> If some code you know nothing about is changing your code, they are
> breaking the rules and should know to expect the consequences, in my
> opinion.


Well... what are the consequences?  For example, Instiki 0.11 works just
fine under WEBrick, but breaks running under FastCGI because of a load
sequence issue with the 0.8.x rails libraries that are shipped with
Instiki
and whatever version of stuff is in my Gems directory.

The consequences of this is I can't use a Rails app in my normal
production
environment.  Sure, I could figure out what's going on... but that's a
waste
of my time (I've already lost 3 hours of consulting revenue trying to
install Instiki as a FastCGI rather than a port-forwarded WEBrick app.)

The consequences of this is I'm screwed.

The consquences of this is I can't recommend Ruby to my enterprise
clients
because they can't predictably deploy applications unless they have a
freeze-dried perfectly versioned system that will never change because
of
the unpredictability and instability of changing library versions.

Oh... BTW -- Instiki passes its unit tests because the load sequence is
correct for the unit tests... but it's not correct when Instiki is
launched
as a CGI or FastCGI.  So... the consquences of this is that you can't
trust
unit tests in Ruby because they can be impacted by Module/Class load
sequences.

James Edward Gray II
Bf6862e2a409078e13a3979c00bba1d6?d=identicon&s=25 Gregory Seidman (Guest)
on 2006-05-03 19:08
(Received via mailing list)
On Thu, May 04, 2006 at 12:22:20AM +0900, kate rhodes wrote:
} Just want to point out that a secondary issue has been introduced to
this
} conversation that makes it much harder to answer the initial question.
} People started talking about large scale development projects and
} enterprise this and that which are valid issues to address when
comparing
} ruby to other languages BUT, the question at hand is should
undiciplined,
} or just poor quality, programmers be handed a language as dynamic and
} flexible as Ruby or something that limits their ability/options to do
} stupid things, like Java or Ada? Ada, as Ed pointed out, probably is a
} better choice than Java by this criteria and it is alive and well in
the
} defence industry.

Poor quality programmers should not be paid to develop software any more
than poor quality construction workers should be paid to build
buildings.
Anyone who isn't good at their work should either make an effort to
improve
or choose different work.

If the goal is to learn how to program from the beginning, I think Ruby
is
an excellent first language. It is very readable, strongly
self-consistent,
and has aspects of several language paradigms. I'm using it to teach my
wife, for example.

If the goal is to learn discipline, the language depends on what variety
of
discipline one is seeking. One learns different flavors of discipline
from
different languages depending on the safety nets inherent in the
languages.
Some (certainly incomplete) examples:

- C++ (and C) programming requires rigorous memory management discipline
- Ruby requires discipline in consistent naming/terminology

If the goal is to learn design, any language will do. Some languages
have
better constructs than others (e.g. Ruby modules vs. C++ namespaces vs.
Java packages), but high-level design is largely language-independent.

If the goal is to collaborate with other developers, especially many
teams
of other developers, languages like C#, Java, and C++ have good
constructs
to keep people from stepping on each others toes. It requires more
rigorous
discipline to develop Ruby code collaboratively, particularly in that
there
is less facility for automated tools to warn of lack of discipline.

If the goal is long-term maintainability, no undisciplined developer
should
come near the project. Maintainability is direclty proportional to the
discipline involved in the development. I don't mean development
process, I
mean everything from coding conventions (e.g. two-space indentation,
underscore-separated variable and method names) to loose coupling (e.g.
minimize entry points into objects) to fine-grained namespaces (e.g.
heavy
use of nested modules). Even Perl code can be maintainable if there is
discipline in development.

There are other goals which (should) affect one's decision to use one
language or another (e.g. portability), and there are usually many goals
involved in any given project. It's all about using the right tool for
the
job. You can't even know the right tool if you don't know several
languages. Start small, gain experience, and learn every step of the way
is
my advice.

} -kate
--Greg
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2006-05-03 19:14
(Received via mailing list)
On 5/3/06, David Pollak <pollak@gmail.com> wrote:
>
> unit tests in Ruby because they can be impacted by Module/Class load
> sequences.

But of course in the Java world there are never any incompatibilities
in different versions of libraries. I can take a Java 1.1 compiled
application and run it fine in the latest Java 1.5.whatever. Sun and
IBM and Microsoft Java VMs all run in exactly the same way. No one
could ever have a older JAR file on their CLASSPATH which causes a
normally fine application not to run because of library differences.
Since it isn't always obvious over the email medium, I'm being
sarcastic.

Then of course in the C++ world there are plenty of problems with DLL
incompatibilies as well.

So, in other words I think your above example, while certainly an
annoying situation, is not a valid argument against Ruby being used
for big applications. Any application that relies on external
libraries can have problems like this.

Ryan
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-05-03 19:57
(Received via mailing list)
On May 3, 2006, at 11:38 AM, David Pollak wrote:

> For example, Instiki 0.11 works just
> fine under WEBrick, but breaks running under FastCGI because of a load
> sequence issue with the 0.8.x rails libraries that are shipped with
> Instiki
> and whatever version of stuff is in my Gems directory.

On the flip side, the version of Instiki I have has trouble with the
--daemon option and can't be run the way I needed it too.  I'm so
glad I was able to add a few lines to its startup script to inject
the fix right into the code where I needed it.

James Edward Gray II
8d16869783573d7ca80a676b65cf98e7?d=identicon&s=25 David Pollak (Guest)
on 2006-05-03 20:09
(Received via mailing list)
Ryan,

If you turn on the verifier for class loading, any incompatible
libraries
get flushed out very, very early in the application run cycle.

This compares very favorably to some 3rd party module magically changing
the
behavior of String, Object, Module, or Class in such a way that makes my
application behave unpredictably.  Because Ruby Modules can and do
change
system classes or my classes (and may change the order in which they do
so
depending on load-order), there is a lot more problems than a method
call
signature changing or method functionality changing.  Compound this with
the
the lack of namespaces and no errors being generated if my class Foo
comflicts with another class Foo (hey... we've got 1 class with a lot of
methods... let's hope the method names don't collide) you've got an
unpredictable mess.

Thanks,

David
52a177e9dbd3e614825aabc4e45f8cd6?d=identicon&s=25 Mark Volkmann (Guest)
on 2006-05-03 20:27
(Received via mailing list)
On 5/3/06, David Pollak <pollak@gmail.com> wrote:

> ... Compound this with the the lack of namespaces ...

What support for namespaces would you like to see beyond the current
ability to put class definitions inside modules?  I always looked at
that as pretty much equivalent to package statements in Java.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-05-03 20:31
(Received via mailing list)
On 5/3/06, Mark Volkmann <r.mark.volkmann@gmail.com> wrote:
> On 5/3/06, David Pollak <pollak@gmail.com> wrote:
>
> > ... Compound this with the the lack of namespaces ...
>
> What support for namespaces would you like to see beyond the current
> ability to put class definitions inside modules?  I always looked at
> that as pretty much equivalent to package statements in Java.

selector namespace will help in the future...
34f159f89cbd1d9beac0276f5a7af552?d=identicon&s=25 John Gabriele (Guest)
on 2006-05-03 22:04
(Received via mailing list)
On 5/3/06, David Pollak <pollak@gmail.com> wrote:
> [snip]
>
> The consequences of this is I'm screwed.
>
> [snip]
>

Hi David,

I'm fairly new to Ruby. Do you think a ruby option, maybe something like

    ruby -w --very-strict

would be worthwhile?

---John
E3ca69382186f5bce8b43ff5f0cb2287?d=identicon&s=25 kate rhodes (Guest)
on 2006-05-03 22:38
(Received via mailing list)
>Sorry to go off on you, but your argument is the same argument that people
>used to claim that C++ was better because developers managed memory rather
>than having the machine manage memory.  Machines are better than developers
>at managing memory.  Machines are better than humans at enforcing rules.

I don't see your post as going off on me at all. I think you're making
pretty much exactly the same point i did in both of my posts...only more
verbosely.

As- i said
> the question at hand is should undiciplined, or just poor
> quality, programmers be handed a language as dynamic and flexible as Ruby
> or something that limits their ability/options to do stupid things, like
Java
> or Ada?

Java and Ada just have more "guard rails" as you put it. I never claimed
any
language was "better" or the right choice. But i did claim that using a
language with more restrictions was probably a better choice for less
disciplined/experienced/good developers, which it seems you did too.

-Kate
E3ca69382186f5bce8b43ff5f0cb2287?d=identicon&s=25 kate rhodes (Guest)
on 2006-05-03 22:44
(Received via mailing list)
All the things you mention unit tests not handling James? That's where
Functional and Accptance tests come in.

The fact that Instiki doesn't work under lighttpd is a poor test of if
you
should recommend ruby. I would not be hard to find 10 apps in *every*
language that don't work in certain environments their creators didn't
plan
for. Time consuming yes...but not hard.
8d16869783573d7ca80a676b65cf98e7?d=identicon&s=25 David Pollak (Guest)
on 2006-05-03 22:54
(Received via mailing list)
Kate,

I don't think you understand the underlying issue in the post.  It's not
that Instiki doesn't work... you're right... that's not uncommon.
It's WHYit does not work.

The reason that Instiki doesn't work under FastCGI because the class
load
sequence running under FastCGI is a different sequence than the class
loading sequence under  WEBrick.  Because the classes are loaded in a
different order, some of the metaprogramming stuff that's happening done
"wrong" and thus Instiki doesn't work.  If a pretty uncomplex system
(Instiki is not very complex) is so very fragile and subject to problems
because of the order classes are loaded into the environment, this
problem
will just get worse in complex systems.

Put another way, Ruby programs can break each other because they can
change
behaviors of the system and/or my classes.  This makes Ruby programs
unpredictable, especially in moderately complex systems.  Unpredictable
are
not testable.  Programs that are not testable cannot be put into
production
in environments such as insurance, financial services, etc.

Thanks,

David
8d16869783573d7ca80a676b65cf98e7?d=identicon&s=25 David Pollak (Guest)
on 2006-05-03 23:03
(Received via mailing list)
Kate,

On 5/3/06, kate rhodes <masukomi@gmail.com> wrote:
>
>
> Java and Ada just have more "guard rails" as you put it. I never claimed
> any
> language was "better" or the right choice. But i did claim that using a
> language with more restrictions was probably a better choice for less
> disciplined/experienced/good developers, which it seems you did too.


No, that is not my point.  My point is that the dangerous parts of a
language should be more difficult to access or at least be wrapped in a
way
that makes explicit that the dangerous features are being used (see the
example of C#'s 'unsafe' keyword which allows developers to access C/C++
style pointers from a managed language.)

This is not a discussion about the discipline of developers.  It's a
discussion about the complexity of software and the difficulty for
anybody,
no matter how skilled they are, to manage that complexity.  My premise
and
argument is simple... in order for Ruby to grow from a tool used by
small
teams to build small to medium sized projects into an enterprise class
environment, it must make available a series of tools/functions/etc.
that
allow better management of the complexities of huge systems.
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2006-05-03 23:21
(Received via mailing list)
On Wednesday 03 May 2006 2:53 pm, David Pollak wrote:

> The reason that Instiki doesn't work under FastCGI because the class load
> sequence running under FastCGI is a different sequence than the class
> loading sequence under  WEBrick.  Because the classes are loaded in a
> different order, some of the metaprogramming stuff that's happening done
> "wrong" and thus Instiki doesn't work.  If a pretty uncomplex system
> (Instiki is not very complex) is so very fragile and subject to problems
> because of the order classes are loaded into the environment, this problem
> will just get worse in complex systems.

You keep using this an an example of a Ruby problem.  It's not a Ruby
problem.
It's not a language problem.  It's an application problem, an Instiki
problem.

In this case, Instiki needs to be fixed, not Ruby.


Kirk Haines
E3ca69382186f5bce8b43ff5f0cb2287?d=identicon&s=25 kate rhodes (Guest)
on 2006-05-03 23:25
(Received via mailing list)
I have to disagree David. In my opinion this is just a case where a
programmer did something a little funky (metaprogramming) and didn't
write
sufficient code to check that his funkyness was always inserted
correctly.

A great example is servlet code in java.. some things are completely
different in Jetty than they are in Tomcat. Put a webapp written with
one in
mind and there's a decent chance it's going to break in the other
because
the programmer made assumptions about the environment. This is just like
instiki's developer making the assumption that it would be run under
Webrick. Does this mean that you can't recommend Java either? If so
you've
got some problems because we can bring up very similar examples from
pretty
much any language. If not, i think you should rethink your decision
against
Ruby. It may still not be appropriate for you clients but...

-Kate
8d16869783573d7ca80a676b65cf98e7?d=identicon&s=25 David Pollak (Guest)
on 2006-05-03 23:59
(Received via mailing list)
Kate,

I'm sorry, but please, go back and read my posts.  I love Ruby.  I think
Ruby is awesome.  There are parts of Ruby that need improvement.  Some
of
these things need to be improved/fixed before Ruby is ready to compete
with
J2EE or .Net for enterprise systems.  The reason I am spending a lot of
time
hammering on this issue is that I believe Ruby should be the next
language/system that captures developer mindshare like Java did 10 years
ago.

One of the things that needs improvement is protection against meta-code
breaking applications.  This is not an issue of a programmer calling one
set
of APIs vs. another set.  This is an issue of the order in which the
classes
were loaded impacting the execution of the code.

In Java (unless the developers have used AOP), I know that no matter the
order that my classes are loaded, the code will execute the same way.

In Ruby this is not the case.  Because classes patch other classes, the
order in which the patches happen impact the code path.  In the case of
running Instiki under WEBrick vs. FastCGI, the EXACT SAME LIBRARIES are
used.  However, they are loaded in a different order and that load order
is
causing some methods to behave differently.  The analogie to running an
app
under Tomcat vs. Jetty doesn't hold.  This is not about making calls to
different implementations of the same interface.  This is an issue that
the
order in which the classes are loaded impacts the way the classes work.
That level of unpredictability is very, very bad.

Once again, please read all my posts rather than branding me a Ruby
hater or
mischaracterising the Instiki instance of the problem as a "you're using
2
different libraries" issue.

I am a Ruby lover and as a Ruby lover, I am working to make Ruby a
better
environment for more people.

There are problems with Ruby that make is not ready for enterprise
systems.
These problems have fixes.  Admitting there are problems and admitting
that
Ruby needs to make it into the enterprise will help to address things
rather
than having Ruby wind up in the heap of "coulda-been" systems like Lisp,
SmallTalk, Objective-C/NextStep/Interface Builder, OS/2 (okay, I hated
OS/2,
but many thought it was great), etc.

VB, Java, C++, and maybe PHP made the grade.  Let's figure out how to
get
Ruby into that club rather than the SmallTalk club.
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-04 00:17
(Received via mailing list)
Hopefully without interrupting quite an interesting discussion -
I think my question has been answered.

Sadly, my friend can't do anything about the particularly poor
programmer
in his team because that programmer is the "lead developer". He is lead
developer because he has been there writing terrible code for so long.

Even more sadly, I will stop recommending Ruby for that environment
because
I imagine that enforcing some discipline should at least control what
comes
out of the bad code even if the internals are incomprehensible and the
results likely to be wrong in many circumstances.

I just have a hard time accepting that we can't just all program in Ruby
all the time! I have tried using IRB as a shell! I am eagerly awaiting
QtRuby
for Windows! I wish I could somehow load Ruby into my little ARM
processor
based embedded devices and kiss C and Assembler goodbye! (ie. in 32k of
RAM!)

So then my only remaining hope is that at some point we'll have
"Razelle"
and
then I will be happy:
http://www.arm.com/products/esd/jazelle_home.html

;-)
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-05-04 00:32
(Received via mailing list)
David, aren't you a bit new here to be making friends this badly
already?  ;)

On May 3, 2006, at 4:58 PM, David Pollak wrote:

> One of the things that needs improvement is protection against meta-
> code
> breaking applications.  This is not an issue of a programmer
> calling one set
> of APIs vs. another set.  This is an issue of the order in which
> the classes
> were loaded impacting the execution of the code.

Obviously, this is your opinion.  I think it's pretty clear from this
thread that it's not a popular opinion, but really the only opinion
that matters in this instance is that of Matz.  I'm pretty sure I've
seen him say that Ruby is meant to trust the programmer to do the
right thing multiple times in the past, so I wouldn't hold your
breath waiting for the patch.

> In Java (unless the developers have used AOP), I know that no
> matter the
> order that my classes are loaded, the code will execute the same way.
>
> In Ruby this is not the case.  Because classes patch other classes,
> the
> order in which the patches happen impact the code path.

I have no idea what you are saying here.  It honestly sounds like you
are making things up now.  I'm pretty confident the order Ruby loads
code is a well defined process.  Please show us some sample code.

> I am a Ruby lover and as a Ruby lover, I am working to make Ruby a
> better
> environment for more people.

I would believe that a *lot* more if you had patched the Instiki
issue you supposedly found.  Why don't you school us on the issue so
we can go fix it for you.

James Edward Gray II
Cff9eed5d8099e4c2d34eae663aae87e?d=identicon&s=25 Jacob Fugal (Guest)
on 2006-05-04 00:57
(Received via mailing list)
On 5/3/06, James Edward Gray II <james@grayproductions.net> wrote:
> I'm pretty confident the order Ruby loads code is a well defined process.
> Please show us some sample code.

I think the core of what David is talking about comes down to this
point:

  $ cat foo.rb
  class Foo
    def quux
      "This is one definition"
    end
  end

  $ cat bar.rb
  class Foo
    def quux
      "This is another definition"
    end
  end

  $ cat baz1.rb
  require 'foo'
  require 'bar'
  puts Foo.new.quux

  $ cat baz2.rb
  require 'bar'
  require 'foo'
  puts Foo.new.quux

  $ ruby baz1.rb
  This is another definition

  $ ruby baz2.rb
  This is one definition

So the execution of the code ("the code" being to everything excepting
the require statements) is dependent on the ordering of the require
statements.

In a simple case like this, it's easy to say "just make sure you
require them in the right order". But, guessing from David's
description, webrick and fastcgi are doing their own requiring --
Instiki is not doing the requiring, and David's code is not doing the
requiring -- in different orders which is causing this problem.

This just reiterates the need for two libraries be *very careful*
about extending any code from foreign libraries. Otherwise, you get
people stomping on each others feet.

So I agree with David about his analysis of the situation -- this
shouldn't be happening. It's not his fault, and it might not even be
instiki's fault (don't know).

I disagree however with the solution. I don't think that this is a
fault of Ruby for allowing this toe stomping, but of the authors of
the libraries that aren't playing nicely together. If you are going to
release a module as a library and that module plays with the internals
of other modules, be *very careful* and *document*! And even if you
think you're only "extending" a module by adding a method not in the
module's original implementation, assume you're actually replacing an
existing method and act accordingly -- you don't know when someone
else, including the author him/herself in a future version, might also
want to use that method name.

Jacob Fugal
E20e89d58211a3631842daecc1245de2?d=identicon&s=25 Ilmari Heikkinen (Guest)
on 2006-05-04 01:24
(Received via mailing list)
On 5/4/06, James Edward Gray II <james@grayproductions.net> wrote:
> are making things up now.  I'm pretty confident the order Ruby loads
> code is a well defined process.  Please show us some sample code.

How about this (long) example:


>cat a.rb
class A; def a; "a"; end end


>cat a2.rb
class A; def a; 10; end end


>cat aizer.rb
require 'a'
require 'a2'

class B;
  def b
    A.new.a + 25
  end
end


>cat kaiser.rb
require 'a2'
class A; def b; a + 10; end end


>cat this_works.rb
require 'aizer'
require 'kaiser'

puts((A.new.b rescue 'A#b failed'))
puts((B.new.b rescue 'B#b failed'))


>cat this_breaks.rb
require 'kaiser'
require 'aizer'

puts((A.new.b rescue 'A#b failed'))
puts((B.new.b rescue 'B#b failed'))


How can this be avoided?


Ilmari
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-05-04 01:48
(Received via mailing list)
On May 3, 2006, at 5:56 PM, Jacob Fugal wrote:

>    def quux
>
>  $ cat baz1.rb
>  require 'foo'
>  require 'bar'
>  puts Foo.new.quux

Luckily, Ruby does warn me there is a problem, as long as I use
warnings:

$ ruby -w baz1.rb
./bar.rb:2: warning: method redefined; discarding old quux
This is another definition

James Edward Gray II
A9b6a93b860020caf9d2d1d58c32478f?d=identicon&s=25 Ross Bamford (Guest)
on 2006-05-04 09:49
(Received via mailing list)
(I was keeping out of this thread, but...)

On Thu, 2006-05-04 at 06:58 +0900, David Pollak wrote:
> I'm sorry, but please, go back and read my posts.  I love Ruby.  I think
> Ruby is awesome.  There are parts of Ruby that need improvement.  Some of
> these things need to be improved/fixed before Ruby is ready to compete with
> J2EE or .Net for enterprise systems.  The reason I am spending a lot of time
> hammering on this issue is that I believe Ruby should be the next
> language/system that captures developer mindshare like Java did 10 years
> ago.

How to win friends and influence people, eh? I'm sure ruby could be
improved in some ways, and I'm sure Matz will make any improvements that
fit. But 'fixed' is the wrong word here - if some idiot chef cuts
himself misusing a sharp knife, should the kitchen throw out all the
knives, or just the idiot chef?

Yes there is ruby-based software out there that, through careless
metaprogramming, breaks in combination with other stuff. I guess we've
all been bitten by a subtlety here and there. One of the benefits of
ruby is that a "very, very good programmer" like yourself can jump right
in and fix such broken software if you wish, rather than complaining
that ruby's sharp knives are defective because they're sharp.
76006c10b0773e69a6fcd70614ac258f?d=identicon&s=25 Joost Diepenmaat (Guest)
on 2006-05-04 10:13
(Received via mailing list)
On Wed, May 03, 2006 at 12:33:24AM +0900, Leslie Viljoen wrote:
> everything worked again, but it took me two days to find the problem.
I must say that this worries me too, sometimes, since I have been bitten
by
this problem a few times in Perl. Although it really isn't Ruby's fault,
I
see a lot of example code and "ways of working" that just assume people
will
create top-level classes with the logical name.

Whenever I create programs with more than a few classes, I try to put
all of
them into one or a few "namespaces" to help prevent this. I believe you
can also
do this with Rails / active record, though I can't recall exactly how
that workes.

In any case, yes this is a potential pitfall, and one of the things that
Java
is supposed to prevent. In my opinion the tradeoffs java makes in the
name of
"code security" aren't worth it unless you're working on really huge
projects,
with many programmers simultaneously, but YMMV.

On the other hand: from what I can see, some Ruby programmers and book
writers
could be a bit more careful and explicit about choosing class names and
polluting
namespaces.

Joost.
D84df7c68f790e492c4ad4ec5fe65547?d=identicon&s=25 Florian Frank (Guest)
on 2006-05-04 14:50
(Received via mailing list)
Ross Bamford wrote:

>One of the benefits of
>ruby is that a "very, very good programmer" like yourself can jump right
>in and fix such broken software if you wish, rather than complaining
>that ruby's sharp knives are defective because they're sharp.
>
>
www.apa.org/journals/features/psp7761121.pdf
8d16869783573d7ca80a676b65cf98e7?d=identicon&s=25 David Pollak (Guest)
on 2006-05-04 15:20
(Received via mailing list)
On 5/4/06, Ross Bamford <rossrt@roscopeco.co.uk> wrote:
> time
> > hammering on this issue is that I believe Ruby should be the next
> > language/system that captures developer mindshare like Java did 10 years
> > ago.
>
> How to win friends and influence people, eh? I'm sure ruby could be
> improved in some ways, and I'm sure Matz will make any improvements that
> fit. But 'fixed' is the wrong word here - if some idiot chef cuts
> himself misusing a sharp knife, should the kitchen throw out all the
> knives, or just the idiot chef?


Ruby is fine for the existing Rubyists who are willing to live with the
issues.  If Ruby wants to become more that a niche language that's
currently
getting 15 minutes of fame because of Rails, Ruby has to evolve to
support
the needs of enterprise users.  Matz has taken the best from a number of
languages.  Reading his slides on Ruby 2.0, it's clear that he
understands a
lot about how Ruby has to grow and evolve.  I am suggesting that there
are
other languages to look at and learn from such that Ruby > 2.0 continues
to
evolve to support the needs of larger teams building larger systems.

Yes there is ruby-based software out there that, through careless
> metaprogramming, breaks in combination with other stuff. I guess we've
> all been bitten by a subtlety here and there. One of the benefits of
> ruby is that a "very, very good programmer" like yourself can jump right
> in and fix such broken software if you wish, rather than complaining
> that ruby's sharp knives are defective because they're sharp.


Perhaps you should go back and read the entirety of my posts rather than
making this statement.

My premise is that Ruby is not ready for enterprise use because the
inability to predict the behavior of programs.  If one cannot predict
the
behavior of programs, one cannot test the programs.  If one cannot test
the
programs, one cannot deploy the programs into environments that have
significant regulation (e.g., financial services, health care,
insurance,
etc.)

I gave as an instance of this issue, Instiki.  So... let's drill down.

   - Instiki was written by someone who was not an 'idiot chef' but a
   skilled Ruby programmer.
   - Instiki was written using Rails... the "way" to write web apps in
   Ruby.
   - Instiki is not a complex app (the application itself is < 2,000
   LOC).
   - Yet Instiki has somehow fallen into this issue of unpredictability
   because of the order of class loading.
   - If a non-complex Ruby app written by a skilled Ruby developer using
   standard Ruby tools breaks, how can a large company trust that a very
   complex Ruby program that has passed QA won't fall into the same
issue if
   the first user opens the "latest transaction" rather than the
"account" page
   first thus causing a different order for class loads.

We can take two approaches to this issue:

   1. Not worry about and 3 years from now sit around saying, "Ruby
   coulda woulda shoulda"
   2. Discuss the issues in a way that leads to solutions being found so
   we can all improve something that we're all passionate about.

To address the personal issues... I'm not here to make friends.  Search
for
dpp@athena.com in comp.sys.next.misc.  You'll see why I spend time in
newsgroups.  It's also not worth my time to spend more than the 3 hours
that
I spent tracking down an issue in 3rd party software.  I'm hosting my
Ruby
Playground on Instiki because I think it's best to eat the Ruby dog
food.
If I wanted a solution to the wiki issue and I didn't want bugs, I'd
install
a PHP or Perl based package.  If I wanted a mature environment for
writing
code, I'd stick with Java.  I want something new and better... Ruby...
and I
want it to grow in popularity by servicing the needs of a larger and
larger
user base.
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-05-04 15:36
(Received via mailing list)
On May 4, 2006, at 8:19 AM, David Pollak wrote:

>   - Instiki was written by someone who was not an 'idiot chef' but a
>   skilled Ruby programmer.

I'm pretty sure DHH has claimed publicly that he didn't think we was
a terrific Ruby programmer when he invented Rails and that would have
been after he invented Instiki.

>   - Instiki was written using Rails... the "way" to write web apps in
>   Ruby.

Instiki has been ported to Rails recently.  It use to be a stand-
alone application.  To my knowledge, the port was done by Instiki's
new maintainer, not DHH.

>   - If a non-complex Ruby app written by a skilled Ruby developer
> using
>   standard Ruby tools breaks, how can a large company trust that a
> very
>   complex Ruby program that has passed QA won't fall into the same
> issue if
>   the first user opens the "latest transaction" rather than the
> "account" page
>   first thus causing a different order for class loads.

You have yet to show us your Instiki issue, but I'm pretty sure you
did not claim it was an issue of visiting a certain page caused a
page to break.  I think you claimed that certain installed software
broke Instiki with some careless class hackery.  To me, those are
pretty different issues.

> If I wanted a solution to the wiki issue and I didn't want bugs,
> I'd install
> a PHP or Perl based package.

Right, because Perl is definitely not a dynamic language like Ruby.
It's so readable too, I'm sure a lot less mistakes are made with it.
Good point.

James Edward Gray II
A777f1a2049d78a12ead38efb8f75f97?d=identicon&s=25 Tanner Burson (Guest)
on 2006-05-04 16:19
(Received via mailing list)
On 5/4/06, David Pollak <pollak@gmail.com> wrote:
> I gave as an instance of this issue, Instiki.  So... let's drill down.
>    standard Ruby tools breaks, how can a large company trust that a very
>    2. Discuss the issues in a way that leads to solutions being found so
>    we can all improve something that we're all passionate about.


The majority of your argument seems to center around the fact that
poorly
written software, or code that relies heavily on re-opening classes
(which
you seem to lump in with meta programming), can break in certain
circumstances.  And I don't think anyone would argue that at all.  But
to
say that Ruby is not ready for "the enterprise" (I'm sure ara t howard
and a
few others would argue this one), because you can't trust that code
added
later won't break existing code is ridiculous.  So, because in C/C++ I
can
gain direct access to memory, and modify objects IN memory, it isn't
enterprise ready either, as depending on what order the code is run,
things
will act very differently.

And a very, very good programmer such as yourself, must welcome the
ability
to re-open the classes of existing code, to provide patched
functionality,
on a per-library, or per-application basis, without needing to add your
code
to a list of "approved" classes to be able to modify it.  Oh wait,
that's
dangerous and can't be tested and shouldn't be allowed in "the
enterpirse",
nevermind.


Ruby may not be ready to fill the "enterprise" nitch that Java currently
sits in.  The right tool, for the right job.  Ruby is great at what it
does,
and I'd hate to see it become the bloated beast that Java is.

Of course you neglect the fact that no open-source language ever gains
significant market in "the enterprise" as PHB's want a specific someone
to
hold accountable for everything, you won't get that with Ruby.
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-04 16:34
(Received via mailing list)
On 5/4/06, James Edward Gray II <james@grayproductions.net> wrote:
>
> On May 4, 2006, at 8:19 AM, David Pollak wrote:
>
> >   - Instiki was written by someone who was not an 'idiot chef' but a
> >   skilled Ruby programmer.
>
> I'm pretty sure DHH has claimed publicly that he didn't think we was
> a terrific Ruby programmer when he invented Rails and that would have
> been after he invented Instiki.


But whether he claimed it or not I think we can all agree he's pretty
good!
Better than me anyway.

>   - Instiki was written using Rails... the "way" to write web apps in
> >   Ruby.
>
> Instiki has been ported to Rails recently.  It use to be a stand-
> alone application.  To my knowledge, the port was done by Instiki's
> new maintainer, not DHH.


But we're getting away from the issue aren't we?
The issue seems to be: should execution behaviour change with the
order of require statements in a program? Is it sufficient to have Ruby
warn us that a method is being redefined?


> If I wanted a solution to the wiki issue and I didn't want bugs,
> > I'd install
> > a PHP or Perl based package.
>
> Right, because Perl is definitely not a dynamic language like Ruby.
> It's so readable too, I'm sure a lot less mistakes are made with it.
> Good point.


AFAIR Perl's require also allows redefinition of the world. If David is
saying
that Perl is easier to write bug free code in, he's wrong in my
experience.
49ab3ce5a4922b4747d1d6f330784629?d=identicon&s=25 Jake McArthur (Guest)
on 2006-05-04 16:50
(Received via mailing list)
I was doing a good job staying out of this thread, but no more. I
have been too annoyed at the lack of understanding, and while I don't
expect to single-handedly change anybody's mind, I wish to point out
what is going wrong here.

> If Ruby wants to become more [than] a niche language that's currently
> getting 15 minutes of fame because of Rails [...]

I'm going to go slightly off topic because this is just not true.
Ruby was getting extremely popular in Japan long before Rails. I
myself, in America, used Ruby for at least a year before I ever heard
of Rails.

> Perhaps you should go back and read the entirety of my posts [...]

You keep claiming that we are not paying you attention, but we are,
and I think it's feeding the troll. Yes, I said it, this has been
reduced to a troll thread. The problem here is not that we are not
paying you enough attention or misunderstanding you. The problem is
in quite the other direction.

> My premise is that Ruby is not ready for enterprise use because the
> inability to predict the behavior of programs.

You are seeing this wrong. The ability to change the behavior of a
class is a _feature_, definitely not a bug. You know this, but you
refuse to just accept it.

> If one cannot predict the
> behavior of programs, one cannot test the programs.

Not true. Properly tested code will not be screwed up unknown by
meddling with it. If your testing practices are good (especially
extensive use of mock objects), then method-changing and duck-typing
will not mess up the program if the tests pass.

> If one cannot test the
> programs, one cannot deploy the programs into environments that have
> significant regulation (e.g., financial services, health care,
> insurance,
> etc.)

Properly tested programs are _tested_ under every environment they
are meant be introduced to, so this is no argument.

Frankly, I think your arguments are quite ridiculous and I find it
hard to believe that you are the very, very good programmer that you
say you are. Sorry to be harsh, but quit trying to lead everybody on.

- Jake McArthur
E3ca69382186f5bce8b43ff5f0cb2287?d=identicon&s=25 kate rhodes (Guest)
on 2006-05-04 16:50
(Received via mailing list)
> Ruby has to evolve to support the needs of enterprise users.

Perl doesn't seem to have catered particularly much to enterprise users
...
pretty much just keeps adding libraries and not changing itself that
much
and yet it seems to keep going strong.

[Yes i'm ignoring perl 6 because it's a) not finished and b) a
completely
different beast. It may as well be a different language that just
happens to
have similar syntax.]

As far as being a rails app, last time i checked instiki had some pretty
significant deviations from the rails way of doing things check out it's
storage mechanism ... something which is at the core of most rails apps
and
the fact that it maintains state (rails apps are generally stateless, as
far
as the app is concerned).

Instiki may be a great app, but i don't think it's a great example of a
rails app.

As for idiot chefs. Even the greatest chefs screw something up from time
to
time when trying something new, or working in a different kitchen.

Your comment about "If a non-complex Ruby app written by a skilled Ruby
developer using standard Ruby tools breaks..." Are you honestly
suggesting
that if one non-complex app by a skilled developer breaks then the
language
it was written in can't be trusted? Because in that case we can throw
out
EVERY programming language EVER invented.

-kate
Ad4caa46eebe9347305177fc33468563?d=identicon&s=25 Mike Nelson (miken700)
on 2006-05-04 17:04
David Pollak wrote:
> The consquences of this is I can't recommend Ruby to my enterprise
> clients
> because they can't predictably deploy applications unless they have a
> freeze-dried perfectly versioned system that will never change because
> of
> the unpredictability and instability of changing library versions.
>

Isn't this the case with any language? As I see it this is not a
language specific problem. You want this kind of control for any
production system in any language. You don't want the throw in new
libraries, or any piece of software for that matter, into a production
system without testing in on a test system first.

> Oh... BTW -- Instiki passes its unit tests because the load sequence is
> correct for the unit tests... but it's not correct when Instiki is
> launched
> as a CGI or FastCGI.  So... the consquences of this is that you can't
> trust
> unit tests in Ruby because they can be impacted by Module/Class load
> sequences.

It sounds like they need to add a test case for this then and then fix
it (if they support that configuration, I don't know). This sounds like
an Instiki issue, I wouldn't apply this generally to Ruby. I think we've
all had problems like this before in systems (whether or not they use
Ruby). I know I've had my share.


Generally, I believe a language or system is considered not ready for
enterprise apps until many people think that it is, and that usually
comes from many people using it for enterprise apps. I know, it's a
catch-22 and it's just based on people's perception which is not based
on reality. Once people believe that it's suitable for this type of app,
people will just start to solve problems like you have found rather than
point to the language as the problem.

Candidly, I personally believe that any language or tool can work in
enterprise, mission critical systems. I also believe that any language
or tool can fail in the enterprise. The only true test is the empirical
test, to test it for what you are going to do with it. In my mind that
is the only proof that matters for whatever problem domain that it
applies too.

Going all the way back to the original question, talk about whether
something is ready for this or that, while very interesting discussion,
is sort of in the clouds intellectually, so to speak. While this can
lead to interesting and very useful ideas it seems impossible to prove
this point one way or another, without actually seriously trying it for
whatever your needs are.

I think what really matters is the comfort level with the people on the
team with the tools that they use. Ruby might work for the system, but
if the developers involved don't think that it is a good tool or doubt
that they know how to use it properly then they are bound to have a
miserable time building the thing. I'd tend to say just use what the
team has the highest confidence with.
65db5b70bf70e5978e0865fa529143ca?d=identicon&s=25 Brian Moelk (Guest)
on 2006-05-04 17:06
(Received via mailing list)
> My premise is that Ruby is not ready for enterprise use because the
> inability to predict the behavior of programs.  If one cannot predict the
> behavior of programs, one cannot test the programs.  If one cannot test
the
> programs, one cannot deploy the programs into environments that have
> significant regulation (e.g., financial services, health care, insurance,
> etc.)

I'm a Ruby newbie, but having done a bunch of work in other languages, I
do
think you have a point.

OTOH, I think you're exaggerating the extent of the problem.  As others
have
mentioned, various testing practices can mitigate the legitimate issues
that
you put forth.  It's also worth stating, again, that these kinds of
problems
aren't exclusively Ruby's.

> I gave as an instance of this issue, Instiki.  So... let's drill down.
...
>    - If a non-complex Ruby app written by a skilled Ruby developer using
>    standard Ruby tools breaks, how can a large company trust that a very
>    complex Ruby program that has passed QA won't fall into the same issue
if
>    the first user opens the "latest transaction" rather than the "account"
page
>    first thus causing a different order for class loads.

IMO, a large company will have their own QA procedures which should test
the
deployment platform.  In this particular example it's hard to say that
this
provides anything more than a single datapoint.

Besides, a skilled programmer like yourself has diagnosed the problem
right?
In my experience, these kinds of deployment issues bite many projects
regardless of the language chosen.

Certainly there is a bit of frustration involved in tracking down a kind
of
bug that might not happen in other languages that one is familiar with,
but
there are other kinds of bugs that happen in other languages that don't
happen in Ruby.

> We can take two approaches to this issue:
>
>    1. Not worry about and 3 years from now sit around saying, "Ruby
>    coulda woulda shoulda"
>    2. Discuss the issues in a way that leads to solutions being found so
>    we can all improve something that we're all passionate about.

I agree that the Ruby community should be thinking/talking about these
kinds
of things.  I also think that there is a natural tendency to get
defensive/offensive about what one is passionate about.

I think what would be most effective at this point is to discuss some
possible solutions to the issues raised rather than trying to
continually
discussing the problem.

These facilities might already exist in Ruby, as I am a newbie myself,
but
for example: is there any way in Ruby to log the order of class loading?
Perhaps a way to require or specify order dependencies of the loading?

FWIW, I too don't feel comfortable with changing lower level classes
that
alter "default" behavior, so it would be nice to at least have some easy
way
of detecting if this has occured for the "core" Ruby classes.  Maybe a
RubyLint?  I see there is CheckR on RubyForge, but it looks to be in the
very early stages.

Anyway, I'd like to have those more knowledgeable/skilled discuss
possible
solutions beyond the testing suggestions offered before.
Ff63c03fd68754adbadd2c6314646bef?d=identicon&s=25 Bill Guindon (agorilla)
on 2006-05-04 18:11
(Received via mailing list)
On 5/4/06, David Pollak <pollak@gmail.com> wrote:

Emphasis added.

> There are problems with Ruby that make is not ready for enterprise systems.
> These problems have fixes.  Admitting there are problems and admitting that
> __Ruby needs__ to make it into the enterprise will help to address things rather
> than having Ruby wind up in the heap of "coulda-been" systems like Lisp,
> SmallTalk, Objective-C/NextStep/Interface Builder, OS/2 (okay, I hated OS/2,
> but many thought it was great), etc.

I refuse to admit that 'Ruby needs to make it into the enterprise'.  I
don't believe that's true any more than I believe that brainf*ck[1] or
logo[2] 'need' to make it into the world of enterprise apps.

> If __Ruby wants__ to become more that a niche language that's currently
> getting 15 minutes of fame because of Rails, Ruby has to evolve to support
> the needs of enterprise users.

Ruby is a programming language.  It has no wants, or needs.  It seems
that you want to use it for enterprise apps, and you believe it needs
to be changed for that to happen, but you are not Ruby.  This reads
like a case of transference[3].

[1] http://en.wikipedia.org/wiki/Brainfuck
[2] http://en.wikipedia.org/wiki/Logo_programming_language
[3] http://en.wikipedia.org/wiki/Transference
51a34236538906ab994cf9f2e533d14d?d=identicon&s=25 Lou Scoras (ljscoras)
on 2006-05-04 22:06
(Received via mailing list)
I think the problem is in the expectations.  Why would you expect that
two /executable runtime/ statements would not depend on the order in
which they are executed?  Require is just another method.

I have to agree with James on this one.  If I've written a library
that plays nicely and then somebody comes along and pulls the rug out
from under my feet, there's not much I can do about it.  My code isn't
the one that is mucking things up.  Besides, if I was suitable
paranoid I could check to make sure I'm not redefining a class and
steping on anybody elses feet:

    fail %q{I don't like what's going on here!} if
Object.const_defined 'ProblemClass'

    class ProblemClass
        # ...
    end

If I throw caution to the wind and stick my nose in other modules
buisness I deserve to get rapped.
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2006-05-04 23:34
(Received via mailing list)
On 5/4/06, Louis J Scoras <louis.j.scoras@gmail.com> wrote:
>
>
>
> --
> Lou
>
>

I'm pretty sure the problem is that you *don't* get rapped for
sticking your nose in other modules.

If I write ProblemClass, then install a gem that defines it, or some
newbie on my team messes around with it, then *I'm* the one who gets
the nasty surprise.  Now there are some pretty simple solutions to
this - ensure you have good procedures in place to keep this from
happening, have a thorough test suite, etc - but the only thing that
David is suggesting is that there be a mechanism to keep these
modifications from happening.

I'm reading David's comments as, "Yeah there are ways to protect
against this, but why not just let the computer handle it?"
Procedures don't always get followed, and really I see no reason why
my unit tests should break because somebody else was careless.  I
don't have a need for it, but David's opinion here seems entirely
reasonable to me.

Wouldn't it be a lot nicer to do

class DontTouchMe
  include Freezable
end

to ensure that nobody messes around with it?  Procedures can be
error-prone, cause let's face it, sometimes they just take a back seat
when you're in a crunch, and having your unit tests randomly blow up
is inconvenient, not to mention a waste of time when you have to
search for the culprit.

Pat
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2006-05-05 00:33
(Received via mailing list)
From: "Pat Maddox" <pergesu@gmail.com>
>
> Wouldn't it be a lot nicer to do
>
> class DontTouchMe
>   include Freezable
> end
>
> to ensure that nobody messes around with it?

Should we start by closing the String class, then?  :)

What sorts of classes do you think should be made closed?

And why is the author of the class in the best position to
determine whether or not it should be open?


Regards,

Bill
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2006-05-05 00:45
(Received via mailing list)
On 5/4/06, Bill Kelly <billk@cts.com> wrote:
> Should we start by closing the String class, then?  :)
>
>
>
>

Personally, I have no use for closing a class.  If I were to write an
app to be used in a financial or health care organization, I would
probably want to be able to write some code with the knowledge that
nobody could arbitrarily change it.

Perhaps I shouldn't even be commenting because I don't have any
real-world experience with designing these kinds of apps.  It just
seems to me that the main point is that sometimes a business has
requirements with a very high cost of failure.  In these specialized
instances, I think it's more than reasonable to protect your code.

Pat
25e11a00a89683f7e01e425a1a6e305c?d=identicon&s=25 Wilson Bilkovich (Guest)
on 2006-05-05 01:10
(Received via mailing list)
On 5/4/06, Bill Kelly <billk@cts.com> wrote:
> Should we start by closing the String class, then?  :)
>
> What sorts of classes do you think should be made closed?
>
> And why is the author of the class in the best position to
> determine whether or not it should be open?
>
>

irb(main):001:0> class String
irb(main):002:1>   def whee
irb(main):003:2>     "whee"
irb(main):004:2>   end
irb(main):005:1> end
=> nil
irb(main):006:0> "".whee
=> "whee"


irb(main):007:0> String.freeze
=> String
irb(main):008:0> class String
irb(main):009:1>   def yarr
irb(main):010:2>     "yarr"
irb(main):011:2>   end
irb(main):012:1> end
TypeError: can't modify frozen class
        from (irb):9
        from :0
irb(main):013:0>
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-05-05 01:38
(Received via mailing list)
Pat Maddox wrote:

> instances, I think it's more than reasonable to protect your code.
Right.  And in those cases it may make sense to use a different
language.  Various degrees of security often come with corresponding
development costs.  For me, those day-to-day costs aren't justified for
what I write; the pros and cons of Ruby work out quite well.    But,
just as one might prefer C to Ruby when speed is the main concern, a
different language might be called for to satisfy other needs.

Better to change languages than to change Ruby.

--
James Britt

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.30secondrule.com   - Building Better Tools
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2006-05-05 02:05
(Received via mailing list)
On Thursday 04 May 2006 5:37 pm, James Britt wrote:

> Right.  And in those cases it may make sense to use a different
> language.  Various degrees of security often come with corresponding
> development costs.  For me, those day-to-day costs aren't justified for
> what I write; the pros and cons of Ruby work out quite well.    But,
> just as one might prefer C to Ruby when speed is the main concern, a
> different language might be called for to satisfy other needs.
>
> Better to change languages than to change Ruby.

Just as a data point, while what I produce are not large team, high
dollar,
multiyear projects (though I would love the opportunity to take on such
a
task), I make the vast majority of my income writing software, in Ruby,
for
customers in the financial, construction, and environmental sectors of
business.  I've been doing this for four years.  Some of the software is
web
related, and some is more related to issues of data handling, storage,
transfer, and transformation.


Kirk Haines
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2006-05-05 05:21
(Received via mailing list)
Leslie Viljoen wrote:
> I just have a hard time accepting that we can't just all program in Ruby
> all the time! I have tried using IRB as a shell! I am eagerly awaiting
> QtRuby
> for Windows! I wish I could somehow load Ruby into my little ARM
> processor
> based embedded devices and kiss C and Assembler goodbye! (ie. in 32k of
> RAM!)
Well ... I had a hard time accepting that I couldn't choose the language
I programmed in if I wanted to get paid for programming ... for about a
week. If I had my druthers, I'd program in Lisp or assembler. It ain't
gonna happen where I work. I program in Perl and R because I know them,
and because I'm on a team with other people who can read my code.

I wrote a very wonderful queuing modeling package a few years back in
Java. Why? Because I wanted something that would run on Windows or UNIX,
which ruled out Visual Basic. That left Perl and Java, and Java was
quite a bit faster, so Java it was.

That code is still sitting in CM untouched! My colleagues are off in a
class learning queuing modeling using something called PDQ, written
first in C and ported to Perl. It looks a *lot* like the package I
wrote. The difference is that it is being *used*, and my code isn't.

Oh yeah ... PDQ has also been ported to Python. Java? Ruby? R? Not
likely unless *I* do it, and since it's open source, what glory or money
would I get out of it? My point is that virtually *no one*, even "lone
wolf" consultants, gets to pick the language on a for-profit project.
It's only in the open-source world where any choice exists. Which is why
Ruby is as good as it is.

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-05 09:36
(Received via mailing list)
On 5/5/06, Kirk Haines <khaines@enigo.com> wrote:
> > Better to change languages than to change Ruby.
> transfer, and transformation.
How big is your team? Do you use any XP methodologies, or would you give
us an idea of what methodologies you do use? How big are the programs
you have written?

Les
9d1f5d2d9de70bd9a934f557dc95a406?d=identicon&s=25 Daniel ----- (liquid)
on 2006-05-05 12:48
(Received via mailing list)
Hi All,

I don't really want to get into this discussion too much.  I'm too new
to
really contribute and this thread is probably a bit confrontational for
me,
I just have a question that I would like some clarification on if
possible.

When using ruby on Windoze the RMagick gem can cause a lot of trouble.
Apparently it redefines some things in the String class.  The long and
short
of it is that many ppl find it difficult/impossible to use the
file_column
plugin with Rails under windoze.

My question is, list/David, is this the situation that David is talking
about?

Thanx for any clarification.

Cheers

Dan
8d16869783573d7ca80a676b65cf98e7?d=identicon&s=25 David Pollak (Guest)
on 2006-05-05 15:31
(Received via mailing list)
Dan,

Yes, this is an instance of the issues I was discussing.

I think James Britt framed the issue perfectly in that it's a trade-off
between (and I'm paraphrasing) freedom and security/costs.

James and others on the list are of the opinion that freedom in the high
order bit.  For where Ruby is today, I think James has the right balance
and
that freedom should be the high order bit as folks come up with the next
set
of cool tools like ActiveRecord/Rails, etc.

I am taking the position that as Ruby-based systems become more complex,
the
balance changes.  The Glue/RMagick/Instiki load issues are hints of the
issues that, I argue, will become more common as there are more
libraries
and more complexity in the Ruby/Rails/whatevers-next code bases.

One post drew the analogy to the danger of meta-programming and the
danger
of C/C++ pointers.  I think it's a perfect analogy.  Pointers are
amazingly
powerful, when used correctly.  Unfortunately, they were sometime
mis-used
which led to nasty program failures and they were ultimately bannished
from
the successor languages to C/C++ (Java, C#).

I think meta-programming should stay part of Ruby.  I also think that
Ruby
should evolve (either through libraries or the runtime with switches,
etc)
to guard rails around meta-programming so that it's power can be used
correctly.

Thanks,

David

PS -- To avoid being branded a troll, this will be my last post in this
thread.  I'm happy to discuss this issue privately.
PPS -- I appologize to folks if they think I wasn't listening to their
point
of view.  If you think I've wronged you, please send me a note.
PPPS -- For those who think I don't know anything about
meta-programming,
please review the presentation I gave on meta-programming at the Silicon
Valley Ruby Conference (
http://dppruby.com/dppsrubyplayground/files/Preso.ppt) and check out a
Domain Specific Language I wrote using Ruby (
http://rubyforge.org/projects/sitemap)
PPPPS -- For those who question my programming skills, if you're using
OS X,
open Mesa and look at the credits.  I wrote Mesa among other award
winning,
highly stable commercial applications.
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2006-05-05 15:58
(Received via mailing list)
David Pollak wrote:
> powerful, when used correctly.  Unfortunately, they were sometime
> correctly.
>
> Thanks,
>
> David
>
> PS -- To avoid being branded a troll, this will be my last post in this
> thread.  I'm happy to discuss this issue privately.
I think this is exactly the *right* place to discuss this issue!!

1. I haven't used meta-programming in a *long* time. The last time I did
anything like it on a for-profit project was in the mid-1960s, and I had
my head handed to me by management for it. It's just not maintainable by
anyone except the original programmer and those *very* closely
associated with the original programmer.

In fact, I think the same goes for domain-specific languages. On a
software project, we already share a spoken language, one or more
programming languages, a shell/command line language, a revision/version
control system and lots of other environmental languages.

2. Complex adaptive systems, no matter whether they are organizations,
software, a living animal, or some combination of these, are ... well
... complex and adaptive. :) Unmastered complexity is a project-killer.

I'm optimistic that Ruby (and Rails) will evolve as they take on larger
and more complex projects. Fortran has, Lisp has, Algol/C/C++/Java/C#
has, Perl has, PHP has and Python has. As I noted before, only one
language seems to have thought all of this out from the start, Ada.

P.S.: In case you haven't noticed, I'm pretty much in violent agreement
with you, David.

P.P.S.: Yes, both meta-programming and domain-specific languages, called
by those names, *were* around in the mid-1960s. They didn't start with
Ruby or Forth or even Lisp. Regular expressions and text editors made
them more or less unneccesary, at the cost of millions of lines of badly
factored code. :)
>

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-05-05 15:59
(Received via mailing list)
On May 5, 2006, at 8:27 AM, David Pollak wrote:

> PS -- To avoid being branded a troll, this will be my last post in
> this
> thread.  I'm happy to discuss this issue privately.

I apologize if you feel I was "trolling" you.  I didn't mean to come
across so harshly.

James Edward Gray II
A52b0e1c5d982f2512a03c5dbfd033d6?d=identicon&s=25 Dick Davies (Guest)
on 2006-05-05 16:35
(Received via mailing list)
Having skimmed over the thread, I get a taste of
'Open classes bad. Strong typing good.' Apologies if I'm paraphrasing
excessively,
but there's no law saying I have to pay attention :)

On 05/05/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

> 1. I haven't used meta-programming in a *long* time. The last time I did
> anything like it on a for-profit project was in the mid-1960s, and I had
> my head handed to me by management for it. It's just not maintainable by
> anyone except the original programmer and those *very* closely
> associated with the original programmer.

That assumes the language makes it difficult to do cleanly, and I
honestly
don't think that's true in Rubys case.

I'm not saying it's always safe. If you're advocating a 'best practice'
approach
then I'm all for it.

Can I propose "extend the object, not the class" as rule #1.

> In fact, I think the same goes for domain-specific languages. On a
> software project, we already share a spoken language, one or more
> programming languages, a shell/command line language, a revision/version
> control system and lots of other environmental languages.

Yes, but C doesn't have key
> 2. Complex adaptive systems, no matter whether they are organizations,
> software, a living animal, or some combination of these, are ... well
> ... complex and adaptive. :) Unmastered complexity is a project-killer.

The last two statements seem in opposition.

Cheers
A52b0e1c5d982f2512a03c5dbfd033d6?d=identicon&s=25 Dick Davies (Guest)
on 2006-05-05 16:54
(Received via mailing list)
On 05/05/06, Dick Davies <rasputnik@gmail.com> wrote:

> Can I propose "extend the object, not the class" as rule #1.

In case that's a bit opaque, this page explains what I'm on about:

  http://www.rubygarden.org/ruby?SingletonTutorial

 - especially the phrase

  'You could add the POP3 server methods to class TCPSocket but that
pollutes a general-purpose system class that you might be using for
other things.'
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2006-05-05 17:38
(Received via mailing list)
On Friday 05 May 2006 1:33 am, Leslie Viljoen wrote:

> How big is your team? Do you use any XP methodologies, or would you give
> us an idea of what methodologies you do use? How big are the programs
> you have written?

Two people, currently, who are geographically separated.

Regarding code size, it varies.  A lot can be done in a small linecount,
when
one doesn't consider the size of frameworks or libraries being used.

The largest single system is 20kloc.  It's a system for a real estate
appraisal company to manage their appriasal ordering/assignment/tracking
process paperlessly (and to be honest, if I wrote it today, I'm sure
that LOC
would be under 10k).

There are a number of systems in the 5-10kloc neighborhood that are used
for a
lot of different data tracking/handling tasks in various companies.  And
then
there are a bunch of small systems, many less than 2kloc (some much
less),
used for very targetted purposes.

As for methodologies, it really boils down to some very basic things.
There
is no pair programming or anything of that nature.  The basic process
tends
to move from a general idea about what the company wants through to a
set of
business requirements over the course of a lot of talking with the
customer.
Sometimes they have specific requirements already fleshed out, but in
practice, the process is one that entails a lot of questioning and
discovery,
as the requirements are often, frankly, very poor.  After that, the
process
becomes one of release early, release often, as it is being developed.

Because that questioning and discovery phase is so common and is tied so
intimately with nebulous requirements, it goes on contantly while the
product
is being developed, and sometimes that means that halfway through the
project
it is discovered that the customer had a requirement in their heads that
was
poorly communicated or simply assumed on their part, but they don't
realize
it concoulsly until they see the project coming together.  It can be a
pain,
but when it happens, it happens, and we just deal with it.

Throughout the development process there is a lot of testing, both from
automated tests and the human-driven variety.  That makes it easier to
shift
gears midstream when an unexpected requirement rears its head.  It also
helps
ensure that when the system is finally delivered in a completed form to
the
customer, that it fullfills their business requirements, and it makes it
easier to write documentation for them.

Like I said, there isn't a lot of really sophisticated methodology.
It's all
pretty basic.  Get the best requirements one can, usually through  alot
of
discussion and questioning.  Stay agile in devopment because
requirements
will mutate.  Keep asking questions.  Don't over-engineer; it tends to
interfere with the requirement to stay agile, even when it seems like a
good
idea at first.  :)  And test test test.

That's basically it.


Kirk Haines
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2006-05-05 18:14
(Received via mailing list)
As I have matured, I've become more and more convinced how much louder
actions speak than words. This is most especially true in the world of
open source software.

In the current case, I would suggest that if David is so convinced of
a need for locking down core classes or limiting meta-programming in
Ruby at the Enterprise level, then he should provide some possible
solutions for that in code. I do agree that modification of core
classes and meta-programming can be a source of problems, just like
any powerful language feature. It probably would be nice to be able to
have control over that at the language level.

But I'll be even more convinced if someone showed me some code that
accomplished this and was easy to use instead of telling me it needs
to be done.

I think much of the push-back David experienced in this thread was the
tone of "this really needs to be done", without any offer of actually
taking part in the doing. You just can't tell people what to do on an
open source project. We all get that enough at work, thank you.

I would suggest that David's posts would have much more warmly
received if they were more like this: "Hi guys, I too have seen the
kind of problems talked about in this thread, and I came up with this
little solution for it. Take a look and let me know what you think."
Instead it seems we got: "Yo guys, Ruby is just not ready for the
enterprise, because of X and Y and Z. You guys really need to get on
the ball if you ever expect Ruby to be anything important!"

Ryan
49ab3ce5a4922b4747d1d6f330784629?d=identicon&s=25 Jake McArthur (Guest)
on 2006-05-05 20:07
(Received via mailing list)
No no no. Don't do that. I don't think anybody accused you of
trolling except for me, and I regret that. I think I was just in a
bad mood for reasons that aren't relevant to the topic. Your points
are valid and interesting and belong here.

- Jake
8d16869783573d7ca80a676b65cf98e7?d=identicon&s=25 David Pollak (Guest)
on 2006-05-06 01:43
(Received via mailing list)
Ryan,

So... "Put your code where your mouth is?"... and given that my mouth is
big, my code should be good (my comments about me, and not ascribed to
you)... :-)

I think you're absolutely right!

I'll work on some 'lock-down' code that will allow classes to lock
themselves down from external modification (not Foo.freeze, but
something
more granular.)

I'll toss it out to the group and see what people have to say.

Thanks,

David
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2006-05-06 04:27
(Received via mailing list)
Brian Moelk wrote:
> I'm a Ruby newbie, but having done a bunch of work in other languages, I do
> think you have a point.
>
> OTOH, I think you're exaggerating the extent of the problem.  As others have
> mentioned, various testing practices can mitigate the legitimate issues that
> you put forth.  It's also worth stating, again, that these kinds of problems
> aren't exclusively Ruby's.
>
"Testing can only show the *presence* of bugs, not their absence." E.W.
Dijkstra

> FWIW, I too don't feel comfortable with changing lower level classes that
> alter "default" behavior, so it would be nice to at least have some easy way
> of detecting if this has occured for the "core" Ruby classes.  Maybe a
> RubyLint?  I see there is CheckR on RubyForge, but it looks to be in the
> very early stages.
>
I don't feel comfortable in modifying the language at all! I gave up on
Squeak because

1. The user interface was so totally orthogonal to everything I've ever
touched that I didn't see the point in learning it, and

2. It's possible to modify the language, the operating system, the
libraries, *everything*.

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2006-05-06 07:28
(Received via mailing list)
Cool, this sounds like a plan David. This was exactly what I wanted my
email to achieve. While we Ruby programmer's love the power and
flexibility of re-opening classes, there are probably times when we
all want to lock things down. Having the *option* of doing this
shouldn't hurt anything, in my opinion.

FYI, I'm not sure if what you propose is possible in pure Ruby (at
least easily), so if you can hack C you might have to look into making
a C extension or a patch to the interpreter. Hopefully it won't be so
bad though.

Regards,
Ryan
Ad7805c9fcc1f13efc6ed11251a6c4d2?d=identicon&s=25 Alex Young (Guest)
on 2006-05-06 11:21
(Received via mailing list)
Ryan Leavengood wrote:
> Cool, this sounds like a plan David. This was exactly what I wanted my
> email to achieve. While we Ruby programmer's love the power and
> flexibility of re-opening classes, there are probably times when we
> all want to lock things down. Having the *option* of doing this
> shouldn't hurt anything, in my opinion.
>
> FYI, I'm not sure if what you propose is possible in pure Ruby (at
> least easily), so if you can hack C you might have to look into making
> a C extension or a patch to the interpreter. Hopefully it won't be so
> bad though.

$ cat freeze-core.rb
@classes = {}
def do_freeze(klass)
   klass.freeze
   @classes[klass] = true
end
ObjectSpace.each_object do |o|
   do_freeze(o) if o.is_a?(Class) and !@classes.has_key?(o)
end

$ ruby -r freeze-core -e 'puts "foo"'
foo
$ ruby -r rubygems -r freeze-core -e 'puts "foo"'
foo
$ ruby -r freeze-core -e 'class String; def len; "foo"; end; end'
-e:1: can't modify frozen class (TypeError)

Something like that?

It also struck me that the require mechanism could be hijacked to
enforce per-file namespacing to give something like Python's system,
which seems to work fairly well.  A require_ns() that wraps a module
named after the filename around the code it includes...  Would that
help?

--
Alex
9d1f5d2d9de70bd9a934f557dc95a406?d=identicon&s=25 Daniel ----- (liquid)
on 2006-05-06 12:52
(Received via mailing list)
Would this still allow extensions to an instance?  This should still be
allowed yes?

@obj.extend(something)
Dd76a12d66f843de5c5f8782668e7127?d=identicon&s=25 Mauricio Fernandez (Guest)
on 2006-05-06 12:52
(Received via mailing list)
On Sat, May 06, 2006 at 06:20:54PM +0900, Alex Young wrote:
> $ ruby -r freeze-core -e 'class String; def len; "foo"; end; end'
> -e:1: can't modify frozen class (TypeError)
...
> >>I'll work on some 'lock-down' code that will allow classes to lock
> >>themselves down from external modification (not Foo.freeze, but
> >>something more granular.)
    =======================

> It also struck me that the require mechanism could be hijacked to
> enforce per-file namespacing to give something like Python's system,
> which seems to work fairly well.  A require_ns() that wraps a module
> named after the filename around the code it includes...  Would that help?

Several implementations have been proposed on ruby-talk before; they
failed
in cases like

$ cat bad.rb
::String.class_eval do
#  forces top-level, defies our efforts to wrap it
  def size; 0 end
end
$ cat naive.rb

a = "foo"
p a.size
load("bad.rb", true)
p a.size
p $"

$ ruby naive.rb
3
./bad.rb:3: warning: method redefined; discarding old size
0
[]

See http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/... for
another proposal.
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-06 13:19
(Received via mailing list)
> $ ruby -r freeze-core -e 'puts "foo"'
> which seems to work fairly well.  A require_ns() that wraps a module
> named after the filename around the code it includes...  Would that help?

Here are my ideas (bearing in mind that I am not much of a Ruby
programmer):

I don't want any of my classes frozen. Say I want all string objects
passed to my function to be able to represent themselves in a certain
way...
ie. my function needs strings in culy braces. So the natural thing for
me would be this:

class String
  def curlify
    "{"+self+"}"
  end
end

This is where I need the curlies and it makes sense for them to be
there.

I even want to be able to say:
require "curlystrings"

And have my strings be able to be curly.

What might be better, though is something like this:

irb> require "curlystrings"
unsafe require, "curlystrings.rb" attempts to add new definition
"curlyify" to existing class "String" in line 5 of
"/home/lesliev/curlystrings.rb". You may want to use
require_over_existing.

irb>
irb> require_over_existing "curlystrings"
=> true

That's the one thing - if I require something, it can't modify
pre-existing classes without me authorizing that.

The other thing is that a gem or library should not be loaded unless I
"require" it. This was the Glue problem. So unless I say "require",
what is not listed in the "built in classes and modules" part of the
Ruby manual should not be part of my environment.

Is this all reasonable?
A52b0e1c5d982f2512a03c5dbfd033d6?d=identicon&s=25 Dick Davies (Guest)
on 2006-05-06 13:58
(Received via mailing list)
On 06/05/06, Leslie Viljoen <leslieviljoen@gmail.com> wrote:

> ie. my function needs strings in culy braces. So the natural thing for
> me would be this:
>
> class String
>   def curlify
>     "{"+self+"}"
>   end
> end
>
> This is where I need the curlies and it makes sense for them to be there.

But then you've tampered with the very fabric of reality (HPL would be
proud) [1].

You could just modify the object you were passed:

def func_that_needs_strings_to_have_a_curlify_method(str)
  def str.curlify
    "{" + self + "}"
  end

  # do something with str
end

This has the side effect on permanently adding a curlify method to
whatever
str points at, but not all Strings in the universe.

You might not want that, of course - but it has less impact than
modifying all strings. (If you only wanted that method to apply with
your
function, you could dup the object you were passed before meddling
with it.

Obviously this example is a bit contrived, but if you were redefining
something like the length() method, it would be saner to limit the
effect
of that.

[1] The ability to meddle with the fabric of reality is a feature, not
a bug, IMO. One of my fondest programming memories is the funny looks I
got
when I discovered I could redefine Integers '+' method to always return
2.
I don't cackle often :)
Cff9eed5d8099e4c2d34eae663aae87e?d=identicon&s=25 Jacob Fugal (Guest)
on 2006-05-06 16:24
(Received via mailing list)
On 5/6/06, Leslie Viljoen <leslieviljoen@gmail.com> wrote:
> The other thing is that a gem or library should not be loaded unless I
> "require" it. This was the Glue problem. So unless I say "require",
> what is not listed in the "built in classes and modules" part of the
> Ruby manual should not be part of my environment.

This is already the way it is done. No libraries are loaded until
required. Not even from the standard library. The only ones there
without an explicit require are the core libraries. (Standard library
only means that the library is always *present*, ready to be required,
without you needing to install anything -- unless you're on some older
flavors of debian/ubuntu).

If the library's being loaded, it's because *someone* is requiring it.
Obviously, in the case mentioned, it wasn't the end user; not
directly, anyways. But some library the *was* included directly was
including Glue *for* them. Probably with some fancy logic that says,
"Well, if Glue's not available, we can do it ourself, no need to make
them install it... but if Glue *is* available, let's use it!" So the
application worked without Glue being installed, but as soon as Glue
was installed, it got required into the project automatically. Not
because Ruby sucked it in automatically, but because some other
library did.

Jacob Fugal
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-06 18:31
(Received via mailing list)
On 5/6/06, Dick Davies <rasputnik@gmail.com> wrote:
> >
>   end
> with it.
Yes... and if I have 50 functions that need curlify? How would I add
curlify to all strings that are passed to methods in my module, for
example?
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-06 19:38
(Received via mailing list)
On 5/6/06, Jacob Fugal <lukfugl@gmail.com> wrote:
> without you needing to install anything -- unless you're on some older
> because Ruby sucked it in automatically, but because some other
> library did.

I guess Rails did it. There's this ticket:
http://dev.rubyonrails.org/ticket/2255
which may give a clue to the problem, but I don't understand it.
I previously had the discussion about Glue and Rails here:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/...

On Kubuntu I have Ruby 1.8.3 installed and if I print out $" I get
nothing,
indicating no "features" have been loaded. On windows, Ruby 1.8.4 and
the 1-click installer, I get 25 files, including a lot from rubygems,
forwardable.rb, time.rb, parsedate.rb, format.rb, rational.rb,
openssl.rb,
and fcntl.rb. Where did all that come from? How did those files get
loaded?
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-06 19:44
(Received via mailing list)
> indicating no "features" have been loaded. On windows, Ruby 1.8.4 and
> the 1-click installer, I get 25 files, including a lot from rubygems,
> forwardable.rb, time.rb, parsedate.rb, format.rb, rational.rb, openssl.rb,
> and fcntl.rb. Where did all that come from? How did those files get loaded?

hmm, I remember asking for ruby gems to be enabled when I installed. I
suppose it's possible that ruby gems pulled in all 25 of those files?
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-05-06 20:45
(Received via mailing list)
On May 6, 2006, at 12:30 PM, Leslie Viljoen wrote:

>> >   end
>>
>> str points at, but not all Strings in the universe.
>
I've been thinking about this recently.

#curlify and friends aren't really instance methods for strings, but
the functuality isn't dramatically different enough to create a
subclass. What curlify really is, is a function that we want to be
able to call like str.curlify instead of curlify(str). Ruby already
has a mechanism for declaring 'functions', private methods on object.
Why not use that? You don't even _have_ to write it
def curlify(str)
   "{#{str}}"
end

you can do this:

public
def curlify
    "{#{self}}"
end

This has many advantages over monkeying about in other classes.

first, as a general rule people expect you to add methods to Object
(it's how ruby does top level functions after all)

Secondly, it won't kill any pre-existing definition of curlify. Any
other class that does it's own curlify is going to override it, so
it's safe from your meddling. Consider the case that curlify is added
to core, but does some thing else, some thing else useful to other
String methods, and is used in the new implementations of many of
them. You won't have broken String since your curlify is higher in
the inheritance chain, the only thing that will have been broken is
your curlify, which will probably be easier to spot, since there's a
good chance you wrote unit tests for your curlify (but probably not
for every method in the String class).

Now, I know it looks funny not having this method inside a class, but
it doesn't  realy belong in String anyway, and in pretty much any
other language you would have made it a function ( curlify(str) ) or
sub-classed String. It's only because of ruby's openn classes that
people get encouraged to change core classes to make life easier. I
figure
public
   def meth(...)
   end


is  even easier, and less typing than

class SomeClass
   def meth(...)
   end
end

and it puts it in the same territory as top-level functions (e.g.
this is for this particular program's  convenience.)

Plus if you want  to avoid namespace pollution just stick this
methods in a module and include the module

e.g.

module Curlify
   def curlify
      "{#{self}}"
   end
end

include Curlify
Cff9eed5d8099e4c2d34eae663aae87e?d=identicon&s=25 Jacob Fugal (Guest)
on 2006-05-06 20:45
(Received via mailing list)
On 5/6/06, Leslie Viljoen <leslieviljoen@gmail.com> wrote:
> > indicating no "features" have been loaded. On windows, Ruby 1.8.4 and
> > the 1-click installer, I get 25 files, including a lot from rubygems,
> > forwardable.rb, time.rb, parsedate.rb, format.rb, rational.rb, openssl.rb,
> > and fcntl.rb. Where did all that come from? How did those files get loaded?
>
> hmm, I remember asking for ruby gems to be enabled when I installed. I
> suppose it's possible that ruby gems pulled in all 25 of those files?

It's very possible. I know from experience with other questions on
this list that requiring rubygems (e.g. the -rubygems switch on the
command line) will pull in rational.rb through a lengthy dependency
chain. I wouldn't be surprised if those other libraries are all pulled
in by rubygems (several of them indirectly, same as rational.rb).

Jacob Fugal
37ee5fa90f5eaeef62553629382497f7?d=identicon&s=25 Leslie Viljoen (Guest)
on 2006-05-06 21:19
(Received via mailing list)
>
> include Curlify

Awesome! Problem easily solved, as usual.
I guess the only downside is that I can now "3.curlify". But then I
can also curlify anything that behaves like a string, which is what
duck typing is all about.
4ab06a38273fa1f5f14bbbca592ee031?d=identicon&s=25 rob (Guest)
on 2006-05-11 22:38
(Received via mailing list)
Re-opening classes is one of the things that makes ruby great. We
frequently re-open classes on public libraries and frameworks to wrap
methods with our own methods to add in-house functionality while not
altering the core functioning of those libraries.

If you write your code you want to be unmodifiable in an interpreted
language you need your head examined. This isn't at all ruby-like and
unless you lock out compiled extensions (bye bye native database
drivers, etc) then you can't stop people circumventing any protection
mechanism you come up with either.

Why so precious? If you don't want people to modify your code say so.
If they go ahead and it blows up it's their fault. If you really did
write your secure important application you wished to be tamper-
resistant in ruby then you demanded to host it on your own secure
servers when you made the contract. If you didn't, you should have.

Think about it...
34f159f89cbd1d9beac0276f5a7af552?d=identicon&s=25 John Gabriele (Guest)
on 2006-05-11 23:06
(Received via mailing list)
On 5/11/06, rob <rob@motionpath.com> wrote:
> Re-opening classes is one of the things that makes ruby great. [snip]
>
> Why so precious? If you don't want people to modify your code say so.
> If they go ahead and it blows up it's their fault.

Not to take any sides, but I think I've heard the argument go: if
you're working on a team on a large project, and all of a sudden
"your" class breaks, management doesn't want to hear about someone
else opening your class... they'll just see your name on the class
causing the hold-up and then it *becomes* your problem.

In the typical "enterprise scale" cubicle farm environment, team
leaders are constantly looking to find someone to blame for the
project being behind. B&D languages like Java lend themselves to rigid
compartmentalization that yields paper trails.

It's interesting to think about the dynamic there -- between the
language and the cube farm.
4ab06a38273fa1f5f14bbbca592ee031?d=identicon&s=25 rob (Guest)
on 2006-05-11 23:43
(Received via mailing list)
Then they just need run 'svn ann' or equivalent for whatever RCS they
are using to clearly see which user created the the problem.

If employees constantly cause problems by doing this then tell them
to stop it. If they won't then they're bad employees.

I don't think we should cripple a language because a couple of
companies may have shoddy management and bad communication.

The reason I'm strongly against this is that publicly available
libraries will may end up freezing their classes "to keep everything
standardized" which would cause us headaches, and in particular me
since I'd end up writing the circumvention mechanism.

A proper revision control system yields a grand paper trail. Leave
tracking of revisions and who-wrote-what to the proper service, the RCS.

None the less, it was enlightening to learn some people thought this.
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2006-05-11 23:53
(Received via mailing list)
On 5/11/06, John Gabriele <jmg3000@gmail.com> wrote:
>
> Not to take any sides, but I think I've heard the argument go: if
> you're working on a team on a large project, and all of a sudden
> "your" class breaks, management doesn't want to hear about someone
> else opening your class... they'll just see your name on the class
> causing the hold-up and then it *becomes* your problem.

Oh come on now, if that company is using Ruby they will be using unit
tests and I would hope, continuous integration and testing. Therefore
if the unit tests for a class break, they won't "blame" the original
author of that class, but whoever did the last submit.

Even in any decent Java shop, the same would apply. It is absurd to
have such strict "code-ownership" to such a level that a random
breaking of a class gets blamed on the "owner" of that class.

> In the typical "enterprise scale" cubicle farm environment, team
> leaders are constantly looking to find someone to blame for the
> project being behind. B&D languages like Java lend themselves to rigid
> compartmentalization that yields paper trails.

Only bad team leaders or managers pull crap like that, and unless the
whole company is rotten with bad management (which means it probably
wouldn't last long), at some point someone is going to call those team
leaders on their crap.

> It's interesting to think about the dynamic there -- between the
> language and the cube farm.

What I hope we'll see is all those "enterprise" companies and their
cube farms and Java code eaten alive by small, dynamic, happy teams of
Ruby coders who don't have to deal with all that nonsense.

Ryan
34f159f89cbd1d9beac0276f5a7af552?d=identicon&s=25 John Gabriele (Guest)
on 2006-05-12 04:05
(Received via mailing list)
On 5/11/06, Ryan Leavengood <leavengood@gmail.com> wrote:
> if the unit tests for a class break, they won't "blame" the original
> author of that class, but whoever did the last submit.

Point well taken.

> leaders on their crap.
Sorry. I've got a pretty small sample size and shouldn't have written
"typical".

> > It's interesting to think about the dynamic there -- between the
> > language and the cube farm.
>
> What I hope we'll see is all those "enterprise" companies and their
> cube farms and Java code eaten alive by small, dynamic, happy teams of
> Ruby coders who don't have to deal with all that nonsense.

Agreed.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2006-05-12 05:19
(Received via mailing list)
> What I hope we'll see is all those "enterprise" companies and their
> cube farms and Java code eaten alive by small, dynamic, happy teams of
> Ruby coders who don't have to deal with all that nonsense.

+1 for the most part.

I don't think it necessarily needs to be language specific, but that
the juggernaut should give way to more agile and sensible approaches.

good points though.
This topic is locked and can not be replied to.