Sharp knives and glue

Ruby
1

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

2

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.

3

On May 2, 2006, at 5:33 PM, Leslie V. 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

4

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 [email protected] 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.

–

5

Leslie V. 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.

6

On 5/2/06, Daniel H. [email protected] 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.general/110876
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.

7

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

8

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+about+weakly+typed+languages+and+design+by+contract

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+must+be+careful

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.

9

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 P. 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 P.'s Ruby Playground
http://dppruby.com

–
M. Edward (Ed) Borasky

10

On 5/2/06, Leslie V. [email protected] 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.

–

11

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.

12

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.

13

Thanks for the reply!

On 5/3/06, Francis C. [email protected] 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.

14

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.

15

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.

16

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

17

Francis,

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

On 5/2/06, Francis C. [email protected] 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 M.o 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?

18

In all candor, I wouldn’t want to hand an undisciplined or poor-quality
programmer any 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! :wink: I suspect what you meant to say is:
should we
hand such tools to inexperienced 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.

19

On May 3, 2006, at 10:46 AM, David P. 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 G. II

20

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.