From: "Pete McBreen, McBreen.Consulting" Date: 2000-12-14T01:40:02+09:00 Subject: [ruby-talk:7157] Re: Ruby in Ruby John Carter wrote in message ... >The point of ruby in ruby is less compilation, but more reflection. >http://www.tunes.org/Review/Reflection.html has a lot to say on the >subject. > >Ben Tilly's point about multiple front ends is correct. Once you remove >the idea that text is the language and replace it with an "Object Tree" is >the language, the gates are open to a large number of strange thoughts. > >What about graphical representations of a program? Reverse engineering the >UML diagrams becomes much easier. > >Why not program in Asian pictographs instead of western ASCII? I agree that it is possible to have multiple front ends, but this has the unfortunate effect of reducing the size of the community. Having once had the fortune of maintaining some German COBOL (where all of the COBOL keywords had been translated into German), it was a really difficult job. It was also a pain having to make sure to invoke the right compiler, sure the linker didn't care, but there was very little sharing between the different applications because of the hassles. Multiple presentations of the source are of course possible, but I'd prefer to keep the underlying source untouched. TogetherJ does a good job at this in the Java world, combining UML diagrams and a source editor in one tool. The few blind programmers I've known seem to have got on OK with hardware that read out what was on the screen and braille keyboard (this was back in the early 1980's on a PL/1 project). Sure, the move to GUI technology has made it harder for blind programmers, but the key thing is we need a common represnetation that everyone can use/read in order for a programming community to grow. As soon as there are dialects, we get a breaking apart of the community. Back in the 1980's DEC did a really good job with all of the programming languages for VMS, pick any language COBOL, C, Pascal, Macro, Bliss, Fortran, Datatrieve etc... all could call functions/routines written in any other language. Even though this capability existed, I saw very little evidence that there was much sharing between projects using different languages. Yes, it was possible, and the debugger would recognize the language appropriately as you stepped into a routine, but to be effective _a developer had to know all of the languages_ and that took a long time and was hard work. >The thing here is ruby is 90% of the way to Tune's ideal. It has the node >structure, one step more makes it reflective. It is pure OOPS already. Why is it that whenever a developer sees a new language they want to add their favorite features into that language? Not having developed an application using Ruby yet I'm not really qualified to comment but as I see it Ruby - the language - doesn't really need much more work. Maybe the current implementation of Ruby on the various platforms might need some fine tuning and fixing, but it seems like it is workable as-is. Agreed there is a lot of work still to be done to suppliment the RAA, maybe that is where we should focus our attention. Part of the attraction of Ruby (for me at least) is that it is a relatively simple language with few surprises. I'd hate for Ruby to evolve into a really large complex beast that is hard to get to grips with - Java 1.3 anyone?;-) Sure Matz could add lots more really cool features, but I'd suggest that for every cool feature that is added two other cool features have to be removed. I value simplicity. Pete ---- Pete McBreen, McBreen.Consulting , Cochrane, AB email: petemcbreen@acm.org http://www.mcbreen.ab.ca/ Software development is meant to be fun, if it isn't the process is wrong