From: Christian Date: 2001-01-20T21:42:48+09:00 Subject: [ruby-talk:9598] Re: 101 Misconceptions About Dynamic Languages I've really backed myself into a corner here. Witness my Houdini act. "Ben Tilly" wrote: > [the assertion that Ruby does not support first-class functions] is patently false. Nods. > See class Continuation. Or the callcc function in the > kernel. You can call it with its call method. I understand that now. It is patently obvious that I am regurgitating unlearned knowledge. I am interested in class Continuation, and will read up. > I think that there is probably more to Ruby than you > currently think. Now to throw fat on your C++ > discussion, a friend who used to love C++ and then grew > to detest it summarized his beefs with the language > somewhat like this: > > If you have a God's eye view of the problem, then > you can construct breathtaking solutions in C++. > When you don't then it is easy to go very wrong > very fast. True enough on both counts -- there is more to Ruby than I currently understantand, and C++ can be 'dangerous'. Witness witless abuse of operator overloading, and ridiculous use of class hierarchies and virtual functions. Then again, one must be optimistic. As Bjarne says, "Don't remove a feature just because it /may/ be misued". As your friend infers, C++ provides the possibility of a path (solution) that efficiently solves problems. Now, it is true that the flexibility provided by C++ (even I am getting tired of this) also leaves a door open to misadventure and pain. But, to quote Rage Against the Machine, "if ignorance is bliss / then slap the smile off my face". I'm a big boy now, I can look after myself. Garbage collection? Who tells me when to delete something? I can specify that myself, implicitly (smart pointers) or explicitly (delete). Removing the option reduces the scope of my solutions. Of course, it also allows "delete this". It is clear that there are horses for courses -- GC is a problem that may not be an issue in your soluion. I wouldn't be here, being an argumentative prat, if I didn't, deep-down, recognise the need for and importance of simpler methodologies and systems. Perhaps a nail /is/ just a nail, afterall. However, one must be careful not to judge a language by it's common use -- just because Ruby is interpreted doesnt mean that it is a toy, and just because C++ is compiled doesnt mean that it cant be used to prototype. > Now perhaps you are in a specialized industry. But > most of the rest of us don't actually get much of a > chance for that God's eye view of the problem. Although it would be flattering to think so, I cannot believe that a "Gods eye view" is special to either game development or myself. It is exactly the attitude that languages like Ruby make anything fundamentally 'easier' that fires me up to write posts like those I made previously. Ruby is Just Another Language. If it has value, that value is contained within a set of new concepts and their interaction (which is in itself expressible conceptually). I'd like to extract that information, and use it in different contexts. I've already gained a lot of new information (regarding Ruby and not) just by being involved in this (off-topic, apologies) thread. We must pay homage to Godel and recognise that there is no one single solution or framework that is both completely general and completely self-consistent. I am interested in Ruby not because it makes things easier, or because it is a sandbox, or because it is 'dynamic' or 'interpreted'. I am interested in it because it is it's own world, and I must continuously learn from different approaches and concepts, or stagnate. Important question: What concepts are unique to Ruby? I am not interested in sugar -- I want substance. Perhaps the substance is the language as a whole, including the developmental process it encourages. But surely there is more. Or not. That's what I came here to find out. Arrogant? Sure. Stupid? No. When I see people asking mundane questions (how to read a file into a string, how to interface to GTK, etc), I wonder. Why bother? This isn't solving problems, its just asking the same questions in a different way. The problem exists irrespective of the solution. To quote Bradd Pitt in Fight Club, "I'm starting to wonder if another woman is really what we need". We aren't addressing problems, we are addressing the questions. Pardon the French, but fuck the questions, solve problems. Translating a problem to another space doesn't solve the problem, it simply renames it. Conversely, Fermat's Last Theorem wasn't solved until the problem was placed in a new and different space. If I sound confused it is because I am. > Instead we have constantly changing specs, legacy > code, and things adapted to do stuff they were never > intended for. Excepting legacy code, that is my world. Imagine designing graphics/networking systems for modern games in the current PC market . Imagine when your 'client' is a game designer that has only a passing knowledge of programming, and even they don't (can't) know what they want. An obvious (partial) solution is an interpreted scripting system. I've written a few, with varying degrees of success (measured by practicality, not just elegance). Hence my presence. > Ruby is designed to be usable by mere mortals like us. I would almost resent that, except for the fact that I am merely mortal as well. > Cheers, > Ben Christian.