Static typing ain't so bad, after all

ruby-talk
21

I have on occasion solved this problem by putting "breakpoint" as the
first line of the method and then inspecting the object that was
received in a debug console. Of course that doesn't always work or
can't always be done, but it has been useful.

Something else that bothers me is that sometimes code raises
exceptions, sometimes it returns nil, and when programming I often
can't decide which is better. When I go with the 'nil' approach I find
myself hunting for where the object became 'nil', often several
methods back. Anyone have any guidelines on this?

Les

···

On 8/22/06, Just Another Victim of the Ambient Morality <ihatespam@rogers.com> wrote:

    ...but this is often not enough. What if the parameter is called
"node." In context, how can this be better? "parse_node?"
"html_parse_node?" What's in this "html_parse_node?" Is it lazy parsing
or did it do the processing as it parsed and the node contains the parsed,
processed data? How would I know this? I can't look up any of the objects
that will be passed in because any object can be passed in; this language
is dynamically typed! I could look for a "class Node" in the hopes that
that is the name of one of the object classes passed in but who knows? It
could be called anything and there's no way for me to know what that
anything is!
    If the language were statically typed, I would know straight away what
type the parameter was and can look up, exactly, what it does and can
probably easily discern what it's role is.

22

   If the language were statically typed, I would know straight away what
   type the parameter was and can look up, exactly, what it does and can
   probably easily discern what it's role is.

i think that's a silly thing to say. straight away, tell me what role this
function plays:

   void (*signal(volatile int x, void (*const y)(int )))(int );

??

and i don't think that's being unfair. the reason is that static typing
builds up mountains of information for even mildly complex function
definitions. there is a reason a program exists (cdecl) to decode them! it's
very existence backs my assertion that little can be groked 'staight away'
merely by statically/explicitly typing function signatures.

in addition, languages like ocaml, while also statically typed, leave this
information out of the source while still be readable:

   let double x = x * 2;;

   let sum x y = x + y;;

   let factorial x =
     if (0 > x) then (raise Exit) else
     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.

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.

so, to drive it home further, you seem to think 'static' means 'explicitly
written by the programmer' - but of course that's not what it means.
fortunately, the 'explicit' route is available to you in ruby by simply
following certain pratices, either comment functions or cast arguments using
the 'class name as casting ctor pattern' used all over the place in ruby. for
isntance

   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.

regards.

Now, don't misunderstand me, I'm not advocating turning Ruby into a
statically typed language. I enjoy that Ruby has no "templates" (in the
C++ sense) because every method is "templatized!" The mere fact that C++
has templates is testimony to the power of dynamic typing.

templates are not dynamic typing though - i'd say they are testimony to how
much of a bastard a strong/static/non-inferred type system can be and how
adding compiler features to do the work for us is essential. note that
templates and any other sort of compiler inference feature __remove__ explicit
type info from the source!

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.

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.

cheers.

-a

···

On Tue, 22 Aug 2006, Just Another Victim of the Ambient Morality wrote:
--
to foster inner awareness, introspection, and reasoning is more efficient than
meditation and prayer.
- h.h. the 14th dali lama

23

Just Another Victim of the -argh-t Morality wrote:

    If your spam filter was triggered, how did you come to read my post?
    I'm also interested to hear if anyone else is annoyed by my name...

I use http://www.ruby-forum.com actually. It's their spam filter that
freaks out about it. The only 'problem' with your name is that I can't
post anything with your name in it, hence the replacement in the quote.

···

--
Posted via http://www.ruby-forum.com/\.

24

"Chris Gehlker" <canyonrat@mac.com> wrote in message
news:C1967BEB-2E20-488B-9977-5EA3B9CB1AC3@mac.com...

    Has anyone noticed this? How do you deal with this issue?

I must be missing something. i can't see why you didn't just ask the
debugger by typing <parametername>.class

    That's a good question...
    I wasn't looking at the source at runtime...

Aha, I interpreted "I was debugging..." as "I was running the debugger"

I could have run it and
stuck a breakpoint but that's when the problem occured to me. In a
hypothetical case, the code might be hard to execute. Indeed, if you're
looking at someone else's code then you might have no clue as to how to
execute it.

True, but I don't see how static typing would help in this case.

You could write some code to call it directly but that
wouldn't give you insight into how the method is used.

But there are times when you can figure out how to call the code that calls the code without starting from the very beginning.

    In my case, the debugger is really slow and it would have taken quite a
while to reach the breakpoint...

True, the debugger is sometimes very slow when executing up to a breakpoint. Sometimes I fall back on print statements.

···

On Aug 22, 2006, at 9:10 AM, Just Another Victim of the Ambient Morality wrote:

On Aug 22, 2006, at 5:30 AM, Just Another Victim of the Ambient >> Morality >> wrote:

---
Neither a man nor a crowd nor a nation can be trusted to act humanely or to think sanely under the influence of a great fear.

-Bertrand Russell, philosopher, mathematician, author, Nobel laureate (1872-1970)

25

you can try ruby-debug extension. It's several times faster than standard
debug.rb

gem install ruby-debug

···

On 8/22/06, Just Another Victim of the Ambient Morality < ihatespam@rogers.com> wrote:

"Chris Gehlker" <canyonrat@mac.com> wrote in message
news:C1967BEB-2E20-488B-9977-5EA3B9CB1AC3@mac.com...
>
> On Aug 22, 2006, at 5:30 AM, Just Another Victim of the > Ambient Morality > > wrote:
>
>> Has anyone noticed this? How do you deal with this issue?
>
> I must be missing something. i can't see why you didn't just ask the
> debugger by typing <parametername>.class

    That's a good question...
    I wasn't looking at the source at runtime... I could have run it and
stuck a breakpoint but that's when the problem occured to me. In a
hypothetical case, the code might be hard to execute. Indeed, if you're
looking at someone else's code then you might have no clue as to how to
execute it. You could write some code to call it directly but that
wouldn't give you insight into how the method is used.
    In my case, the debugger is really slow and it would have taken quite
a
while to reach the breakpoint...

--
Kent
---

26

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.

···

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

"Farrel Lifson" <farrel.lifson@gmail.com> wrote in message
news:c2c0b660608220540y3cf55b18v18c5879ce4ea55a9@mail.gmail.com...
>
> In my experience the way to handle this is to have parameters and
> variables with logical, consistent names. If I'm debugging a function
> 'foo(i)' it's almost impossible to know what is. If the function
> instead was defined as 'foo(categoryName)' it's a lot easier to deduct
> that it's a (string or an object that should be able to ducktyped to a
> string).

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

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Ben Franklin: "As we enjoy great Advantages from the Inventions of
others we should be glad of an Opportunity to serve others by any
Invention of ours, and this we should do freely and generously."

27

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?

···

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

MustExpandYourEmailClientsAdressColumnToThreeTimesItsUsualSize is

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"A script is what you give the actors. A program
is what you give the audience." - Larry Wall

28

Kewl,
Some times the best part of these threads is the parenthetical advice.

···

On Aug 22, 2006, at 9:58 AM, Kent Sibilev wrote:

you can try ruby-debug extension. It's several times faster than standard
debug.rb

gem install ruby-debug

--
No matter how far you have gone on the wrong road, turn back.
  -Turkish proverb

29

> If the language were statically typed, I would know straight away what
> type the parameter was and can look up, exactly, what it does and can
> probably easily discern what it's role is.

i think that's a silly thing to say. straight away, tell me what role this
function plays:

   void (*signal(volatile int x, void (*const y)(int )))(int );

??

and i don't think that's being unfair. the reason is that static typing
builds up mountains of information for even mildly complex function
definitions. there is a reason a program exists (cdecl) to decode them! it's
very existence backs my assertion that little can be groked 'staight away'
merely by statically/explicitly typing function signatures.

in addition, languages like ocaml, while also statically typed, leave this
information out of the source while still be readable:

   let double x = x * 2;;

   let sum x y = x + y;;

   let factorial x =
     if (0 > x) then (raise Exit) else
     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.

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/

···

ara.t.howard@noaa.gov wrote:

On Tue, 22 Aug 2006, Just Another Victim of the Ambient Morality wrote:

so, to drive it home further, you seem to think 'static' means 'explicitly
written by the programmer' - but of course that's not what it means.
fortunately, the 'explicit' route is available to you in ruby by simply
following certain pratices, either comment functions or cast arguments using
the 'class name as casting ctor pattern' used all over the place in ruby. for
isntance

   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.

regards.

> Now, don't misunderstand me, I'm not advocating turning Ruby into a
> statically typed language. I enjoy that Ruby has no "templates" (in the
> C++ sense) because every method is "templatized!" The mere fact that C++
> has templates is testimony to the power of dynamic typing.

templates are not dynamic typing though - i'd say they are testimony to how
much of a bastard a strong/static/non-inferred type system can be and how
adding compiler features to do the work for us is essential. note that
templates and any other sort of compiler inference feature __remove__ explicit
type info from the source!

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

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

cheers.

-a
--
to foster inner awareness, introspection, and reasoning is more efficient than
meditation and prayer.
- h.h. the 14th dali lama

30

<ara.t.howard@noaa.gov> wrote in message
news:Pine.LNX.4.62.0608220913440.21284@harp.ngdc.noaa.gov...

   If the language were statically typed, I would know straight away
what
   type the parameter was and can look up, exactly, what it does and can
   probably easily discern what it's role is.

i think that's a silly thing to say. straight away, tell me what role
this
function plays:

  void (*signal(volatile int x, void (*const y)(int )))(int );

??

and i don't think that's being unfair. the reason is that static typing
builds up mountains of information for even mildly complex function
definitions. there is a reason a program exists (cdecl) to decode them!
it's
very existence backs my assertion that little can be groked 'staight
away'
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).

in addition, languages like ocaml, while also statically typed, leave
this
information out of the source while still be readable:

  let double x = x * 2;;

  let sum x y = x + y;;

  let factorial x =
    if (0 > x) then (raise Exit) else
    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...

so, to drive it home further, you seem to think 'static' means
'explicitly
written by the programmer' - but of course that's not what it means.
fortunately, the 'explicit' route is available to you in ruby by simply
following certain pratices, either comment functions or cast arguments
using
the 'class name as casting ctor pattern' used all over the place in ruby.
for
isntance

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

Now, don't misunderstand me, I'm not advocating turning Ruby into a
statically typed language. I enjoy that Ruby has no "templates" (in the
C++ sense) because every method is "templatized!" The mere fact that
C++
has templates is testimony to the power of dynamic typing.

templates are not dynamic typing though - i'd say they are testimony to
how
much of a bastard a strong/static/non-inferred type system can be and how
adding compiler features to do the work for us is essential. note that
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!

···

On Tue, 22 Aug 2006, Just Another Victim of the Ambient Morality wrote:

31

"Chad Perrin" <perrin@apotheon.com> wrote in message
news:20060822190314.GA28969@apotheon.com...

"Farrel Lifson" <farrel.lifson@gmail.com> wrote in message
news:c2c0b660608220540y3cf55b18v18c5879ce4ea55a9@mail.gmail.com...
>
> In my experience the way to handle this is to have parameters and
> variables with logical, consistent names. If I'm debugging a function
> 'foo(i)' it's almost impossible to know what is. If the function
> instead was defined as 'foo(categoryName)' it's a lot easier to deduct
> that it's a (string or an object that should be able to ducktyped to a
> string).

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

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

···

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

32

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

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

···

On Wed, 23 Aug 2006, Just Another Victim of the Ambient Morality wrote:
--
to foster inner awareness, introspection, and reasoning is more efficient than
meditation and prayer.
- h.h. the 14th dali lama

33

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.

···

On Wed, Aug 23, 2006 at 04:55:13AM +0900, Just Another Victim of the Ambient Morality 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.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The first rule of magic is simple. Don't waste your time waving your
hands and hopping when a rock or a club will do." - McCloctnick the Lucid

34

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

···

On 8/22/06, Just Another Victim of the Ambient Morality <ihatespam@rogers.com> wrote:

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

35

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 Vallner

36

<ara.t.howard@noaa.gov> wrote in message
news:Pine.LNX.4.62.0608221432440.21284@harp.ngdc.noaa.gov...

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

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

   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:

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

···

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

37

Leslie Viljoen wrote:

···

On 8/22/06, Just Another Victim of the Ambient Morality > <ihatespam@rogers.com> wrote:

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

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

But it kinda sounds like a fun project...hmmmmmm....

-Justin

38

That was a perceptive comment. The fact that there are so few true cases of
objects that metamorphose in flight also accounts for the observed "magical"
behavior that "duck-typing" seems to "just work" almost all of the time. (By
magical, I mean unexpected for people like me with too many years of
experience programming in statically-typed languages.) The intention of a
well thought-out code path is generally easy to express without typing all
the types along the way. It doesn't break often, and when it does break, it
doesn't make a big mess.

···

On 8/22/06, David Vallner <david@vallner.net> wrote:

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.

39

"David Vallner" <david@vallner.net> wrote in message
news:44EB91B4.5070805@vallner.net...

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.

    I don't think we disagree here. This is one thing that dynamic typing
allows you to do and I'm questioning whether this is a benefit and you're
saying it absolutely isn't. So, we can agree that this does not contribute
to the benefits of dynamic typing...

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.

    By "it's a reduction ad extremum of a way of constraining object
behaviour" do you mean that it reduces object behaviour in an extremely
non-constraining way?
    With statically typed languages, the behaviour of an object is defined
by membership. If this variable is a member of this set, then it may have
these properties. So, when a function requires that a parameter be of a
certain type, it must be a member of this certain set. The use of other
types that may also work in this function but are not in this set are
(arbitrarily) excluded.
    With dynamically typed langauges, because variables (including
parameters) may be of any type, parameters passed into a method will work
as long as they, literally, satisfy the requirements of the method. This
is much more flexable than defining arbitrary membership. It's "ad
extremum" in the direction of flexability. Unfortunately, it's also
flexable enough to allow you to pass a totally inappropriate parameter into
a method but that's the trade off. Is it worth it? Most of us think so...

    In my opinion, this amounts to promoting the use of code in differing
contexts (or, simply, code reuse), which is the advantage that I had stated
before...

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.

    This isn't a contrived example, it's just a vague one.
    If you want an example you can use in the future, how about a function
or method that takes a vector and a list of vectors and sees if the given
vector can be expressed as a linear combination of the list of vectors.
Because so many things have vector properties (real numbers, complex
numbers, Cartesian vectors, matrices, real valued functions, almost
anything, it seems), you can reuse this function or method with any of
these types! How amazing is that?

40

   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.

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

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

···

On Wed, 23 Aug 2006, Just Another Victim of the Ambient Morality wrote:
--
to foster inner awareness, introspection, and reasoning is more efficient than
meditation and prayer.
- h.h. the 14th dali lama