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
