[FoRK] ravioli code

damien morton dmorton at bitfurnace.com
Sun Nov 16 05:13:01 PST 2008


This must be why software engineers are so strongly represented amongst
pastafarians

On Sun, Nov 16, 2008 at 4:46 PM, <owen at permafrost.net> wrote:

> Fork is the second hit for "ravioli code"
> http://www.xent.com/FoRK-archive/spring97/0091.html
>
> "The ideal software structure is one having components that are small and
> loosely coupled; this ideal structure is called ravioli code. In
> ravioli code, each of the components, or objects, is a package
> containing some meat or other nourishment for the system; any component
> can be modified or replaced without significantly affecting other
> components."
>
> Owen
>
>
> On Sat, Nov 15, 2008 at 08:33:33PM -0800, Stephen Williams wrote:
> > damien morton wrote:
> > >I learned a new phrase today. "Ravioli Code".
> > >
> > >>From Richard Carlson, developer of "parametrised modules" for erlang, a
> > >kind
> > >of object oriented programming facility:
> > >
> > >
> > >In the Object Oriented Programming world, "ravioli code"
> > >is what you get when you have factored your program into
> > >too many small chunks of code, so that it becomes impossible
> > >to keep track of where the actual work is being done.
> > >
> > I have always disliked this.  Having too many classes in Java is a
> > similar issue.  You just don't need extreme modularity everywhere all
> > the time.
> >
> > I like to see the code without jumping through 20 files...
> >
> > sdw
> > >(It's "all in the sauce", which of course is hard to get a good
> > >grip of.) With abstract modules, these kinds of programs become
> > >possible also in Erlang. In the worst case, a program
> > >could start with instantiating hundreds of abstract modules,
> > >nally creating an "application" module instance M and calling
> > >M:start/0, and it could then take weeks to understand
> > >(even for the original author) which parts of the code are
> > >actually being called, from where, and at what time.
> > >This kind of overuse of parameterizing modules should be
> > >avoided. The strategy to be used mainly depends on the
> > >programming problem: some problems map easily onto a
> > >set of functions without any real need for parameterizing
> > >the module itself { in those cases, the temptation to create
> > >an abstract module should be resisted. In other cases, parameterizing
> > >the module solves the problem in a very elegant
> > >manner. Use abstraction with discretion.
> > >_______________________________________________
> > >FoRK mailing list
> > >http://xent.com/mailman/listinfo/fork
> > >
> >
> >
> >
> > _______________________________________________
> > FoRK mailing list
> > http://xent.com/mailman/listinfo/fork
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork
>


More information about the FoRK mailing list