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


 

Forums >

comp.lang.ruby

OT: Strict typing on large projects

Michael Campbell

10/17/2003 8:41:00 PM

I don't necessarily mean to stir a pot here, but was reading an
article
on slashdot, and came across the comment:

"What I would love to see is a 100,000+ lines project written in PHP
being mantained by one or two developers. You can't do that without
strict typing."

Here's the thread if any of you care to rebut (many have already):
http://developers.slashdot.org/comments.pl?sid=82622&threshold=1&commentsort=0&tid=108&tid=126&tid=156&tid=169&mode=thread&c...



__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping...
6 Answers

Robert Church

10/17/2003 8:59:00 PM

0

On Sat, Oct 18, 2003 at 05:41:03AM +0900, Michael Campbell quipped:
> "What I would love to see is a 100,000+ lines project written in PHP
> being mantained by one or two developers. You can't do that without
> strict typing."

(a) PHP is a poor language for a number of reasons.

(b) Since this is a ruby list, it's important to note that Ruby *is
not* weakly typed. It is dynamically typed. C is an examply of a
weakly typed language, in that, for instance, you can assign a
character to an integer, and the character data will then be treated
as an integer value. This cannot happen in Ruby.

(c) In dynamically typed languages, you can do a lot more with 100,000
lines than you can in statically typed languages. 100,000 lines is
often simply not necessary. Also, see Greenspun's 10th Law.

"Any sufficiently complicated C or Fortran program contains an
ad-hoc, informally-specified, bug-ridden, slow implementation of half
of Common Lisp."

(d) There are certainly such projects out there. Zope is gigantic,
though I don't know off the top of my head *how* gigantic it is. There
are huge, industrial size Lisp and Smalltalk apps in the world
cranking out payrolls and trading stocks as we speak. The idea that
*real programs are written in statically typed languages* is a recent
innovation and lacks any basis in truth.

Dan Sugalski

10/17/2003 9:04:00 PM

0

Jason Creighton

10/18/2003 3:14:00 PM

0

On Sat, 18 Oct 2003 05:58:40 +0900
Robert Church <rc@pgdn.org> wrote:

> (b) Since this is a ruby list, it's important to note that Ruby *is
> not* weakly typed. It is dynamically typed.

Ack!

This is just an example of the many terms for different types of typing
floating around. Why don't we just explictly say what we mean:

In Ruby, a typing is checked at runtime and a typing error is caused by
method non-existence, or a number of arguments mis-match.

I think that sums it up much better than throwing around "weakly typed",
"strongly typed", "satically typed", "dynamically typed", etc.

Jason Creighton

Paul Brannan

10/20/2003 6:39:00 PM

0

On Sat, Oct 18, 2003 at 06:04:04AM +0900, Dan Sugalski wrote:
> C is a weakly typed language because, with casts, you can make the
> compiler treat any memory location as any type you'd care to.

You don't even need casts:

int main()
{
void * x = 5;
int y = x;
printf("%d\n", y); /* implementation-specific behavior here, but
* will probably print 5 */
}

I can use casts to make the compiler treat any memory location as any
type in C++, but many people consider C++ to be strongly-typed (or at
the very least less weakly-typed than C). I get the impression that C++
is considered strongly typed because dangerous implicit conversions like
the above code are illegal in C++.

Paul

Dan Sugalski

10/20/2003 6:44:00 PM

0

Paul Brannan

10/21/2003 3:32:00 PM

0

On Tue, Oct 21, 2003 at 03:44:22AM +0900, Dan Sugalski wrote:
> Function calls are a form of cast, albeit a hidden one, and the trick
> you're using here isn't actually valid on all processors. You can do this
> with any function as long as the body and use of that function differs in
> type.

I think you misunderstood what I was saying.

The call to printf() is not important except to display the value of y;
my point was that assigning a void* to an int is perfectly valid C code
(though the value that the int will have after the assignment is
implementation-dependent).

Paul