Typo-checking instead of static typing

Discussion in 'Ruby' started by Ben Giddings, May 3, 2005.

  1. Ben Giddings

    Ben Giddings Guest

    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
     
    Ben Giddings, May 3, 2005
    #1
    1. Advertising

  2. Ben Giddings

    Curt Hibbs Guest

    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
     
    Curt Hibbs, May 3, 2005
    #2
    1. Advertising

  3. Ben Giddings

    SER Guest

    > 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
     
    SER, May 3, 2005
    #3
  4. Ben Giddings

    James Britt Guest

    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
     
    James Britt, May 3, 2005
    #4
  5. Ben Giddings

    Eric Hodel Guest

    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 - - http://segment7.net
    FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
     
    Eric Hodel, May 3, 2005
    #5
  6. Ben Giddings

    John Carter Guest

    On Wed, 4 May 2005, SER wrote:

    >> 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



    http://rubyforge.org/snippet/detail.php?type=snippet&id=47

    Description:
    Searches through all defined symbols for near misses in namespace.
    Hopefully some of those listed will be mispelling bugs.

    Usage :-
    ruby -w Mispel.rb

    Will run its unit tests.

    ruby -rmodule1 -rmodule2 -rmodule... Mispel.rb --cache

    Will create ~/.mispel_ignore, a list of known near misses in the
    system and in those modules.

    If you add into your script, after all require statements...

    require 'Mispel'
    Mispel::problem_cases
    exit(1)

    It will (after a long time) print out all near misses in namespace
    that are not in ~/.mispel_ignore


    John Carter Phone : (64)(3) 358 6639
    Tait Electronics Fax : (64)(3) 359 4632
    PO Box 1645 Christchurch Email :
    New Zealand


    Somewhere on the edge of a Galaxy, one of literally billions of such
    galaxies, is a sun, one of literally billions of suns in that
    galaxy.

    Orbiting that sun is a small rock 330000 times smaller than that
    sun.

    This rock is covered by a very very thin scum of life. (Think 6000km
    of rock followed by a meter or so of biomass.)

    Amongst the millions of species in that scum are many hundreds of
    thousands of types beetle and a mere handful of primates.

    Surprisingly enough, this email does not originate from a beetle.

    It originates from just one of the 6 billion vastly outnumbered humans.

    I trust you will keep this perspective and context in mind when
    reacting to this email.
     
    John Carter, May 3, 2005
    #6
  7. Ben Giddings

    Hal Fulton Guest

    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
     
    Hal Fulton, May 3, 2005
    #7
  8. Ben Giddings

    Eric Hodel Guest

    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 - - http://segment7.net
    FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
     
    Eric Hodel, May 3, 2005
    #8
  9. Ben Giddings

    Hal Fulton Guest

    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
     
    Hal Fulton, May 3, 2005
    #9
  10. Ben Giddings

    pat eyler Guest

    On 5/3/05, Eric Hodel <> 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]:
    &lt;"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."&gt; expected but was
    &lt;"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."&gt;.

    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
    &lt; If you want to give back to the community, you can work on any of
    these problems, even if you're not a programmer.
    ---
    &gt; 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 - - http://segment7.net
    > 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, May 3, 2005
    #10
  11. Ben Giddings

    pat eyler Guest

    On 5/3/05, pat eyler <> 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 &gt; and &lt;
    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)
     
    pat eyler, May 3, 2005
    #11
  12. Ben Giddings

    Nick Woolley Guest

    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?


    At the risk of being jeered: I have found perl's 'use strict' with 'my'
    declarations have helped keep my feet unshot in the past. It won't get
    everything, but misspelt variables won't pop into existance behind your
    back. Conversely, javascript has always spent me to deadline hell with
    just this sort diabolical mischief (grr).

    I've always wondered why ruby doesn't have somthing similar. Presumably
    there's some flaw/objection to the idea of having this? But! surely
    this is exactly what Ben is asking for?

    Also, conceivably, couldn't (optional) implicit run-time checks be added
    which match the declared 'type' of an assignee variable to the current
    type of the assigned object? No type inference, just a little extra
    runtime overhead (which could be switched off). And/or similar optional
    preconditions on method arguments?

    e.g.

    Fruit var1 = Banana.new # ok
    Flesh var2 = Sausage.new # ok
    Object var3 = Hamster.new # no checks on this var
    var3 = var2 # so, Sausages are okay here
    var3 = var1 # so are Bananas
    var1 = var2 # but not here, cos Sausages aren't Fruit - bang!
    var4 = 0 # var4 isn't predeclared - bang!

    Um, this seems so obvious I am expecting someone to reveal my
    cluelessness imminently.

    Nick
     
    Nick Woolley, May 4, 2005
    #12
  13. Ben Giddings

    Hal Fulton Guest

    Nick Woolley wrote:
    >
    > Also, conceivably, couldn't (optional) implicit run-time checks be added
    > which match the declared 'type' of an assignee variable to the current
    > type of the assigned object? No type inference, just a little extra
    > runtime overhead (which could be switched off). And/or similar optional
    > preconditions on method arguments?
    >
    > e.g.
    >
    > Fruit var1 = Banana.new # ok
    > Flesh var2 = Sausage.new # ok
    > Object var3 = Hamster.new # no checks on this var
    > var3 = var2 # so, Sausages are okay here
    > var3 = var1 # so are Bananas
    > var1 = var2 # but not here, cos Sausages aren't Fruit - bang!
    > var4 = 0 # var4 isn't predeclared - bang!
    >
    > Um, this seems so obvious I am expecting someone to reveal my
    > cluelessness imminently.
    >


    It's not a question of cluelessness, but I would state it
    this way: Absence of explicit typing and variable declarations
    are two of Ruby's best features, and they are foundational in
    its design.


    Hal
     
    Hal Fulton, May 4, 2005
    #13
  14. SER wrote:
    >> 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.


    Thanks for that comprehensive summary. However I don't fully agree: in
    Ruby land it *is* a beast - although it's not in Eiffel land. Note:
    context matters. :)

    Kind regards

    robert
     
    Robert Klemme, May 4, 2005
    #14
  15. On Wed, May 04, 2005 at 06:18:11AM +0900, John Carter wrote:
    > On Wed, 4 May 2005, SER wrote:
    >
    > >>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

    >
    >
    > http://rubyforge.org/snippet/detail.php?type=snippet&id=47
    >
    > Description:
    > Searches through all defined symbols for near misses in namespace.
    > Hopefully some of those listed will be mispelling bugs.
    >


    It's also interesting to note that perl does a simpler (but surprisingly
    effective) check if you enable warnings:

    code:

    #!/usr/bin/perl -w

    $a = 1;

    print $aa + 3;



    output:

    Name "main::a" used only once: possible typo at test.pl line 3.
    Name "main::aa" used only once: possible typo at test.pl line 5.
    Use of uninitialized value in addition (+) at test.pl line 5.
    3


    Joost.
     
    Joost Diepenmaat, May 4, 2005
    #15
  16. Ben Giddings wrote:
    >
    > Static typing tends to find typos and brainos in code before it's
    > executed.
    >


    My most frequent Ruby error:
    "NoMethodError: undefined method `foo' for nil:NilClass"

    Not a typo, and arguably anything is a braino.

    Fixed by asking oneself two questions
    1) How in sam hill did that get set to nil?
    2) Can method bar can return nil, if blah blah foozle wimble?

    --
    J. Lambert
     
    Jon A. Lambert, May 4, 2005
    #16
  17. Nick Woolley wrote:

    > No type inference, just a little extra
    > runtime overhead (which could be switched off). And/or similar optional
    > preconditions on method arguments?


    The latter is available through ruby-contract. See
    http://ruby-contract.rubyforge.org/
     
    Florian Groß, May 4, 2005
    #17
  18. 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>
    >
    >
    > Hal


    Are there any code coverage tools for Ruby?

    -Charlie
     
    Charles Mills, May 4, 2005
    #18
  19. Ben Giddings

    Joe Van Dyk Guest

    On 5/4/05, Jon A. Lambert <> wrote:
    > Ben Giddings wrote:
    > >
    > > Static typing tends to find typos and brainos in code before it's
    > > executed.
    > >

    >
    > My most frequent Ruby error:
    > "NoMethodError: undefined method `foo' for nil:NilClass"
    >
    > Not a typo, and arguably anything is a braino.
    >
    > Fixed by asking oneself two questions
    > 1) How in sam hill did that get set to nil?
    > 2) Can method bar can return nil, if blah blah foozle wimble?
    >


    That's about my most common error too (it ties with a parse error due
    to a missing 'end' statement).
     
    Joe Van Dyk, May 4, 2005
    #19
  20. Ben Giddings

    Hal Fulton Guest

    Joe Van Dyk wrote:
    > On 5/4/05, Jon A. Lambert <> wrote:
    >
    >>Ben Giddings wrote:
    >>
    >>>Static typing tends to find typos and brainos in code before it's
    >>>executed.
    >>>

    >>
    >>My most frequent Ruby error:
    >>"NoMethodError: undefined method `foo' for nil:NilClass"
    >>
    >>Not a typo, and arguably anything is a braino.
    >>
    >>Fixed by asking oneself two questions
    >>1) How in sam hill did that get set to nil?
    >>2) Can method bar can return nil, if blah blah foozle wimble?
    >>

    >
    >
    > That's about my most common error too (it ties with a parse error due
    > to a missing 'end' statement).
    >


    Yes. Most languages just shift this "boundary problem" into
    different paradigms and terminology.

    In Java, the "pointerless language," the most common runtime
    error is "NULL pointer exception."

    Or in Pascal, "Attempt to dereference nil pointer."

    Or in C, "Segmentation fault."


    Hal
     
    Hal Fulton, May 4, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Digital Puer
    Replies:
    27
    Views:
    5,152
    James Rogers
    Sep 13, 2003
  2. Michael Muller

    Static typing

    Michael Muller, Jul 25, 2003, in forum: Python
    Replies:
    12
    Views:
    643
    Michael Muller
    Aug 1, 2003
  3. Bryan Rasmussen
    Replies:
    2
    Views:
    365
    Scott David Daniels
    Jun 12, 2005
  4. JimLad
    Replies:
    0
    Views:
    523
    JimLad
    Jan 26, 2010
  5. Charles Oliver Nutter
    Replies:
    4
    Views:
    153
    Rick DeNatale
    Oct 2, 2007
Loading...

Share This Page