I want to learn a new language...

Hans Fugal hans at fugal.net
Thu Feb 15 13:51:55 MST 2007

On Thu, 15 Feb 2007 at 10:48 -0700, Bryan Sant wrote:
> On 2/14/07, Hans Fugal <hans at fugal.net> wrote:
> >I disagree that duck typing (which is a feature of ruby also) is a
> >problem. I find it much more useful than not. I do agree however that it
> >is important to document what is accepted and expected for your methods.
> Doesn't this defacto need to document your parameters bring back much
> of the verbosity of a statically typed language?  I'm not trying to be
> inflammatory, it's a sincere question I've had for a long time.  I've
> avoided using dynamic languages partly for this reason.
> Granted that the interpreter doesn't *require* you to specify the type
> or order of parameters, it makes sense that this is a good idea
> (especially when working on a larger project, or building a lib that
> will be used by others).  But if this information is valuable,
> wouldn't it be better if the language forced you to specify the type
> and order of parameters?  Wouldn't it be better to remove the guess
> work about how a method, class, and library are used because the
> contract for how you call them is embedded in the language?

It's always important for the API to be understood. The advantage to a
dynamic (duck-typing) language is not that you don't have to understand
or make understood the API. The advantage to a dynamic language is that
you can pass a guy dressed in a duck suit to the library that was only
designed for ducks. The difference becomes you documenting "something
that behaves like a duck in this sense" vs. static type checking which
requires things that descend from Duck or _are_ Duck. It's not a matter
of power, it's a matter of expressiveness. People argue that static
languages are safer. I say we have enough of that with our government
treating us like babies. I don't need my compiler/interpreter to do it

> >Incidentally, Ruby has similar (perhaps worse) limitations in threading.
> >These are on the table for repair with the virtual machine work being
> >done. The story is long, but basically you can do threads but they're
> >not real threads, and I say that in the pragmatic sense not the academic
> >sense.
> Is this a limitation for Rails?  Does Rails run as a single process
> with green threads or messaging, or pooled out in separate processes
> like mod_perl or CGI?

I'm not a Rails expert, but I do believe ruby threads are not a problem
(though it may have been something they had to work around). How rails
runs is as much a matter of deployment as anything. A common deployment
is the fastcgi-like setup, whether it's really fastcgi or some other
http daemon with something similar.  So in short, I believe it's usually
a pool of processes handling requests.

Hans Fugal ; http://hans.fugal.net
There's nothing remarkable about it. All one has to do is hit the 
right keys at the right time and the instrument plays itself.
    -- Johann Sebastian Bach
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://plug.org/pipermail/plug/attachments/20070215/06861580/attachment.bin 

More information about the PLUG mailing list