"stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )<Pine.LNX.4.44.0311171402340.1133-100000@ool-435 5dfae.dyn.optonline.net>

ruby-talk
21

Austin Ziegler austin@halostatue.ca writes:

Consider generics in Java (templates in C++). These effectively
introduce the sort of dynamicity that is found in Perl, Python, and
Ruby. Instead of having to do:
int max(int x, int y) { return x >= y ? x : y }
float max(float x, float y) { return x >= y ? x : y }
double max(double x, double y) { return x >= y ? x : y }
You can do:
def max(x, y); x >= y ? x : y; end
I know which I would prefer, and C++'s move toward generics is a
halting step toward that step.

BTW, to see a different point of view, you might investigate
Ocaml (or other ML languages, or Haskell). Ocaml is strongly,
statically type-checked. Here is max:

let max x y = if x > y then x else y

(Note that there are no type declarations!)

# max 3 4;;
- : int = 4
# max 3.0 4.0;;
- : float = 4

Why does this work? How can max return an int the first time, and
a float the second? Because the type declaration for max (as
inferred by the compiler) is:

 max : 'a -> 'a -> 'a = <fun>

That is, max takes two arguments, of type 'a (whatever that
happens to be), and returns something of the same type. So
when it is called with two ints, it returns an int, and
when called with two floats, it returns a float. And when
called with one of each? The compiler generates an error:

# max 3 4.0;;
    ^^^
This expression has type float but is here used with type int

Compile-time type-checking, with no type annotations!

My point being, C++ and Java are not the extent of statically-typed
languages. In fact, I suspect what most people here hate is not
static typing, but mandatory type annotation.

Someone also said that types are for compilers, not developers.
Wrong: They’re for both. The compiler can generate better code with
types; developers can use it as documentation, and can express
useful constraints. That’s why Ocaml supports type declarations,
even though you can write programs without them.

(Oh, just to be clear – I love Ruby.)

···

–
Steven
“I buried Flanders.”

23

No, type checking based on class inheritance (and mix-ins) is
completely fine. Just think of the checking not as “type
enforcement” but as “interface declaration.”

Class != type. Type checking on inheritance is, IMO, explicitly a
bad thing in Ruby.

A class is a declaration which says “I do this.”

No. A class is a declaration which says “I am this.” There is a
difference, and it’s this difference that I think people aren’t
getting. As I noted earlier, a StringIO does not inherit (at all!)
from either String or IO, but it conforms to the expectations of
both. Name-based type checking would unnecessarily restrict your
capabilities.

The programmers just needs to know.

RDoc handles this. If you need programmatic discovery of this
information for RPC dynamism or GUI object inspectors, then I’d
agree with you that it’s useful. But otherwise, YAGNI.

It’s good to have the mechanism like that, I agree, even I put
the feature in my latest slides. But there’s still long way to
design and implement it efficiently, if I am right.

Matz: note that Python went through this discussion five years ago
and it still doesn’t have it. I’m not sure Ruby really needs it,
either. The only thing that I think Ruby could use is a standardized
way of publishing method signature information for the cases I’ve
outlined.

If a programmer goes out of his way to change the object
radically, fine, it will break just like it breaks now. No harm
done.

Bollocks. You’ve been given several examples as to how it would
break things, especially Ruby’s dynamism.

The alternative would be to enforce that all expected methods and
parameters are present in a precise form, and that would be
insanely strict.

No, the alternative is to document and assume that the programmer’s
not an idiot. You don’t have to typecheck; just use the methods
expected.

Some people will need it occassionally, probably library
developers mostly.

As someone who has primarily developed libraries, I can tell you
that I haven’t needed it. I suspect most of the users of my
libraries wouldn’t want it, either.

Re: static or strong typing in Ruby? YAGNI.

-austin (My initial efforts were pretty heavily typed, too – I learned
better)

···

On Thu, 20 Nov 2003 04:45:56 +0900, Sean O’Dell wrote:

austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.19
* 15.28.59

24

Likely not. Because if you’re looking at choosing a scripting
language based on its type-checking, you’re excluding the vast
majority of modern scripting languages including Perl, Python,
JavaScript, and Ruby.
Exactly my point. People are sticking with C++ where they could
really benefit from moving to a script language like Ruby, or
they’re learning Java and they’re stuck being C++/Java
programmers.

I somehow doubt it.

[snip]

Again: consider the words of Bruce Eckels. The man knows what
he’s talking about and is amazed by the power of not statically
type checking. It’s saved him loads of work. You want to add the
work back into Ruby development. Optionally, I grant, but part
of what a language designer like Matz must consider, is what
changes like you’re talking about would mean to the “culture” of
the language. If people start using an “optional” method
signature mechanism for type name enforcement, then that changes
the assumed and actual dynamicity of Ruby. I suspect that the
number of people thinking “ah screw it” are few and far between
and instead are feeling liberated from having to specify types
unnecessarily.
The programmers who jump into Ruby, yes. Their managers, no. There
are requirements in the real world that go beyond “what feels
good” and some of it has a basis in reality. Being able to ask
what interface an object implements does a lot to make up for bad
documentation and crazy error messages. On large, multi-developer
projects, and with poorly documented libraries, this gets proven
every single day. Type checking, in whatever form it takes, helps
a LOT.

This is pointy-haired boss twaddle. Type checking does not help
either the developer or the project – it helps the compiler. I’ve
worked on very large scale projects and type checking did nothing to
help. In fact, it is my professional experience that type checking
harms the project because it encourages the (improper) concept that
“if it compiles, it must be okay.” Again: read the Eckels article.

Ruby is also in large scale production use in several places
(including Amazon), and doesn’t use static typing.

Managers don’t know the upsides or downsides to static typing.
Most of them won’t actually have a clue as to what the term means.
There are legitimate reasons to use C, C++, and Java. Static typing
isn’t one of them, and I can’t think of a single manager in my past
who would argue that it would be. Some developers, perhaps, but they
are also people who didn’t have exposure to dynamically typed
object systems and languages.

Consider generics in Java (templates in C++). These effectively
introduce the sort of dynamicity that is found in Perl, Python,
and Ruby. Instead of having to do:
int max(int x, int y) { return x > = y ? x : y }
float max(float x, float y) { return x > = y ? x : y }
double max(double x, double y) { return x > = y ? x : y }

You can do:
def max(x, y); x > = y ? x : y; end

I know which I would prefer, and C++'s move toward generics is a
halting step toward that step.
I loath templates. But I know what you mean.

I don’t like C++ templates, but they’re better than the alternatives
available to C++.

I am not an advocate for strong static typing. I only advocate a
reasonable assurance that an object implements a certain
interface.

As Matz has said, there’s no clean way to do this in Ruby at this
point. Simply doing name checking (whether interfaces or
inheritance) doesn’t ensure compliance, so it actually buys us
absolutely nothing more than assuming we have the right object to
begin with.

It’s not that I don’t want to listen: it’s that type checking
doesn’t help in the real world. Ruby is used in a number of real
world large-scale projects.
No, it is not. Perhaps one day.

You don’t know what you’re talking about:

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

One of the things not mentioned there is that Ruby is also used in
the Amazon apparel store (see [ruby-talk:54605]). All of these have
been done without type checking.

[…]

I really think doing some form of intelligent, flexible interface
checking will put Ruby a notch up in a lot of C++/Java developer’s
eyes. It won’t be static type checking, but you can bill it as a
suitable replacement, and I’m sure that’d be good enough for most
water-cooler discussions.

shrug I don’t think that it’s necessary. Most people I’ve talked
to have been convinced that Ruby’s worth looking at because of the
deep object orientation.

Useless runtime processing.
Listen. My thoughts on this were already written. I said it could
be shut off at runtime.

A NOOP still costs performance. Further, since most things can be
redefined at runtime (there are very few keywords in Ruby), it’s not
exactly something that can be turned off.

I tend to open the code and look at it.
That’s you. Don’t make the assumption that performing such a task
is fine for everyone. That’s not a language feature, that’s a
personal habit.

It seems to be the nature of many Ruby developers.

Obviously, you’re not speaking about that which you know. I
recommend against it. I’ve done plenty of C, C++, Java, and
Pascal programming – as well as truly strongly typed languages
(Ada, PL/SQL). Ada provides type checking that is truly useful
(and exceedingly annoying because of its inflexibility), not the
half-assed crap you get in C and C++. I’ve had to write two to
twenty times the amount of code in C/C++, Java, or Pascal to do
the same amount of work in Ruby. Not only that, my Ruby handles
more types than my equivalent statically typed code.
You know what Ziegler? If you toss around insults, I’m simply
going to ignore you. Telling a man who’s programmed for 20 years,
the last 12 of which were in C++ that he doesn’t know about C++ is
extremely presumptuos and insulting. If you want to start talking
to air, keep insulting me.

I’m not insulting you. You suggested that because I don’t like
static typing, I must not program in statically typed languages and
therefore don’t know what I am talking about. You demonstrably
don’t know what you’re talking about when it comes to my knowledge
and background. I may not have twenty years under my belt, but I’m
not about to pretend that static typing is a boon for anyone when
some very bright people (like Bruce Eckels) are coming to realize
that dynamic typing is a very good thing.

Still don’t like it. I’d accept method signature publication that
Fact is, it doesn’t seem like you like anything I say, so I think
my thread with you is at an impasse.

No, I don’t like what you’ve proposed. Propose something that is
useful and I can see supporting it. So far, you’ve suggested
something that does not add value or hasn’t been done by others
(namely Ryan Pavlik’s metadata module).

-austin

···

On Thu, 20 Nov 2003 08:19:08 +0900, Sean O’Dell wrote:

On Wednesday 19 November 2003 03:00 pm, Austin Ziegler wrote:
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.19
* 19.26.11

25

[snip]

At the recent lightweight languages conference, some BBN people gave a
talk on ACME (“a parallel agent system for testing used in UltraLog, a
DARPA effort aimed at creating an ultra-survivable multi-agent
society”), that’s driven by Ruby. I believe Rich Kilmer was involved in
writing the underlying Ruby infrastructure. They have video, it’s the
first presentation in Session 1.

http://ll3.ai.mit.edu/

Regards,

Mark

···

On Nov 19, 2003, at 6:19 PM, Sean O’Dell wrote:

[snip]

It’s not that I don’t want to listen: it’s that type checking
doesn’t help in the real world. Ruby is used in a number of real
world large-scale projects.

No, it is not. Perhaps one day. But not right now. Java and C++ own
that
distinction, and I think if called the conglomeration of scripts
written in
Perl that I’ve seen thrown together in one directory a “project” then
I think
Perl is a runner-up. Perhaps if you could all the interface code that
PHP
has generated, it would also be up there somewhere. Ruby is used in
some
fair-sized projects, but I can’t think of a single large, successful
one
right now.

26

Austin Ziegler austin@halostatue.ca writes:

Consider generics in Java (templates in C++). These effectively
introduce the sort of dynamicity that is found in Perl, Python, and
Ruby. Instead of having to do:
int max(int x, int y) { return x >= y ? x : y }
float max(float x, float y) { return x >= y ? x : y }
double max(double x, double y) { return x >= y ? x : y }
You can do:
def max(x, y); x >= y ? x : y; end
I know which I would prefer, and C++'s move toward generics is a
halting step toward that step.

BTW, to see a different point of view, you might investigate
Ocaml (or other ML languages, or Haskell). Ocaml is strongly,
statically type-checked. Here is max:

let max x y = if x > y then x else y

(Note that there are no type declarations!)

# max 3 4;;
- : int = 4
# max 3.0 4.0;;
- : float = 4

But in Ocaml

3.4 + 1.2

is not allowed, as + is only defined on integers (there’s no type
overloading). So you have to use +. for floating point addition, *. for
multiplication, print_int, print_string, print_float etc. Sometimes,
that’s pretty ugly , IMHO.

Why does this work? How can max return an int the first time, and
a float the second? Because the type declaration for max (as
inferred by the compiler) is:

 max : 'a -> 'a -> 'a = <fun>

Indeed, this does only work, as the comparison operators are defined
internally for every type. You cannot do this with your own funtioncs,
say:

if (greater x y) then x else y

This is where Haskell & Co is clearly better (or GCaml, generic OCaml).

Regards,

Michael

···

On Thu, Nov 20, 2003 at 01:12:15PM +0900, Steven@ruby-lang.org wrote:

27

No, type checking based on class inheritance (and mix-ins) is completely
fine.

No, no, matz is right : it's bad

Don't forget that I've written and *used* this

svg% cat b.rb
#!./ruby
class A
   def tt(Enumerable a)
      p "I respond to #each : #{a.inspect}"
   end

   def tt(Kernel a)
      p "I don't know #each : #{a.inspect}"
   end
end

a = A.new
a.tt([1, 2])
a.tt("string")
a.tt(A.new)

svg%

svg% b.rb
"I respond to #each : [1, 2]"
"I respond to #each : \"string\""
"I don't know #each : #<A:0x4009c360>"
svg%

Guy Decoux

28

It’s not, but if you look at a class as one form of interface declaration, it
can be. If a class has String in its ancestry, I can expect an object of
that type to contain all the methods that the String class implements. So,
you CAN think of an object that has String in its ancestry to declare “I
implement the String interface.”

Sean O'Dell
···

On Wednesday 19 November 2003 11:50 am, Chad Fowler wrote:

On Thu, 20 Nov 2003, Sean O’Dell wrote:

A class is a declaration which says “I do this.”

This is the root of the misunderstanding. A class is a convenient
collection of behaviors that can be applied, like a template, to an
object. In Ruby, it’s not a declaration.

29

No, type checking based on class inheritance (and mix-ins) is
completely fine. Just think of the checking not as “type
enforcement” but as “interface declaration.”

Class != type. Type checking on inheritance is, IMO, explicitly a
bad thing in Ruby.

I’ve already said I don’t want type checking. I’ve used that term
incorrectly. All I want is a declaration that an object implements a certain
interface.

A class is a declaration which says “I do this.”

No. A class is a declaration which says “I am this.” There is a
difference, and it’s this difference that I think people aren’t
getting. As I noted earlier, a StringIO does not inherit (at all!)
from either String or IO, but it conforms to the expectations of
both. Name-based type checking would unnecessarily restrict your
capabilities.

Okay, again, terminology. When I say an object declares “I do this” I am not
speaking about the function of one or more methods. I am talking about the
entire purpose of the class, which I equate to “I am this.”

It’s good to have the mechanism like that, I agree, even I put
the feature in my latest slides. But there’s still long way to
design and implement it efficiently, if I am right.

Matz: note that Python went through this discussion five years ago
and it still doesn’t have it. I’m not sure Ruby really needs it,
either. The only thing that I think Ruby could use is a standardized
way of publishing method signature information for the cases I’ve
outlined.

A good system of method signatures serves the same purpose in my mind, if
they’re convenient enough to call that we can expect people to actually use
them where they’re needed, and not avoid them because they’re a pain to use.

Either way, the called method can ask “does this object do what I want?” which
is all I am after.

If a programmer goes out of his way to change the object
radically, fine, it will break just like it breaks now. No harm
done.

Bollocks. You’ve been given several examples as to how it would
break things, especially Ruby’s dynamism.

Huh? I know how it breaks things. Right now, an error occurs deep in someone
else’s code. Sooner or later, that’s simply going to happen.

The alternative would be to enforce that all expected methods and
parameters are present in a precise form, and that would be
insanely strict.

No, the alternative is to document and assume that the programmer’s
not an idiot. You don’t have to typecheck; just use the methods
expected.

True, that’s what we have now. I guess doing nothing is an option.

Some people will need it occassionally, probably library
developers mostly.

As someone who has primarily developed libraries, I can tell you
that I haven’t needed it. I suspect most of the users of my
libraries wouldn’t want it, either.

As someone who has developed libraries in Lisp, C, C++, Java, Ruby, Perl,
Visual Basic, Delphi, Pascal, bash shell, as well as developing O’Basic, a
complete script language itself, I can tell you that I have always tried to
make life easier for the developers who have had to use my libraries.

If you don’t want to provide type checking to your users, then you are not
putting yourself in their shoes when something goes wrong because they passed
in the wrong object. You are intimately knowledgable about your code whereas
they are not. It’s entirely frustrating to get errors messages fly out from
deep in someone else’s code, and not a single word about what type of object
is expected. If you document your library, that’s fantastic, but
documentation does not always evolve in perfect sync with the code, and many
libraries are either devoid of documentation or are poorly documented thusly.

Sean O'Dell
···

On Wednesday 19 November 2003 12:29 pm, Austin Ziegler wrote:

On Thu, 20 Nov 2003 04:45:56 +0900, Sean O’Dell wrote:

30

On Thu, 20 Nov 2003 04:45:56 +0900, Sean O’Dell wrote:

> No, type checking based on class inheritance (and mix-ins) is

> completely fine. Just think of the checking not as "type

> enforcement" but as “interface declaration.”

···

On Thu, 20 Nov 2003, Austin Ziegler wrote:

Class != type. Type checking on inheritance is, IMO, explicitly a

bad thing in Ruby.

Does “IMO” mean “In Matz’s Opinion”? I’m joking of course, but the answer
is (also) yes.

31

Exactly my point. People are sticking with C++ where they could
really benefit from moving to a script language like Ruby, or
they’re learning Java and they’re stuck being C++/Java
programmers.

I somehow doubt it.

Well, I’m a senior developer/team leader. I have been considering moving
the team from “c” to ruby. However I have doubts that the lower-level
programmers can handle development without any type-checking support. So
we will probably move to either Java or c#.

That doesn’t mean I don’t like Ruby - personally, I love it.

However I have noticed that I need to “read the source” far more often
than with Java libraries, and correctly interpreting the source requires
experience.

It’s not that I don’t want to listen: it’s that type checking
doesn’t help in the real world. Ruby is used in a number of real
world large-scale projects.
No, it is not. Perhaps one day.

You don’t know what you’re talking about:

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

One of the things not mentioned there is that Ruby is also used in
the Amazon apparel store (see [ruby-talk:54605]). All of these have
been done without type checking.

I think the referenced page proves the point pretty well. There is only
one entry there that I would consider of anything less than “minor”
scale:

“We used Ruby to develop a complete Web Application Server and an
Object Oriented database”

All the others are one-person-three-month type projects.

Now I know that Python has been used to generate significant-sized
projects, and I have heard rumours that Smalltalk has also. I’m not sure
if any of those projects included run-of-the-mill programmers, like most
commercial projects will.

Can anyone give any example of dynamically-typed programming languages
used to develop apps of more than 12-man-months size, including
programmers with skills of a level typically found in commercial
companies?

I would love to do a comparative experiment myself; one team with Java
and one with Ruby. Just not sure the boss would fund it :slight_smile:

Regards,

Simon

···

On Thu, 2003-11-20 at 14:06, Austin Ziegler wrote:

32

The programmers who jump into Ruby, yes. Their managers, no. There
are requirements in the real world that go beyond “what feels
good” and some of it has a basis in reality. Being able to ask
what interface an object implements does a lot to make up for bad
documentation and crazy error messages. On large, multi-developer
projects, and with poorly documented libraries, this gets proven
every single day. Type checking, in whatever form it takes, helps
a LOT.

This is pointy-haired boss twaddle. Type checking does not help
either the developer or the project – it helps the compiler. I’ve
worked on very large scale projects and type checking did nothing to
help. In fact, it is my professional experience that type checking
harms the project because it encourages the (improper) concept that
“if it compiles, it must be okay.” Again: read the Eckels article.

I really feel this is just personal experience talking now. I’ve shared code
with developers on both typed and untyped code bases, and ALWAYS it’s the
typed code that they have less trouble with and ends up getting screwed up
the least when they add code or make calls to my code. The untyped code
ALWAYS went to crap and became an unusable tangled mess after a point, and
was ALWAYS refactored several times or converted to typed code (C++). The
typed code almost always stayed alive and was easy to merge and use.

Ruby is also in large scale production use in several places
(including Amazon), and doesn’t use static typing.

Amazon is large, but how large is their deployment of Ruby?

Managers don’t know the upsides or downsides to static typing.
Most of them won’t actually have a clue as to what the term means.
There are legitimate reasons to use C, C++, and Java. Static typing
isn’t one of them, and I can’t think of a single manager in my past
who would argue that it would be. Some developers, perhaps, but they
are also people who didn’t have exposure to dynamically typed
object systems and languages.

Managers are generally programmers who don’t program as much as they look at
code and try to help people design integration. They like typing because it
helps them understand the code. Typing helps. Like it or not. I’m not
saying Ruby sucks because it’s untyped, I’m saying typing helps.

I loath templates. But I know what you mean.

I don’t like C++ templates, but they’re better than the alternatives
available to C++.

Sometimes I felt forced to use templates, but I still loathed them. In fact,
there’s quite a bit about the C++ specification I am at odds with.

I am not an advocate for strong static typing. I only advocate a
reasonable assurance that an object implements a certain
interface.

As Matz has said, there’s no clean way to do this in Ruby at this
point. Simply doing name checking (whether interfaces or
inheritance) doesn’t ensure compliance, so it actually buys us
absolutely nothing more than assuming we have the right object to
begin with.

I agree there’s probably no efficient way to offer guarantees. I agree doing
something like that would be way too off-the-path for Ruby. But I don’t
think that a half-promise is useless.

One of the things not mentioned there is that Ruby is also used in
the Amazon apparel store (see [ruby-talk:54605]). All of these have
been done without type checking.

I have no idea how to refer to [ruby-talk:54605], but I’ll assume that Amazon
uses Ruby as the backend for their apparel store. That’s good to hear, but
it doesn’t mean it can scale out to other things very easily. The larger it
spreads out, the more typing is handy.

I really think doing some form of intelligent, flexible interface
checking will put Ruby a notch up in a lot of C++/Java developer’s
eyes. It won’t be static type checking, but you can bill it as a
suitable replacement, and I’m sure that’d be good enough for most
water-cooler discussions.

shrug I don’t think that it’s necessary. Most people I’ve talked
to have been convinced that Ruby’s worth looking at because of the
deep object orientation.

This is a baby-and-bathwater issue. I still HATE that I can’t control when
objects die and that there’s no destructor. Yes, garbage collection is
nifty. Yes, I use yield now for doing cleanup, and it serves as a
replacement, but in the year or two I’ve been programming in Ruby, I still
hate that objects just hang around until the collector gets them, and I hate
that all I get is a finalizer.

I LOVE Ruby, but I don’t love that part, and probably never will.

Useless runtime processing.

Listen. My thoughts on this were already written. I said it could
be shut off at runtime.

A NOOP still costs performance. Further, since most things can be
redefined at runtime (there are very few keywords in Ruby), it’s not
exactly something that can be turned off.

I think the performance issue is blown out of proportion. Code gets added
with each release that adds more to the code base and does far less than what
a type checking mechanism would.

I tend to open the code and look at it.

That’s you. Don’t make the assumption that performing such a task
is fine for everyone. That’s not a language feature, that’s a
personal habit.

It seems to be the nature of many Ruby developers.

Which is a curious trait that I don’t share. And since, save for my
occassional ranting threads, there is little traffic in this newsgroup/list,
I am wondering if perhaps I’m just not “getting it” here and should move on
to something else.

When did the Ruby community become so hostile? I remember the last couple of
discussions I had, they were energetic but polite, and now it seems like a
war zone.

If you folks are dead-set in your ways and look unkindly upon people who
suggest that Ruby change and grow out off the beaten path a little, just say
the word. I’m a free soul here, I’m not signed up for anything in
particular. I like Ruby, and I think a lot of it is smart, but because it’s
free and flexible, not because there’s a hardened core of zealots who defend
it from change at all costs. This seems silly. I got an anonymous comment
on my RCR from someone calling my RCR “static typing.” That’s getting
ludicrous. What is that about? Is this what the community is boiling down
to?

Lighten up folks. Take my RCR and comment on it until it works.

Fact is, it doesn’t seem like you like anything I say, so I think
my thread with you is at an impasse.

No, I don’t like what you’ve proposed. Propose something that is
useful and I can see supporting it. So far, you’ve suggested
something that does not add value or hasn’t been done by others
(namely Ryan Pavlik’s metadata module).

Is that the Metatags module he has in RAA? I thought that was more of a
documentation thing that would be useful by parsers other than Ruby itself?
I kind of remember something about that. It was a YAML thing, was it not?

I don’t think it’s the same thing. I think it’s also dependent on the
developer keeping the code in sync with the metatags. I could be wrong.

Also, I think you are just disagreeing with me to disagree. Not once have I
heard a suggestion to alter my idea to make it work. It’s not set in stone.
It’s yours, it’s Matz’s, it’s everyone’s idea now. Talk and make it work.
Off my ass now, please. You understand me, the idea is written up as an RCR.
Go comment on it constructively.

Sean O'Dell
···

On Wednesday 19 November 2003 05:06 pm, Austin Ziegler wrote:

On Thu, 20 Nov 2003 08:19:08 +0900, Sean O’Dell wrote:

33

[snip]

It’s not that I don’t want to listen: it’s that type checking
doesn’t help in the real world. Ruby is used in a number of real
world large-scale projects.

No, it is not. Perhaps one day. But not right now. Java and C++
own that
distinction, and I think if called the conglomeration of scripts
written in
Perl that I’ve seen thrown together in one directory a “project” then
I think
Perl is a runner-up. Perhaps if you could all the interface code
that PHP
has generated, it would also be up there somewhere. Ruby is used in
some
fair-sized projects, but I can’t think of a single large, successful
one
right now.

[snip]

At the recent lightweight languages conference, some BBN people gave a
talk on ACME (“a parallel agent system for testing used in UltraLog, a
DARPA effort aimed at creating an ultra-survivable multi-agent
society”), that’s driven by Ruby. I believe Rich Kilmer was involved
in writing the underlying Ruby infrastructure. They have video, it’s
the first presentation in Session 1.

Yep. I wrote the ACME framework. Its a REAL framework written
completely in Ruby. Its over 20k lines at this point. It drives a
very big java application framework running on well over 100 machines
at a time (300 in all). Ruby configures and controls all the JVMs
across the network (its a multiagent system). It uses Jabber as a
system-to-system comm backbone. For each execution of the society,
there are over 100K jabber messages flowing across. About 15-20 folks
on the project have contributed Ruby code to the framework. We don’t
use strong typing, and it works beautifully.

···

On Nov 19, 2003, at 11:05 PM, Mark Wilson wrote:

On Nov 19, 2003, at 6:19 PM, Sean O’Dell wrote:

http://ll3.ai.mit.edu/

Regards,

Mark

34

Matz: note that Python went through this discussion five years
ago and it still doesn’t have it. I’m not sure Ruby really
needs it, either. The only thing that I think Ruby could use is a
standardized way of publishing method signature information for
the cases I’ve outlined.
A good system of method signatures serves the same purpose in my
mind, if they’re convenient enough to call that we can expect
people to actually use them where they’re needed, and not avoid
them because they’re a pain to use.

Either way, the called method can ask “does this object do what I
want?” which is all I am after.

What you’re talking about and what I’m talking about are two
different things. I’m talking about informative metadata, not
enforcement or error diagnostics. I’m also specifically talking
about it in the cases outlined – RPC and GUI object inspectors.

As someone who has developed libraries in Lisp, C, C++, Java,
Ruby, Perl, Visual Basic, Delphi, Pascal, bash shell, as well as
developing O’Basic, a complete script language itself, I can tell
you that I have always tried to make life easier for the
developers who have had to use my libraries.

I would suggest that you haven’t used my libraries, then. Because if
you had, you would know that your suggestion has nothing to do with
reality.

-austin

···

On Thu, 20 Nov 2003 06:02:05 +0900, Sean O’Dell wrote:

On Wednesday 19 November 2003 12:29 pm, Austin Ziegler wrote:
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.19
* 16.42.05

35

Well, I’m a senior developer/team leader. I have been considering moving
the team from “c” to ruby. However I have doubts that the lower-level
programmers can handle development without any type-checking support. So
we will probably move to either Java or c#.

That doesn’t mean I don’t like Ruby - personally, I love it.

That’s my experience. I love Ruby, but I just don’t see a large team working
together without at least SOME form of type checking.

However I have noticed that I need to “read the source” far more often
than with Java libraries, and correctly interpreting the source requires
experience.

Thank you, that was my point. It’s far easier to read the method definition
and see the types than to dig around in code. Good for smallish projects,
not efficient nor safe for large team projects.

I would love to do a comparative experiment myself; one team with Java
and one with Ruby. Just not sure the boss would fund it :slight_smile:

This was my point, too. At least with some type checking you could show that
Ruby would be at least as safe as Java, but with all the freedom of Ruby.
It’s a win-win. Hard to argue against.

Sean O'Dell
···

On Wednesday 19 November 2003 05:40 pm, Simon Kitching wrote:

36

Simon Kitching wrote:

Exactly my point. People are sticking with C++ where they could
really benefit from moving to a script language like Ruby, or
they’re learning Java and they’re stuck being C++/Java
programmers.

I somehow doubt it.

Well, I’m a senior developer/team leader. I have been considering moving
the team from “c” to ruby. However I have doubts that the lower-level
programmers can handle development without any type-checking support. So
we will probably move to either Java or c#.

That doesn’t mean I don’t like Ruby - personally, I love it.

I’m in the same position too. Love Ruby but cannot recommend it for
team development w/o having the language provides some sort of intrinsic
interface validation. I guess it’s the truism that no language can
satisfy everything - so just choose one that best fit the application.
Lacking this, does seems to limit the applications that ruby could be
used for - i.e. could be all implemented by one/two skilled programmers.
Most places I worked at will only deployed a limited set of supported
languages, and as much as I hate it, Python would be the next choice
(not that it is better for type check, but for other reasons).

One thing I find interesting is respond_to? was frequently cited as
a better way to handle the dynamism of Ruby than kind_of? - But, every
faults that was found with kind_of? could be applied to respond_to?
It also does ‘name only’ checking (name has no association with
behaviour), could easily be overridden in any other way the programmer
wanted to - in fact, I see method could be mangled much more easily than
class, so the defects propagates both way.

If we would believe that type checking is bad for Ruby, at least we
should be honest in saying that Ruby does not offer type checking,
as designed / or by its spirit,
and programmers must be willing to deal with it in intelligent way -
rather than offering a broken solution which automatically trigger
the question from newcomer - “Oh it does not quite work - how would
we fix this?” and trigger these kinds of flamefests on who is smarter
than whom.

This reminds me of my fascination with Python when it first come out
until was turned off by the uncompromising and strident attitude of
its proponents (not that Python did not turn out to be a very successful
language).

I do wonder what functional purpose does “kind_of?” serves now that it
was severely denigrated in the language - should it be deprecated/
removed? since it is considered totally bad style to use.

Regards

Thien

···

On Thu, 2003-11-20 at 14:06, Austin Ziegler wrote:

37

[…]

I’ve shared code with developers on both typed and untyped code
bases, and ALWAYS it’s the typed code that they have less trouble
with
[…]

I think that you’re assuming a conclusion not necessarily supported
by the facts. First, did you actually read the Eckels article? If
you did, you would see that Eckels is also a proponent of tested
code. Thus, the developers would have a set of unit tests to run.
One of the main reasons that Ruby code is successful without type
checking is that it’s part and parcel to see the code be well
tested. Testing is part of the Ruby culture.

Second, why did the untype-tested code turn into a sticky mess?
There are facts not in evidence here – were the developers
unfamiliar with the untype-tested language? Was it a lower priority?
Were those developers given adequate training on the untype-tested
language? Did the developers chosen for such languages have good,
discipline programming practices (I suspect not) or were there
strong coding guidelines (again, I suspect not).

I suspect you’re just using the terminology incorrectly, but Ruby
isn’t an untyped language. It is very strongly – but dynamically –
typed. What isn’t present is method signature introspection beyond
arity and presence. As I said, there are cases when more than this
would be useful, but that’s IMO/E a small subset of the universe of
programs for Ruby.

Managers don’t know the upsides or downsides to static typing.
Most of them won’t actually have a clue as to what the term
means. There are legitimate reasons to use C, C++, and Java.
Static typing isn’t one of them, and I can’t think of a single
manager in my past who would argue that it would be. Some
developers, perhaps, but they are also people who didn’t have
exposure to dynamically typed object systems and languages.
Managers are generally programmers who don’t program as much as
they look at code and try to help people design integration.

I don’t know where you’re working, but none of the companies where
I’ve worked have managers actually ever looked at the code that
I’ve worked on. That’s been left for senior developers (in the role
of mentor or team lead), designers, and architects. As a team lead
and senior designer, I would happily put people to work using a
dynamically typed language like Ruby (or Python, but I have a strong
prejudice against Python’s inconsistencies). But I’d also introduce
a rigorous test-first paradigm and make sure that my developers were
familiar with the language being used.

They like typing because it helps them understand the code. Typing
helps. Like it or not. I’m not saying Ruby sucks because it’s
untyped, I’m saying typing helps.

I think that TDD helps more than typing.

[…]

As Matz has said, there’s no clean way to do this in Ruby at this
point. Simply doing name checking (whether interfaces or
inheritance) doesn’t ensure compliance, so it actually buys us *
absolutely* nothing more than assuming we have the right object
to begin with.
I agree there’s probably no efficient way to offer guarantees. I
agree doing something like that would be way too off-the-path for
Ruby. But I don’t think that a half-promise is useless.

I do, because it’s not really a promise at all. It’s a claim.
Ultimately, we still have to verify – or potentially crash horribly
– that the claim is true.

One of the things not mentioned there is that Ruby is also used
in the Amazon apparel store (see [ruby-talk:54605]). All of these
have been done without type checking.
I have no idea how to refer to [ruby-talk:54605], but I’ll assume
that Amazon uses Ruby as the backend for their apparel store.
That’s good to hear, but it doesn’t mean it can scale out to other
things very easily. The larger it spreads out, the more typing is
handy.

[ruby-talk:54605] refers to this mailing list and its archive
message number. Try http://www.ruby-talk.org/54605/ for the original
announcement and thread.

shrug I don’t think that it’s necessary. Most people I’ve
talked to have been convinced that Ruby’s worth looking at
because of the deep object orientation.
This is a baby-and-bathwater issue. I still HATE that I can’t
control when objects die and that there’s no destructor. Yes,
garbage collection is nifty. Yes, I use yield now for doing
cleanup, and it serves as a replacement, but in the year or two
I’ve been programming in Ruby, I still hate that objects just hang
around until the collector gets them, and I hate that all I get is
a finalizer.

I LOVE Ruby, but I don’t love that part, and probably never will.

I far prefer the advantages that garbage collectors give me. I don’t
like having to deal with my own allocation and destruction. It might
be useful to have a concept like:

GC.mark(object)

That marks the object invalid, but that’s made slightly difficult
because there’s no “real” way to access the raw object without a
reference.

A NOOP still costs performance. Further, since most things can be
redefined at runtime (there are very few keywords in Ruby), it’s
not exactly something that can be turned off.
I think the performance issue is blown out of proportion. Code
gets added with each release that adds more to the code base and
does far less than what a type checking mechanism would.

Most of those changes have narrower impact than what a type checking
mechanism would involve.

Which is a curious trait that I don’t share. And since, save for
my occassional ranting threads, there is little traffic in this
newsgroup/list, I am wondering if perhaps I’m just not “getting
it” here and should move on to something else.

Um … the list has about 3,000 messages a month. We’re already at
about 2,200 messages for November. That’s not “little traffic.”

When did the Ruby community become so hostile? I remember the last
couple of discussions I had, they were energetic but polite, and
now it seems like a war zone.

You have the unfortunate happenstance of defending a position that
has been discussed to death, and recently. Ruby with type checking
is not Ruby. I strongly suspect that in most cases, where people
want type checking, other techniques could fill in nicely without
making the code brittle. Test-driven development is one such
technique. Design by Contract is another.

I’m not hostile to you, by the way, I am hostile to the idea of
importing something that doesn’t really add anything to Ruby for
specious reasons. Part of the reason that you’re confused by the
dichotomy that I hold is that if I want a contractual guarantee, I
want it to be rock-solid. I don’t want it to be a useless promise
that I have to check behind anyway.

If you folks are dead-set in your ways and look unkindly upon
people who suggest that Ruby change and grow out off the beaten
path a little, just say the word. I’m a free soul here, I’m not
signed up for anything in particular.

What’s being discussed isn’t a little growth. It’s a radical change
in direction if it’s to be a useful change, and an unnecessary thing
if it isn’t.

I like Ruby, and I think a lot of it is smart, but because it’s
free and flexible, not because there’s a hardened core of zealots
who defend it from change at all costs. This seems silly. I got an
anonymous comment on my RCR from someone calling my RCR “static
typing.” That’s getting ludicrous. What is that about? Is this
what the community is boiling down to?

Note that the people who read your RCR on RubyGarden may not read
ruby-talk. The Ruby community isn’t monolithic. Nor am I trying to
defend Ruby from change. I’m trying to ensure that such change is
useful.

Lighten up folks. Take my RCR and comment on it until it works.

I don’t think your RCR will ever be workable as part of the core
language. It asserts a promise – that need not even be kept,
leaving us exactly where we are today. It’s rather like the
prototypes in Perl ($@$%) theoretically guarantee that the
parameters will be passed as scalar, array, scalar, and hash, but
IIRC you still have to do special work with non-scalars. It buys
you nothing and is merely confusing in the end.

No, I don’t like what you’ve proposed. Propose something that is
useful and I can see supporting it. So far, you’ve suggested
something that does not add value or hasn’t been done by others
(namely Ryan Pavlik’s metadata module).
Is that the Metatags module he has in RAA? I thought that was more
of a documentation thing that would be useful by parsers other
than Ruby itself? I kind of remember something about that. It was
a YAML thing, was it not?

No, not YAML. But that’s the one, and it is sort of documentation.
He’s set it up so that it can be queried by programmers using Ruby,
though.

I don’t think it’s the same thing. I think it’s also dependent on
the developer keeping the code in sync with the metatags. I could
be wrong.

It is dependent for such. It’s also string-based, which is one of
the reasons that I find it unusable.

Also, I think you are just disagreeing with me to disagree. Not
once have I heard a suggestion to alter my idea to make it work.

Because, IMO, it cannot work. The best option for this RCR is to
die. Propose, perhaps, that DbC become part of Ruby, or that there
be a cleaner way of making this information available in the Ruby
core, but I don’t know what the “right” answer is offhand. What I do
know is that I don’t need static typing or interface checking in
the programs and libraries that I’ve written for Ruby.

It’s not set in stone. It’s yours, it’s Matz’s, it’s everyone’s
idea now. Talk and make it work. Off my ass now, please. You
understand me, the idea is written up as an RCR. Go comment on it
constructively.

IMO, there is no constructive statement to be made for it. What I’m
trying to do is convince you either (a) to make a proposal that
can be worked with or (b) to understand what can be used in place
of type checking of any sort in Ruby.

-austin

···

On Thu, 20 Nov 2003 10:48:01 +0900, Sean O’Dell wrote:

On Wednesday 19 November 2003 05:06 pm, Austin Ziegler wrote:
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.20
* 00.52.26

38

Sean O’Dell wrote:

shrug I don’t think that it’s necessary. Most people I’ve talked
to have been convinced that Ruby’s worth looking at because of the
deep object orientation.

This is a baby-and-bathwater issue. I still HATE that I can’t control when
objects die and that there’s no destructor. Yes, garbage collection is
nifty. Yes, I use yield now for doing cleanup, and it serves as a
replacement, but in the year or two I’ve been programming in Ruby, I still
hate that objects just hang around until the collector gets them, and I hate
that all I get is a finalizer.

I LOVE Ruby, but I don’t love that part, and probably never will.

Yeah - I hate that part too (with the presumption that an live object is
only a glob of memory - creates many sort of half-alive/zombie that we
have to deal with). But it is just GC/not Ruby, and other languages -
especially Java - that popularize this approach - so we just have to
learn to deal with it well now.

Thien

39

Matz: note that Python went through this discussion five years
ago and it still doesn’t have it. I’m not sure Ruby really
needs it, either. The only thing that I think Ruby could use is a
standardized way of publishing method signature information for
the cases I’ve outlined.

A good system of method signatures serves the same purpose in my
mind, if they’re convenient enough to call that we can expect
people to actually use them where they’re needed, and not avoid
them because they’re a pain to use.

Either way, the called method can ask “does this object do what I
want?” which is all I am after.

What you’re talking about and what I’m talking about are two
different things. I’m talking about informative metadata, not
enforcement or error diagnostics. I’m also specifically talking
about it in the cases outlined – RPC and GUI object inspectors.

Then why did you respond to my post?

As someone who has developed libraries in Lisp, C, C++, Java,
Ruby, Perl, Visual Basic, Delphi, Pascal, bash shell, as well as
developing O’Basic, a complete script language itself, I can tell
you that I have always tried to make life easier for the
developers who have had to use my libraries.

I would suggest that you haven’t used my libraries, then. Because if
you had, you would know that your suggestion has nothing to do with
reality.

How can you tell?

Sean O'Dell
···

On Wednesday 19 November 2003 01:45 pm, Austin Ziegler wrote:

On Thu, 20 Nov 2003 06:02:05 +0900, Sean O’Dell wrote:

On Wednesday 19 November 2003 12:29 pm, Austin Ziegler wrote:

40

I’m in the same position too. Love Ruby but cannot recommend it
for team development w/o having the language provides some sort of
intrinsic interface validation.

Again: why? Why do you need intrinsic interface validation? As
Michael Campbell noted, if a library writer isn’t going to document
their code, what makes you think that they’re going to put interface
validation in there?

That’s what no one in this discussion has been able to explain. The
broad statement is made: “I need interface validation!” But no
convincing explanation as to why it’s needed is made, either. OR why
interface validation is preferred to DbC or TDD – both of which I
consider to be superior techniques to compile time type checking.

I’ve seen explanations like “I need it to protect myself” or “I
don’t think my programmers can deal without it” or “I’ve tried it
before but it didn’t work.” None of these seems to have been done
with the full suite of Ruby techniques.

I guess it’s the truism that no language can satisfy everything -
so just choose one that best fit the application. Lacking this,
does seems to limit the applications that ruby could be used for -
i.e. could be all implemented by one/two skilled programmers.

This does not follow. Yes, it’s the current case with Ruby
development, but it does not follow that Ruby won’t scale just
because it doesn’t have static typing or interface validation.

[…]

One thing I find interesting is respond_to? was frequently cited
as a better way to handle the dynamism of Ruby than kind_of? -
But, every faults that was found with kind_of? could be applied to
respond_to? It also does ‘name only’ checking (name has no
association with behaviour), could easily be overridden in any
other way the programmer wanted to - in fact, I see method could
be mangled much more easily than class, so the defects propagates
both way.

Not really. You’re right that the standard #respond_to? only
responds to a name. But while it shares the “name-based” defect,
it’s less fragile because it doesn’t restrict classes of objects,
speaking broadly. As noted: StringIO is not an IO, but it implements
all of IO. There are likely very good reasons as to why it’s not a
subclass of IO (and IO is a class, not a module, so it can’t be
mixed in). Therefore, checking for #<< (or better, simply using
#<<) is likely to be less fragile than checking for kind_of? IO.

If we would believe that type checking is bad for Ruby, at least
we should be honest in saying that Ruby does not offer type
checking, as designed / or by its spirit, and programmers must be
willing to deal with it in intelligent way - rather than offering
a broken solution which automatically trigger the question from
newcomer - “Oh it does not quite work - how would we fix this?”
and trigger these kinds of flamefests on who is smarter than whom.

I don’t think that anyone has suggested that they are smarter than
the other. Nor do I think that this has been a flamefest. IMO, TDD
is far more successful than object type checking.

I do wonder what functional purpose does “kind_of?” serves now
that it was severely denigrated in the language - should it be
deprecated/ removed? since it is considered totally bad style to
use.

I don’t think that it’s totally useless. I do think that it’s of
extremely limited utility.

-austin

···

On Thu, 20 Nov 2003 14:52:17 +0900, Thien Vuong wrote:

austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.20
* 01.31.09