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

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 :wink:

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:mikkelfj-anti-spam@bigfoot.com]
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

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:rich@infoether.com]
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 :wink:

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:mikkelfj-anti-spam@bigfoot.com]
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