Re: The coolest thing since sliced bread

Hmm.....

-----Original Message-----
From: Curt Hibbs [mailto:[e-mail]]
Sent: Wednesday, December 11, 2002 12:53 PM
To: [e-mail]
Subject: Re: The coolest thing since sliced bread


Garriss, Michael wrote:
>
> Ugh!  Free write forces users into a new editor?  I'm lost without Vim.

Sounds like an opportunity to me!

Some Vim lover out there (maybe, you?) could easily create a FreeRIDE plugin
to implement Vim key bindings.

Curt

> -----Original Message-----
> From: MikkelFJ [mailto:[e-mail]]
> Sent: Tuesday, December 10, 2002 9:16 PM
> To: [e-mail]
> 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
>
>
>
>