On Nov 14, 2011, at 8:15 AM, Jean-Denis MUYS wrote: > The workflow loop would then become: > > 1- test some app action > 2- notice a bug. Don't quit. Switch to Xcode. > 3- change the relevant Ruby file > 4- save > 5- there is no step 5 > > I can't see any reason why this would not possible, and even easy, Ruby > newbie as I may be. To me, this is the major MacRuby promise, and that > promise is not kept yet. > > Am I out of my mind?
I don't think you're out of your mind at all, and in fact this was the source of many "spirited discussions" that Laurent and I had about MacRuby and where it might someday go. I have always felt that MacRuby's true potential was hidden behind the homogenizing IDE that is Xcode, just as the Eclipse IDE hides a fair amount of the power of Java in its attempt to create something more Visual-studio-like. I think a static IDE is a fine tool for big, honkin' projects that are written in compiled languages like C or Fortran, in other words, but I think it somewhat lobotomizes the notion of truly interactive design and development as a consequence of focusing more on the project management side of things than promoting a REPL and introspective design style. For examples of the latter, we need to go back to the Smalltalk workbench or the early LISP Machines, where everything from the "OS" to the highest layers of the system were easily introspected, recomposed into new code, and so on. I harped on this so much, in fact, that Laurent recently sent me a link to this app; I'll admit that I have yet to purchase it, and I don't know how much it truly exemplifies the "graphical workspace" ideas that Laurent and I tossed around. Just looking at the video, I have to suspect "not much", but it's certainly more aligned in that direction than Xcode. The idea of having your code "drawn on the back" of the windows created to run that code is kind of clever, and where I don't think it goes far enough is in the direction of having "software ICs" drawn on a screen with the ability to randomly string them together with the programming environment being clever enough to let you know visually when software lego block A does not fit with software lego block B, or being able to see your code as a set of graphical relationships with literal black boxes hiding the implementation details until you tap on them. In short, I think chasing Xcode compatibility is a classic case of doing the obvious thing vs doing the most inspired thing. Ruby isn't C, or any other static language, it's both a language and an environment, and yet everyone seems to be focused rather myopically on the former attribute to the detriment of the latter. Sigh! :) - Jordan
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
