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

[Laurent Julliard]

On Wed, 2002-12-11 at 05:55, Rich Kilmer wrote:
> This was posted on RubyTalk...I almost don't know how to respond ;-)
> 

One could say it's even a bit embarassing ;-)

BTW, I think there are a lots of good ideas in this message. My belief
is that another revolution should take place in the software. The way we
develop software today is the bottleneck in the innovation process.

Laurent


> -----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
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Freeride-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/freeride-devel
-- 
Laurent Julliard <address@hidden>
A la maison / At home