Ruby on Rails?

asj schrieb:

John A. Bailo wrote:
Can it replace .net, php and java?

No. Hype passes unless it has widespread industry or popular backing.
Ruby has neither, although JRuby on Rails is being pushed in JavaOne
this week.

PHP had neither, and it is a de-facto standard today.

May 16 '06 #10

Remon van Vliet

"asj" <ka*******@yahoo.com> wrote in message
news:11**********************@j55g2000cwa.googlegr oups.com...

John A. Bailo wrote:
Can it replace .net, php and java?

No. Hype passes unless it has widespread industry or popular backing.
Ruby has neither, although JRuby on Rails is being pushed in JavaOne
this week.

Is this true?? Why on earth would Sun be interested in pushing new hype
languages at a conference specifically focussed on Java? Or is it
specifically about JRuby rather than Ruby (on Rails)?

May 16 '06 #11

Remon van Vliet

"Timo Stamm" <ti********@arcor.de> wrote in message
news:44**********************@newsread2.arcor-online.net...

asj schrieb:
John A. Bailo wrote:
Can it replace .net, php and java?

No. Hype passes unless it has widespread industry or popular backing.
Ruby has neither, although JRuby on Rails is being pushed in JavaOne
this week.

PHP had neither, and it is a de-facto standard today.

It is? for what?

May 16 '06 #12

Daniel Dyer

On Tue, 16 May 2006 11:44:40 +0100, Remon van Vliet <re***@exmachina.nl>
wrote:

"Timo Stamm" <ti********@arcor.de> wrote in message
news:44**********************@newsread2.arcor-online.net...
asj schrieb:
John A. Bailo wrote:
Can it replace .net, php and java?

No. Hype passes unless it has widespread industry or popular backing..
Ruby has neither, although JRuby on Rails is being pushed in JavaOne
this week.

PHP had neither, and it is a de-facto standard today.

It is? for what?

I wouldn't call it a standard, but PHP hosting is nearly ubiquitous.
Every cheap web host seems to offer PHP + MySQL pre-configured. Java
servlet/JSP hosting by contrast is much more expensive. If Ruby starts to
become as widely deployed as PHP, then Rails becomes a very attractive
choice for the kind of off-the-shelf web-apps that are currently the
domain of PHP (message boards, online communities, content management
systems, etc.).

Dan.

--
Daniel Dyer
http://www.dandyer.co.uk

May 16 '06 #13

asj

Timo Stamm wrote:

asj schrieb:
John A. Bailo wrote:
Can it replace .net, php and java?

No. Hype passes unless it has widespread industry or popular backing.
Ruby has neither, although JRuby on Rails is being pushed in JavaOne
this week.

PHP had neither, and it is a de-facto standard today.

PHP fulfilled a niche that was not there - cheap, easy, open source web
development - in that sense, it had built in pupular backing, and being
bundled with apache, the world's most popular web server didn't hurt
either. That's the niche that ruby is trying for, and PHP is already
there. Is Ruby bundled with anything? Are hosting services rushing to
use it? I've seen it in a very few, but not even close to how
ubiquitous PHP is.

May 16 '06 #14

asj

Remon van Vliet wrote:

"asj" <ka*******@yahoo.com> wrote in message
No. Hype passes unless it has widespread industry or popular backing.
Ruby has neither, although JRuby on Rails is being pushed in JavaOne
this week.

Is this true?? Why on earth would Sun be interested in pushing new hype
languages at a conference specifically focussed on Java? Or is it
specifically about JRuby rather than Ruby (on Rails)?

JRuby. It would be nice if more languages run well on the JVM.
http://headius.blogspot.com/

May 16 '06 #15

Daniel Dyer schrieb:

On Tue, 16 May 2006 11:44:40 +0100, Remon van Vliet <re***@exmachina.nl>
wrote:

"Timo Stamm" <ti********@arcor.de> wrote in message
news:44**********************@newsread2.arcor-online.net...
asj schrieb:
John A. Bailo wrote:
> Can it replace .net, php and java?

No. Hype passes unless it has widespread industry or popular backing.
Ruby has neither, although JRuby on Rails is being pushed in JavaOne
this week.

PHP had neither, and it is a de-facto standard today. It is? for what?

I wouldn't call it a standard,

From wikipedia.org:

| De facto is a Latin expression that means "in fact" or "in practice".
| It is commonly used in contrast to de jure (which means "by law") when
| referring to matters of law, governance, or technique (such as
| standards), that are found in the common experience as created or
| developed without or against a regulation.

Calling PHP on webservers a standard would be wrong because nobody ever
standardized it oficially. Calling it a "de-facto" standard is perfectly
valid, though.

but PHP hosting is nearly ubiquitous. [...]

Yes.
Timo

May 16 '06 #16

Stephan Eggermont

In comp.lang.java.programmer John A. Bailo <ja*****@texeme.com> wrote:

Dr. Dobbs has a /glowing/ article on Ruby on Rails this month.

What do you guys think?

Can it replace .net, php and java?

And be the Open Source OOP web solution that is not bound to Sun or MS?

No, the replacement will be seaside on squeak, or something similar.

Stephan

May 16 '06 #17

Stephan Eggermont schrieb:

In comp.lang.java.programmer John A. Bailo <ja*****@texeme.com> wrote:
Dr. Dobbs has a /glowing/ article on Ruby on Rails this month.

What do you guys think?

Can it replace .net, php and java?

And be the Open Source OOP web solution that is not bound to Sun or MS?

No, the replacement will be seaside on squeak, or something similar.

Ruby is actually quite similar to Smalltalk.

May 16 '06 #18

Robert Klemme

Timo Stamm wrote:

Stephan Eggermont schrieb:
In comp.lang.java.programmer John A. Bailo <ja*****@texeme.com> wrote:
Dr. Dobbs has a /glowing/ article on Ruby on Rails this month.

What do you guys think?

Can it replace .net, php and java?

And be the Open Source OOP web solution that is not bound to Sun or MS?

No, the replacement will be seaside on squeak, or something similar.

Ruby is actually quite similar to Smalltalk.

.... in certain areas. I'm not sure the claim would hold as a general
statement (too low Smalltalk knowledge here).

Kind regards

robert

May 16 '06 #19

Stephan Eggermont

In comp.lang.java.programmer Timo Stamm <ti********@arcor.de> wrote:

Stephan Eggermont schrieb:
In comp.lang.java.programmer John A. Bailo <ja*****@texeme.com> wrote:
Dr. Dobbs has a /glowing/ article on Ruby on Rails this month.

What do you guys think?

Can it replace .net, php and java?

And be the Open Source OOP web solution that is not bound to Sun or MS?

No, the replacement will be seaside on squeak, or something similar.

Ruby is actually quite similar to Smalltalk.

It is a lot slower, has a weird syntax, and wee isn't as far
developed as seaside.

Stephan

May 16 '06 #20

Tim Smith

In article <44***********************@news.xs4all.nl>, Remon van Vliet
wrote:

PHP had neither, and it is a de-facto standard today.

It is? for what?

Web-based X, for X in {blogs, forums, email, galleries, portals, CMS}.
Most small to medium sites that provide these use PHP, as do a few very
large ones (such as Yahoo).

--
--Tim Smith

May 16 '06 #21

Daniel Dyer

On Tue, 16 May 2006 14:14:17 +0100, Timo Stamm <ti********@arcor.de> wrote:

PHP had neither, and it is a de-facto standard today.
It is? for what?

I wouldn't call it a standard,

From wikipedia.org:

| De facto is a Latin expression that means "in fact" or "in practice"..
| It is commonly used in contrast to de jure (which means "by law") when
| referring to matters of law, governance, or technique (such as
| standards), that are found in the common experience as created or
| developed without or against a regulation.

Calling PHP on webservers a standard would be wrong because nobody ever
standardized it oficially. Calling it a "de-facto" standard is perfectly
valid, though.

I know what "de facto" means, but I still not sure that I would call it a
standard, de facto or otherwise, simply because it is popular. AlthoughI
can see why you could argue that. To me, "standard" implies something
more than just popularity. It implies that it's popularity would
contribute to it being a better choice than some other alternative (often
to aid interoperability), and that I would be disadvantaged by not
choosing the "standard". If 80% of people use PHP for their server-side
scripting, it doesn't make it a better choice for me than it would be if
only 10% of people used it. However, if 80% of people use Internet
Explorer then that makes its interpretation of HTML a de facto standard,
and I would be disadvantaged by choosing to ignore it when developing a
website.

Dan.
--
Daniel Dyer
http://www.dandyer.co.uk

May 16 '06 #22

Daniel Dyer schrieb:

I know what "de facto" means, but I still not sure that I would call it
a standard, de facto or otherwise, simply because it is popular.
Although I can see why you could argue that. To me, "standard" implies
something more than just popularity. It implies that it's popularity
would contribute to it being a better choice than some other alternative
(often to aid interoperability), and that I would be disadvantaged by
not choosing the "standard".
I think this applies to PHP. If you want to develop a product like a web
shop that targets small companies as customers, you have to make sure
that the shop works on the servers these companies have available, which
makes PHP first choice.

You would be seriously disadvantaged if you used Java for this market
segment. Someone at the company might know how to upload PHP files to a
FTP server, but he probably doesn't know how to install and configure a
servlet container (and is not allowed to on a cheap virtual server).

If 80% of people use PHP for their
server-side scripting, it doesn't make it a better choice for me than it
would be if only 10% of people used it. However, if 80% of people use
Internet Explorer then that makes its interpretation of HTML a de facto
standard, and I would be disadvantaged by choosing to ignore it when
developing a website.

I agree that Internet Explorer is a much stronger case of "standard".
Timo

May 16 '06 #23

Roedy Green

On Mon, 15 May 2006 08:35:23 -0700, "John A. Bailo"
<ja*****@texeme.com> wrote, quoted or indirectly quoted someone who
said :

Can it replace .net, php and java?

I saw some benchmarks. Ruby's flexibility has a fairly high CPU
overhead. You would not want to use it for heavy duty computation.

Ruby is clearly a lot faster to knock out code than Java, but I
suspect it may be harder to maintain without all the static type
information you get with Java.

It will be interesting to see what niche it carves out for itself.

Ruby is perhaps more important culturally. It is the first important
computer language to come out of Asia. That may give it an edge in
Asia, even though it uses English keywords, just out of continental
pride.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

May 21 '06 #24

Roedy Green <my******************************@munged.invalid > wrote:

Can it replace .net, php and java?

I saw some benchmarks. Ruby's flexibility has a fairly high CPU
overhead. You would not want to use it for heavy duty computation.

Ruby is clearly a lot faster to knock out code than Java, but I
suspect it may be harder to maintain without all the static type
information you get with Java.

Specifically about Rails, as well, it appears that Rails is designed for
writing basic CRUD database/web bridges. Perhaps there's more to it
than that. If so, no major source of basic information on the Rails
framework is capable of communicating that fact. Rails is certainly
much faster than almost anything else I've seen at writing and
maintaining applications that shouldn't have been written anyway. I'm
still waiting for anything else.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

May 21 '06 #25

Roedy Green wrote:

On Mon, 15 May 2006 08:35:23 -0700, "John A. Bailo"
<ja*****@texeme.com> wrote, quoted or indirectly quoted someone who
said :
Can it replace .net, php and java?
I saw some benchmarks. Ruby's flexibility has a fairly high CPU
overhead. You would not want to use it for heavy duty computation.

Ruby is clearly a lot faster to knock out code than Java, but I
suspect it may be harder to maintain without all the static type
information you get with Java.

Actually this is not a problem. Most ruby developers are also TDDers or
at least unittesters. In fact, Ruby has Unit & Acceptance testing
framework built in. We trade the compile time type check for runtime
checks via the tests we write, which means we still have the benefits of
static languages like Java, but can also have the benefits of the
dynamic typed language.

It will be interesting to see what niche it carves out for itself.
Rails is certainly the killer framework for it - Its shown the power and
ease that can be used of Ruby. So the niche wont be a small one - there
will be lots of websites running it as the next few years tick by. This
is greatly helped by most flavours of Unix now having Ruby installed as
standard.

Ruby is perhaps more important culturally. It is the first important
computer language to come out of Asia. That may give it an edge in
Asia, even though it uses English keywords, just out of continental
pride.

May 21 '06 #26

Andrew McDonagh wrote:

Roedy Green wrote:
On Mon, 15 May 2006 08:35:23 -0700, "John A. Bailo"
<ja*****@texeme.com> wrote, quoted or indirectly quoted someone who
said :
Can it replace .net, php and java?

I saw some benchmarks. Ruby's flexibility has a fairly high CPU
overhead. You would not want to use it for heavy duty computation.

Ruby is clearly a lot faster to knock out code than Java, but I
suspect it may be harder to maintain without all the static type
information you get with Java.

Actually this is not a problem. Most ruby developers are also TDDers or
at least unittesters. In fact, Ruby has Unit & Acceptance testing
framework built in. We trade the compile time type check for runtime
checks via the tests we write, which means we still have the benefits of
static languages like Java, but can also have the benefits of the
dynamic typed language.

Oh also, we tend to use additional testing frameworks like Selenium,
this drives the browser - and is very cool!

May 21 '06 #27

Roedy Green wrote:

Ruby is clearly a lot faster to knock out code than Java, but I
suspect it may be harder to maintain without all the static type
information you get with Java.

Andrew McDonagh <ne**@andmc.com> wrote: Actually this is not a problem. Most ruby developers are also TDDers or
at least unittesters. In fact, Ruby has Unit & Acceptance testing
framework built in. We trade the compile time type check for runtime
checks via the tests we write, which means we still have the benefits of
static languages like Java, but can also have the benefits of the
dynamic typed language.

These are not the same thing. The problem areas solved by static
verification tools (and, in particular, type systems) overlap slightly
with those solved by testing tools. The area of overlap is that type
systems can detect some of the same problems as testing can. The areas
where the two techniques do not overlap include the following additional
uses of types:

Type systems:
- Provide reliable documentation of code
- Enable more powerful development tools
- Support program analysis tools
- Enforce simple invariants, rather than single test cases
- Allow more aggressive optimizations

Of these, the first four definitely fit under reasons that Ruby code may
be harder to maintain because of the lack of types. It would, of
course, be remiss not to point out the one advantage to maintaining Ruby
code, which is that there would be less of it to maintain.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

May 21 '06 #28

Erik Funkenbusch

On Sat, 20 May 2006 18:49:17 GMT, Roedy Green wrote:

Ruby is clearly a lot faster to knock out code than Java, but I
suspect it may be harder to maintain without all the static type
information you get with Java.

The jury is still out on the long term maintenance costs of RoR. However,
I think RoR is going to be significant in that many of the cool ideas
represented in RoR will be ported to other languages. Many of the features
will be available in C# 3.0's LINQ features, for instance. I would expect
to see similar enhancements to Java and other languages as well.

Ruby is a so-called DSL, or Domain Specific Language. That's great when
you're working in that domain, but often times projects span domains, and
then it becomes harder to use such DSL's, and general purpose languages
have to fill in the gaps.

May 21 '06 #29

Erik Funkenbusch schrieb:

Ruby is a so-called DSL, or Domain Specific Language.

Ruby is not a domain specific language. It is a general purpose language
that allows you to create in-language DSLs using the metaprogramming,
introspection and reflection.

http://www.martinfowler.com/bliki/Do...cLanguage.html
Timo

May 21 '06 #30

Andrew McDonagh wrote:

Most ruby developers are also TDDers or
at least unittesters.

Is that actually true ? I know that TDD/Uniters make a lot of noise, but is
that indicative of the actual numbers ?

-- chris

May 21 '06 #31

Chris Smith wrote:

It would, of
course, be remiss not to point out the one advantage to maintaining Ruby
code, which is that there would be less of it to maintain.

I think the impression conveyed by "the one advantage" is false.
Non-declarative type systems, in particular dynamic type systems, have more
benefits than just reducing the amount of code. Rubyers (and Pythonists, etc)
know this very well.

-- chris

May 21 '06 #32

Chris Uppal wrote:

Andrew McDonagh wrote:
Most ruby developers are also TDDers or
at least unittesters.

Is that actually true ? I know that TDD/Uniters make a lot of noise, but is
that indicative of the actual numbers ?

-- chris

I have no actual numbers, just the impression given the various
discussion boards, conferences and teams I know who use Ruby.

Obviously in the early days of Ruby (its around 15 years old) not many
people would have done) but its had testing built into the distro for
long time now.

May 21 '06 #33

WARNING _ I dont want to start a pissing compo of dynamic vs static
languages - I'm a Java dev first after all.

Chris Smith wrote:

Roedy Green wrote:
Ruby is clearly a lot faster to knock out code than Java, but I
suspect it may be harder to maintain without all the static type
information you get with Java.

Andrew McDonagh <ne**@andmc.com> wrote:
Actually this is not a problem. Most ruby developers are also TDDers or
at least unittesters. In fact, Ruby has Unit & Acceptance testing
framework built in. We trade the compile time type check for runtime
checks via the tests we write, which means we still have the benefits of
static languages like Java, but can also have the benefits of the
dynamic typed language.

These are not the same thing. The problem areas solved by static
verification tools (and, in particular, type systems) overlap slightly
with those solved by testing tools. The area of overlap is that type
systems can detect some of the same problems as testing can.

I wasn't saying they are they same thing. I was saying that the type
checking a compiler does can be done via unit tests - nothing more.

Its a runtime check versus a compile time check.

With Java's reflection capabilities, Java _almost_ has the same ability.

The areas where the two techniques do not overlap include the following additional
uses of types:

Type systems:
- Provide reliable documentation of code
Depends upon the type of documentation you want. Ruby can have JavaDoc
style docs too. Other than that, for most people, its the design
methodology you use which is the documentation, not the language you use.

RUP users would rely upon UML diagrams. TDDers would rely upon
Acceptance & Unit Tests (we consider them to be executable design docs).

YMMV

- Enable more powerful development tools As in IDEs?

No really.

The original refactoring IDE was developed for the Smalltalk language
and at that time it supported the following...

Instance/Class Variable Refactorings
add variable
rename variable
remove variable
push down variable
pull up variable
create accessors
abstract variable

Method Refactorings
add method
rename method
remove method
push down method
pull up method
add parameter to method
extract code as method
move method across object boundary

Class Refactorings
create new class
rename class
remove class

See http://st-www.cs.uiuc.edu/~droberts/tapos/TAPOS.htm
The Parc small talk IDE was so influential that most IDEs (eclipse,
intelliJ, etc) today allow themselves to be easily configured to
replicate it. IBMs VisualAge for Java is actually setup like it out of
the box.
- Support program analysis tools
Like what?

SmallTalk for instance has had SmallLint for ages - (the following page
was last update in 97)

http://st-www.cs.uiuc.edu/users/bran...intChecks.html
- Enforce simple invariants, rather than single test cases
True, but then by not enforcing them, we get other benefits - its a
trade off
- Allow more aggressive optimizations
Like what?

Of these, the first four definitely fit under reasons that Ruby code may
be harder to maintain because of the lack of types. It would, of
course, be remiss not to point out the one advantage to maintaining Ruby
code, which is that there would be less of it to maintain.

I simply disagree - but YMMV

May 21 '06 #34

Thomas Hawtin

Chris Uppal wrote:

Chris Smith wrote:
It would, of
course, be remiss not to point out the one advantage to maintaining Ruby
code, which is that there would be less of it to maintain.

I think the impression conveyed by "the one advantage" is false.
Non-declarative type systems, in particular dynamic type systems, have more
benefits than just reducing the amount of code. Rubyers (and Pythonists, etc)
know this very well.

One of the things that annoys me with some of the most vocal dynamic
type advocates is that they only highlight reduced code through not
declaring variable types and defining interfaces. Dynamic typed
languages require shorted code that appears superficially easier to
understand. If you want to understand the code sufficiently to be able
to maintain it, or just write it in the first place, static typing wins
hands down (IMO). As an argument it's as bad as SpringLayout and Swixml
advocates showing how easy it is to make a layout with wonky labels[1][2].

It appears that the real big advantage of dynamic typing is that
infrastructure programmers can programmatically add boilerplate to
classes (or objects for prototype-based systems), in much the same way
as you can use APT (only very much easier). (And Rails is good for
sensible defaults and not being daft.)

Tom Hawtin

[1]http://java.sun.com/docs/books/tutorial/figures/uiswing/layout/SpringDemo3.gif
[2]http://today.java.net/images/2006/02/EmailTest.png
--
Unemployed English Java programmer
http://jroller.com/page/tackline/

May 21 '06 #35

Thomas Hawtin wrote:

One of the things that annoys me with some of the most vocal dynamic
type advocates is that they only highlight reduced code through not
declaring variable types and defining interfaces.
It's as though they miss the point of their own pet languages ;-)

(BTW, I found Xah Lee's recent x-post on the subject of pet languages and the
high priest thereof -- the philosopher one -- interesting, well argued, and
relevant. Things are looking up.)

The other thing that irritates me, from the same pople, is the standard line
"declarative typing is unnecessary because we have unit tests which catch type
errors (as well as lots of other errors)". I have nothing against testing (of
any variety), and (as readers in c.l.j.p may remember) I'm no great fan of
static declarative typing either. It's the "because" that gets up my nose.

In my experience (and I was very surprised to find this when I switched from
Java to Smalltalk), unit tests don't /find/ type errors because people don't
/make/ type errors (or only very rarely). So, once again, the high priests
seem not to understand the virtues of their own languages. I can understand
them missing the weaknesses, but they should be able to articulate the positive
points...

Dynamic typed
languages require shorted code that appears superficially easier to
understand. If you want to understand the code sufficiently to be able
to maintain it, or just write it in the first place, static typing wins
hands down (IMO).
This has not been my experience. It requires a different mind-set (and a new
set of learned skills), but I find it no harder to pick apart well-written
Smalltalk code than I do well-written Java code -- it's basically a matter of
switching from a focus on /type/ to a focus on /behaviour/. (Working with
badly-written code in either language is like being staked out on an ants nest,
of course.) Once you have made that switch (which took me quite a while, I
admit), it is just as easy to "penetrate" existing Smalltalk code as Java
(actually, it's quite a bit easier, but mostly as a side-effect of the reduced
verbosity -- which is a trivial issue -- and for other reasons which have
nothing to do with the dynamic/static debate).

Mind you, I don't know how well my experience would carry over to other
dynamically typed languages. I suspect that the Smalltalk programming
environment (which is no mere "IDE") has a lot to do with this, so -- for all I
know -- doing real programming in Ruby (which only has IDEs -- if that) might
be as frustrating for me as you suggest it would be for you.

It appears that the real big advantage of dynamic typing is that
infrastructure programmers can programmatically add boilerplate to
classes (or objects for prototype-based systems), in much the same way
as you can use APT (only very much easier).

It's certainly true that the further away one gets from the boring, vanilla,
crank-out-another-application, style of coding, the more the tradeoff between
the respective benefits of static and dynamic approaches swings in favour the
latter.

-- chris

May 21 '06 #36

Chris Uppal <ch*********@metagnostic.REMOVE-THIS.org> wrote:

I think the impression conveyed by "the one advantage" is false.
Non-declarative type systems, in particular dynamic type systems, have more
benefits than just reducing the amount of code. Rubyers (and Pythonists, etc)
know this very well.

That was my mistake. I meant to say "the one obvious advantage", but I
forgot to type that word. I certainly don't mean to say that there is
no other advantage to maintaining code in Ruby.

Incidentally, let's be clear: although it's a common colloquiallism to
talk about "dynamically typed" languages, such languages do not have a
type system. The standard text is Pierce, who says a type system is: "a
tractable syntactic method for proving the absence of certain program
behaviors". Dynamically "typed" languages do not have this; they
guarantee the absence of certain behaviors, but they do not do it with a
tractable syntactic method. Pierce suggests it would be more correct to
call them "dynamically checked", but "dynamically typed" is widely used
as a figure of speech.

I'd draw the line, though, at talking about "non-declarative type
systems" or "dynamic type systems". These phrases are oxymorons.
There's no reason to actively seek to make the use of words in software
development different from their uses in formal logic and the like.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

May 21 '06 #37

Andrew McDonagh <ne**@andmc.com> wrote:

Type systems:
- Provide reliable documentation of code
Depends upon the type of documentation you want. Ruby can have JavaDoc
style docs too. Other than that, for most people, its the design
methodology you use which is the documentation, not the language you use.

RUP users would rely upon UML diagrams. TDDers would rely upon
Acceptance & Unit Tests (we consider them to be executable design docs).

Hopefully, no one uses UML to document all the kinds of things that are
documented automatically by type systems. That would be a pain. Even
if they did, UML diagrams can generally get out of date, especially if
the code doesn't contain enough information to keep them up to date with
tools that do that sort of thing. JavaDoc (or any equivalent, as you
say Ruby has) can definitely get out of date. Documentation expressed
by the type system within the syntax of the language doesn't get out of
date.

Unit tests as documentation is another thing. They are kept up to date
with code. The weakness, of course, lies in being so separated from
code; often residing in a different directory from the code that is
being documented by that test. The other weakness is that the tests are
in a language that as fundamentally just as opaque to reasoning about
behavior as the original programming language (in fact, it generally is
the same language). While one might hope that the code would be kept at
least a little simpler -- or perhaps that you'd write unit tests or
acceptance tests for the unit tests or acceptance tests -- the result
will still not match a form of expression designed for describing facts
about code that are the basis for simple reasoning about behavior.

Interestingly, if I start to imagine languages in which simple unit
tests can be written inline to put the documentation closer to the code,
and possibly in a simpler language that is more prone to reasoning about
behavior, then I end up thinking about a proper design-by-contract
language. Hmm...

- Enable more powerful development tools

As in IDEs?

Sure, or other tools. Doesn't really matter if they are integrated or
not.
No really.

The original refactoring IDE was developed for the Smalltalk language
and at that time it supported the following...

Yes. However, a good portion of the refactorings you list are
computationally intractable in Smalltalk in the general case. I am not
a Smalltalk programmer, and I don't know how the refactoring tools
handled that... perhaps they would give up, or perhaps they would guess
according to some heuristic to guess at the meaning of the code, and
rely on your unit tests to catch any errors that are introduced. Either
could be reasonable, depending on how good the heuristic can be made,
but either one is also a significant barrier to having usable tools.

So clearly, tools can be written for dynamic languages. The question is
whether they can be as good as tools for typed languages can be. (I'm
arguing the less popular side here; I would, however, probably agree if
you point out that an interactive tool that works 99.99% of the time is
just as good as one that works 100% of the time. I don't know if
Smalltalk's refactorings really do work 99.99% of the time or not.)

- Allow more aggressive optimizations

Like what?

Like, for example, implementation of polymorphic method dispatch in
practically the same time cost as a standard procedure call by using
vtables. Also, as an example, some of the work being done toward
optimizing away heap allocations by moving data onto the stack in Java
depends on static type analysis.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

May 21 '06 #38

Chris Smith wrote:

[me:]

I think the impression conveyed by "the one advantage" is false.
Non-declarative type systems, in particular dynamic type systems, have
more benefits than just reducing the amount of code. Rubyers (and
Pythonists, etc) know this very well.
That was my mistake. I meant to say "the one obvious advantage", but I
forgot to type that word.

I suspected as much ;-)

Incidentally, let's be clear: although it's a common colloquiallism to
talk about "dynamically typed" languages, such languages do not have a
type system.
Well, I disagree. (Ignoring the trivial, Crowlean, "Do as thou wilt shall be
the whole of the law", type system.) I think that the term can be and is
properly applied. A generalisation of the classical notion, I agree, but not
an awkward or misleading one.

The standard text is Pierce, who says a type system is: "a
tractable syntactic method for proving the absence of certain program
behaviors".

Hmm. I would be reluctant -- /extremely/ reluctant -- to talk of a "standard
text" on this subject. (And, as it happens, wouldn't be keen to accept Pierce
as the standard anyway since I've never heard of it ;-) Classical type
systems in logic and mathematics have little (IMO) to do with programming
languages -- for instance it would be as wrong to speak of a "static" (locution
for "compile-time") type system in a mathematical context as it would to talk
of a "dynamic" (locution for "runtime") one.

It would certainly be completely wrong to speak of dynamically-typed languages
having dynamic type /analysis/ -- analysis is a static concept[*]. But talking
about type /systems/ is not the same as talking about type /analysis/. In an
extreme case it might be that the system existed, and was well-defined, but
wasn't subject to analysis. Such a system might not be much use (who knows ?),
but the idea is not /incoherent/. Dynamic languages certainly have type
systems -- there is an abstract logic of what [sequences of] operations have
meaning. Depending on the structure of the language that might or might not
resemble a classical type system. But it certainly exists -- how else could
anyone understand even one line of code in a dynamically typed language,
there'd be nothing to have a mental model /of/ ?

([*] Except that some implementations /do/ in fact do dynamic type analysis --
the Self implementation which fed into HotSpot for instance ;-)

The other use of the phrase "type system" is to mean "that part of the language
system which does type checking". In C++ that part is in the compiler. In
Java it is split between the compiler and runtime. In Smalltalk it's all in
the runtime. You may not like that particular use of the phrase, but it seems
to have become established. To me it seems perfectly reasonable -- so I use
it ;-) But feel free to translate my uses of the term (in that sense) into
"type checker" if you wish.

Consider the following assertion. The price that statically analysed languages
pay is that they must accept an impoverished type system (logic of allowable
operations) in order to have a practically implementable ("tractable";-) type
checker. Dynamic languages, on the other hand, have a type system (logic)
which is /exactly/ as wide as is possible, but at the cost of a type checker
working at runtime. You may or may not agree with the assertion; but my point
is that the assertion is meaningful. We can coherently /compare/ the type
systems of C++, Java, and Smalltalk, which would not be possible if I were
abusing language by attaching the same phrase to incomparable concepts, or if
Smalltalk could not be said to have a type system at all.

-- chris

May 22 '06 #39

Chris Smith wrote:

Yes. However, a good portion of the refactorings you list are
computationally intractable in Smalltalk in the general case. I am not
a Smalltalk programmer, and I don't know how the refactoring tools
handled that... perhaps they would give up, or perhaps they would guess
according to some heuristic to guess at the meaning of the code, and
rely on your unit tests to catch any errors that are introduced. Either
could be reasonable, depending on how good the heuristic can be made,
but either one is also a significant barrier to having usable tools.

So clearly, tools can be written for dynamic languages. The question is
whether they can be as good as tools for typed languages can be. (I'm
arguing the less popular side here; I would, however, probably agree if
you point out that an interactive tool that works 99.99% of the time is
just as good as one that works 100% of the time. I don't know if
Smalltalk's refactorings really do work 99.99% of the time or not.)
Just for background information: the Refactoring Browser is considered to be an
absolutely essential tool by many (most?) Smalltalk programmers. It is used
all the time, which argues that it is at least adequate in practise.

Indeed I'm regarded as something of a weirdo for refusing to use its facilities
(I don't like automated refactoring of any kind -- in any language).

- Allow more aggressive optimizations

Like what?

Like, for example, implementation of polymorphic method dispatch in
practically the same time cost as a standard procedure call by using
vtables.

I don't think vtables are widely regarded as the best implementation technique,
even for languages which can use them. Routinely jumping through an
indirection is a killer. Inline dispatch, with a fallback to vtable lookup,
seems to be the Done Thing These Days. Also see the "polymophic inline caches"
of Self -- a set of techniques which are applicable to static and dynamic
languages. Although apparently PICs are not as valuable for Java, where a
simpler inline cache (plus vtables) does as good, or better, job with less
complication. (Presumably because megamorphic call sites are less common in
Java than in Self or Smalltalk -- although I don't know what part of that is
because the static type system can resolve method calls more precisely, and
what part is just down to differences in the ways that the languages are used.)
Also, as an example, some of the work being done toward
optimizing away heap allocations by moving data onto the stack in Java
depends on static type analysis.

That's escape analysis, and it can be done as easily (albeit more
conservatively) in dynamic languages as static ones. (Always assuming that the
language isn't /so/ dynamic that the concept of "a variable" can't be isolated
from runtime behaviour.)

-- chris

May 22 '06 #40

Chris Smith wrote:

Andrew McDonagh <ne**@andmc.com> wrote:
Type systems:
- Provide reliable documentation of code Depends upon the type of documentation you want. Ruby can have JavaDoc
style docs too. Other than that, for most people, its the design
methodology you use which is the documentation, not the language you use.

RUP users would rely upon UML diagrams. TDDers would rely upon
Acceptance & Unit Tests (we consider them to be executable design docs).

Hopefully, no one uses UML to document all the kinds of things that are
documented automatically by type systems. That would be a pain. Even
if they did, UML diagrams can generally get out of date, especially if
the code doesn't contain enough information to keep them up to date with
tools that do that sort of thing. JavaDoc (or any equivalent, as you
say Ruby has) can definitely get out of date. Documentation expressed
by the type system within the syntax of the language doesn't get out of
date.

I did say, 'depends upon what type you want' I didn't mean that to come
across as using them to document Types relations that are done by type
systems.

Unit tests as documentation is another thing. They are kept up to date
with code. The weakness, of course, lies in being so separated from
code; often residing in a different directory from the code that is
being documented by that test.
This is never a problem - the unit tests are considered as high a value
(or more) as the production code and therefore always compiled and run
as part of the build.

If they don't compile (because they haven't been kept up to date) then
the build fails.

If they don't ALL pass (because they haven't been kept upto date) then
the build fails.

Basically they either are up to date or the build fails.
The other weakness is that the tests are
in a language that as fundamentally just as opaque to reasoning about
behavior as the original programming language (in fact, it generally is
the same language). While one might hope that the code would be kept at
least a little simpler -- or perhaps that you'd write unit tests or
acceptance tests for the unit tests or acceptance tests -- the result
will still not match a form of expression designed for describing facts
about code that are the basis for simple reasoning about behavior.

Unit tests are best written in the same language as the code, as they
are only to describe what the code IS and how to USE it.

Their target audience is developers.

Acceptance Tests on the other hand should indeed be in a domain specfic
langauage. As this allows the stakeholders, testers and developers to
understand what the system is supposed to do.
Units tests are for Building the Code Right.

Acceptance Tests are for Building the Right Code

Interestingly, if I start to imagine languages in which simple unit
tests can be written inline to put the documentation closer to the code,
and possibly in a simpler language that is more prone to reasoning about
behavior, then I end up thinking about a proper design-by-contract
language. Hmm...
Having the unit tests in a parallel directory structure is only one of a
few standard ways of organising them. Lots of teams have the test code
in the same directory as the production code.

- Enable more powerful development tools

As in IDEs?

Sure, or other tools. Doesn't really matter if they are integrated or
not.
No really.

The original refactoring IDE was developed for the Smalltalk language
and at that time it supported the following...

Yes. However, a good portion of the refactorings you list are
computationally intractable in Smalltalk in the general case. I am not
a Smalltalk programmer, and I don't know how the refactoring tools
handled that... perhaps they would give up, or perhaps they would guess
according to some heuristic to guess at the meaning of the code, and
rely on your unit tests to catch any errors that are introduced. Either
could be reasonable, depending on how good the heuristic can be made,
but either one is also a significant barrier to having usable tools.

And yet it doesn't in practice this does not seem to be the case....
So clearly, tools can be written for dynamic languages. The question is
whether they can be as good as tools for typed languages can be. (I'm
arguing the less popular side here; I would, however, probably agree if
you point out that an interactive tool that works 99.99% of the time is
just as good as one that works 100% of the time. I don't know if
Smalltalk's refactorings really do work 99.99% of the time or not.)

I haven't yet found a tool for statically typed languages that work
99.99% of the time (Eclipse, IntellJ, etc).

I don't personally find that the language type system has any impact on
usability or reliability.

- Allow more aggressive optimizations

Like what?

Like, for example, implementation of polymorphic method dispatch in
practically the same time cost as a standard procedure call by using
vtables. Also, as an example, some of the work being done toward
optimizing away heap allocations by moving data onto the stack in Java
depends on static type analysis.

Chris Uppal has already answered this one better than I can.

May 24 '06 #41

Sorry for the delay. For some reason, my server just now got all of
your posts from the last few days.

Chris Uppal <ch*********@metagnostic.REMOVE-THIS.org> wrote:

Hmm. I would be reluctant -- /extremely/ reluctant -- to talk of a "standard
text" on this subject.
Okay. It's the one I've heard of most often, but perhaps this is a
provincial thing.
It would certainly be completely wrong to speak of dynamically-typed languages
having dynamic type /analysis/ -- analysis is a static concept[*]. But talking
about type /systems/ is not the same as talking about type /analysis/. In an
extreme case it might be that the system existed, and was well-defined, but
wasn't subject to analysis. Such a system might not be much use (who knows ?),
but the idea is not /incoherent/. Dynamic languages certainly have type
systems -- there is an abstract logic of what [sequences of] operations have
meaning.
My dispute is whether that logic is tractable and syntactic. In other
words, is it sufficient that you could prove whether or not an operation
(or sequence) has meaning given the syntax of the language, but no
formal semantics such as evaluation rules or axioms. If this is not
true, then I'd think you would need to at least very carefully qualify
calling such things "types" at all.

It's interesting that the word "type" is used in exactly this way, in
general, with Java as well. When it's said that variables have types
but objects have classes, that means that only variables have
annotations about their possible values that are used in syntactic
analysis of the program to prove the absence of behaviors. Of course,
the behaviors whose absence is proven may in fact have to do with
objects -- for example, it is proven that a program may never call a
method that doesn't exist. However, the information used by these
checks is purely syntactic. Java is also dynamically checked, so errors
are raised at runtime if an incorrect downcast is performed or an array
is accessed out of bounds. However, we don't consider the class of an
object or the length of an array part of the "type" because it is not
used by the type system; only by the dynamic checks that ensure program
safety.
The other use of the phrase "type system" is to mean "that part of the language
system which does type checking". In C++ that part is in the compiler. In
Java it is split between the compiler and runtime. In Smalltalk it's all in
the runtime.
This is actually assuming the faulty definition of types to begin with.
If types are as they are understood in the texts I know on type theory
in CS, and as they are used in Java, for example, then it is *not* true
that type checking is done by the runtime in Smalltalk. It is true that
program safety is implemented by runtime checks in Smalltalk. However,
these checks relate to concepts that are not types.
You may not like that particular use of the phrase, but it seems
to have become established.
Indeed it is established in some circles, in any case -- mostly, as a
matter of fact, in communities of people working with some "dynamically
typed" language. I suspect that this has historical roots, springing
from the false idea that untyped languages would also necessarily be
unsafe. In any case, I'm not quite ready to give up the meaning of a
perfectly useful term like "type"... especially when there exists
perfectly well-respected literature that still uses the term.

You seem to be arguing for removing any kind of validity at all from the
word "untyped"... or perhaps reserve it for cases where the bad program
behavior that we can't prove to be absent is actually undefined by the
language rather than merely bad. This is either pointless (in the
former), or not very close to the ideas implied by the word "type" and
closer to the word "safe" (in the latter).
Consider the following assertion. The price that statically analysed languages
pay is that they must accept an impoverished type system (logic of allowable
operations) in order to have a practically implementable ("tractable";-) type
checker. Dynamic languages, on the other hand, have a type system (logic)
which is /exactly/ as wide as is possible, but at the cost of a type checker
working at runtime. You may or may not agree with the assertion; but my point
is that the assertion is meaningful.

I don't believe that it is meaningful, though I can infer what you mean
from my knowledge that "dynamically typed" is often used as a synonym of
"untyped". I can translate that to "dynamically checked", and I can
translate the statement to the following, which IS meaningful:

The price that typed languages pay is that they must accept an
impoverished program semantics in order to have a tractable type
checker. The benefit is that they can convert a subset of the
necessary safety checks into static constraints. Dynamic languages,
on the other hand, have a program semantics that is defined without
that specific constraint, but they lose the benefit, as well.

I think my statement is clearer than yours, incidentally, for a number
of reasons. They include not just a substitution of words; but also a
removal of the false dichotomy between "type checking" and other
language safety checks which just don't happen to be part of the type
checker in our hypothetical typed language above.

Incidentally, I do agree with the (translated) statement.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

May 24 '06 #42

Chris Uppal <ch*********@metagnostic.REMOVE-THIS.org> wrote:

I don't think vtables are widely regarded as the best implementation technique,
even for languages which can use them. Routinely jumping through an
indirection is a killer.

You are possibly right for environments with less impoverished
development tools... but at least as of about five years ago, lookup in
the vtable was basically the way to do method dispatch for C++ virtual
method dispatch in run-of-the-mill build processes with separate per-
class compiling and a relatively dumb linker. Method inlining may be
possible if the compiler can do global program analysis, but that's not
commonly possible in that build environment. There is certainly no
reason to believe that doing this killed the performance of C++
applications.

Of course, there are a number of factors here. Typical C++ code
involves quite a bit fewer virtual method dispatches than typical
Smalltalk code (or even typical Java code). If the vtables end up
cached, though, the indirection doesn't really cost much of anything at
all. It is also an advantage of runtime native code generation (as in
Java and Smalltalk) that complete information about the environment is
available during the build.

Also, as an example, some of the work being done toward
optimizing away heap allocations by moving data onto the stack in Java
depends on static type analysis.

That's escape analysis [...]

You're right. I was confusing myself.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

May 24 '06 #43

Andrew McDonagh <ne**@andmc.com> wrote:

Chris Smith wrote:
Andrew McDonagh <ne**@andmc.com> wrote:
Type systems:
- Provide reliable documentation of code

I did say, 'depends upon what type you want' I didn't mean that to come
across as using them to document Types relations that are done by type
systems.
Ah. I'm somewhat at a loss, then. I was talking about type systems
providing documentation automatically. That seems to have little to do
with UML at all.
Unit tests as documentation is another thing. They are kept up to date
with code. The weakness, of course, lies in being so separated from
code; often residing in a different directory from the code that is
being documented by that test.

This is never a problem - the unit tests are considered as high a value
(or more) as the production code and therefore always compiled and run
as part of the build.

This, again, seems to have nothing to do with whether unit tests provide
a benefit equivalent to that of the self-documentation of a type system.
Unit tests are best written in the same language as the code, as they
are only to describe what the code IS and how to USE it.

Their target audience is developers.
I'm not so sure that's true, or at least that it's the whole story.
Their target audience is at least two-fold: developers, and the compiler
and/or runtime that executes them. The question is whether they meet
the two aims well. Clearly, if the point is to demonstrate that certain
piece of code is correct, it is not sufficient to use a test case whose
correctness is just as much in doubt as the original code. This is even
less sufficient when we consider unit tests as documentation rather than
as active tests.

Acceptance tests may be in a different language, but that language is no
more suited to understanding the code than unit tests. Probably less
so, as it is designed for different goals.
Units tests are for Building the Code Right.
Acceptance Tests are for Building the Right Code
But these are not what we're talking about. We're talking about how to
help developers understand the assumptions and invariants and other
elements of meaning that can be attributed to code but is not contained
within the functional part of the code itself. Unit tests at least
sometimes help with that, and acceptance tests do nothing at all.
Having the unit tests in a parallel directory structure is only one of a
few standard ways of organising them. Lots of teams have the test code
in the same directory as the production code.
Yet rarely in the same source file sitting next to the code where it can
be easily used to see what the code is trying to do...
[Smalltalk refactoring]

And yet it doesn't in practice this does not seem to be the case....

Having never used the Smalltalk refactoring browser, I can't say much
here. It very well have have some very good heuristics involved so that
it almost never breaks your code or fails. I don't know. I know it
doesn't work ALL the time, but I can't say how often it does work.
I haven't yet found a tool for statically typed languages that work
99.99% of the time (Eclipse, IntellJ, etc).

Do you mean that Eclipse or IntelliJ or some other editor may, for
example, forget to rename call site when you choose to rename a method?
I've never seen that. Can you give an example?

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

May 24 '06 #44