Asp Forum - Typo-checking instead of static typing

Ben Giddings

5/3/2005 7:27:00 PM

Once again, static typing reared its head on the mailing list, and once
again, the knights of the Ruby table slayed the beast... but it will
return. The wheel of time continues to turn and the beast will return
again.

But really, when people talk about "static typing", what is it they
*really* want. What does static typing buy you? I'd argue it's simple.

Static typing tends to find typos and brainos in code before it's executed.

It's as simple as that. I don't need to talk about the various down sides
to static typing here, but that upside is particularly important when
there are bits of code that might very rarely be executed.

So the real question is: in a dynamic, strongly typed language like Ruby,
how do you find typos and brainos in code that your app may very rarely
use?

The stock answer here is "unit tests", but honestly, I never bought that
answer. Maybe it's because too often I deal with things that are
incredibly difficult to unit test, i.e. GUIs, external data sources,
unreliable networks, opaque 3rd-party interfaces and other things which
are very difficult to mock out. It isn't to say they aren't testable,
just that they're really hard to test well.

My open question is then: how do you find typos and brainos in seldom-run
code in a dynamic language like Ruby?

(And maybe we can use the answers next time the monster rears its head)

Ben

32 Answers

Curt Hibbs

5/3/2005 7:46:00 PM

Ben Giddings wrote:
> Once again, static typing reared its head on the mailing list, and once
> again, the knights of the Ruby table slayed the beast... but it will
> return. The wheel of time continues to turn and the beast will return
> again.
>
> But really, when people talk about "static typing", what is it they
> *really* want. What does static typing buy you? I'd argue it's simple.
>
> Static typing tends to find typos and brainos in code before it's executed.
>
> It's as simple as that. I don't need to talk about the various down sides
> to static typing here, but that upside is particularly important when
> there are bits of code that might very rarely be executed.
>
> So the real question is: in a dynamic, strongly typed language like Ruby,
> how do you find typos and brainos in code that your app may very rarely
> use?
>
> The stock answer here is "unit tests", but honestly, I never bought that
> answer. Maybe it's because too often I deal with things that are
> incredibly difficult to unit test, i.e. GUIs, external data sources,
> unreliable networks, opaque 3rd-party interfaces and other things which
> are very difficult to mock out. It isn't to say they aren't testable,
> just that they're really hard to test well.
>
> My open question is then: how do you find typos and brainos in seldom-run
> code in a dynamic language like Ruby?
>
> (And maybe we can use the answers next time the monster rears its head)

As I read this, I immediately imagined parsing all the individual tokens
in a set of Ruby programs, and counting the number of occurrences of
each. Tokens that appear infrequently (like once) are likely to be typos.

This idea, with a little more smarts added, could be used to detect
potential typos.

Curt

SER

5/3/2005 7:56:00 PM

> Once again, static typing reared its head on the mailing list, and
once
> again, the knights of the Ruby table slayed the beast...

It would be more accurate to say that the Knights claimed the beast
was:

1) impossible to implement
2) insignificant
3) not really a beast

largely in that order.

--- SER

james_b

5/3/2005 8:20:00 PM

Ben Giddings wrote:
> Once again, static typing reared its head on the mailing list, and once
> again, the knights of the Ruby table slayed the beast... but it will
> return. The wheel of time continues to turn and the beast will return
> again.
>
> But really, when people talk about "static typing", what is it they
> *really* want. What does static typing buy you? I'd argue it's simple.
>
> Static typing tends to find typos and brainos in code before it's executed.
>
> It's as simple as that. I don't need to talk about the various down sides
> to static typing here, but that upside is particularly important when
> there are bits of code that might very rarely be executed.

The arguments I've heard for static typing rarely focus on catching
finger farts. Yes, that's a part of it, but the essence seems to be a
desire for some assurance that not only does code compile and that
objects respond to specific messages, but that the resulting behavior
will match certain expectations.

(Oh, and speed is another argument.)

>
> So the real question is: in a dynamic, strongly typed language like Ruby,
> how do you find typos and brainos in code that your app may very rarely
> use?

-w ?
-c ?

Comprehensive unit tests?

James

Eric Hodel

5/3/2005 9:05:00 PM

On 03 May 2005, at 12:27, Ben Giddings wrote:

> The stock answer here is "unit tests", but honestly, I never bought
> that
> answer. Maybe it's because too often I deal with things that are
> incredibly difficult to unit test, i.e. GUIs, external data sources,
> unreliable networks, opaque 3rd-party interfaces and other things which
> are very difficult to mock out. It isn't to say they aren't testable,
> just that they're really hard to test well.
>
> My open question is then: how do you find typos and brainos in
> seldom-run
> code in a dynamic language like Ruby?

Yes, unit tests and ruby -w. I wrote the thing in the 'I Rock.' post
between midnight and 4am. As you can imagine, writing code tired is
fraught with crazy typos, but the unit tests found them all.

When I was almost done, I spent 15 minutes on a 1 character typo (rrc
in one spot, rcc in another). I didn't have a unit test for that case.

--
Eric Hodel - drbrain@segment7.net - http://se...
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

John Carter

5/3/2005 9:18:00 PM

Hal E. Fulton

5/3/2005 9:22:00 PM

Eric Hodel wrote:
> On 03 May 2005, at 12:27, Ben Giddings wrote:
>
>>
>> My open question is then: how do you find typos and brainos in seldom-run
>> code in a dynamic language like Ruby?
>
>
> Yes, unit tests and ruby -w. I wrote the thing in the 'I Rock.' post
> between midnight and 4am. As you can imagine, writing code tired is
> fraught with crazy typos, but the unit tests found them all.
>
> When I was almost done, I spent 15 minutes on a 1 character typo (rrc in
> one spot, rcc in another). I didn't have a unit test for that case.

Let me put in a plug for code coverage tools in general.
Combined with good unit tests, these are truly invaluable.

There's a good one out there, but I forget what it's called --
<admission>I don't use it much, I've only played with it.</admission>

Hal

Eric Hodel

5/3/2005 9:35:00 PM

On 03 May 2005, at 14:22, Hal Fulton wrote:

> Eric Hodel wrote:
>> On 03 May 2005, at 12:27, Ben Giddings wrote:
>>>
>>> My open question is then: how do you find typos and brainos in
>>> seldom-run
>>> code in a dynamic language like Ruby?
>> Yes, unit tests and ruby -w. I wrote the thing in the 'I Rock.' post
>> between midnight and 4am. As you can imagine, writing code tired is
>> fraught with crazy typos, but the unit tests found them all.
>> When I was almost done, I spent 15 minutes on a 1 character typo (rrc
>> in one spot, rcc in another). I didn't have a unit test for that
>> case.
>
> Let me put in a plug for code coverage tools in general.
> Combined with good unit tests, these are truly invaluable.
>
> There's a good one out there, but I forget what it's called --
> <admission>I don't use it much, I've only played with it.</admission>

ZenTest?

PS: ZenTest comes, free of charge, with unit_diff, which is the
spiffiest test running helper tool ever. It runs your actual/expected
outputs through diff helping you spot the differences in massive
structures. Or even small ones of one or two lines.

--
Eric Hodel - drbrain@segment7.net - http://se...
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

Hal E. Fulton

5/3/2005 9:40:00 PM

Eric Hodel wrote:
>
> On 03 May 2005, at 14:22, Hal Fulton wrote:
>>
>> Let me put in a plug for code coverage tools in general.
>> Combined with good unit tests, these are truly invaluable.
>>
>> There's a good one out there, but I forget what it's called --
>> <admission>I don't use it much, I've only played with it.</admission>
>
>
> ZenTest?
>
> PS: ZenTest comes, free of charge, with unit_diff, which is the
> spiffiest test running helper tool ever. It runs your actual/expected
> outputs through diff helping you spot the differences in massive
> structures. Or even small ones of one or two lines.
>

I don't know ZenTest. I was thinking of rcov or whatever
it is called. Was it Simon S who took that over??

Hal

pat eyler

5/3/2005 9:46:00 PM

On 5/3/05, Eric Hodel <drbrain@segment7.net> wrote:
>
> PS: ZenTest comes, free of charge, with unit_diff, which is the
> spiffiest test running helper tool ever. It runs your actual/expected
> outputs through diff helping you spot the differences in massive
> structures. Or even small ones of one or two lines.

unit_test is awesome! Here's an example from an article I wrote
recently (to be published soon) -- first without unit_test, then the
same thing with unit_test.

$ ruby ts_long.rb
Loaded suite ts_long
Started
F
Finished in 0.02506 seconds.

1) Failure:
test_long(TestLong) [ts_long.rb:33]:
<"If you use open source software, you're sure to brush up against
some of its rough edges. It may be a bug, or a place where the
documentation isn't clear (or doesn't exist), or maybe it's not
available in your language.\n\nIf you want to give back to the
community, you can work on any of these problems, even if you're not a
programmer.\n\nYou could write a bug report for the developers (and
submit a patch if you're a programmer).\n\nYou could write or extend
existing documentation.\n\nIf you're really up for a challenge, you
could even work on translating the application and/or
documentation.\n\nHowever you choose to get involved, you should start
by contacting the developers."> expected but was
<"If you use open source software, you're sure to brush up against
some of its rough edges. It may be a bug, or a place where the
documentation isn't clear (or doesn't exist), or maybe it's not
available in your language.\n\nIf you want to give back to the
community you can work on any of these problems, even if you're not a
programmer.\n\nYou could write a bug report for the developers (and
submit a patch if you're a programmer).\n\nYou could write or extend
existing documentation.\n\nIf you're really up for a challenge, you
could even work on translating the application and/or
documentation.\n\nHowever you choose to get involved, you should start
by contacting the developers.">.

1 tests, 1 assertions, 1 failures, 0 errors
$ ruby ts_long.rb | unit_diff.rb
Loaded suite ts_long
Started
F
Finished in 0.017676 seconds.

1) Failure:
test_long(TestLong) [ts_long.rb:33]:
3c3
< If you want to give back to the community, you can work on any of
these problems, even if you're not a programmer.
---
> If you want to give back to the community you can work on any of
these problems, even if you're not a programmer.
1 tests, 1 assertions, 1 failures, 0 errors
$

>
> --
> Eric Hodel - drbrain@segment7.net - http://se...
> FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
>
>

--
thanks,
-pate
-------------------------
We are often unable to tell people what they need to know, because
they want to know something else, and would therefore only
misunderstand what we said
- the Raven (George MacDonald, Lilith)

pat eyler

5/3/2005 9:49:00 PM

On 5/3/05, pat eyler <pat.eyler@gmail.com> wrote:
> unit_test is awesome! Here's an example from an article I wrote
> recently (to be published soon) -- first without unit_test, then the
> same thing with unit_test.
>
[lots of test result stuff snipped]
oops, all that was all prepped for xml, so replace the > and <
characters as needed :)

--
thanks,
-pate
-------------------------
We are often unable to tell people what they need to know, because
they want to know something else, and would therefore only
misunderstand what we said
- the Raven (George MacDonald, Lilith)

comp.lang.ruby

Typo-checking instead of static typing

Ben Giddings

Curt Hibbs

SER

james_b

Eric Hodel

John Carter

Hal E. Fulton

Eric Hodel

Hal E. Fulton

pat eyler

pat eyler

x Login to ForumsZone