[FR-devel] FW: The coolest thing since sliced bread

[Rich Kilmer]

This was posted on RubyTalk...I almost don't know how to respond ;-)

-----Original Message-----
From: MikkelFJ [mailto:address@hidden 
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