Because my libraries tend to be very informative about errors. I use custom
exceptions extensively.
-austin
On Thu, 20 Nov 2003 06:51:49 +0900, Sean O’Dell wrote:
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?
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.19
* 18.01.34
Austin Ziegler wrote:
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.
Could you give me an example of what is considered a good use then?
Given the presumption that object classification and knowledge is bad,
what good information could be gained from knowing it?
Thien
Austin Ziegler wrote:
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’ll take a shot here - sorry could not resist.
The way it works for me is: what we need is based on a analysis of the
requirement and the previous experience/learning of how this sort of
things is done. And that is not based on what language we used before
although it would probably has some influence. This is a decision/
intelligent choice.
It would then be communicated to the team as the guideline on how to do
it. We then monitor its progress/success/failure and make adjustment.
If it works well - it got promoted to other groups, or even boast about
it in comp.lang.ruby (on other thought, maybe not :). If not, oh well
… sorry… Who made that damn decision?
Library writer
good/bad behaviour is not relevant, because this is a group recommended/
enforced guideline - i.e. seek employment elsewhere if an individual
does not wish to conform/be accounted to minimum project requirements.
Can’t wave hand and say we don’t need that at all because it is
the dynamic language Ruby - we can’t guarantee anything. It may
work with some of us (including me), but a non-starter to convince others.
Agree that DbC is better for this particular requirement (which is only
one of an design requirements) - but at this time, I am trying to
use Ruby, not Eiffel.
Thien
On Thu, 20 Nov 2003 14:52:17 +0900, Thien Vuong wrote:
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?
At some point, you ought to quit asking people why. They’ve answered you on
this question, and what you’re doing is continually asking “why why why?”
Just accept it. This is something people want. It’s getting annoying hearing
about how you can’t understand why they want it.
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.
Explanations have been offered, you’ve just chosen to remain unconvinced or
have ignored them. They are there. Go browse back and look.
Sean O'Dell
On Wednesday 19 November 2003 10:47 pm, Austin Ziegler wrote:
On Thu, 20 Nov 2003 14:52:17 +0900, Thien Vuong wrote:
Why are you telling me this? Are you responding to something I’ve said about
your libraries?
Sean O'Dell
On Wednesday 19 November 2003 03:02 pm, Austin Ziegler wrote:
On Thu, 20 Nov 2003 06:51:49 +0900, Sean O’Dell wrote:
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?
Because my libraries tend to be very informative about errors. I use custom
exceptions extensively.
Austin Ziegler wrote:
Again: why? Why do you need intrinsic interface validation? […]
I’ll take a shot here - sorry could not resist.
I’m glad you didn’t resist. This, IMO, gets to the heart of the
matter.
The way it works for me is: what we need is based on a analysis of
the requirement and the previous experience/learning of how this
sort of things is done. And that is not based on what language we
used before although it would probably has some influence. This is
a decision/intelligent choice.
I’ll accept that as a basis.
It would then be communicated to the team as the guideline on how
to do it. We then monitor its progress/success/failure and make
adjustment. If it works well - it got promoted to other groups, or
even boast about it in comp.lang.ruby (on other thought, maybe not
:). If not, oh well … sorry… Who made that damn decision?
This is where TDD would help – whether or not you’re using Ruby.
The work I’m doing in Delphi right now I prototyped in Ruby, but
will be applying to Delphi using DUnit. Indeed, if the requirements
can be defined as unit tests for each unit, then there is a
concrete, visible progress for development.
The requirements and design for a Ruby project aren’t all that
different from any other project, either.
Can’t wave hand and say we don’t need that at all because it is
the dynamic language Ruby - we can’t guarantee anything. It may
work with some of us (including me), but a non-starter to convince
others.
Erm. You can guarantee things in Ruby, though. If a method
requires a particular behaviour from a parametric object, you can
guarantee that it will fail if it doesn’t provide that behaviour 
Aside from that, if you approach it from the concept of TDD, you get
people to start guaranteeing behaviour.
Agree that DbC is better for this particular requirement (which is
only one of an design requirements) - but at this time, I am
trying to use Ruby, not Eiffel.
Ruby does have a simple – if old and possibly non-working – DbC
implementation available.
In some ways, unit tests provide DbC capabilities, although they
are outside of the implementation themselves.
While this code no longer represents the “state of the art” (see
Gavin’s standard extensions project on RubyForge), you’ll see a
number of tests there. I will grant that I wrote the tests after I
implemented the base code, but I tried to be comprehensive. When I
found weaknesses, I modified the code. Those tests document the code
better than any English document ever could.
-austin
Hi –
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?At some point, you ought to quit asking people why. They’ve answered you on
this question, and what you’re doing is continually asking “why why why?”Just accept it. This is something people want. It’s getting annoying hearing
about how you can’t understand why they want it.
I’m not big on the “Just Do It” stuff (I boycott Nike actually), so
you’ll have to forgive me for not Just Accepting It. (Very uppity, I
know In any case, I think it might be useful to clear a few
cobwebs and look at this in its most distilled form. Here I go:
If this statement is true:
Ruby should include a type-checking framework.
then one of the following two statements is also true:
There is no third possibility; that is, given the premise, the only
two possibilities are that #1 is true and that #2 is true.
Now, if #1 is true, then Ruby is, and always was, a bad idea.
Everything that has been done with it is tainted and moribund, because
it should never have existed in the first place. I find the evidence
to the contrary compelling, and therefore reject #1 out of hand.
That means that #2 is true (again, given the original premise). This,
in turn, means that at some point, we will reach a state of
equilibrium where (a) one or more languages exist which do not have
type-checking frameworks, and (b) both the existence of those
languages and their lack of type-checking frameworks will be deemed
acceptable.
And this, in turn, leads me to wonder: if we’re going to reach that
point some day anyway, why not just decide that we’ve reached it now,
with Ruby?
David
On Fri, 21 Nov 2003, Sean O’Dell wrote:
On Wednesday 19 November 2003 10:47 pm, Austin Ziegler wrote:
On Thu, 20 Nov 2003 14:52:17 +0900, Thien Vuong wrote:
–
David Alan Black
home: dblack@wobblini.net # New email address
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav
It’s interesting to note that at the same time (as this thread) there is also
big discussion on comp.lang.functional - Why I don’t believe in static typing?
Sincerely,
Gour
Sean O’Dell (sean@celsoft.com) wrote:
Explanations have been offered, you’ve just chosen to remain unconvinced or
have ignored them. They are there. Go browse back and look.
–
Gour
gour@mail.inet.hr
Registered Linux User #278493
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?
At some point, you ought to quit asking people why. They’ve
answered you on this question, and what you’re doing is
continually asking “why why why?”
Sorry, but you need to reread the type checking proponents’ posts
yourself if you think that what I’ve been told amount to “reasons.”
At best, they are excuses. I mean that quite charitably, as I don’t
think that anyone has deliberately avoided answering the question.
If you look a bit closely, Thien Vuong actually attempted to give an
answer, which was perhaps the clearest answer given so far. It’s
telling, then, that when I responded to him, he acknowledged that
what he’s after isn’t type checking, but assurance.
Just accept it. This is something people want. It’s getting
annoying hearing about how you can’t understand why they want it.
People want it, but without justification, I see no reason that they
should get it. Granted, I am not the person that makes the final
decision, but I feel that there’s a fundamental disconnect between
the people who want type checking and what they really need. I
cannot believe that dynamically typed languages are inherently
less productive and/or stable than statically typed languages. Nor
can I believe – without evidence (and the plural of anecdote is
not data) – that statically typed languages are superior for medium
to large teams.
Why do people who want type checking not want to explore alternative
mechanisms offered by Ruby – most notably automated unit testing,
or a DbC-style implementation? I’ve already pointed out that type
checking increases code fragility and repetition:
int max(int a, int b) { return a > b ? a : b; }
float max(float a, float b) { return a > b ? a : b; }
double max(double a, double b) { return a > b ? a : b; }
char max(char a, char b) { return a > b ? a : b; }
String max(String a, String b) { return a > b ? a : b; }
Complex max(Complex a, Complex b) { return a > b ? a : b; }
or:
def max(a, b); a > b ? a : b; end
This is duck typing at its best: as long as a can be compared
against b (either by supporting #> directly or through #<=>), then
max will work for the specified classes. We don’t even have to be
comparing two of the same types.
If I try to do max(3.0, 4) or max(3, 4.0), the C++ compiler is
confused.
max.cpp:11: error: call of overloaded max(double, int)' is ambiguous max.cpp:3: error: candidates are: int max(int, int) max.cpp:4: error: float max(float, float) max.cpp:5: error: double max(double, double) max.cpp:6: error: char max(char, char) max.cpp:12: error: call of overloaded max(int, double)’ is
ambiguous
max.cpp:3: error: candidates are: int max(int, int)
max.cpp:4: error: float max(float, float)
max.cpp:5: error: double max(double, double)
max.cpp:6: error: char max(char, char)
In comparison, the Ruby version just does the right thing. A lot of
extra work needs to be done to predict solutions with typed
languages. You yourself said you don’t care for C++ templates, and I
can’t disagree – they’re ugly and unwieldy. If there’s anything
that requires a brilliant programmer to deal with, it’s C++
templates. Ruby, on the flip side, isn’t nearly as confusing as C++
templates.
What again, does static typing buy you that test driven development
doesn’t deliver better – in spades?
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.
Explanations have been offered, you’ve just chosen to remain
unconvinced or have ignored them. They are there. Go browse back
and look.
Sorry, but “I need it because I want to avoid questions” (sorry,
Simon) isn’t an answer. Neither is your apparent favourite: “I just
need it, that’s why.”
-austin
On Fri, 21 Nov 2003 02:20:04 +0900, Sean O’Dell wrote:
On Wednesday 19 November 2003 10:47 pm, Austin Ziegler wrote:
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
* 13.54.02
Note that what follows is my opinion only:
Checking against your own types. See Ruwiki’s lib/ruwiki.rb lines
81 and 193.
Distinguishing between Array, Hash, and String in times when such
distinctions are necessary (e.g., #each).
This example from MIME::Type:
def <=>(other) #:nodoc:
if other.respond_to?(:content_type)
@content_type <=> other.content_type
elsif other.kind_of?(String)
@simplified <=> Type.simplified(other)
else
@content_type <=> other
end
end
There’s not a lot of examples where I use #kind_of? in my code.
-austin
On Thu, 20 Nov 2003 16:02:14 +0900, Thien Vuong wrote:
Austin Ziegler wrote:
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.
Could you give me an example of what is considered a good use
then? Given the presumption that object classification and
knowledge is bad, what good information could be gained from
knowing it?
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.20
* 14.18.00
No has to just do it. But when people ask for something, it gets annoying to
hear over and over “but why but why but why.” Why is not an appropriate
question anymore.
Ruby simply isn’t going to have these features, so there’s a door open now for
a Ruby-like language that does. I, personally, would prefer Ruby close that
door and do SOMETHING for these people. But if that’s not to be, then that’s
not to be.
Sean O'Dell
On Thursday 20 November 2003 09:56 am, dblack@wobblini.net wrote:
Hi –
On Fri, 21 Nov 2003, Sean O’Dell wrote:
On Wednesday 19 November 2003 10:47 pm, Austin Ziegler wrote:
On Thu, 20 Nov 2003 14:52:17 +0900, Thien Vuong wrote:
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?At some point, you ought to quit asking people why. They’ve answered you
on this question, and what you’re doing is continually asking “why why
why?”Just accept it. This is something people want. It’s getting annoying
hearing about how you can’t understand why they want it.I’m not big on the “Just Do It” stuff (I boycott Nike actually), so
you’ll have to forgive me for not Just Accepting It. (Very uppity, I
know
cobwebs and look at this in its most distilled form. Here I go:
You reject their reasoning and thus see no reason to give them what they ask
for, and that what these people want is disconnected from what they actually
need.
Okay Ziegler, whatever you say!
Sean O'Dell
On Thursday 20 November 2003 10:54 am, Austin Ziegler wrote:
On Fri, 21 Nov 2003 02:20:04 +0900, Sean O’Dell wrote:
Just accept it. This is something people want. It’s getting
annoying hearing about how you can’t understand why they want it.People want it, but without justification, I see no reason that they
should get it. Granted, I am not the person that makes the final
decision, but I feel that there’s a fundamental disconnect between
the people who want type checking and what they really need. I
Hi,
I’m not big on the “Just Do It” stuff (I boycott Nike actually), so
you’ll have to forgive me for not Just Accepting It. (Very uppity, I
know
cobwebs and look at this in its most distilled form. Here I go:If this statement is true:
Ruby should include a type-checking framework.
then one of the following two statements is also true:
- No programming language without a type-checking framework
should exist.- It is acceptable for one or more programming languages without
type-checking frameworks to exist, but Ruby should not be
one of those languages.There is no third possibility; that is, given the premise, the only
two possibilities are that #1 is true and that #2 is true.Now, if #1 is true, then Ruby is, and always was, a bad idea.
Everything that has been done with it is tainted and moribund, because
it should never have existed in the first place. I find the evidence
to the contrary compelling, and therefore reject #1 out of hand.That means that #2 is true (again, given the original premise). This,
in turn, means that at some point, we will reach a state of
equilibrium where (a) one or more languages exist which do not have
type-checking frameworks, and (b) both the existence of those
languages and their lack of type-checking frameworks will be deemed
acceptable.And this, in turn, leads me to wonder: if we’re going to reach that
point some day anyway, why not just decide that we’ve reached it now,
with Ruby?
Interesting logic. But it’s not good enough to persuade Sean (and me).
Can I summarize my opinion and feeling toward Sean’s idea:
we have had many many people requiring “static typing” in Ruby.
They were basically either ignorants or trolls. This is the
reason why Sean had so strong objection at the beginning.
Sean’s idea is (or becomes) not so-called static type checking.
It’s interface checking. So we have no reason to refuse it like
other “proposal”.
Optional interface checking can produce better messages than
simple NoMethodError. This is a good thing.
When I hacked tDiary plugin, I had hard time understanding
existing tDiary code, because it’s kinda hard to distinguish types
of arguments, and it was not convenient to put “printf” in the
server-side program. This kind of interface checking might help
me; but plain API document would do too.
We have two challenges to implement interface checking. The one
is proper design of interface. Sean wrote a new proposal in
[ruby-talk:85888]. But I don’t like its appearance (my personal
feeling). I have no idea what is good interface design.
The other is implementation. Considering Ruby’s dynamic nature,
the interface check would be done at run-time. Since all of us do
not want the serious performance degrade, interface checking must
be implemented efficiently. But I have no idea how to do it.
In summary, “interface checking” (not static type checking we had seen
before) is a good thing. But I’m not sure it’s good enough to put in
the future Ruby, where API document might help, and where we have two
challenges above.
matz.
In message “Re: “stereotyping” (was: Re: Strong Typing (Re: Managing metadata about attribute types) )” on 03/11/21, dblack@wobblini.net dblack@wobblini.net writes:
Austin Ziegler wrote:
I’m in the same position too. Love Ruby but cannot recommend it
for team development w/o having the language provides some sort
……
int max(int a, int b) { return a > b ? a : b; }
float max(float a, float b) { return a > b ? a : b; }
double max(double a, double b) { return a > b ? a : b; }
char max(char a, char b) { return a > b ? a : b; }
String max(String a, String b) { return a > b ? a : b; }
Complex max(Complex a, Complex b) { return a > b ? a : b; }or:
def max(a, b); a > b ? a : b; end
This is duck typing at its best: as long as a can be compared
against b (either by supporting #> directly or through #<=>), then
max will work for the specified classes. We don’t even have to be
comparing two of the same types.
…-austin
but do also consider:
max(5.3, “austin”)
Which is silly if you are using literals, but which could be
a = 5.3
…
b = “5.25”
…
max(a, b)
Using duck typing, of course, doesn’t free you from the requirement of
error checks (I almost said type checks here One does need to
ensure that the formats are compatible. Even numerics aren’t sufficient
(consider kilometers vs. miles, e.g.). But without context one doesn’t
know whether max should do the automatic conversion, or raise and
exception. And context is the real problem here.
Type systems are attempts to capture context. One can reasonably argue
that they are better than nothing. Classes are other attempts to
capture context. Neither is, or should be made, perfect. But how
context should be specified is far from clear. Even when assertions are
built into the system, as they are with Eiffel, they are far from
perfect. In Ruby… well, they exist, but I don’t know how to use them,
and assert doesn’t show up in the pickaxe book (at least a grep of the
online version didn’t find it).
I sure don’t know what the right answer is. The flexibility that
makes Ruby (and Python) so powerful is not something that should be
readily given up. (And the benefits of doing so are, in any case,
problematic.) But I do frequently want a convenient way for my routines
to be able to check on their parameters, and how they can be used.
Unfortunately, there doesn’t seem to be a decent way to specify unit
types (outside of creating separate classes for the different units).
Fortunately that’s not impossible, and with open classes not even
infeasible. But it sure is a lot more work than just typing 3 ft. 7 in.
On Fri, 21 Nov 2003 02:20:04 +0900, Sean O’Dell wrote:
On Wednesday 19 November 2003 10:47 pm, Austin Ziegler wrote:
On Thu, 20 Nov 2003 14:52:17 +0900, Thien Vuong wrote:
With the exception of Thien’s statement, I haven’t seen reasoning.
I’ve seen excuses and circular arguments.
Why can’t you give a logical reason as to why you need this?
-austin
On Fri, 21 Nov 2003 04:06:51 +0900, Sean O’Dell wrote:
You reject their reasoning and thus see no reason to give them
what they ask for, and that what these people want is disconnected
from what they actually need.
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.20
* 14.44.57
- We have two challenges to implement interface checking. The one
is proper design of interface. Sean wrote a new proposal in
[ruby-talk:85888]. But I don’t like its appearance (my personal
feeling). I have no idea what is good interface design.
Do you mean the one titled “New Type Checking System Idea?”
- The other is implementation. Considering Ruby’s dynamic nature,
the interface check would be done at run-time. Since all of us do
not want the serious performance degrade, interface checking must
be implemented efficiently. But I have no idea how to do it.
Actually, the new proposal only checks at compile-time, when a class which
implements an interface is loaded, and whenever methods are added to the
class. After that, there is as little overhead as I can possibly imagine.
After that, you just check for a flag in the object. The flag says “this
object has in its ancestry a class which properly, and completely implemented
this interface.” It’s a very, very quick check. You don’t calculate
anything, the flag is passed from the class after the class has fully
implemented the last of all the interface requirements. I can’t even imagine
any other system being quicker.
In summary, “interface checking” (not static type checking we had seen
before) is a good thing. But I’m not sure it’s good enough to put in
the future Ruby, where API document might help, and where we have two
challenges above.
This is heartening to hear. All I get nowadays is Ziegler in one ear buzzing
in and telling me everything I say is nonsense.
If I didn’t make myself very clear in my new proposal, please ask me
questions. The new proposal should put the burden mostly at compile-time,
and run-time checks should be very quick. The syntax, I think, is far from
ugly as well; in fact, it’s really just plain Ruby pretty much.
Sean O'Dell
On Thursday 20 November 2003 02:04 pm, Yukihiro Matsumoto wrote:
Hi –
On Fri, 21 Nov 2003, Yukihiro Matsumoto wrote:
Interesting logic. But it’s not good enough to persuade Sean (and me).
I’m not trying to persuade you not to do it – just pointing out that
the fact that some people claim to need it does not mean discussion
and evaluation should end. (Not that this discussion is in danger of
ending too early But actually it may get more interesting as we
move away from kind_of? and friends.)
David
–
David A. Black
dblack@wobblini.net
For the same reason I cannot argue why I need anything in life. Because
someone can always come along and argue against me and declare themselves
unconvinced.
Sean O'Dell
On Thursday 20 November 2003 11:46 am, Austin Ziegler wrote:
On Fri, 21 Nov 2003 04:06:51 +0900, Sean O’Dell wrote:
You reject their reasoning and thus see no reason to give them
what they ask for, and that what these people want is disconnected
from what they actually need.With the exception of Thien’s statement, I haven’t seen reasoning.
I’ve seen excuses and circular arguments.Why can’t you give a logical reason as to why you need this?
Sean,
Actually, the new proposal only checks at compile-time, when a class which
implements an interface is loaded, and whenever methods are added to the
class.
How can this be done efficiently with Ruby’s dynamic nature at compile time?
I’m going to go read your proposal now. =)
Zach