From: Curt Hibbs Date: 2002-12-12T04:53:18+09:00 Subject: Re: The coolest thing since sliced bread Garriss, Michael wrote: > > Ugh! Free write forces users into a new editor? I'm lost without Vim. Sounds like an opportunity to me! Some Vim lover out there (maybe, you?) could easily create a FreeRIDE plugin to implement Vim key bindings. Curt > -----Original Message----- > From: MikkelFJ [mailto:mikkelfj-anti-spam@bigfoot.com] > Sent: Tuesday, December 10, 2002 9:16 PM > To: ruby-talk@ruby-lang.org > Subject: The coolest thing since sliced bread > > > The coolest thing since sliced bread is a piece of sandwich bread which is > sliced to 1/3 of the original thickness then polished for crumbs > by rotating > the slice on a breadboard. The slice is then cut into small > triangles which > are covered by a thin layer of sugar and fried until the sugar becomes > caramel and the triangles curve. Served on home made icecream - > that's whats > I learned on telly today anyway. > > The other thing I learned today was that humans may genetically > have carried > the ability to carve tiny animals out of bone for about 50.000 > years before > actually doing so. How about software 50.000 years from now? Grep will > propably work as it ever did. Emacs, no - stop that thought. > > I meant to write that FreeRide that is the coolest thing since > sliced bread > before getting distracted by broadcast media but now it can only be the > second coolest thing since sliced bread. I was impressed with the Eclipse > plugin design. I was happy that FreeRide was build in Ruby (rather then > being an Eclipse plugin) but chose to follow some of the design principles > of Eclipse. Eclipse is large and bulky in size, yet it is also some of the > best Java GUI around partially due to the SWT GUI and partially due to the > plugin design. > > I don't yet know how FreeRide turns out, but I have followed the > project on > the sideline peeking at source code, documentation and screenshots. > My expectations are high - I have been following various software > technologies - and also experimented with different principles myself - I > have looked at many technologies. On my shortlist of technologies > are Ruby, > Fox, Scintilla, YAML, bidirectional or publish/subscribe based design, > decoupling of GUI from logic, message passing, automated testing, local > responsibility, proper dependency handling (see also SCons build > tool). The > key points here is being unbloated, efficient and in control of what is > happening. > I'm not sure about the unit-testing part of FreeRide, but then GUI testing > is non-trivial - but otherwise FreeRide is packed with what I > consider great > technologies and principles. It really shows how time spend at doing a > proper initial design pays off - at any rate an IDE this flexible in the > given timeframe and the given manpower is fairly impressive. If only a > number of known operating systems had put as much thought into the core > design, many things would be easier. I'd mention one operating sytem which > seem to have got this right though: QNX. In fact QNX uses message > passing in > its tiny core and most services are user processes connected via > a namespace > that covers the entire network. QNX scales massively and runs > happily across > many machines (it has problems such as security and hard realtime not > necessarily being good for desktops - but there you are). > Actually the pipes > of Unix was designed out of a similar vision of plugability, and they > certainly have been useful. > > On a conceptual level FreeRide demonstrates some interesting aspects of > software development: > I was never into Ruby because it was all objects - A while back I > changed my > view of software as more organic than what can be represented as > objects and > class hierachies - after all - what a thing is depends on who looks at the > thing - not the ancestor of the thing. But then I never though > Ruby was only > useful for strictly object oriented design. In fact the Array > protocol is a > key example - how many collections are derived from Array? They may use > Array and they may even Mix In Array, but they are rarely derived from > Array. > > Try pick a UML tool an document the design of FreeRide. Sure you can > describe the each class involved using object and class diagrams. > Better yet > you may capture the intialization scenario of some plugin - but how do you > capture the essence of FreeRide? > FreeRide is based on a DataBus where plugins hook up and sence > the presence > of other pieces based on patterns of connectivity that lives on > the Bus, not > in any single object. It's like Suns mantra: the network is the computer > (they got that right). I really believe this on the path of next > generation > software development (even if some of principles are age old) - > the DataBus > was designed and implemented, but could have been an integral part of a > software tool as it works at a deeper level than the actual application. > Some of the success of XML related to similar pattern based connectivity > that cannot be formulated in "simple" class relations, at least > not in a way > that readily convey the essence of the relationships. Rubys MixIn and Duck > Typing principles also follows these more organic patterns which in turn > originate from Lisp and SmallTalk as I understand. > > Now I mentioned the organic aspect - genetically a bird is designed to sit > on a branch of a tree - so why do all birds sit on electrical wires these > days? Its because a bird recognizes a certain feature set as > being a branch > useful for sitting for. If these conditions are met, the bird > could not care > less whether the branch originates from a tree of the pine-tree family or > not. Which puts us back to duck typing. If it walks like a duck and quacks > like a duck, it is a duck. > > As some may have noticed another technology on my shortlist is the > statically type language OCaml - so how does the work in an > organic setting? > This langauge basically works on graphs of pieces of data each of > which are > statically typed, but they can be recombined in endless ways - we are > essentially short-circuiting the type concept by focusing the types and > basic operations which much like a language grammar allows us to produce > these many combinations which in turn happens to be studied in real life > organisms such as tree growth (L-grammer systems as I recall). Instead of > creating a tree object we a designing branch constructing functions etc. > Thus static typing does not necessarily have anything to do with being > organic or not. A good demonstration of OCamls dynamic nature is the Lexer > module - it's just a record of six or so fields, but some of these fields > are functions that can be completely customized for example > reading buffers > by morsecode from the spacebar instead of ASCII from standard input. Lexer > is given to the parser. In a twisted version of the bird analogy, > the parser > is the bird and the lexer is the branch. The Ocaml lex/yacc > parser is among > the most flexible parsing tools around and still the only type > safe parser I > know of. Ruby really needs a Lexer module btw. Thus I'll maintain > the claim > that static typing can be organic. > > I've recently been "forced" do (D)HTML (it's called work) - and JavaScript > (ECMA / JScript) has many of the same organic aspects of both Ruby and > functional languages - it's dynamically typed and is heavy on > closures. You > can do pretty cool stuff in this otherwise fairly limited language. > > I see FreeRide as hands on example of how this kind of organic programming > paradigm works. I just hope it does not turn out to be dog slow, bulky and > buggy... In case it is not - it will be an example of dynamic > typing versus > the fairly fixed world of Java. It's not quite fair though - there's Java > Messaging and JavaSpaces but who uses that anyway? > > Whether you actually send messages as in QNX or you call functions with > context (closures) as in functional programming, or call methods > in Ruby or > SmallTalk, the essence is that whatever you call can be > dynamically replaced > thus decoupling dependecies and support plugability in ways not to be > predicted just like the birds new favority hangout - the electric wire. > FreeRide provides its own communication model via the DataBus > based on this > line organic software principles. Thus - where will FreeRide be > 50.000 years > from now? > > I'd like to introduce the term Organic Oriented Design & Programming > (OOD/OOP), but I guess it's taken so what about Organic Software Behavior > (OSB). In the end it's not about design or programming, but about how > software interacts with other software and the enviroment. > > I have to mention Ant Based Optimization: Ants are dumb, they > follow simple > rules that happen to work, or rather, they follow feromone > tracks. Turns out > to be an efficient way to solve the rather hard travelling > salesman problem. > Keywoard is localized decoupled behaviour with an appropriate > sensing input > and output. Giving up global control (such as systematic searching) gives > access to scalability and adaptability. It doesn't quite fit into the > concepts being addressed here, but it is nice to have in mind as the next > thing in software agents communicating over a bus (or over a virtual ant > trails). > > I've spend a fair bit of time thinking about and implementing various > aspects of organic software development in my spare time after having seen > the same software being developed over and over again with slightly > different names in yet another collection class. > I'm both embarrassed that FreeRide jumps in and does it fairly simple in > Ruby and thrilled that the concept seems to be workable in practice > (although it's not exactly what I'm looking into). I'd love to be part of > FreeRide but then I'm in over my head with my own projects and work. > > I hope FreeRide works out really well and perhaps I may also one day use > FreeRide for developing in other languages - I'm already using Scite for > most development as long as I'm not debugging. > > > > Mikkel > > > >