[TriLUG] Modularity: was Debian Sid/Unstable

[Steve Litt]

On Fri, 28 Feb 2014 12:48:10 -0500
Kevin Hunter Kesling <hunteke at earlham.edu> wrote:

> The whole point of what I'm getting at is
> that dynamically loaded libraries are built per application.  If a
> system piece needs to talk to another, the general wisdom is to talk
> over a clean interface.  For example, ESR talks about this in Chapter
> 1 of The Art of Unix Programming and has this as the first rule of
> Unix programming philosophy:
> 
>      1. Rule of Modularity: Write simple parts connected by clean
>         interfaces.
> 
> In the same chapter, he writes:
> 
>      Unix tradition strongly encourages writing programs that read
>      and write simple, textual, stream- oriented, device-independent
>      formats. Under classic Unix, as many programs as possible are
>      written as simple filters, which take a simple text stream on
>      input and process it into another simple text stream on output.
>      Despite popular mythology, this practice is favored not because
>      Unix programmers hate graphical user interfaces. It's because if
>      you don't write programs that accept and emit simple text
>      streams, it's much more difficult to hook the programs together.
> 
> In other words, if two server pieces are talking, they should either
> be built as a unit (in which case they would be one server piece,
> from a library standpoint), or over a well-defined interface, so that
> neither relies on the other's assumptions about their respective
> libraries.

Now this discussion is starting to get interesting!

Kevin, if I needed something coded that I couldn't code myself, I'd
hire you just based on the preceding paragraphs. 

You know who else should hire you? The guys at the KDE project. What an
intertangled abomination KDE is. Nepomuk, Akonadi, heavy use of Dbus,
every app knowing every other app's business: What could *possibly* go
wrong?

Guys like you, ESR and me are the minority. Regardless of lip service
most folks give toward modularity, most folks would accept any level of
entangled monolith if it were to present them with the slightest and
most arcane convenience.

A friend of mine named Gary Miller writes all his apps as pure back end
on the server, exposing themselves as a port and simple protocol, and a
pure display module on the front end, that interfaces with the port
using the same protocol. If he's not sure what's going on, he can
replace his GUI front end with Telnet or Openssl to see exactly what's
going on. Now THAT'S living!

On the other end of the spectrum, my favorite email client, Claws-Mail,
has a certain search that's not recursive. I figured, great, I'll fix
it. I mean, how much brainpower does it take to wrap an existing
algorithm in a loop that recurses email folders? So I downloaded the
code, and found out why nobody wanted to make it recursive. That search
algorithm was completely and inseparably interwoven with GUI code.

Speaking of Claws-Mail, KDE, and modularity, you know what I replaced
my old Kmail with? Now my desktop Dovecot server holds all emails, fed
by fetchmail into procmail, with all filtering done with .procmailrc
that dumps emails into the correct Dovecot maildir directory, with
Claws-Mail used only as a viewport to my Dovecot server and as an email
composer/sender. When anything breaks (and it almost never does), it
takes about five minutes to figure out what went wrong. If I want to
implicate or rule out Claws-Mail, I can substitute Thunderbird. And
there's no component in my system that can't be replaced easily. You
can see a block diagram of my system as the final graphic in this
article:
http://www.troubleshooters.com/lpm/201202/201202.htm#_My_New_Architecture

On a different subject, I once made a home-grown, CLI menu program
called UMENU. Then I discovered I could make a no-interface,
all-command-line-options program and, within five minutes with Vim, bolt
on a UMENU menu interface. LOL, talk about reusable code

Hey, wasn't OOP supposed to increase modularity? How's that working
out for everyone?  I really enjoy those environments where you need to
code everything as a window, even if it's doing nothing but processing
or calculation. LOL, about as much as I enjoy swimming in ice water.
And you *gotta* love those 1000 line classes that don't really seem to
represent anything conceptual, but see to exist just so it won't be
called "procedural code."

As long as I'm killing sacred cows, how bout that MVC? We all know that
it's a great way to increase modularity by separating data from business
rules from presentation, but is it just me, or does it seem that in
real life, MVC is a beach volleyball team, where every system
functionality gets repeatedly passed between Model, View and
Controller? Now where the heck did I put that code? Personally, I like
the Gary Miller method a lot better.

Back to ESR. I've been in this industry since 1984, and heard all sorts
of bullshit about software reuse and "software factories" where
programmers are like factory workers you hire for minimum wage to bolt
together "software components", but in all that time, the only truly
reusable code I ever saw was Unix commands and executables, and the
only cheap and easy software assembly from "software components" I ever
saw was bolting together Unix commands and programs with pipes, fifos,
signals, and of course, a shellscripting language like bash or cshell.

The guys who made Unix were geniuses.

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance