On Thu, 15 Feb 2007 at 10:48 -0700, Bryan Sant wrote: > On 2/14/07, Hans Fugal <[EMAIL PROTECTED]> 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 too. > >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
signature.asc
Description: Digital signature
/* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
