Static typing ain't so bad, after all

Ruby
21

[email protected] wrote:

notice - this is statically typed. also notice the lack of explicitly encoded
typing - the compiler figures it out.

Yes type inference is wonderful, and for completeness let’s note that
in OCaml (and Haskel and Clean and…) we can also choose to add
explicit type declarations.

my point, in going down this tangent, is hopefully to point out what i always
point out in these threads - that people generally do not even understand what
it means to be statically (c is static ruby is not) or strongly typed (ruby is
strongly typed, c and java are not) and, furthermore, that having this
explicitly written by the programmer has nothing to do with the existence if a
feature in the language - taking ocaml’s type inference as an example.

Maybe part of it is easier to understand if we speak about
statically-type-checked and dynamically-type-checked.

What people mean by “strongly typed” is more puzzling to me. I’ll just
agree with this:

‘So what is “strong typing”? This appears to be a meaningless
phrase, and people often use it in a nonsensical fashion. To some it
seems to mean “The language has a type checker”. To others it means
“The language is sound” (that is, the type checker and run-time
system are related). To most, it seems to just mean, “A language like
Pascal, C or Java, related in a way I can’t quite make precise”. If
someone uses this phrase, be sure to ask them to define it for you.
(For amusement, watch them squirm.)’

p263 Type Soundness, “Programming Languages: Application and
Interpretation”
http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/

22

On Tue, Aug 22, 2006 at 11:50:12PM +0900, Just Another Victim of the
Ambient M. wrote:

...but this is often not enough.  What if the parameter is called

“node.”

That doesn’t even address the exhortation to name your functions
properly, because “node” is a terrible name for a function unless the
operation of your program is so clearly defined and its requirements and
context so obvious that “node” becomes an explicit description of
functionality. Even then, it’s probably not as expressive as it could
be.

23

“Chad P.” [email protected] wrote in message
news:[email protected]…

that it’s a (string or an object that should be able to ducktyped to a
be.
You know, it looks like you trimmed off the context and then responded
that, rather than reading the post and then trimming off the unimportant
parts in your response.

In my example, "node" is a parameter and an object, not a method

name.
It’s curt but it’s not entirely a bad name, as long as it is a node of
something that has nodes. It could be more expressive but just as my
example demonstrated (the context that you trimmed in your response),
it’s
hard to expand on it. You could say what type of structure it is a node
for but that doesn’t help that much unless you’re intimately familiar
with
that structure. In my case, what would really have helped is if I can
find
the definition of one of these nodes that will be passed in (so that I
may
become intimately familiar with that structure). In my case, I think
there
is only one type that will ever be passed into this function but, of
course, that’s hard to tell…

24

[email protected] wrote in message
news:[email protected]…

merely by statically/explicitly typing function signatures.
You’re right. I did make a blanket statement about statically typed
languages that’s not always true. However, it does often help to know
what
types are being used when reading a function definition. Consider this
example:

def parse data, machine
node = data.index 0
machine.process node
end

As it is now, it's rather contrived but you could add some

(contextually) sensible code around it without disturbing this basic
functionality and see it offers no clue as to what “node” or “machine”
is.
You could look for anything with a “process” method but what “node” will
be
is much harder to find and important to the understanding of what this
method is for (despite that it’s obviously not important to
understanding
what the method actually does).

match x with
    0 -> 1
  | n -> (n * (factorial (n - 1)));;

notice - this is statically typed. also notice the lack of explicitly
encoded
typing - the compiler figures it out.

You're right.  I'm talking more about explicit typing rather than

“static typing,” so perhaps my thread is ill named…

def m a, b, c
a = String a
b = Integer b
c = Float f

....

end

now, that’s not static, but it is explicit. you can obivously follow
this
pattern with user defined classes.

I may but others may not.  I am looking over code that does not

follow
this convention (nor did I expect them to) so it doesn’t help my
situation…

templates and any other sort of compiler inference feature remove
explicit
type info from the source!

...but they perform the same purpose.
The purpose of C++ templates is to reuse code.  Often, you want to

perform the same operations on different types of data. A linked list
of
integers doesn’t behave any differently than a linked list of strings,
except that one has integers while the other has strings.
The purpose of dynamic typing, as far as I can tell, is to reuse
code.
Sure, you can reuse a variable for very different purposes but is that
really such an advantage? In my opinion, the purpose of dynamic typing
is
so that methods can accept parameters of varying types and perform the
same
operations on those types, thus reusing the method code…

I’m just saying that static typing “ain’t so bad,” in that this is one
problem I would not have had were I working with a statically typed
language.

correct - you’d simply have different ones.

Of course...  What do you think I'm trying to say here?  That static

typing is the way to go and Ruby should adopt it? You can’t probably
think
that after everything else I’ve said so it must be something else…
I’m looking to see how people deal with the problems that come up
from
being dynamically typed…

I’m also looking for how people deal with this issue, since it surely
must
come up from time to time…

well, i showed one solution above. there are plenty of others.

Well, I can't wait to hear them!
25

On Wed, Aug 23, 2006 at 04:55:13AM +0900, Just Another Victim of the
Ambient M. wrote:

You know, it looks like you trimmed off the context and then responded

that, rather than reading the post and then trimming off the unimportant
parts in your response.

I just didn’t want to swim through code – which is sorta the point of
good naming conventions: not having to reason through an entire
program’s logic to figure out what something does. I see something
called “node” and think “What the hell does THAT mean?” then start
wondering whether I have to read through, and flowchart, the entire
program to figure it out.

26

On Wed, 23 Aug 2006, Just Another Victim of the Ambient M. wrote:

As it is now, it’s rather contrived but you could add some (contextually)
sensible code around it without disturbing this basic functionality and
see it offers no clue as to what “node” or “machine” is. You could look
for anything with a “process” method but what “node” will be is much
harder to find and important to the understanding of what this method is
for (despite that it’s obviously not important to understanding what the
method actually does).

fair enough. i don’t disagree here that explicit typing might help
here,
but it’s only one tool when statically analyzing code.

You’re right. I’m talking more about explicit typing rather than “static
typing,” so perhaps my thread is ill named…

ok.

I may but others may not. I am looking over code that does not follow
this convention (nor did I expect them to) so it doesn’t help my
situation…

granted.

…but they perform the same purpose. The purpose of C++ templates is to
reuse code. Often, you want to perform the same operations on different
types of data. A linked list of integers doesn’t behave any differently
than a linked list of strings, except that one has integers while the
other has strings. The purpose of dynamic typing, as far as I can tell,
is to reuse code. Sure, you can reuse a variable for very different
purposes but is that really such an advantage? In my opinion, the
purpose of dynamic typing is so that methods can accept parameters of
varying types and perform the same operations on those types, thus
reusing the method code…

hmmm. i see the primary advantage of dynamic typing as the time saving
i gain
by not spoon feeding the compiler and the associated productivity gain.
you
are pointing out that it does not always save time, but my experience is
that
it does for a large percentage of the time.

Of course… What do you think I’m trying to say here? That static
typing is the way to go and Ruby should adopt it? You can’t probably
think that after everything else I’ve said so it must be something
else… I’m looking to see how people deal with the problems that come
up from being dynamically typed…

i understand. still, these static/dynamic threads often get muddled by
ill
definitions and then ramble forever - it’s best to get on the same page
regarding terms and the problem… that’s all.

Well, I can’t wait to hear them!

i guess what i’d offer is that mechanisms like

  • explicit typing
  • documentation
  • introspection (as in runtime debugging)
  • static typing
  • clear coding conventions

all contribute to code understanding and that many of these features are
available to ruby and not, for example, c and vise-versa. if someone
leaves
you with no tools then it’s just bad code! :wink:

in this case it seems nearly so but you do still have rtti under
irb/debug
mode. it’s a powerful tool if not easy to get setup with an appropriate
env…

kind regards.

-a

27

On 8/22/06, Just Another Victim of the Ambient M.
[email protected] wrote:

course, that’s hard to tell…
Almost anyone can write hard to understand code in any language - I
try to comment anything that might be unclear in the code I’m writing.
Particularly I maintain a lot of C# code where arb names are invented
for objects, making it hard to guess their function.

But you are right that it’s normally easy to determine the structure
of objects passed to functions in C# - normally as easy as
“right-click->go to definition”. Since most of my Ruby functions get
called with only certain objects as parameters, I wonder if a clever
text search wouldn’t be able to guess at those objects. Of course,
just looking at the function it would be impossible to tell, but a
clever search might be able to see:

def PrintMarks(marks)

has been called only by:
PrintMarks(marks)

and above that is:

marks = markSheet[0]

and somewhere before that is:

markSheet[0] = StudentMarkTable.new

etc.

Of course it might not be worth the effort to write such a thing, I
have certainly not needed it badly enough.

Les

28

[email protected] wrote in message
news:[email protected]…

tell,
are pointing out that it does not always save time, but my experience is
that
it does for a large percentage of the time.

Personally, I don't see these small "time savings" as a big

advantage.
Perhaps I shouldn’t shrug off “syntactic sugar” so easily but features
of a
language that save a bit of typing aren’t a big deal to me. I’m a fast
typist and software is plagued by so many other issues…
Please don’t misunderstand me. Ultimtely, all features of a
language
are “time saving” ones, in that we obviously want to spend as little
time
as possible to get the job done. However, since I spend most of my time
thinking about how to do things and figuring out why my implementation
doesn’t work (debugging) and very little time actually typing out my
program, I prefer some of the more macroscopic features of a language.
For
C++, that would be templates (the STL and boost), typing and subtyping.
For Ruby, that would be dynamic typing (which replaces the whole C++
template idea), blocks as closures and it’s general run-time flexability
(the fact that attr_accessor can be defined in the language itself is
amazing!)…
This may explain why I use other people’s code so much. I’d rather
not
waste time re-inventing the wheel and will gladly borrow one from
someone
else…

all contribute to code understanding and that many of these features are
available to ruby and not, for example, c and vise-versa. if someone
leaves
you with no tools then it’s just bad code! :wink:

Yeah, I'm not surprised that this might be one of those "what can

you
do? Life is hard…" problems. I was just throwing this out there in
case
it was interesting and that, maybe, someone might have a surprising
solution or approach to this issue…

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…

29

On Wed, 23 Aug 2006, Just Another Victim of the Ambient M. wrote:

Personally, I don’t see these small “time savings” as a big advantage.
Perhaps I shouldn’t shrug off “syntactic sugar” so easily but features of
a language that save a bit of typing aren’t a big deal to me. I’m a fast
typist and software is plagued by so many other issues…

ah. just to clarify i meant that the reduction in total lines of code
is a
huge boon for me, not only when writing code, but more importantly when
reading it later. no amount of static typing helps with 10,000 line
fortran files, for instance, and i maintain a lot of code.

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…

this seems like a good fit for ruby-breakpoint.

gem install ruby-breakpoint

it’s great for debugging these kinds of things via introspection - just
throw
in a breakpoint and start inspecting live code.

on a related note - curl and wget sure work good :wink:

good luck!

-a

30

On 2006-08-22, William C. [email protected] wrote:

For preventing the problem, my answer is the same as everyone
else’s… Good naming techniques.

Word! I still remember the time I found a bug in my code simply by
renaming a poorly-named method. As soon as I saw the result of the
replacement I thought “Hold on, that’s wrong!”.

Jeremy H.

31

Just Another Victim of the Ambient M. wrote:

[email protected] wrote in message
news:[email protected]…

-snip-

leaves
you with no tools then it’s just bad code! :wink:

Yeah, I'm not surprised that this might be one of those "what can you

do? Life is hard…" problems. I was just throwing this out there in case
it was interesting and that, maybe, someone might have a surprising
solution or approach to this issue…

Another mechanism - IDE support.

The most basic Smalltalk code exploration builds on tools for browsing
implementors/senders of methods. We’d browse all implementors of “parse
data, machine” to see if we were dealing with a massively polymorphic
method, and then we’d browse all senders of “parse data, machine” and
keep tracing back to see what sort of things “data.index 0” was being
initialized with.

32

Leslie V. wrote:

for but that doesn’t help that much unless you’re intimately familiar
Almost anyone can write hard to understand code in any language - I
clever search might be able to see:

and somewhere before that is:

markSheet[0] = StudentMarkTable.new

etc.

Of course it might not be worth the effort to write such a thing, I
have certainly not needed it badly enough.

Les

But it kinda sounds like a fun project…hmmmmmm…

-Justin

33

On 2006-08-22, William C. [email protected] wrote:

As for static typing… I feel your pain. It’s heresy, but I
prefer static typing.

You’ll come round! I did, and I was a hard-core ML/Haskell lover.
They all crack in the end! :wink:

Jeremy H.

34

Isaac G. wrote:

Another mechanism - IDE support.

The most basic Smalltalk code exploration builds on tools for browsing
implementors/senders of methods. We’d browse all implementors of “parse
data, machine” to see if we were dealing with a massively polymorphic
method, and then we’d browse all senders of “parse data, machine” and
keep tracing back to see what sort of things “data.index 0” was being
initialized with.

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.

Dynamic typing is inherently more prone to being hard to maintain. The
problems can be very well mitigated using proper conventions, and common
sense.

But that’s not always the case, and when you get thrown on a project as
a maintainer or to contribute feature XY into revision Z of a codebase
that had random people without a code style guide leading them working
on it for two years, you get very, very happy that you have Ctrl-Shift-G
in Eclipse on your side. In a rainy day scenario, the systems aren’t
quite equivalent.

David V.

35

Also, please – PLEASE – read the hundreds, or perhaps thousands, of
posts about this in the ruby-talk archives. I’m not optimistic about
breaking the cycle; it seems we’re doomed to have this thread repeated
three or four times a year. But, I don’t know, maybe one of these
years we can stop.

Here, take a “PWNT3HN00BS!” T-shirt. Brought to you by the Grumpy Jaded
Gits Anonymous.

The best strategy is to take two painkillers, wait for the caffeine to
wear off, and then start copy/pasting the explanations.
MustExpandYourEmailClientsAdressColumnToThreeTimesItsUsualSize is
obviously a tad bit new, so you can either start making scary
hand-motions in hopes he runs for the hills, or join the crowd in
showing him The Light. I actually find that strangely soothing - gives
me that fuzzy feeling all over when someone Gets It.

wombles back to proselytizing

David V.

36

William C. wrote:

As for static typing… I feel your pain. It’s heresy, but I prefer
static typing. Inheritance provides everything I need that Duck Typing
does for me. (At least, so far. I’m really new to Ruby.)

Static typing has limitations where dynamic typing doesn’t have them,
but they’re really few and far between. Doing proof-of-concept code, or
exploring more exotic design patterns come to mind. Horses for courses,
I presume, I’m in the “add optional type / interface / protocol
adherence checks” camp myself.

-sigh- Victim, your name triggers the spam filter here. Am I the only
one annoyed by this?

Har. So far, only the spam filters in my head go off. Reminds me of my
little sister’s 12 year old IM friends that whap arbitrary deep-sounding
fluff into their screen names.

David V.

37

On Wed, Aug 23, 2006 at 08:21:05AM +0900, David V. wrote:

MustExpandYourEmailClientsAdressColumnToThreeTimesItsUsualSize is

On that note . . .

I’d really like to see subject lines get shorter than they have been
lately, on a number of threads. What good is a subject line so long
that you can’t see half of it displayed in your MUA?

38

Sure, you can reuse a variable for very different purposes but is that
really such an advantage?

You don’t do this. Heck, you shouldn’t even reuse a variable for the
same purpose. Reusing variables tends to imply that you don’t really
know what their purpose was in the first place.

The advantage of dynamic typing comes in working with the hairier design
patterns. It’s a reduction ad extremum of a way of constraining object
behaviour - the typical members of the “expliticly” typed language group
use type / class hierarchies for this, and check against those.

The group of dynamically typed languages doesn’t make assumptions based
on the elements that make up an object’s behaviour belonging together -
an object is of the correct type for a given message send if it responds
to said one message, nothing more, nothing less.

For (a very contrived) example any object that just so happens to
properly respond to the messages for arithmethical operations can be
substituted for an “integer” you only ever do arithmetics with without
the language runtime batting an eyelash.

In dynamically typed languages, the type of an object isn’t its “class”
or any other predictable concept, it’s just the protocol it adheres to
during its lifetime. Most such languages also make no presumption that
this protocol, or the behaviour of an object remains the same during its
lifetime - which makes compile-time checks rather pointless.

Of course, you rarely use even this aspect of dynamic typing - in fact,
I can’t come up with a single noncontrived example for it, these things
just don’t occur in daily coding. But dynamic languages sure a heck
faster to type, and the fact the compiler rarely bitches at all is very,
very appealing to people that know what they’re doing most of the time.

David V.

39

David V. wrote:

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.

40

Just Another Victim of the Ambient M. wrote:

(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 B.

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