From: cworth@cworth.org (Carl Worth)
Subject: [sup-talk] In next: thread-view-mode labelling No method join for Set
Date: Wed, 19 Aug 2009 21:03:08 -0700 [thread overview]
Message-ID: <1250740488-sup-1624@yoom.home.cworth.org> (raw)
In-Reply-To: <1250734085-sup-2162@ntdws12.chass.utoronto.ca>
Excerpts from Ben Walton's message of Wed Aug 19 19:57:25 -0700 2009:
> Excerpts from Carl Worth's message of Wed Aug 19 20:31:12 -0400 2009:
>
> > [*] Totally off-topic: This is one of the things about "dynamically
> > typed" languages that I've never been able to wrap my brain around. I
> > really like that with static typing I can trust the compiler to help
> > me be very thorough if I make a type change like this, (and catch all
> > the cases before shipping any code).
...
> The term you'll see bandied about in ruby circles/books/etc is 'duck
> typing' which coming from strongly typed languages is definitely
> something that takes some getting used to. Basically, instead of
> caring about the type of the object, you case about what the object
> does. If it walks like a duck and quacks like a duck, treat it like a
> duck.
Yes, I understand that just fine. But two points:
1. That's not actually helping in the current case where we're trying
to do simple things like '+' and the distinction between Set and
Array is causing problems. (See the patch where we're having to add
.to_a and Set.new to coerce things.) So, here, at least things are
falling down. So somehow something in ruby isn't living up to the
concept here.
> Then, you'll see many examples where there is code like:
>
> raise SomeException, "blah" unless someobject.respond_to?(:somemethod)
>
> Your code doesn't care _what kind_ of object it gets as long as it
> knows _how_ to talk to it.
2. Even with the "duck typing" I'd still like to express this
constraint in a way that is decidable statically. I've definitely
failed as a programmer if a user sees a runtime exception like
that. Sytems with sophisticated runtimes are very interesting to
me. It's just discouraging to me that so many such systems fail to
actually help me avoid problems like this before the user is
running my code.
> Personally, I really like this. Ruby isn't perfect by any stretch,
> but of all the languages I've used, it's hands down the most fun to
> write.
That could still be the case for me here. I haven't tried much with it
yet, so I don't have any strong opinion there yet. :-)
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/aae17dcd/attachment.bin>
next prev parent reply other threads:[~2009-08-20 4:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-19 20:41 Wirt Wolff
2009-08-20 0:31 ` Carl Worth
2009-08-20 2:57 ` Ben Walton
2009-08-20 4:03 ` Carl Worth [this message]
2009-08-21 0:16 ` Ben Walton
2009-08-24 18:13 ` William Morgan
2009-08-25 7:44 ` Nicolas Pouillard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1250740488-sup-1624@yoom.home.cworth.org \
--to=cworth@cworth.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox