There’s a scene in Buster Keaton’s film “Sherlock, Jr.” where Keaton
…
side of the gap. A second earlier or a second later, he would indeed
have plummeted – but for just that instant, the necessary components
were in place.
Ruby objects remind me of that scene. They are what they are at a
given moment, whether or not that’s what they were or what they will
be. And in their momentary permutations and capabilities, they can do
some very powerful things.
This also very much indicate the fragility of the method.
I don’t believe Ruby objects are so fragile in praxis and I think we should
not focus too hard on Rubys extreme dynamism (don’t do it just because you
can).
[…]
So why would people like types: Personally I like the Ruby syntax
and spirit but also realize that most code do not expose and great
dependency on extreme dynamism - why shouldn’t we be able to compile
this efficiently?
I guess my instinct is that there’s much to learn and gain from Ruby’s
dynanism, and that even if it isn’t being fully exploited now, that
doesn’t mean it’s either too dangerous or too arcane (or even too
inefficient) to explore further.
I’ve done that, for instance, in my dbdbd (database definer) program.
It uses 1-originating array notation to index columns, but can also
use field-names. So the reader method for the sort_key (for example)
is:
def sort_key @sort_key - 1
rescue NameError @sort_key
end
When you announced dbdbd I quickly browsed through the code. I
had the impression that I understood your well written program -
besides this very example. I really tried to understand what’s going
on, but I just couldn’t get it.
which I think looks better than:
def sort_key
if @sort_key.respond_to?( @sort_key - 1
else @sort_key
end
end
Ok. With this alternative code and the remarks in your mail I finally
understand what you did. But for me the most intention revealing
implementation would simply be:
def sort_key
if @sort_key.is_a? Integer @sort_key - 1
else @sort_key
end
end
Dave’s method: use :-, catch exception
Pit’s method: use :- if key is_a Integer
Gavin’s method: use :- if (key - 1) is_a Integer
Ruby: so much flexibility == so many choices
So many choices == difficulty in making wise and consistent decisions
Static languages tend to make some of these decisions for you. They are
uninspiring, but the seatbelts are sometimes comfortable. Java is a language
suited for dummies. I don’t think we’ll see Ruby fit that mould, even though
its simplicity and flexibility makes it, IMO, the perfect language for
teaching.
Regards,
Pit
Gavin
···
----- Original Message -----
From: “Pit Capitain” pit@capitain.de
Enumerable is the Mix-in module for the enumeration. The including class
must provide the method each. All methods provided by Enumerable are
defined using each.
You might as well say that exceptions are a redundant mechanism
because you might just return some garbage or nil and find the error
during testing.
You’re right. I might as well just say that, and sometimes, I actually
do.
The question is how easy is to find the actual error basing on the
diagnostic. In my experience static typing makes it much easier,
especially when you change something in a working program and want
to update all places which depend on the change.
Sounds like static typing is an excuse not to always aim for as close to
100% test coverage as possible.
Is this a wise approach? Is there ever a time that the program doesn’t
benefit from having test coverage closer to 100%?
I think working in a dynamically typed language almost /forces/ me to
work harder at maintaining good/high test coverage which the program
clearly benefits from. Statically typed languages give a false sense of
security and correctness and thus make it easier for people to “make
excuses” for why they don’t /need/ better test coverage.
–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)
I don’t think the verb thing is a necessity. Maybe I’m just being
If I remember correctly there was a science story floating
around in the mass media recently, about an experiment
that thinking about verbs fire ups more neurons in the
part of your brain usual responsible for motoric coordination,
which in reveres logic probable means that the Germans love
for compound nouns explains that … well, take your pick;-)
influenced by the “Ich kann Deutsch” (“I can [speak] German”) idiom.
Actually this is all reminiscent of Franz Schubert’s stock question,
upon being introduced to or told about another person: “Kann er was?”
(Can he do anything? i.e., is he good at anything?)
Sounds like static typing is an excuse not to always aim for as
close to 100% test coverage as possible.
Covering 100% of code with tests is not a silver bullet. What if code
producing some data is covered by tests and code consuming that data
is covered by tests, but sometimes the producer emits data which is
not understood by the consumer? Each taken in isolation looks correct
because the form of the data is not formally specified.
Even if tests do cover the relevant code, it takes time to understand
why a test fails, or maybe that this is the test which is out of date.
Imagine a compiler with a tree representing the internal form of the
code. In a statically typed language the type of the tree (possible
forms of nodes with arguments) is specified in one place. When I
change the representation of a construct, I change this specification
first and try to compile the compiler. I will be immediately told
where these nodes were produced from the previous stage and where
they were consumed by later stages.
How to specify valid shape of the tree with tests and ensure that
the producer produces only valid code no matter what the input is,
the consumer understands all valid code?
Static typing just makes it much easier and more straightforward.
Is this a wise approach? Is there ever a time that the program
doesn’t benefit from having test coverage closer to 100%?
You don’t need tests which check that the producer emits nodes only
from the given set if types ensure that. You don’t need tests which
ensure that only lists of expressions are put in the “function call”
node in place of arguments - the compiler checks this, etc. Many
tests are reduntant when types are checked statically - they are even
impossible to write because otherwise the program would not compile.
Ruby’s mixins have similar features to Java interfaces, but they are more
flexible, and don’t play any specification role. Also, Ruby classes don’t need
any interface description to be able to plug-n-play; they just need to support
the rigth methods at the right time.
In short, it’s not a technical reason. Ruby doesn’t want to be as strict as
Java. Result: more flexibility, but no guarantees.
If you find yourself in a situation where you want these things, but also want
to use Ruby, either:
use Ruby as a prototype and then convert to Java if necessary
enforce type-compliance to key methods by raising exceptions
Why doesn’t Ruby have some sort of Contract/Interface specification (ala
Java Interfaces or Eiffel Contracts)? Is there a technical reason that
these aren’t possible, or is it just a subject that has not been
properly approached yet? I’ve seen lots of discussion about static
types and responds_to? method, but I think both of these are really just
one small aspect of the much larger problem: guaranteeing up front that
the library user implements the required functionality.
Why do you think that I've added module in the signature (see
(ruby-talk:50139)) ?
You answered this yourself already - to kill the whole idea;-)
This was one way to say it, the other way is to say that ruby has modules
and if you can't use modules in the dispatch it's faster to remove modules
from ruby.
I've not understood what you do with modules, when you put all your
methods at toplevel.
Sounds like static typing is an excuse not to always aim for as close to
100% test coverage as possible.
Is this a wise approach? Is there ever a time that the program doesn’t
benefit from having test coverage closer to 100%?
To characterize the abundant, thorough, and indeed necessary research
and development that went into static typing and has pervaded computing
science over the last several decades as merely “an excuse” is an
extreme mischaracterization. While I enjoy the benefits and flexibility
brought by dynamically typed languages such as Smalltalk and Ruby, there
were and are very good reasons for the introduction and continued use of
static typing.
···
–
Jason Voegele
“We believe that we invent symbols. The truth is that they invent us.”
– Gene Wolfe, The Book of the New Sun
Ruby’s mixins have similar features to Java interfaces, but
they are more flexible, and don’t play any specification
role. Also, Ruby classes don’t need any interface
description to be able to plug-n-play; they just need to
support the rigth methods at the right time.
Interesting … I’ve always considered Ruby mixins to be the exact opposite of Java interfaces. Interfaces provide interface without
implementation. Mixins provide implemenation, but aren’t required for
interface.
Based on my first impression of scanning the comp.lang.objective-c, it
seems that:
objective-c does not have a default gc (C# does!)
objective-c is kind-of Apple oriented (?)
AFAIK Objective-C is used to develop on OSX, but saying it is
Apple-oriented is like saying C++ is Windows-oriented You can for
instance use gobjc, which will run on platforms supported by the gcc
compiler, as it uses the gcc backend to generate optimized code.
So I skip objective-c for now.
I wouldn’t throw it away that fast…
Not that I know anything about Objc, but I have often heard good
things about it.
···
On Mon, Sep 30, 2002 at 11:16:46PM +0900, William Djaja Tjokroaminata wrote:
Ruby’s mixins have similar features to Java interfaces, but they are more
flexible, and don’t play any specification role. Also, Ruby classes don’t need
any interface description to be able to plug-n-play; they just need to support
the rigth methods at the right time.
In short, it’s not a technical reason. Ruby doesn’t want to be as strict as
Java. Result: more flexibility, but no guarantees.
If you find yourself in a situation where you want these things, but also want
to use Ruby, either:
use Ruby as a prototype and then convert to Java if necessary
enforce type-compliance to key methods by raising exceptions
While I understand your point, I do have to disagree and say that Mixins
aren’t anything like interfaces coming from my perspective.
unerringly guarantee than an object ALWAYS provides specific
functionality. Mixins are a way to share common functionality amongst
multiple objects via code-reuse, but they don’t guarantee that said
functionality will be implemented (methods can be changed after the
fact). A contract says I must do something. If I no longer do
something, I no longer follow that contract and it is therefore no
longer valid. I’ve never read anything about Ruby Mixins being
immutible like this
Also, another important reason why I think the two concepts don’t serve
the same purpose is that interfaces only guarantee functionality.
They say nothing about how that functionality is implemented (are you
reading from a database? or from an xml file?). A mixin is a mixin and
it behaves a certain way. You can have two mixins with the same
behavior, they may look and act the same but they are in fact two
distinct things (unless I’m misunderstanding Mixins).
You can use Mixins to implement interface like funtionality, so your
point is certainly valid. But you can’t use Mixins to GUARANTEE that
functionality across the board for all time. That’s the missing piece
for a lot of us.
Bryan
···
From my perspective, interfaces and/or contracts are a way to
Monday, September 30, 2002, 6:16:46 PM, you wrote:
objective-c is kind-of Apple oriented (?)
reverse - OC was used in nextstep, which itself is base of new aplle’s
unix-derived OS. so, at this time OC is dead, except for using it in
nextstep/darwin programs
> Ruby's mixins have similar features to Java interfaces, but
> they are more flexible, and don't play any specification
> role. Also, Ruby classes don't need any interface
> description to be able to plug-n-play; they just need to
> support the rigth methods at the right time.
Interesting … I’ve always considered Ruby mixins to be the exact opposite of Java interfaces. Interfaces provide interface without
implementation. Mixins provide implemenation, but aren’t required for
interface.
And a very fair point of view it is too. But there are some similarities to
Java interfaces:
class X
include Enumerable
end
x = X.new
x.is_a? Enumerable # => true
i.e. mixins are a kind of inheritance.
But the similarity ends somewhere: no mixin is required for comparing objects,
for instance.
class Y implements Comparable {
public int compare(Object other) { return 0; }
}
class Y
def <=>(other)
1
end
end
The Java and ruby classes aer now both ready to be sorted, for instance.
However, the Java one advertises its comparability, whereas the Ruby one just
is comparable.
Conclusion: no simple statement can be made about the relationship between Java
interfaces and Ruby mixins.
On Mon, Sep 30, 2002 at 11:16:46PM +0900, William Djaja Tjokroaminata wrote:
Hi,
Based on my first impression of scanning the comp.lang.objective-c, it
seems that:
objective-c does not have a default gc (C# does!)
objective-c is kind-of Apple oriented (?)
AFAIK Objective-C is used to develop on OSX, but saying it is
Apple-oriented is like saying C++ is Windows-oriented You can for
instance use gobjc, which will run on platforms supported by the gcc
compiler, as it uses the gcc backend to generate optimized code.
So I skip objective-c for now.
I wouldn’t throw it away that fast…
Not that I know anything about Objc, but I have often heard good
things about it.
If you like Ruby, I think Objective-C is the most natural
choice. They have a very similar mindset. Objective-C is
not “just an apple thing”. It was around long before NeXTstep
picked it and has managed to survive NeXTStep’s death and
rebirth.
You can for