Static typing ain't so bad, after all...

[Matthew Johnson]

Even dynamic / duck typing isn't completely eschewing type checks,

even if you can get away with that for spectacularly long. And the
problem is that expressing the parameter constraint with "is a
Vector" is a little clearer than "has vector properties". It's not -
that- apparent in this example, but for more complex ones, where
you need a larger set of behaviours from the function parameters,
the formal granular constraints on them would be very verbose and
hard to understand. Having "ubmrella" concepts that are readily
understood is very helpful in that case. And the path between
concept and code is sometimes a very short one - having a mixin
Vector module with documented methods that you expect from an
object "with vector properties" and some helper methods you'd use
would probably be my first move after making a vector manipulation
library with the dynamism you describe.

Just in case anyone following this thread missed it I just posted in
another thread a quite lengthy discussion of these issues called Duck
Typed Concepts for Ruby with analysis applied to collection types
(the post was prompted by the ordered hash discussion).

Matthew

 

[Isaac Gouy]

Type information being part of the method signatures usually helps
narrow this down. I sort of get where HorkingLongAndObnoxiousName is
coming from - "parse" is a very generic method name and might be found
around the system with even the same arity for wildly varying purposes.
Without as much as receiver type information, the code search could show
a lot of unrelated results.

Hopefully, you could further narrow them down by making assumptions
based on identifier names, but that's a) error-prone, and b) better not
to have to do by hand.

Making sophisticated tool support is much easier if the tools have much
more information at their disposal, and statically typed code does
provide more / easier machine-analysable information.

Of course the point in mentioning the most basic Smalltalk IDE
functionality was that
- it doesn't actually require type signatures (hello Ruby)
- although basic it's surely a step up from not being able to easily
browse project-wide (or hierarchy local) implementors/sendors

I imagine the main practical difficulty is that people use many
different text editors rather than an IDE.

 

[James Britt]

Incidentally, what inspired all this is that I'm trying to use
mechanize and it's totally not working. Specifically, some sites like
slashdot.org work fine but rubyforge.org fails spectacularly. What happens
is that all links at rubyforge.org are nil. Some debugging suggests that
the problem is in htmltools, which mechanize uses to parse the HTML. So,
someone else's code uses someone else's code to do the work. Now you can
see why the term "node" comes up a lot in my example problems.
Except for the copyright and license agreement, there's almost no
documentation...
I'm tempted to make another post asking other people who use mechanize
(and/or htmltools) to go to rubyforge.org and see if they have the same
problems I do...

I've used Mechanize for a few things. When I've had undesired behavior,
I've added debugging print statements where htmltools or mechanize is
grabbing raw text and emitting "fixed" text or a REXML DOM.

If the source HTML is screwy, the parser may end up making really bad
guesses as to what the correct markup should be. (One tell-tale sign is
a series of identical closing tags.)

So you may want to visually inspect some sample source HTML to see if it
is proper HTML, and if it is not, see what might be choking the parser.

I just grabbed a random project page, and found an unclosed link
element, and 2 ul end tags that had no begin tags. Odd. Certainly not
the XHTML the doctype claims it to be, and perhaps enough to screw
Mechanize.

(Offhand, I don't see how static or explicit typing would help track
these sorts of issues. Unit tests might.)


--
James Britt

"Programs must be written for people to read, and only incidentally
for machines to execute."
- H. Abelson and G. Sussman
(in "The Structure and Interpretation of Computer Programs)

 

[David Vallner]

(Offhand, I don't see how static or explicit typing would help track
these sorts of issues. Unit tests might.)

Hrm. Mechanize or htmltools optionally passing HTML input through tidy
perhaps? I've no idea what the scope of htmltools markup error recovery
capabilities is, that just might help.

David Vallner

 

[Alex Young]

Hrm. Mechanize or htmltools optionally passing HTML input through tidy
perhaps? I've no idea what the scope of htmltools markup error recovery
capabilities is, that just might help.

Minimal, in my experience. There are some very, very broken pages out
there.

My current method for doing this sort of thing involves sniffing the
character set, normalising to utf-8, chucking the output through tidy to
get xml, ripping off the xml processing instruction and passing what's
left through REXML. You have to take the processing instruction off
because if the page actually includes text in more than one character
set (you'd be surprised how often this happens), the normalising won't
be complete and tidy will get it wrong half the time, which barfs REXML.
I can show code if you want.

In any case, this is tangential - the fundamental issue is that static
and explicit typing can't catch semantic errors. The original paper on
Hungarian notation (which Joel Spolsky goes on about at
http://www.joelonsoftware.com/articles/Wrong.html) nails this problem,
but I've never seen a language whose interpreter/compiler enforces
matched variable and function naming conventions.