Forum: Ruby begining programmer questions

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-14 23:55
I was wondering, i thought in Ruby you didnt have to declare variables
but in this little exercise from the book i have the error i get is that
the variable info is undeclared. Basically the exercise is to keep
filling an array with user input until they choose exit and then the
array is sorted and printed out, is that how i would go about doing
that?

def input
  puts "Enter some info"
  info[] = gets.chomp
while info[] != "exit"
info[] = gets.chomp
end
info[].sort
puts "#{info}"
end
2c80e1b0837eec76d38d4f7fa1c15e87?d=identicon&s=25 Michael Gorsuch (Guest)
on 2006-05-15 00:07
(Received via mailing list)
When you call 'info[]', the '[]' piece is actually trying to invoke a
method
in the object.

since 'info' is not delcared as an object, Ruby has no clue what to do.

Now, if you did this:

info = []

or

info = Array.new

You'd be better off.

As for stuffing 'info' with data, you can do this:

info << gets.comp

and

info.sort!

Does this help you at all?
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 00:12
oh ok thats right it has to be an object in order to be useful. The book
i am reading didnt mention that in the entire chapter on arrays. thats
why i didnt get it.



Michael Gorsuch wrote:
> When you call 'info[]', the '[]' piece is actually trying to invoke a
> method
> in the object.
>
> since 'info' is not delcared as an object, Ruby has no clue what to do.
>
> Now, if you did this:
>
> info = []
>
> or
>
> info = Array.new
>
> You'd be better off.
>
> As for stuffing 'info' with data, you can do this:
>
> info << gets.comp
>
> and
>
> info.sort!
>
> Does this help you at al
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 00:17
i dont know doing info = Array.new seems like an array declaration to
me. Couldn the constrution of an array object be implied in just saying
info[] you what what i mean? That would be even more simplified.



corey konrad wrote:
> oh ok thats right it has to be an object in order to be useful. The book
> i am reading didnt mention that in the entire chapter on arrays. thats
> why i didnt get it.
>
>
>
> Michael Gorsuch wrote:
>> When you call 'info[]', the '[]' piece is actually trying to invoke a
>> method
>> in the object.
>>
>> since 'info' is not delcared as an object, Ruby has no clue what to do.
>>
>> Now, if you did this:
>>
>> info = []
>>
>> or
>>
>> info = Array.new
>>
>> You'd be better off.
>>
>> As for stuffing 'info' with data, you can do this:
>>
>> info << gets.comp
>>
>> and
>>
>> info.sort!
>>
>> Does this help you at al
2c80e1b0837eec76d38d4f7fa1c15e87?d=identicon&s=25 Michael Gorsuch (Guest)
on 2006-05-15 00:22
(Received via mailing list)
I suppose it could, but I think the easiest way to build an Array in
ruby is
as follows:

info = []

You can build a Hash via:

info = {}
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 00:25
ok thanks for the help



Michael Gorsuch wrote:
> I suppose it could, but I think the easiest way to build an Array in
> ruby is
> as follows:
>
> info = []
>
> You can build a Hash via:
>
> info = {}
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 00:29
well i tried what you said but i still get an error now, it says that i
have the wrong number of arguments. I know it isnt that important of
program but i just dont understand the error messages.

def input
  puts "Enter some info"
  info = []
  info << gets.chomp
while info[] != "exit"
info << gets.chomp
end
info.sort
puts "#{info}"
end



corey konrad wrote:
> ok thanks for the help
>
>
>
> Michael Gorsuch wrote:
>> I suppose it could, but I think the easiest way to build an Array in
>> ruby is
>> as follows:
>>
>> info = []
>>
>> You can build a Hash via:
>>
>> info = {}
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 00:36
oh ok i needed to remove the [] in the while loop to, ok. Now when i
type exit the while loop ends but then the entire program ends instead
of sorting the aray and printing it...? I dont understand that


corey konrad wrote:
> well i tried what you said but i still get an error now, it says that i
> have the wrong number of arguments. I know it isnt that important of
> program but i just dont understand the error messages.
>
> def input
>   puts "Enter some info"
>   info = []
>   info << gets.chomp
> while info[] != "exit"
> info << gets.chomp
> end
> info.sort
> puts "#{info}"
> end
>
>
>
> corey konrad wrote:
>> ok thanks for the help
>>
>>
>>
>> Michael Gorsuch wrote:
>>> I suppose it could, but I think the easiest way to build an Array in
>>> ruby is
>>> as follows:
>>>
>>> info = []
>>>
>>> You can build a Hash via:
>>>
>>> info = {}
2c80e1b0837eec76d38d4f7fa1c15e87?d=identicon&s=25 Michael Gorsuch (Guest)
on 2006-05-15 00:37
(Received via mailing list)
while info[] != "exit"

this line is giving the error.

The '[]' piece expects an integer to placed in there to reference the
array.  For example, info[0] or info[53].

I suggest something similar to this:

def input
  puts "Enter some info"
  info = []
  while (data = gets.chomp) != 'exit'
    info << data
  end
  info.sort!
  puts info
end
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-15 00:41
(Received via mailing list)
A lot of people have the mistaken notion that Ruby is not "strongly
typed"
(perhaps because they confuse dynamic type-resolution with weak typing),
and
this is a good counterexample. You might suppose that Ruby could infer
from
the syntax info[]= that it should create an object of type Array, but in
fact the method named []= is defined on other classes (such as Hash),
and
could of course be defined or meta-defined in your own classes. So Ruby
doesn't try to guess what class you meant.
2c80e1b0837eec76d38d4f7fa1c15e87?d=identicon&s=25 Michael Gorsuch (Guest)
on 2006-05-15 00:41
(Received via mailing list)
Just to be clear, will you please send your current source.  I'd be glad
to
look at it.
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 00:45
you're talking over my head francis, i am a beginner. I have no idea
what strongly typed even means to be honest.


Francis Cianfrocca wrote:
> A lot of people have the mistaken notion that Ruby is not "strongly
> typed"
> (perhaps because they confuse dynamic type-resolution with weak typing),
> and
> this is a good counterexample. You might suppose that Ruby could infer
> from
> the syntax info[]= that it should create an object of type Array, but in
> fact the method named []= is defined on other classes (such as Hash),
> and
> could of course be defined or meta-defined in your own classes. So Ruby
> doesn't try to guess what class you meant.
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 00:46
Michael Gorsuch wrote:
> Just to be clear, will you please send your current source.  I'd be glad
> to
> look at it.


this is it:

def input
  puts "Enter some info"
  info = []
  info = gets.chomp
while info != "exit"
info = gets.chomp
end
info.sort
puts "#{info}"
end
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-05-15 00:50
(Received via mailing list)
On May 14, 2006, at 6:17 PM, corey konrad wrote:

> i dont know doing info = Array.new seems like an array declaration to
> me. Couldn the constrution of an array object be implied in just
> saying
> info[] you what what i mean? That would be even more simplified.

The problem here is you are confusing declaring a variable with
assigning a vlaue to a variable.

In ruby I can type
x = 0 # assigns 0 to x
without declaring the variable x.

In C I have to type
int x; /* declares variable named x */
x = 0; /* assigns 0 to it */

Acutally I could have typed

int x = 0;

but that's merely a more concise way of writing the declaration and
the assigment.

Technically this is what happens in ruby as well, but declarations
occur as a side effect of the first (spatial, not necessarily
chronilogical) assignment.

You can see this with the following two pieces of code:

% cat example1.rb
puts x.inspect

% ruby example1.rb
example1.rb:1: undefined local variable or method `x' for main:Object
(NameError)

You'll note that since x doesn't not appear in any preceding code as
the left hand side of an assignment statement, the variable x is not
declared. Likewise no method named x exists, so it raises a NameError

% cat example2.rb
if false
   x = 0
end

puts x.inspect

% ruby example2.rb
nil

Now this time no exception was raised, even though x never actually
got set to zero. This is because ruby determines variable
declarations when it parses the source, it makes not of any
identifiers on the lhs of an assignment operator.

Now why can't this work for
info[] = blah
?

because []= is a method call. Only identifier = expression is an
actual assignment. Any number of objects can have different  meanings
for []=.

info[] = blah

is

info.[]=(blah)

in actuality.
2c80e1b0837eec76d38d4f7fa1c15e87?d=identicon&s=25 Michael Gorsuch (Guest)
on 2006-05-15 00:50
(Received via mailing list)
Corey -

A strongly type language would insist that you declare everything before
use.

Example, in C, you would have to do

"int my_variable" before you put anythign in it.  And it better be an
int
;-)

In Ruby, you can just start working.  Objects do have to be created,
though
some can be figured out Ruby itself.

Even better, a variable can become something else.  Example:

# 'c' is a string here
c = "some text"

# 'c' is now an array of strings
c = []
c << "some more text"
c << "some other stuff"

You couldn't get away with this in a strictly typed language such as
Java or
C - variables must always behave as they are commanded in the beginning.
2c80e1b0837eec76d38d4f7fa1c15e87?d=identicon&s=25 Michael Gorsuch (Guest)
on 2006-05-15 00:53
(Received via mailing list)
Ah!

Take a look here:

"info = gets.chomp"
You've just changed 'info' into a String.

Instead, do this:

"info << gets.chomp"

This means 'get some stuff, chomp it, and add it to the info Array'
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-05-15 00:56
(Received via mailing list)
On May 14, 2006, at 6:46 PM, corey konrad wrote:

>   puts "Enter some info"
>
> --
> Posted via http://www.ruby-forum.com/.
>

Oh boy.

info = [] # an array
info = gets.chomp # info is now a string, you've lost anything that
was in info
while info != "exit" # ok...
info = gets.chomp # you're not adding to the back of the array,
you're changing the meaning of info to another string.
end
info.sort # This will give back an array of sorted strings, broken on
newlines in info. There won't be any newlines in info. Also you
probably meant sort!
puts "#{info}" # will always print exit
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-05-15 01:06
(Received via mailing list)
On May 14, 2006, at 6:49 PM, Michael Gorsuch wrote:

> Corey -
>
> A strongly type language would insist that you declare everything
> before
> use.
>

Ruby is strongly typed, it's not statically typed. C has weaker types
than ruby (Oh look, I just cast an int to a pointer). A statically
typed language would insist you declare the types of everything
before use. That is unless you have type inference.

e.g. at an ocaml prompt:
# let f x = x + 1;;
val f : int -> int = <fun>

You'll note I did not declare the type  of  x, nor the return type of
the function, yet OCaml correctly deduced it. But that's tangential.
Note also that typing doesn't necessarily determine whether or not
you need to declare something before use. In both Javascript and Perl
you can declare variables:

var x;

my $x;


Likewise, while I can't think of any languages that do this, I'm sure
one could devise a statically typed language with no declarations.
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-15 01:24
(Received via mailing list)
With some trepidation I'll commit the sin of threadjacking in order to
clarify some of this. I'm doing this because "weakly-typed" is an
unjustified criticism often made by Ruby's detractors, so I think it's
important for us to be able to answer it.

A strongly-typed language has well-defined, unambiguous rules about the
operations that may be performed on an object, and it refuses to perform
inferred type conversions. (Which is why Ruby won't let you add numbers
to
strings as Perl does.) Ruby doesn't ever figure out for itself what type
an
object is. If you create an object yourself, you need to type it
(generally
with Klassname.new, or one of the shorthands like x=[]). Of course, if
you
call a method that returns an object, that object will have a type
(determined by the writer of the method) and you can use it without
declaring it, but that doesn't mean Ruby figured out the type on its
own.

Similarly, to say:
c = 100
c = "100"
is not dynamic re-typing, but rather a dynamic *rebinding* of a
different
object to an already-used variable name. Perhaps the point you wanted to
make with this example is the distinction between static and dynamic
languages. In the former (C++, Java, etc), the type of every object in
the
program must be determinable by the compiler, whereas in Python or Ruby
these determinations are not made until runtime. For people who come to
Ruby
with strong experience in C/C++/Java, the lack of static typing is
perhaps
the biggest shock. But it doesn't mean that Ruby is weakly-typed! Type
mismatches in Ruby always generate errors, but they occur at runtime
rather
than compile-time.

I think the big controversy here is with people who reflexively reject
the
idea that type errors should not be visible until runtime. It took me a
long
time to get over this hump, but I now believe that dynamic type errors
are
not a particularly nasty class of error and not to be feared.

Now that I'm a million miles away from Corey's original point, I'll go
back
into my hole :-).
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 01:27
oh ok basicly the issue is that i just didnt  understand what the gets
method was doing, it was creating another string? Wow i thought it just
GOT another string i didnt know it created one. Thats really confusing.
Puts and Gets have been really confusing methods for me so far.

also why does puts #{info} always print exit even if a user doesnt type
that in, that doesnt make sense to me at all.



Michael Gorsuch wrote:
> Ah!
>
> Take a look here:
>
> "info = gets.chomp"
> You've just changed 'info' into a String.
>
> Instead, do this:
>
> "info << gets.chomp"
>
> This means 'get some stuff, chomp it, and add it to the info Array'
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 01:33
this stuff is discouraging, lol. Since i started learning to program i
feel like i am mentally retarded or something. Is it normal to have this
many problems with understanding simple things when you  learn this
stuff, for some people it seems to just come naturally like they were
born into it.
2c80e1b0837eec76d38d4f7fa1c15e87?d=identicon&s=25 Michael Gorsuch (Guest)
on 2006-05-15 01:36
(Received via mailing list)
'gets' will read a string from input and build a new string object.

When you did 'info = gets.chomp', you wiped out your array and made it a
simple String object.

'exit' is being stored because your program logic is placing the string
into
the Array, and then checking to see if the last retrieved value is
'exit'.

You may be better off using a temporary variable first, checking it, and
then storing it.
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 01:41
so gets changes the array into a string object during each loop and then
just keeps changing the what is in that string object ok i understand
that. I still dont understand the issue with "exit" thouse i dont see
how i am putting exit into anything, i am just testing to see if info is
== to exit i thought. I dont know maybe i should stick with networking,
lol this stuff is frustrating i dont know how a person could do this 8
hours a day.




Michael Gorsuch wrote:
> 'gets' will read a string from input and build a new string object.
>
> When you did 'info = gets.chomp', you wiped out your array and made it a
> simple String object.
>
> 'exit' is being stored because your program logic is placing the string
> into
> the Array, and then checking to see if the last retrieved value is
> 'exit'.
>
> You may be better off using a temporary variable first, checking it, and
> then storing it.
2c80e1b0837eec76d38d4f7fa1c15e87?d=identicon&s=25 Michael Gorsuch (Guest)
on 2006-05-15 01:42
(Received via mailing list)
If you keep at it, and keep reading, it will click.

The key (for me, at least) is gaining an understanding for what is
happening
underneath.

Keep asking the questions you are asking.

Also, I recommend "Learning to Program" by Chris Pine (I picked this up
for
a friend, and she loves it) as well as "Programming Ruby".  Read them,
and
work through the excercises.  It'll come together.
2c80e1b0837eec76d38d4f7fa1c15e87?d=identicon&s=25 Michael Gorsuch (Guest)
on 2006-05-15 01:48
(Received via mailing list)
Here is the code I am going by:

def input
  puts "Enter some info"
  info = []
  info <<  gets.chomp
  while info.last != "exit"
    info << gets.chomp
  end
  info.sort
  puts info
end

Now, take a look at the while loop.

You start the loop, put data in to 'info', and then start over.  At the
top
of the loop, you have to see what is stored in 'info'.
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 01:49
that actually is the book i am having so many problems with
understanding, lol Learning to program by Chris Pine.



Michael Gorsuch wrote:
> If you keep at it, and keep reading, it will click.
>
> The key (for me, at least) is gaining an understanding for what is
> happening
> underneath.
>
> Keep asking the questions you are asking.
>
> Also, I recommend "Learning to Program" by Chris Pine (I picked this up
> for
> a friend, and she loves it) as well as "Programming Ruby".  Read them,
> and
> work through the excercises.  It'll come together.
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 01:50
Thanks for the help and encouragment i appreciate it


corey konrad wrote:
> that actually is the book i am having so many problems with
> understanding, lol Learning to program by Chris Pine.
>
>
>
> Michael Gorsuch wrote:
>> If you keep at it, and keep reading, it will click.
>>
>> The key (for me, at least) is gaining an understanding for what is
>> happening
>> underneath.
>>
>> Keep asking the questions you are asking.
>>
>> Also, I recommend "Learning to Program" by Chris Pine (I picked this up
>> for
>> a friend, and she loves it) as well as "Programming Ruby".  Read them,
>> and
>> work through the excercises.  It'll come together.
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-05-15 01:54
(Received via mailing list)
On May 14, 2006, at 7:33 PM, corey konrad wrote:

> this stuff is discouraging, lol. Since i started learning to program i
> feel like i am mentally retarded or something. Is it normal to have
> this
> many problems with understanding simple things when you  learn this
> stuff, for some people it seems to just come naturally like they were
> born into it.
>
> --
> Posted via http://www.ruby-forum.com/.
>

There's a _big_ hump the first time you learn to program. Once it
clicks though, a whole bunch of other stuff becomes easier. I don't
know if ruby is necessarily the best programming language for a
beginner either, since it was designed by Matz. for Matz. (And I'm
pretty sure Matz. isn't a beginning programmer). The problem is I
can't think of a better one. Every language out there has it's own
quirks that are detrimental to the learning of how to just program,
for the very first time. I think someone should write a procedural
language with a simple, forgiving syntax (i.e. whitespace is not
significant, and as few funny characters as possible), with garbage
collection and dynamic typing. Kind of a subset of perl with a ruby-
like syntax. It should also have a very rich runtime introspection
capabilities, not necessarily for the students, so that you can step
through code and have the data structures visualized( sort of like
[1] but they should be shown more like a diagram out of a text book).

[1] http://www.gnu.org/software/ddd/
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-05-15 02:13
(Received via mailing list)
corey konrad wrote:
> this stuff is discouraging, lol. Since i started learning to program i
> feel like i am mentally retarded or something. Is it normal to have this
> many problems with understanding simple things when you  learn this
> stuff, for some people it seems to just come naturally like they were
> born into it.
>

Haha, that's totally normal. Nobody was born into it.
Some learn faster, but mostly, they just study longer.


Hal
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 02:32
yeah a friend of mine said that PHP would be a good language to learn as
a beginner.




Logan Capaldo wrote:
> On May 14, 2006, at 7:33 PM, corey konrad wrote:
>
>> this stuff is discouraging, lol. Since i started learning to program i
>> feel like i am mentally retarded or something. Is it normal to have
>> this
>> many problems with understanding simple things when you  learn this
>> stuff, for some people it seems to just come naturally like they were
>> born into it.
>>
>> --
>> Posted via http://www.ruby-forum.com/.
>>
>
> There's a _big_ hump the first time you learn to program. Once it
> clicks though, a whole bunch of other stuff becomes easier. I don't
> know if ruby is necessarily the best programming language for a
> beginner either, since it was designed by Matz. for Matz. (And I'm
> pretty sure Matz. isn't a beginning programmer). The problem is I
> can't think of a better one. Every language out there has it's own
> quirks that are detrimental to the learning of how to just program,
> for the very first time. I think someone should write a procedural
> language with a simple, forgiving syntax (i.e. whitespace is not
> significant, and as few funny characters as possible), with garbage
> collection and dynamic typing. Kind of a subset of perl with a ruby-
> like syntax. It should also have a very rich runtime introspection
> capabilities, not necessarily for the students, so that you can step
> through code and have the data structures visualized( sort of like
> [1] but they should be shown more like a diagram out of a text book).
>
> [1] http://www.gnu.org/software/ddd/
Bd0203dc8478deb969d72f52e741bd4f?d=identicon&s=25 Daniel Baird (Guest)
on 2006-05-15 02:52
(Received via mailing list)
On 5/15/06, corey konrad <0011@hush.com> wrote:
>
> yeah a friend of mine said that PHP would be a good language to learn as
> a beginner.



Aargh!  I mean, erm, no, I definitely think you're on the right track
with
Ruby.  I know it doesn't feel like it, but you seems quite close to
"getting" it.  You're just missing the idea that variable names kinda
"point" at objects.

The object pointed at might be an array, or a string, or whatever.. with
a
whiteboard it's quite easy to illustrate the idea, but let's try this:

when you say:
  info = "hello there"

..that makes a pointer from the variable "info" to the string "hello
there".  Here's a picture:

  info ----------> String "hello there"

When you say:

  info = []

..that makes a pointer from the variable "info" to a new, empty array.
Doesn't matter what info used to "point" to.. it's now pointing at an
array.  Like this:

  info ----------> Array []


Hope that helps a bit!

;D
403a239ccedd8d7c07ef5fae23f6adcc?d=identicon&s=25 Robert Nicholson (Guest)
on 2006-05-15 02:52
(Received via mailing list)
Yeah isn't everything a first class object in Ruby.

Looked to me as though the issue was the scope since he originally
declared it in
the def rather than in the scope of the caller where he wants to
refer to it.
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 03:37
oh ok i remember reading that in the book about pointers the = method or
operator whatever it is, makes something point to something else. So the
only way to truly change the variable is to change what it points too.
So i should remmeber that any time i use the = method i am causing
something to point to something else otherwise i might run into trouble,
that kind of makes sense. The pointer graphic -----------> helps, lol.




Daniel Baird wrote:
> On 5/15/06, corey konrad <0011@hush.com> wrote:
>>
>> yeah a friend of mine said that PHP would be a good language to learn as
>> a beginner.
>
>
>
> Aargh!  I mean, erm, no, I definitely think you're on the right track
> with
> Ruby.  I know it doesn't feel like it, but you seems quite close to
> "getting" it.  You're just missing the idea that variable names kinda
> "point" at objects.
>
> The object pointed at might be an array, or a string, or whatever.. with
> a
> whiteboard it's quite easy to illustrate the idea, but let's try this:
>
> when you say:
>   info = "hello there"
>
> ..that makes a pointer from the variable "info" to the string "hello
> there".  Here's a picture:
>
>   info ----------> String "hello there"
>
> When you say:
>
>   info = []
>
> ..that makes a pointer from the variable "info" to a new, empty array.
> Doesn't matter what info used to "point" to.. it's now pointing at an
> array.  Like this:
>
>   info ----------> Array []
>
>
> Hope that helps a bit!
>
> ;D
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 03:38
they should change the = to -----> then maybe i would have gotten it
right away, lol.



corey konrad wrote:
> oh ok i remember reading that in the book about pointers the = method or
> operator whatever it is, makes something point to something else. So the
> only way to truly change the variable is to change what it points too.
> So i should remmeber that any time i use the = method i am causing
> something to point to something else otherwise i might run into trouble,
> that kind of makes sense. The pointer graphic -----------> helps, lol.
>
>
>
>
2c80e1b0837eec76d38d4f7fa1c15e87?d=identicon&s=25 Michael Gorsuch (Guest)
on 2006-05-15 03:41
(Received via mailing list)
See, Corey.  You're getting it.  It just takes time, and soon enough
you'll
be answering our questions.
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 03:44
yeah that would something, corey konrad ruby expert, maybe i'll extend
the language and call it diamond, or better yet clam that way perl could
fit inside it, lol.


Michael Gorsuch wrote:
> See, Corey.  You're getting it.  It just takes time, and soon enough
> you'll
> be answering our questions.
Bd0203dc8478deb969d72f52e741bd4f?d=identicon&s=25 Daniel Baird (Guest)
on 2006-05-15 03:53
(Received via mailing list)
On 5/15/06, corey konrad <0011@hush.com> wrote:
>
> oh ok i remember reading that in the book about pointers the = method or
> operator whatever it is, makes something point to something else. So the
> only way to truly change the variable is to change what it points too.
> So i should remmeber that any time i use the = method i am causing
> something to point to something else otherwise i might run into trouble,
> that kind of makes sense. The pointer graphic -----------> helps, lol.



You know, originally i'd typed a shorter arrow --> but it seemed to make
more sense if it was really long!  I'm glad I could help.. like Michael
G
says, you're getting it.

Good luck

;Daniel
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 03:58
yup i'll get it, need a break now though, you know when you read tacos
as a misspelling of "to cos" that you have been studying programming and
math all day.




Daniel Baird wrote:
> On 5/15/06, corey konrad <0011@hush.com> wrote:
>>
>> oh ok i remember reading that in the book about pointers the = method or
>> operator whatever it is, makes something point to something else. So the
>> only way to truly change the variable is to change what it points too.
>> So i should remmeber that any time i use the = method i am causing
>> something to point to something else otherwise i might run into trouble,
>> that kind of makes sense. The pointer graphic -----------> helps, lol.
>
>
>
> You know, originally i'd typed a shorter arrow --> but it seemed to make
> more sense if it was really long!  I'm glad I could help.. like Michael
> G
> says, you're getting it.
>
> Good luck
>
> ;Daniel
Ff63c03fd68754adbadd2c6314646bef?d=identicon&s=25 Bill Guindon (agorilla)
on 2006-05-15 04:00
(Received via mailing list)
On 5/14/06, corey konrad <0011@hush.com> wrote:
> this stuff is discouraging, lol. Since i started learning to program i
> feel like i am mentally retarded or something. Is it normal to have this
> many problems with understanding simple things when you  learn this
> stuff, for some people it seems to just come naturally like they were
> born into it.

I started learning Ruby a couple of years ago, but I started
programming somewhere around 1981.  By the time I found Ruby, yeah, it
sort of 'came naturally' to me.  So yeah, some people are 'naturals',
and it looks like you might be one of them.  The part where it 'comes
naturally' happens later.

It's driving you nuts, but you still keep doing it.  Why?
You _must_ figure out what you are doing wrong.
You _must_ find a way to make it do what you want.
To me, that sounds like a 'natural' ;)

Since nobody's mentioned it (I think), most Ruby users are coming from
other languages.   Granted, that can be true for many languages, but I
think the ratio is higher for Ruby.

Until Rails, it was relatively unknown in the US.  Certainly far below
perl, Java, PHP, Python, etc.  Most of the people (like myself) who
looked into Ruby were already programmers, and probably knew more than
one language.  That's part of all the 'Ruby is wonderful' hype.  It
may take experience with other languages to see that part.

I'm not saying it's not a good language to learn first, I have no idea
if it is or not, I don't think enough people (US at least) have
learned it as their first language to decide that case.  What I'm
saying is, once you learn another language (after you learn Ruby that
is), then you're more likely to see the 'beauty' that is Ruby.

On the bright side, once 'it clicks', and you get Ruby (or any other
language for that matter), learning other languages becomes easier.
Personally, I think that once you've learned 3 languages, you'll be
convinced that you can learn any language.

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

You might as well just sign up for the list, it's your destiny ;)
http://www.ruby-lang.org/en/20020104.html
Ff63c03fd68754adbadd2c6314646bef?d=identicon&s=25 Bill Guindon (agorilla)
on 2006-05-15 04:03
(Received via mailing list)
On 5/14/06, corey konrad <0011@hush.com> wrote:
> yup i'll get it, need a break now though, you know when you read tacos
> as a misspelling of "to cos" that you have been studying programming and
> math all day.

Yeah, definitely a natural.  It won't be long before you wake up
dreaming of code ;)
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2006-05-15 04:36
(Received via mailing list)
On 5/14/06, Bill Guindon <agorilla@gmail.com> wrote:
> On 5/14/06, corey konrad <0011@hush.com> wrote:
> > yup i'll get it, need a break now though, you know when you read tacos
> > as a misspelling of "to cos" that you have been studying programming and
> > math all day.
>
> Yeah, definitely a natural.  It won't be long before you wake up
> dreaming of code ;)

Oh man, code comes to you at the WEIRDEST times.  I can't tell you how
many times I've half-woken up at 3am, and in that mid-dreamy state
somehow figured out the answer to a problem.  Then I hop out of bed
and make it happen.  Sometimes it doesn't work, and then you're like,
"It'll only take 10 minutes or so" and you find yourself still
pounding at the keyboard at 7am.  "hrm, better shower and go to work."
 I like it better when my dream code works perfectly though :)

Also, I have a lot of answers come to me in the shower for some
reason.  I keep a small whiteboard and grease pen in the shower so I
can write it down, instead of prematurely ending my shower or having
to repeat the solution in my head over and over until I'm done.

Corey, don't worry if some of this stuff seems hard.  I remember when
I first started, I would literally stare at the same 10 lines of code
for hours, not having any clue that I was just missing a semicolon or
something stupid like that.  The very beginning is cumbersome, to say
the least, but it teaches you perhaps one of the most important things
about programming - how to read documentation and look up errors.

Pat
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-05-15 07:34
(Received via mailing list)
Hi --

On Mon, 15 May 2006, Francis Cianfrocca wrote:

> with Klassname.new, or one of the shorthands like x=[]). Of course, if you
> call a method that returns an object, that object will have a type
> (determined by the writer of the method) and you can use it without
> declaring it, but that doesn't mean Ruby figured out the type on its own.

It sounds like you're talking about class, rather than type.  A
string, for example (that is, an object that says "String" when you
ask it its class), can allow integers to be added to it, and is
therefore of class String but of *type* "string-like thing that lets
you add integers to it" (or whatever).

So the type of Ruby objects is almost a tautology: the type of object
o is "the type of objects that have the capabilities and interface of
object o."  Class, meanwhile, though more tangible in a sense, is only
the starting point for the object's life-cycle.


David
49ab3ce5a4922b4747d1d6f330784629?d=identicon&s=25 Jake McArthur (Guest)
on 2006-05-15 07:59
(Received via mailing list)
Agreed. In fact, at its core, I would say that Ruby is "untyped,"
since everything is of the same type (Object). The only meaningful
information about the qualifications of an object for a certain task
is whether it responds to certain necessary methods, as you said.
Based on this, I would say that Ruby simply attempts to blindly
execute the code with _no_ type checking at all, but simply chokes if
a method is missing. Is this a bad way to think of it?

- Jake McArthur
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-05-15 08:26
(Received via mailing list)
Hi --

On Mon, 15 May 2006, Jake McArthur wrote:

>> object o."  Class, meanwhile, though more tangible in a sense, is only
>> the starting point for the object's life-cycle.
> Agreed. In fact, at its core, I would say that Ruby is "untyped," since
> everything is of the same type (Object). The only meaningful information
> about the qualifications of an object for a certain task is whether it
> responds to certain necessary methods, as you said. Based on this, I would
> say that Ruby simply attempts to blindly execute the code with _no_ type
> checking at all, but simply chokes if a method is missing. Is this a bad way
> to think of it?

I would apply the word "class" to Object (rather than type), and leave
"type" available for that other thing you're talking about -- the
thing where a given object can do some things and not do others.
People sometimes refer to this as an object's "duck type", but it's
really just its type (and duck typing is, in my view, simply
programming in Ruby in a way that embraces how type [not "duck type"]
operates).

I think it's right to say that variables are untyped, but not that
objects are.  It's true, though, that type -- understood as the
aggregate of an object's capabilities at some given point in runtime
-- is almost an invisible concept.  No designation or discussion of an
object's type actually has any bearing on what happens when that
object gets sent a message.

Of course the vast majority of Ruby objects that get created do not,
in fact, deviate from the type laid down by their class.  But when
they do, the only way to understand what's happening is to have
understood already that they *can*.  Without that understanding, even
something like class methods (where a particular Class instance
deviates from the type of a freshly-created Class instance) becomes a
huge mystery.  And then we start hearing about running with scissors,
and rope and shooting in foot, and all that :-)


David
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-15 12:03
(Received via mailing list)
I have to admit I don't understand the distinction you're making between
"class" and type. To level-set: I care about this discussion primarily
because plenty of people (but no one on this thread, of course)
criticize
Ruby as being less strongly-typed than C++ or Java, whereas the truth is
that Ruby is _dynamically_ typed rather than _weakly_ typed. In Ruby, an
object never changes its type (although delegation and the ability to
add
methods to a single object instance also may make it seem like it does).

More to the point, Ruby will never implicitly perform operations on an
object that are not part of its type, as a result of inferences about
some
particular statement of code. This Ruby code will generate an error:
"abc" + 5
because Fixnum can't be an argument to the String method named +. Both C
and
Ruby will perform certain type-transformations automatically (mostly
widening numeric types) but these are well defined and stated upfront in
the
language definition.

Weak typing (such as you see in languages like Perl and Javascript) can
often be the source of very difficult errors. Ruby and other dynamic,
strongly-typed languages (Python) don't go this far. However, they do
relax
the requirement that the object bound to a particular variable be
constant
throughout the run of a program. Types are attributes of objects, not of
variables. For example:
a = "abc"
b = a
a = 5
isn't permitted in a static program but is permitted in a dynamic one.
The
object "abc" (of type String) still exists (it's bound to variable b at
the
end of the fragment) but it's meaningless to speak of the type of
variable
a. Rather, at the end of the run, a is bound to an object of type Fixnum
(and value 5). This throws people who are used to the fact that
compilers
can find a large class of errors in languages that don't permit
variables to
be rebound to objects of different types. However, the key insight of
dynamic languages is that this class of statically-discoverable errors,
while large, is not deep or difficult.

I've noticed that younger programmers seem to have much less conceptual
trouble with "duck typing" and dynamic languages than older people like
me.
I wonder if it's because for a while, CS programs taught people with
functional languages like Scheme, where the distinction between objects
and
variable-bindings is explicit and clear. (Nowadays of course, all the
younger people coming out of university seem to have learned nothing but
Java...)
04bd97396a23bebf19887fd041e15123?d=identicon&s=25 Esteban Manchado =?iso-8859-1?Q?Vel=E1zquez?= (Guest)
on 2006-05-15 12:55
(Received via mailing list)
Hi,

On Mon, May 15, 2006 at 08:46:58AM +0900, Michael Gorsuch wrote:
>  puts info
> end

    Hmmm... note that the "sort" method _doesn't_ change the object. You
should put either (1) info.sort! instead of info.sort, or (2) replace
both
lines with "puts info.sort".
7264fb16beeea92b89bb42023738259d?d=identicon&s=25 Christian Neukirchen (Guest)
on 2006-05-15 14:33
(Received via mailing list)
Logan Capaldo <logancapaldo@gmail.com> writes:

> I don't
> know if ruby is necessarily the best programming language for a
> beginner either, since it was designed by Matz. for Matz. (And I'm
> pretty sure Matz. isn't a beginning programmer).

That's the reason it is that good. :-)

Now, if there only was a way to become an expert programmer without
being influenced by the languages you (had to) use to become one---I
really wonder what that language would look like.
F5b3c1ebfb2e9fc5f67bb48b119f6054?d=identicon&s=25 Randy Kramer (Guest)
on 2006-05-15 15:21
(Received via mailing list)
I'm not the original OP, but found this post quite helpful.  But, in the
interest of knowing what's going on under the hood, I wanted to expound
on
some things (based on my understanding) to find out if my understanding
is
correct:

On Sunday 14 May 2006 08:50 pm, Daniel Baird wrote:
> there".  Here's a picture:
>
>   info ----------> String "hello there"

Actually, to be a little more pedantic, it creates a string in memory
containing "hello there" and then creates a variable info which points
to it.
(?)

> When you say:
>
>   info = []
>
> ..that makes a pointer from the variable "info" to a new, empty array.

Again, this creates a new, empty array in memory, then changes the
contents of
the variable info to point to it instead of to the string containing
"hello
there" (that may be a stilted way of saying it).

The string "hello there" still exists in memory, but (unless something
else
has been done, like another variable created (not mentioned so far)
pointing
to that string), it is no longer accessible and is subject to garbage
collection (when Ruby, in it's infinite wisdom, decides it is
appropriate to
collect garbage). (?)

Randy Kramer

PS: Just to go off on a tangent, for a (poor) programmer with experience
in
some other languages, in some other languages, the:

info = "hello there"

statement might create a string in memory and permanently associate
"info"
with the address of that string.

If someone then tried:

info = []

either that address in memory would have "hello string" wiped out and
replaced
with an empty array, or (in a <something> typed language), the statement
would fail because the types don't match.
Ad4caa46eebe9347305177fc33468563?d=identicon&s=25 Mike Nelson (Guest)
on 2006-05-15 16:40
Francis Cianfrocca wrote:
(Nowadays of course, all the
> younger people coming out of university seem to have learned nothing but
> Java...)

At the risk of tangenting a tangent, I've noticed this as well. I'm very
curious why this is the case. My best guess right now is that many CS
professors are very fimilar with C or C+ and Java seems a bit easier to
teach than either of them to undergrads. It's an easy step to teach Java
for them; easy for the professor to pick up and apply a lot of concepts
that they used to teach in C, since the syntax for C and Java is very
similar, and easier to teach than C in some ways.

If this is the case, then its seems like a weird reason to have a lot of
people coming out of university coding in Java.
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-15 16:52
(Received via mailing list)
Well, I have a somewhat different theory. Because remember five to ten
years ago, when all the young people were coming out having learned
Scheme and nothing else, so they were useless? I think someone told
the professors they need to train people for the real world, but they
responded by picking Java as the default choice. Seems like it would
be nice to find a happy medium between solid training in CS
fundamentals and practical knowledge. The Java training they're
getting now seems to be little more than recipes.
A10d049aeb1dbd373a3bc1a4065fa4c7?d=identicon&s=25 Regg (Guest)
on 2006-05-15 19:50
I'm a newbie to Ruby, but not to programming.

But the follow statement made by "Michael Gorsuch" is confusing.

"When you did 'info = gets.chomp', you wiped out your array and made it
a
 simple String object."

I thought that Ruby was a strong typed language.
How can it change an Array to a String...I would have expected an error
to be produced in this instance.

I would have hoped that once a type has been established for an object,
the object would only adhere to the rules of that object...not change
itself into a new object type.

I agree...this stuff can make you pull your hair out!!

Argh...


Michael Gorsuch wrote:
> 'gets' will read a string from input and build a new string object.
>
> When you did 'info = gets.chomp', you wiped out your array and made it a
> simple String object.
>
> 'exit' is being stored because your program logic is placing the string
> into
> the Array, and then checking to see if the last retrieved value is
> 'exit'.
>
> You may be better off using a temporary variable first, checking it, and
> then storing it.
49ab3ce5a4922b4747d1d6f330784629?d=identicon&s=25 Jake McArthur (Guest)
on 2006-05-15 20:01
(Received via mailing list)
On May 15, 2006, at 12:50 PM, Regg wrote:

> I would have hoped that once a type has been established for an
> object,
> the object would only adhere to the rules of that object...not change
> itself into a new object type.

This is the case. However, variables are only references and are
themselves "typeless," in a sense. While you cannot change the object
a variable points to from one type to another, you can have the
variable point to a different object entirely which can be of a
different type. Here is something that won't work:

"5" + 5

Since the two objects are different types, they cannot be added/
appended. The two correct variations are below:

"5".to_i + 5 # => 10
"5" + 5.to_s => "55"

Hope that clears things up.

- Jake McArthur
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2006-05-15 20:09
Regg wrote:
> I'm a newbie to Ruby, but not to programming.
>
> But the follow statement made by "Michael Gorsuch" is confusing.
>
> "When you did 'info = gets.chomp', you wiped out your array and made it
> a
>  simple String object."
>
> I thought that Ruby was a strong typed language.
> How can it change an Array to a String...I would have expected an error
> to be produced in this instance.
>
> I would have hoped that once a type has been established for an object,
> the object would only adhere to the rules of that object...not change
> itself into a new object type.

Names and Objects!

When you do "info = gets.chomp", you are saying "take the object
returned from gets.chomp and associate it with the name 'info'.
Thereafter, anytime you use the name 'info', you are refering to the
object associated with info.

The original array object wasn't really wiped out.  It still exists, and
if another name is associated with it, you can still use it.  However,
the name 'info' no longer refers to it.

-- Jim Weirich
A10d049aeb1dbd373a3bc1a4065fa4c7?d=identicon&s=25 Regg (Guest)
on 2006-05-15 20:14
But when I hear statements about Ruby being a strong type language, I
would expect that to be applied to variables.

Most assignments happen between variables.

But if what you are saying is that variables are "typeless", then I have
to go with the belief that Ruby is a "weak" typed langauge and not a
strong one.


In C++ (a strong typed language) you can't do this:

MyOtherClass *m_otherclass = new MyOtherClass();
MyClass *m_class = new MyClass();


 m_class = m_otherclass;   <--ERROR (Can't convert MyOtherClass to
MyClass)


but this seems to be possible in Ruby.

Please correct me if I'm wrong (I want to be wrong here). :)




> This is the case. However, variables are only references and are
> themselves "typeless," in a sense. While you cannot change the object
> a variable points to from one type to another, you can have the
> variable point to a different object entirely which can be of a
> different type. Here is something that won't work:
>
> "5" + 5
>
> Since the two objects are different types, they cannot be added/
> appended. The two correct variations are below:
>
> "5".to_i + 5 # => 10
> "5" + 5.to_s => "55"
>
> Hope that clears things up.
>
> - Jake McArthur
49ab3ce5a4922b4747d1d6f330784629?d=identicon&s=25 Jake McArthur (Guest)
on 2006-05-15 20:39
(Received via mailing list)
On May 15, 2006, at 1:14 PM, Regg wrote:

> But when I hear statements about Ruby being a strong type language, I
> would expect that to be applied to variables.
>
> Most assignments happen between variables.

Variables are not objects. They are simply names associated with
objects. A name can be associated with any type of object.

a = 1
b = a
a = "foo"

a # => "foo"
b # => 1

What's special about the above? The returned 1 is the exact same
object as the original literal when it was assigned to a! The object
did not change type at all, only which objects the variables pointed to.

> but this seems to be possible in Ruby.
I'm going to have to help you distinguish between strong typing and
static typing....

C is a statically, weakly typed language. It is static because a
variable can only be on a certain type, but it is weak because the
data associated with that variable can be of any type. For example
(untested and syntax may be bad):

struct vector {
   double x, y, z;
};

struct some24ByteStruct {
   int a, b;
   char c, d, e, f;
   double g, h;
};

struct vector a = {2.0, 3.0, 4.0};
struct some24ByteStuct b = (struct some24ByteStruct)a;

We know that we have some integers (b.a and b.b), some characters
(b.c, b.d, b.e, and b.f), and some doubles (b.g and b.h), but this is
scary stuff since we have no idea what kind of data will be in those
variables. The former point is what makes C statically typed, but the
latter point makes it weakly typed.

Ruby is a dynamically, strongly typed language. It is dynamic because
a variable can point to data of any type, but strong because that
data will never change type. The Ruby example I gave above
demonstrates this.

Make any more sense now?

- Jake McArthur
A10d049aeb1dbd373a3bc1a4065fa4c7?d=identicon&s=25 Regg (Guest)
on 2006-05-15 21:04
In your example:

" struct vector a = {2.0, 3.0, 4.0};
 struct some24ByteStuct b = (struct some24ByteStruct)a;"

You are manually forcing this relationship my casting one type to
another.

To me that is one of the things I love about C is that it will allow you
do something that the compiler otherwise would not allow.

But in Ruby you are not "forcing" the type casting, it just does it
without any warning or error.

So I still can't see how it can be said that "Ruby is a dynamically,
strongly typed language".

It seems to be a dynamically, "any" typed language.

What benefit is gained from a variable being (switched/pointed to) from
one type to another? (This is an honest question, maybe I'm missing
something)

It seems like a recipe for disaster.

Thanks


> C is a statically, weakly typed language. It is static because a
> variable can only be on a certain type, but it is weak because the
> data associated with that variable can be of any type. For example
> (untested and syntax may be bad):
>
> struct vector {
>    double x, y, z;
> };
>
> struct some24ByteStruct {
>    int a, b;
>    char c, d, e, f;
>    double g, h;
> };
>
> struct vector a = {2.0, 3.0, 4.0};
> struct some24ByteStuct b = (struct some24ByteStruct)a;
>
> We know that we have some integers (b.a and b.b), some characters
> (b.c, b.d, b.e, and b.f), and some doubles (b.g and b.h), but this is
> scary stuff since we have no idea what kind of data will be in those
> variables. The former point is what makes C statically typed, but the
> latter point makes it weakly typed.
>
> Ruby is a dynamically, strongly typed language. It is dynamic because
> a variable can point to data of any type, but strong because that
> data will never change type. The Ruby example I gave above
> demonstrates this.
>
> Make any more sense now?
>
> - Jake McArthur
49ab3ce5a4922b4747d1d6f330784629?d=identicon&s=25 Jake McArthur (Guest)
on 2006-05-15 21:34
(Received via mailing list)
On May 15, 2006, at 2:04 PM, Regg wrote:

> do something that the compiler otherwise would not allow.
Sure, but in order for you to manipulate that data in the new
structure, you probably have to translate the data from the first
form to the other anyway. An explicit cast is really most useful when
casting from one primitive to another (moot in Ruby, of course), but
not for more complex data types (excluding buffers, which is the only
special case I can think of right now... also moot in Ruby).

> But in Ruby you are not "forcing" the type casting, it just does it
> without any warning or error.

There is no type casting going on in the Ruby code that I can see. Do
you mean the reassignment of the variable to an object of a different
type? There is no conversion taking place.

> What benefit is gained from a variable being (switched/pointed to)
> from
> one type to another? (This is an honest question, maybe I'm missing
> something)
>
> It seems like a recipe for disaster.

Consider this:

class Foo
   def do_something
     puts "FOO!"
   end
end

class Bar
   def do_something
     puts "BAR!"
   end
end

def call_do_something(arg)
   arg.do_something
end

call_do_something(Foo.new)
call_do_something(Bar.new)

Notice something cool here? We didn't have to subclass to pass two
different types into the same method. This is known by some as "duck
typing," referring to the "looks like a duck, talks like a duck"
metaphor. Any object that responds to the do_something method can be
passed into the call_do_something method, and it will work perfectly.
This is powerful, and not as dangerous as you think.

- Jake McArthur
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2006-05-15 21:55
Regg wrote:
> But when I hear statements about Ruby being a strong type language, I
> would expect that to be applied to variables.

One must be clear on exactly what "strong typing" means.   Often people
confuse strong typing with the static declaration of variable types.
There are actually (at least) three dimensions to the type question:

static VS dynamic
strong VS weak
manifest VS implicit

C++ is statically typed (variable types are known statically at compile
time), manifestly typed (type declarations must be explicitly made for
all variables), and mildly strongly typed (some common type errors are
caught at compile time, but no runtime checking whatsoever, leaving type
holes big enough to drive a truck through).

Ruby, on the other hand, is dynamically typed (the type of objects
associated with variable names are determined at run time), implicitly
typed (no need to declare types of variables) and strongly typed (type
errors are always caught).

> Most assignments happen between variables.

In C, C++, Java and many other languages, an assignment statement means
"copy this data from that location to this location".  In Ruby, Python,
Lisp and most other dynamic languages, an assignment means "bind this
name to that object".

In languages that have "copy" semantics, its important to know that the
copied data ends up in a location where it can be properly interpreted.
This is especially important because the interpretation of that data
depends on the declared type of that memory location.

In languages that "bind names", that issue is not nearly as important.
Since the object itself (not the declared type of the location)
determines its interpretation, there is never any confusion.

> But if what you are saying is that variables are "typeless", then I have
> to go with the belief that Ruby is a "weak" typed langauge and not a
> strong one.

In C++, a variable is a location in memory that contains the data in
question.   Variables in Ruby are not locations at all, i.e. they have
no L-Value.  Variables in Ruby are truely just names used to lookup
objects.  It is the Objects that have a "type".

> In C++ (a strong typed language) you can't do this:
>
> MyOtherClass *m_otherclass = new MyOtherClass();
> MyClass *m_class = new MyClass();

The purpose of strong typing is to prevent performing type-inappropriate
actions on objects.  Since C++ carries almost no runtime type
information about its objects, the only way it can prevent inappropriate
type actions is to do all the checking at compile time.

In C++ you can do this:

   MyClass * m_class = NULL;
   m_class->do_something();

And the results are undefined (by the language standard).[1]  If you are
lucky, you might get segmentation fault.  However, the equivalent in
Ruby:

   m_class = nil
   m_class.do_something

is a predictable runtime error than can be handled like all the other
runtime errors that are possible in a program.

>  m_class = m_otherclass;   <--ERROR (Can't convert MyOtherClass to
> MyClass)
>
> but this seems to be possible in Ruby.

In summary:

Unlike C++, variable names are not associated with a particular type.
Unlike C++, it is not possible to perform type-unsafe operations.

-- Jim Weirich

[1] Some might quibble that attempting to dereference a null pointer is
not really a type violation.  Perhaps.  But consider the following code:

   MyClass * m_class = (MyClass) m_otherclass;
   m_class->do_something();

Obviously the hammer cast breaks the type safety, and produces similar
undefined behavior.  It all about having the wrong data in the m_class
pointer variable.  In one case it's a null pointer, in the other case
it's an inappropriate pointer.  I would call them both type errors.
A10d049aeb1dbd373a3bc1a4065fa4c7?d=identicon&s=25 Regg (Guest)
on 2006-05-15 22:27
In your example:

" In C++ you can do this:

    MyClass * m_class = NULL;
    m_class->do_something();

 And the results are undefined (by the language standard).[1]  If you
are
 lucky, you might get segmentation fault.
"
This would also generate a error just like it would in Ruby.

In your other example:

"    MyClass * m_class = (MyClass) m_otherclass;
    m_class->do_something();

 Obviously the hammer cast breaks the type safety, and produces similar
 undefined behavior.  It all about having the wrong data in the m_class
 pointer variable.  In one case it's a null pointer, in the other case
 it's an inappropriate pointer.  I would call them both type errors."

This is something that YOU are forcing the compiler to do.
You are FORCING the compiler to accept this assignment even if it's
wrong.
That is not the fault of the language but the fault of the developer.

But in Ruby you are not forcing it, it just allows it to happen with no
warning.






Jim Weirich wrote:
> Regg wrote:
>> But when I hear statements about Ruby being a strong type language, I
>> would expect that to be applied to variables.
>
> One must be clear on exactly what "strong typing" means.   Often people
> confuse strong typing with the static declaration of variable types.
> There are actually (at least) three dimensions to the type question:
>
> static VS dynamic
> strong VS weak
> manifest VS implicit
>
> C++ is statically typed (variable types are known statically at compile
> time), manifestly typed (type declarations must be explicitly made for
> all variables), and mildly strongly typed (some common type errors are
> caught at compile time, but no runtime checking whatsoever, leaving type
> holes big enough to drive a truck through).
>
> Ruby, on the other hand, is dynamically typed (the type of objects
> associated with variable names are determined at run time), implicitly
> typed (no need to declare types of variables) and strongly typed (type
> errors are always caught).
>
>> Most assignments happen between variables.
>
> In C, C++, Java and many other languages, an assignment statement means
> "copy this data from that location to this location".  In Ruby, Python,
> Lisp and most other dynamic languages, an assignment means "bind this
> name to that object".
>
> In languages that have "copy" semantics, its important to know that the
> copied data ends up in a location where it can be properly interpreted.
> This is especially important because the interpretation of that data
> depends on the declared type of that memory location.
>
> In languages that "bind names", that issue is not nearly as important.
> Since the object itself (not the declared type of the location)
> determines its interpretation, there is never any confusion.
>
>> But if what you are saying is that variables are "typeless", then I have
>> to go with the belief that Ruby is a "weak" typed langauge and not a
>> strong one.
>
> In C++, a variable is a location in memory that contains the data in
> question.   Variables in Ruby are not locations at all, i.e. they have
> no L-Value.  Variables in Ruby are truely just names used to lookup
> objects.  It is the Objects that have a "type".
>
>> In C++ (a strong typed language) you can't do this:
>>
>> MyOtherClass *m_otherclass = new MyOtherClass();
>> MyClass *m_class = new MyClass();
>
> The purpose of strong typing is to prevent performing type-inappropriate
> actions on objects.  Since C++ carries almost no runtime type
> information about its objects, the only way it can prevent inappropriate
> type actions is to do all the checking at compile time.
>
> In C++ you can do this:
>
>    MyClass * m_class = NULL;
>    m_class->do_something();
>
> And the results are undefined (by the language standard).[1]  If you are
> lucky, you might get segmentation fault.  However, the equivalent in
> Ruby:
>
>    m_class = nil
>    m_class.do_something
>
> is a predictable runtime error than can be handled like all the other
> runtime errors that are possible in a program.
>
>>  m_class = m_otherclass;   <--ERROR (Can't convert MyOtherClass to
>> MyClass)
>>
>> but this seems to be possible in Ruby.
>
> In summary:
>
> Unlike C++, variable names are not associated with a particular type.
> Unlike C++, it is not possible to perform type-unsafe operations.
>
> -- Jim Weirich
>
> [1] Some might quibble that attempting to dereference a null pointer is
> not really a type violation.  Perhaps.  But consider the following code:
>
>    MyClass * m_class = (MyClass) m_otherclass;
>    m_class->do_something();
>
> Obviously the hammer cast breaks the type safety, and produces similar
> undefined behavior.  It all about having the wrong data in the m_class
> pointer variable.  In one case it's a null pointer, in the other case
> it's an inappropriate pointer.  I would call them both type errors.
Bbc4b3fca1ae3161257a8636145b424d?d=identicon&s=25 Elliot Temple (Guest)
on 2006-05-15 22:51
(Received via mailing list)
On May 15, 2006, at 1:27 PM, Regg wrote:

> This is something that YOU are forcing the compiler to do.
> You are FORCING the compiler to accept this assignment even if it's
> wrong.
> That is not the fault of the language but the fault of the developer.
>
> But in Ruby you are not forcing it, it just allows it to happen
> with no
> warning.

In ruby it does not happen at all. when you bind foo = 5, that is
fine. when it's bound to "hi" that is fine as well. there are no
objects that foo shouldn't be bound too.

there is no cast happening when you do

foo = "hi"
foo = 5

foo just points to something new, now, and the "hi" gets lost in the
abyss (unless something else is pointing to it)

the C code above treated some bits representing one thing as if they
were representing something else. ruby doesn't do that just by
assignment. when you do foo = 5   ruby now treats foo like an integer
not a string. if you want 5 treated like a string you have to convert
it.

-- Elliot Temple
http://www.curi.us/blog/
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-05-15 22:54
(Received via mailing list)
Hi --

On Mon, 15 May 2006, Francis Cianfrocca wrote:

> I have to admit I don't understand the distinction you're making between
> "class" and type.

Basically, class is the thing that the object is an instance of.  Type
is the sum of the object's behaviors -- which may or may not be
exactly the same as the behaviors it started out with.

> To level-set: I care about this discussion primarily
> because plenty of people (but no one on this thread, of course) criticize
> Ruby as being less strongly-typed than C++ or Java, whereas the truth is
> that Ruby is _dynamically_ typed rather than _weakly_ typed. In Ruby, an
> object never changes its type (although delegation and the ability to add
> methods to a single object instance also may make it seem like it does).

It never changes its *class*, but it can change its type.

> More to the point, Ruby will never implicitly perform operations on an
> object that are not part of its type, as a result of inferences about some
> particular statement of code. This Ruby code will generate an error:
> "abc" + 5

Yes, but this won't:

irb(main):004:0> a = "abc"
=> "abc"
irb(main):005:0> def a.+(other); self << other.to_s; end
=> nil
irb(main):006:0> a + 3
=> "abc3"

The thing about type in Ruby is that there are no words for different
types.  There's no need for them; the fact that a defines + the way it
does is all you'd need to know.  There's no need for a word that
means, "the type of objects that start out as strings but redefine +
so that it performs an automatic to_s....."  And since the type
spectrum is infinite, there's no way to have words for all of them.

> I've noticed that younger programmers seem to have much less conceptual
> trouble with "duck typing" and dynamic languages than older people like me.
> I wonder if it's because for a while, CS programs taught people with
> functional languages like Scheme, where the distinction between objects and
> variable-bindings is explicit and clear. (Nowadays of course, all the
> younger people coming out of university seem to have learned nothing but
> Java...)

I'd be at least mildly surprised if you're older than I am :-)  But in
any case, it comes down to this: There are two things going on with
Ruby objects.  One is their class.  The other is the fact that they
are dynamic; their behaviors can change, and even two objects that
report themselves to be of the same class can have different
behaviors.

It's conventional to refer to the first of these things as class, and
the second as type.  The disadvantage of referring to the first one as
both class *and* type is that then we need a new word to refer to the
second one, when in fact "type" is really the best word.

(See the Pickaxe (2nd edition) for a lengthy and enlightening
discussion of the difference between class and type in Ruby.)


David
F3b7109c91841c7106784d229418f5dd?d=identicon&s=25 Justin Collins (justincollins)
on 2006-05-15 22:55
(Received via mailing list)
Francis Cianfrocca wrote:
> Well, I have a somewhat different theory. Because remember five to ten
> years ago, when all the young people were coming out having learned
> Scheme and nothing else, so they were useless? I think someone told
> the professors they need to train people for the real world, but they
> responded by picking Java as the default choice. Seems like it would
> be nice to find a happy medium between solid training in CS
> fundamentals and practical knowledge. The Java training they're
> getting now seems to be little more than recipes.
>
This is exactly correct. A lot of CS programs (my own included) are
struggling with a balance between marketable skills (ugh) and a solid
theoretical base. My school is currently considering switching from C++
to Java for intro CS classes. I was lucky enough to have classes with
both C++ and Java, as well as a programming languages class that used
Scheme. Most of the CS students younger than myself will be lucky if
they are exposed to Python.

I think the main problem is that some students just want to learn to be
software engineers, others want to be computer scientists. The best
proposal I've heard so far is to split the CS program into the two, one
track for the practical side and the other for theoretical. Of course,
there would be quite a bit of overlap.

In my opinion, it should be straight computer science, drop the software
engineering or make it a different major :) Too bad the department is
heading in the direct opposite direction.

-Justin
Bbc4b3fca1ae3161257a8636145b424d?d=identicon&s=25 Elliot Temple (Guest)
on 2006-05-15 23:10
(Received via mailing list)
On May 15, 2006, at 1:54 PM, Justin Collins wrote:

>>
> The best proposal I've heard so far is to split the CS program into
> the two, one track for the practical side and the other for
> theoretical. Of course, there would be quite a bit of overlap.
>
> In my opinion, it should be straight computer science, drop the
> software engineering or make it a different major :) Too bad the
> department is heading in the direct opposite direction.

Which half of the split would you say that learning how to implement
an AVL tree falls under?

-- Elliot Temple
http://www.curi.us/blog/
F3b7109c91841c7106784d229418f5dd?d=identicon&s=25 Justin Collins (justincollins)
on 2006-05-15 23:17
(Received via mailing list)
Elliot Temple wrote:
>>> fundamentals and practical knowledge. The Java training they're
>> I think the main problem is that some students just want to learn to
> an AVL tree falls under?
>
> -- Elliot Temple
> http://www.curi.us/blog/
>
At my school, tree structures are introduced in the third CS class,
'Data Structures'. It's likely that particular class would be required
for both (in my hypothetical curriculum :)

-Justin
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 23:18
Francis Cianfrocca wrote:
> Well, I have a somewhat different theory. Because remember five to ten
> years ago, when all the young people were coming out having learned
> Scheme and nothing else, so they were useless? I think someone told
> the professors they need to train people for the real world, but they
> responded by picking Java as the default choice. Seems like it would
> be nice to find a happy medium between solid training in CS
> fundamentals and practical knowledge. The Java training they're
> getting now seems to be little more than recipes.


by the thread i started has turned into a very large conversation.

yeah i have actually been in a computer information systems program for
2 years i'll be done in august so i am actually not a complete beginner
i have had java 1, 2 vb.net 1 2, programming lgi, systems analysis etc.
Yet i have serious problems understanding programming for some reason
even though i get good grades. Part of the problem is that the education
i am getting isnt very good. All the classes are only 7 weeks long so we
dont have alot of time to get involved in things, also all they are
teaching is the language syntax, there is absolutly no problem solving
or algorithm development. Its just making toy programs while the
instructor basicall holds our hands and its been that way or the past 2
years. So now in august i will have a crappy education and be $30,000 in
debt. Pretty frustrating. I cant get hired anywhere at any programming
job because i just dont have the skills and i am almost done with this
degree. Networking is a different story though its a bit more
straightforward pluging things in and configuring them etc. So i think
i'll just compliment my crappy education with some certifications like a
CCNA or something to make myself marketable. If i thought i would win
i'd take this school to court for screwing me over with a crappy
education.
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2006-05-15 23:20
Regg wrote:
> In your example:
>
> " In C++ you can do this:
>
>     MyClass * m_class = NULL;
>     m_class->do_something();
>
>  And the results are undefined (by the language standard).[1]  If you
> are
>  lucky, you might get segmentation fault.
> "
> This would also generate a error just like it would in Ruby.

Ummm ... its undefined.  That means it is, ummm, undefined.  As in every
system might handle it differently.

Most modern systems will give you a Segmentation Fault and dump the
program.   Is there a language defined way to handle that? (I don't
recall one ... but my C++ is a bit rusty).

In Ruby however, it is a standard exception.  You can handle it as
easily as handling end of file exceptions or file not found exceptions.

> This is something that YOU are forcing the compiler to do.
> You are FORCING the compiler to accept this assignment even if it's
> wrong.

It IS wrong (well, most of the time), and yes, I'm able to force the
compiler to accept it anyways (because occasionally it is not wrong).

> But in Ruby you are not forcing it, it just allows it to happen with no
> warning.

That's because it is NOT wrong in Ruby.

It's not wrong until you use the object inappropriately, and that that
point you get a well defined exception that you can deal with inside the
language.

C++ attempts to prevent object misuse by making the assignment an error,
but letting you override that error and make any misuse your problem.

Ruby prevents object misuse by preventing the misuse when it happens,
not by objecting to assignments that may or may not be correct.

Is this helping?  A lot of people coming from statically typed languages
deal with this same issue (I was one at one time).  We put a lot of
faith in the hope that static typing will catch a lot of our errors for
us.  And it seems that a dynamic language is too "loosey-goosey" to be
safe.  It turns out (at least for me) the errors that are caught by a
static type system and aren't caught by a dynamic system are not all
that common.

But me telling you these things probably isn't going to convince you one
way or another.  You need to use the language a while and see if your
fears are born out.

At any rate, I hope you enjoy some Ruby programming while you are
learning!

-- Jim Weirich
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-05-15 23:24
(Received via mailing list)
On May 15, 2006, at 3:04 PM, Regg wrote:

> do something that the compiler otherwise would not allow.
> from
> one type to another? (This is an honest question, maybe I'm missing
> something)
>
> It seems like a recipe for disaster.
>
> Thanks


I like to explain the differences like this:

1) With static, strong typing the variables are typed
2) With weak typing the operations are typed
3) With dynamic, strong typing the objects are typed.

So with 1) we have C++

string a = 7;
compile time error

2) we have perl

$a = 1 + 7;
$b = 1 . 7;

$a is 8, $b is "17".

3) We have ruby and python and smalltalk and some others

a = 7
b = "string"
c = a + b
Runtime error, you can't add a string to a number

The (4) one which I didn't mention was static weak-typing which is C.
You're right that you have to explicitly cast the type, but the
problem is unless it's one of those "magic" casts like from double to
int what you are _literally_ doing is changing the type (w/o changing
the representation). In C I can actually write this:
double q = 2.0;
printf("%s\n", (char *)q);

(char *)q does not make me a string "2.0", it just says take this
memory address and treat it as a pointer to a char. This will
hopefully segfault, but maybe it won't and it will print something
very odd. You can see the weak-typing I hope. Of course the upside is
is that it is exactly this capability that lets us have our Fixnums,
nil, true, false, and Symbols as immediate values.
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2006-05-15 23:27
(Received via mailing list)
On 5/15/06, Jake McArthur <jake.mcarthur@gmail.com> wrote:
> variable point to a different object entirely which can be of a
> different type.

Perhaps this is nitpicking, perhaps not, but it's incorrect to say
that you cannot change an object's type (to paraphrase).

class Dog
  def woof; "woof"; end
end

class Duck
  def quack; "quack"; end
end

dog = Dog.new
Okay so dog points to a Dog object, and is obviously not a Duck.  Can
we change its type to Duck though?  Instead of full on changing it,
can we ADD the Duck type?  Yeah, it's pretty simple:

def dog.quack
  "identity crisis"
end

You can now call dog.quack, and Duck is one of its types.

You might say "Well no, all you did is add a quack method to that
particular object, it's still a Dog."  You're right...but for the most
part we don't care about an object's class - that's only interesting
at creation time.  An object's type is simply its interface, and as
long as my Dog object responds to each method that a Duck does, then
the Dog is also of type Duck.  That may seem kind of confusing, and
that's really because you shouldn't be thinking of it in these
partitioned terms anyway.  All we really care about when playing with
an object is whether we can make method calls on it without our
program blowing up.

Pat
139a2a2f6b330cc59a8dc6384bbf8837?d=identicon&s=25 Corey Konrad (ckonrad)
on 2006-05-15 23:36
yeah i just need to do it for some reason, so i guess thats makes sense,
if it wasnt natural then i would have quit a long time ago. Its just
discouraging sometimes because i am going on 30 here and i meet 18 year
olds that can just do amazing things with programming. When i talked
about natural i meant people that have been doing programming since they
were kids, i have been into computers for about 3 years now thats about
it. I didnt even know what the internet was when i was 18 and it didnt
exist when i was a kid all i had was my commadore 64 and copy of ultima
4, lol.




Pat Maddox wrote:
> On 5/14/06, Bill Guindon <agorilla@gmail.com> wrote:
>> On 5/14/06, corey konrad <0011@hush.com> wrote:
>> > yup i'll get it, need a break now though, you know when you read tacos
>> > as a misspelling of "to cos" that you have been studying programming and
>> > math all day.
>>
>> Yeah, definitely a natural.  It won't be long before you wake up
>> dreaming of code ;)
>
> Oh man, code comes to you at the WEIRDEST times.  I can't tell you how
> many times I've half-woken up at 3am, and in that mid-dreamy state
> somehow figured out the answer to a problem.  Then I hop out of bed
> and make it happen.  Sometimes it doesn't work, and then you're like,
> "It'll only take 10 minutes or so" and you find yourself still
> pounding at the keyboard at 7am.  "hrm, better shower and go to work."
>  I like it better when my dream code works perfectly though :)
>
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2006-05-15 23:46
Logan Capaldo wrote:
> I like to explain the differences like this:
>
> 1) With static, strong typing the variables are typed
> 2) With weak typing the operations are typed
> 3) With dynamic, strong typing the objects are typed.

I hadn't seen it called out like this before.  I like it.

-- Jim Weirich
Bbc4b3fca1ae3161257a8636145b424d?d=identicon&s=25 Elliot Temple (Guest)
on 2006-05-15 23:58
(Received via mailing list)
On May 15, 2006, at 2:16 PM, Justin Collins wrote:

> At my school, tree structures are introduced in the third CS class,
> 'Data Structures'. It's likely that particular class would be
> required for both (in my hypothetical curriculum :)

This is totally off topic (so i've changed the subject), but learning
implementation details, like AVL trees, -- which I can easily look up
myself if I ever want to --  is one of the main sorts of things that
made me quit University. (also there was the java)

this was aggravated by things like being asked, on tests, to
implement data structures with pen and paper. and then being graded
on syntax. *glare*. but anyway...

under my ideal curriculum, students wouldn't be told "learn this" or
"learn that" for specific details. they would instead be given
interesting problems to work on, and teaching would focus more on
general methods of solving problems. so, for example, instead being
taught AVL trees and given a practice problem where the solution is
an AVL tree, they'd be given a problem with a non-obvious solution
and taught how to figure out what data structure to use (and how to
look up or otherwise learn an implementation).

-- Elliot Temple
http://www.curi.us/blog/
49ab3ce5a4922b4747d1d6f330784629?d=identicon&s=25 Jake McArthur (Guest)
on 2006-05-16 00:23
(Received via mailing list)
I prefer to just think of Ruby as not having any types at all. All I
care about is whether the object responds to the correct messages,
and if it doesn't, all you have to do is make it so that it does. Add
methods, mix in modules, whatever suits the case.

- Jake McArthur
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2006-05-16 00:26
(Received via mailing list)
Exactly.

"That may seem kind of confusing, and that's really because you
shouldn't be thinking of it in these partitioned terms anyway.  All we
really care about when playing with an object is whether we can make
method calls on it without our program blowing up."

In my opinion, thinking in terms of types serves merely as an obstacle
to taking advantage of Ruby's power.

Pat
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2006-05-16 02:29
(Received via mailing list)
Elliot Temple wrote:
>
>>
>> In my opinion, it should be straight computer science, drop the
>> software engineering or make it a different major :) Too bad the
>> department is heading in the direct opposite direction.
>
>
> Which half of the split would you say that learning how to implement  an
> AVL tree falls under?
>

Heh heh heh... the "AVL tree" part is conmputer science,
and the "implementing" part is software engineering... ;)


Hal
288733e11db1c6dbbf50871d2c6738c6?d=identicon&s=25 uncutstone (Guest)
on 2006-05-16 05:02
Jim Weirich wrote:
> Logan Capaldo wrote:
>> I like to explain the differences like this:
>>
>> 1) With static, strong typing the variables are typed
>> 2) With weak typing the operations are typed
>> 3) With dynamic, strong typing the objects are typed.
>
> I hadn't seen it called out like this before.  I like it.
>
> -- Jim Weirich

Yes, it's so good a summary. I like it too , it's kind of wisdom.
This topic is locked and can not be replied to.