From: Friedrich Dominicus Date: 2002-09-27T01:15:07+09:00 Subject: Re: adding overload to ruby William Djaja Tjokroaminata writes: > Hi All, > > I sense that this discussion is related to a previous question, "Has a > 'Scripting Language' Been Used for Real Business/Corporate World > (read: large-scale) Applications?" > > Also a person asked before that since there is no compile-time type > checking, probably that is what hinders a "scripting language" from being > used in large scale corporate development. I don't buy that any longer. A counter example, how much of ruby is itself written in ruby? > > We all know the facts that large-scale software, including Ruby > itself, currently is almost always written in C, C++, or Java. (Yes, > probably there are others, such as Eiffel, but I don't know.) Well the reason for that are definitly not static typing. Typing in C is thiner than fig leaf. The same is true for C++, but with discpipine you will get further with it there. Java can not live without casts too. Just see all the container classes. So if static typing would really be so important there would be very few choices. Ada, Eiffel and modern functional programming languages. > And we see > that these "large-scale software" languages all have type > declarations. We all know the benefits of type declaration, although it > usually increases the development time. This can be said in general. If the type are automatiall inferred you do not have to bother.... > > Now, I think we have two options. First, it seems that some people > (myself included) are really interested in doing large scale software > development in Ruby. This has resulted in the discussion on "private > variables" among other things. Now, we are discussing > "overloading". This is good, This argumentation is arguable. Why should overloading be considered good? And why should it look as bad as in C++ e.g.? I prefer the Haskell approach here much more. If we talk about static typing I really would appriciate not takin the worst examples as guideline. > > The second option is we do not change Ruby too much, and we leave large > scale software development problem to the core by writing the core in C, > C++, or Java (with JRuby) and use Ruby more on the interface. Surely we > don't like to write in C/C++/Java, but from performance alone (Java may be > excluded), probably it is the right thing to do. I would think it very much depends if performance is that crucial, if it really was than it's inexplicable why people use Java and compile it down to JVM-Code. > > Finally, since people love writing in Ruby so much, probably more research > should be done on how to ultimately create a translator from Ruby to, say, > C. Even the rb2c web page > (http://easter.kuee.kyoto-u.ac.jp/~hiwada/ruby/rb2c/) states that you can > get scripts run "a little bit faster". No the right way, is making interfacing totally easy. Than write the software in Ruby, than check if it's fast enough, than improve the algorithmgs than check again if it's fast enough and than one might consider re-writing part in supposed-to-be-faster languages. Iff interfacing is as easy as wrting Ruby itself than you could easiest wrap libraries from elsewhere. Regards Friedrich