From: Friedrich Dominicus Date: 2002-09-12T15:39:37+09:00 Subject: Re: Larry Wall's comments on Ruby matz@ruby-lang.org (Yukihiro Matsumoto) writes: Sorry for TOFU, but I send the reply to matz via mail. I'm sorry for bothering you with that mail. Here's the correct place for the reply > Hi, > > In message "Re: Larry Wall's comments on Ruby" > on 02/09/11, Friedrich Dominicus writes: > > |> Multi-method is kinda like multiple inheritance. It is *natural* > |> extension of the original concept. It is theoretically clean. But it > |> is easy to make thing too complex with them. Only smart people can > |> use their full power. If you see no problem, it's because you're > |> smarter than me. ;-) > | > |Sorry I do not like this smarter than anyone else stuff. even with a > |;-) You do not have to use multiple inheritance if you do not like > |it. You do not have to use Multimethods if you don't like it. And you > |can avoid using a lot of other thing if you do not like them. > | > |But it's your (the programmers) choice. If the langauge does not offer > |those facilities you simply do not have a choice. > > I'm sorry if you are bothered by my "smarter than" stuff. It was only > a parable. But it has too important issue to ignore. I understand, I probably have to explain the answer a bit. I recognice too that there are smarter people than others. But having a smart tag just with one feature in a languages is definitly wrong. I would argue that all who have developed a language are on there special way smart. Language design is one of those areas where engineering ideas come into play. A language designer must be fully aware of himself and he must have an excellent understanding on what he likes or dislikes. One of the design ideas in Ruby seems to be heavily influenced by Smalltalk, treating all things as objects. That is a major decision. It means you can not accept that some types are special. The speciality must be hideen behind an OO facade. That limits further decisions and gives the direction. I guess you've written down what you wanted to achieve with Ruby but I do not know it well enough. But I do think that you have looked at different languages. How they present themselves to the user. And than you have decided what you want. That is engineering. Checking alternatives, knowing ones goal and than decide what should be forced what should be forgotten. > > There's two major opposite attitude in designing and criticizing > languages (and perhaps other thing too). They are minimalism and > maximalism. In a word, it's fight against alternatives. One wants as > less alternatives as possible. Other wants opposite. For example, > people who hate "unless" in Ruby are minimalist. And people who want > as many choice as possible are maximalist. Well we have seen the "fight" just from the beginning with FORTRAN and LISP. > > And I believe a good language design lies somewhere between these two > extreme spectrum. Because "ordinary people" often feel uncomfortable > in extreme situation. We don't use the simplest language ever > (machine instruction) anymore. We don't use the most complex language > either (Ada? PL/I? whatever). It's the matter of balance. I agree, but I don't think Assembler is a good example for a simply language. I'll tell you why I think so. Assembler programmer must know extremly much about different memory access models. This is complex. Therefor I don't think Assembler can be a simple language. The other thing which makes it complex that you must do it all by hand, you have to know exactly how the processor at hand works, and you must know that types there are and this book-keeping has to be done by you. Therefor Assembler is not easy, as describe here C or Pascal are easy. (and a bunch of others too) > Again, it's the matter of balance. I agree. And the bounds are sliding. Regards Friedrich