[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: lib for optional static typing

robertj

12/8/2005 5:25:00 PM

<sigh>

thats the problem.
sometimes "dymamic guys" argue with as much
stubborness as the "static typing guys" do.
only the other way around.

fact is that sometimes "static" typing is
extremly helpful and sometimes it is in your way
as much.

the question imo not so much if static typing is useful
or if dynamic typing is useful
BUT when to use static typing.


ciao robertj
20 Answers

Christian Neukirchen

12/9/2005 10:25:00 AM

0

"robertj" <robert_kuzelj@yahoo.com> writes:

> <sigh>
>
> thats the problem.
> sometimes "dymamic guys" argue with as much
> stubborness as the "static typing guys" do.
> only the other way around.
>
> fact is that sometimes "static" typing is
> extremly helpful and sometimes it is in your way
> as much.
>
> the question imo not so much if static typing is useful
> or if dynamic typing is useful
> BUT when to use static typing.

The *real* question is where to get a type-system that is flexible
enough to analyze non-runtime dynamic parts of Ruby without spraying
class names all over. :-)

This is left as an exercise for the reader.

> ciao robertj
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneuk...

james_b

12/9/2005 3:25:00 PM

0

Christian Neukirchen wrote:
> "robertj" <robert_kuzelj@yahoo.com> writes:
>
>
>><sigh>
>>
>>thats the problem.
>>sometimes "dymamic guys" argue with as much
>>stubborness as the "static typing guys" do.
>>only the other way around.
>>
>>fact is that sometimes "static" typing is
>>extremly helpful and sometimes it is in your way
>>as much.
>>
>>the question imo not so much if static typing is useful
>>or if dynamic typing is useful
>>BUT when to use static typing.
>
>
> The *real* question is where to get a type-system that is flexible
> enough to analyze non-runtime dynamic parts of Ruby without spraying
> class names all over. :-)
>
> This is left as an exercise for the reader.

BTW, there is a discussion on the Pragmatic Programmer mailing list
right now about the pros/cons of static typing.

http://groups.yahoo.com/group...



James

--

http://www.ru... - Ruby Help & Documentation
http://www.artima.c... - Ruby Code & Style: Writers wanted
http://www.rub... - The Ruby Store for Ruby Stuff
http://www.jame... - Playing with Better Toys
http://www.30seco... - Building Better Tools

Christian Neukirchen

12/10/2005 11:33:00 AM

0

James Britt <james_b@neurogami.com> writes:

>>>the question imo not so much if static typing is useful
>>>or if dynamic typing is useful
>>>BUT when to use static typing.
>> The *real* question is where to get a type-system that is flexible
>> enough to analyze non-runtime dynamic parts of Ruby without spraying
>> class names all over. :-)
>> This is left as an exercise for the reader.
>
> BTW, there is a discussion on the Pragmatic Programmer mailing list
> right now about the pros/cons of static typing.

Except the archives are only accessible by members, which probably
read it already anyway. :-)

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneuk...

robertj

12/10/2005 3:10:00 PM

0

>The *real* question is where to get a type-system that is flexible
>enough to analyze non-runtime dynamic parts of Ruby without spraying
>class names all over. :-)

that is certainly a point of view that many "typed" guys
would subscribe to.
the problem imo is not to define a "sound" typesystem
(as most static typing systems try to do and fail
regardless of the imense effort that has been put into)
but one that helps to define contracts on the borders of your
system without being restricting on the rest of the system.

the only language i know that did an excellent job on that
was VB (classic) where you could work mostly untyped
(if you wanted and you did not care bout performace).
whenever you wanted to release a COM-object you had
to define the types.
this was a very pragmatic approach.

ciao robertj

Bill Atkins

12/10/2005 4:45:00 PM

0

On 12/10/05, robertj <robert_kuzelj@yahoo.com> wrote:
> >The *real* question is where to get a type-system that is flexible
> >enough to analyze non-runtime dynamic parts of Ruby without spraying
> >class names all over. :-)
>
> that is certainly a point of view that many "typed" guys
> would subscribe to.
> the problem imo is not to define a "sound" typesystem
> (as most static typing systems try to do and fail
> regardless of the imense effort that has been put into)
> but one that helps to define contracts on the borders of your
> system without being restricting on the rest of the system.
>
> the only language i know that did an excellent job on that
> was VB (classic) where you could work mostly untyped
> (if you wanted and you did not care bout performace).
> whenever you wanted to release a COM-object you had
> to define the types.
> this was a very pragmatic approach.
>
> ciao robertj
>
>
>

Common Lisp supports something like that. All values are dynamically
typed by default (as in Ruby), but typing can be added to specific
areas where you need it. The user can decide whether to have the
typing used only as a compiler hint to get faster code, and/or to have
it enforced so that an error will be signaled when an attempt is made
to store an object of the wrong type into that variable.

I'm not familiar with Visual Basic, but is it the case that all
objects will eventually be COM objects? I was under the impression
that they're pretty separate concepts. Doesn't seem that pragmatic if
I have to change my regular code to a COM object just to get typing.

--
Bill Atkins

Daniel Berger

12/10/2005 4:46:00 PM

0

robertj wrote:
> >The *real* question is where to get a type-system that is flexible
> >enough to analyze non-runtime dynamic parts of Ruby without spraying
> >class names all over. :-)
>
> that is certainly a point of view that many "typed" guys
> would subscribe to.
> the problem imo is not to define a "sound" typesystem
> (as most static typing systems try to do and fail
> regardless of the imense effort that has been put into)
> but one that helps to define contracts on the borders of your
> system without being restricting on the rest of the system.
>
> the only language i know that did an excellent job on that
> was VB (classic) where you could work mostly untyped
> (if you wanted and you did not care bout performace).
> whenever you wanted to release a COM-object you had
> to define the types.
> this was a very pragmatic approach.
>
> ciao robertj

Evan Webb mentioned that it would be possible to add a pseudo type
system via Behaviors. He may even have a working implementation for
Sydney, but I'll have to double check. It would look something like
this:

# pseudocode
require "behavior/strongtyping"

def foo(String x, y)
end

In this example, x must be a String, while y can be anything. In
effect, optional typing.

I'm actually not sure if I want this, though. I know I've supported it
in the past, but I worry that Java/C/C++ programmers coming to Ruby,
fearing the removal of the static typing training wheels, might adhere
to this style too readily when it should only be used sparingly.

Regards,

Dan

Doug H

12/10/2005 4:56:00 PM

0

robertj wrote:
> the problem imo is not to define a "sound" typesystem
> (as most static typing systems try to do and fail
> regardless of the imense effort that has been put into)
> but one that helps to define contracts on the borders of your
> system without being restricting on the rest of the system.
>
> the only language i know that did an excellent job on that
> was VB (classic) where you could work mostly untyped
> (if you wanted and you did not care bout performace).
> whenever you wanted to release a COM-object you had
> to define the types.
> this was a very pragmatic approach.

See also boo http://boo.cod... which has both static
and dynamic typing. http://boo.cod...Duck+Typing
It has some stuff borrowed from ruby like anonymous closures.

If you pass "-wsa" to the booc.exe compiler, it will use "end"
statements like ruby instead of python-like indenting (although
it still requires the redundant colon at the beginning of a block).

dblack

12/10/2005 5:04:00 PM

0

james_b

12/10/2005 6:09:00 PM

0

Doug H wrote:

>
>
> See also boo http://boo.cod... which has both static
> and dynamic typing. http://boo.cod...Duck+Typing
> It has some stuff borrowed from ruby like anonymous closures.


I believe JScript.net also gives the choice of dynamic/static typing.
(Since it also supports the open 'class', prototype run-time
modification, it strikes me as the most palatable of the .net languages)



James Britt

--

http://www.ru... - Ruby Help & Documentation
http://www.artima.c... - Ruby Code & Style: Writers wanted
http://www.rub... - The Ruby Store for Ruby Stuff
http://www.jame... - Playing with Better Toys
http://www.30seco... - Building Better Tools

Jakub Hegenbart

12/10/2005 11:08:00 PM

0

Bill Atkins wrote:
> Common Lisp supports something like that. All values are dynamically
> typed by default (as in Ruby), but typing can be added to specific
> areas where you need it. The user can decide whether to have the
> typing used only as a compiler hint to get faster code, and/or to have
> it enforced so that an error will be signaled when an attempt is made
> to store an object of the wrong type into that variable.
Well, personally, I really like Common Lisp and its approach. But
concerning compiler hints...what about the Stalin Scheme compiler? I
recently started studying compiler techniques it uses and it almost
convinced me that there _is_ such a thing as the legendary "sufficiently
smart compiler". :-) I'm just wondering, if there is such a thing for
Scheme, would Ruby also benefit from such a kind of compiler? Such a
dynamic object model that Ruby uses is quite a beast to tame, on the
other hand, the optimizations that Stalin performs are nothing short of
a miracle. ;-)

Jakub