Re: The coolest thing since sliced bread

Thanks for the kind words.

For those that are historically inclined I will mention that the original
Databus was a Java implementation that went through four complete rewrites
and currently is happily running in several production GUI applications.
However, the Ruby version is an order of magnitude better (mostly because
Ruby allows it to be better).

While FreeRIDE has a long ways to go to achieve many of its goals, we are
very pleased with it so far, and its very gratifying that you (and hopefully
others) think so as well.

Curt

> -----Original Message-----
> From: Rich Kilmer [mailto:[e-mail]]
> Sent: Tuesday, December 10, 2002 9:21 PM
> To: ruby-talk ML
> Subject: Re: The coolest thing since sliced bread
>
>
> Well, having authored some of FreeRIDE I don't know
> how to respond...except...never stop refactoring.
>
> The DataBus idea evolved, it was not really designed.
> But then that supports your Organic Software Behavior.
>
> Oh...and FreeRIDE runs fast.  There are bugs, but
> there are being crushed (or evolved out...through natural
> selection ;-)
>
> We _will_ have a holiday present for the Ruby community.
> I just need to finish my proposal first (damn paying work!)
>
> Thank you for your thoughts...when I have more time I
> would like to respond more fully.
>
> -rich
>
> PS. I would agree that the described bread recipe is the
> coolest thing, and don't mind second place with competition
> like that!
>
> > -----Original Message-----
> > From: MikkelFJ [mailto:[e-mail]]
> > Sent: Tuesday, December 10, 2002 11:16 PM
> > To: ruby-talk ML
> > 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
> >
> >
> >
> >
> >
>
>
>
>