Ruby on Rails?

[Tim Smith]

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

 

[Daniel Dyer]

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.

 

[Timo Stamm]

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

 

[Roedy Green]

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.

 

[Chris Smith]

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

 

[Andrew McDonagh]

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.

 

[Andrew McDonagh]

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!

 

[Chris Smith]

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

 

[Erik Funkenbusch]

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.

 

[Timo Stamm]

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/DomainSpecificLanguage.html


Timo

 

[Chris Uppal]

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

 

[Chris Uppal]

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

 

[Andrew McDonagh]

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.

 

[Andrew McDonagh]

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

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/brant/Refactory/LintChecks.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

 

[Thomas Hawtin]

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

 

[Chris Uppal]

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

 

[Chris Smith]

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

 

[Chris Smith]

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

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

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

 

[Chris Uppal]

Chris Smith wrote:

[me:]

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

 

[Chris Uppal]

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

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