From: wmorgan-sup@masanjin.net (William Morgan)
Subject: [sup-talk] In next: thread-view-mode labelling No method join for Set
Date: Mon, 24 Aug 2009 11:13:43 -0700 [thread overview]
Message-ID: <1251137007-sup-3974@masanjin.net> (raw)
In-Reply-To: <1250727630-sup-3112@yoom.home.cworth.org>
Reformatted excerpts from Carl Worth's message of 2009-08-19:
> I've attached a patch that at least makes the crashes I was able ro
> reproduce go away.
Applied, thanks!
> [*] 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). Instead, here, there's a hard
> task of exercising every possible code path (at run time) before we
> know if there are any type errors still lingering. I've seen some
> proponents of dynamically-typed languages argue that unit testing
> should provide the same coverage that a statically-typed compiler
> would, but I haven't seen that in practice.
You're right, this is a classic example of the type of bug that would be
caught with static typing. Unit tests are the canonical answer. I'd
argue that unit tests provide better error checking than static typing,
since they allow you to capture the exact set of errors you're
interested in, rather than the set of type mismatches that a
type-checker can detect. (IMO the two sets rarely have more than a very
small overlap.)
Unit tests are only useful, of course, if you write them. Sup doesn't
have very many. I've made an explicit choice to spend my oh-so-limited
Sup time adding new features rather than ensuring a rock-solid platform.
The occasional bug like this is the price we all pay. But it's a matter
of tradeoffs---I do believe that if I were using a statically-typed
language, development would be significantly slower, and Sup would be
nowhere near the point it is now. I have no proof of this statement, of
course.
And if anyone wants to retrofit some unit tests, I'm more than happy to
accept them!
--
William <wmorgan-sup at masanjin.net>
next prev parent reply other threads:[~2009-08-24 18:13 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
2009-08-21 0:16 ` Ben Walton
2009-08-24 18:13 ` William Morgan [this message]
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=1251137007-sup-3974@masanjin.net \
--to=wmorgan-sup@masanjin.net \
/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