A rejection of the rejection of 70s tech aesthetic

[Henri Bergius]

Hi,

Many of you may enjoy this:
http://www.storytotell.org/essays/74-response.html

As I mentioned in my Wakanday NoFlo talk, FBP is one of these good ideas from the 70s that are due to be resurrected.

/Henri

[Ged Byrne]

Henrick,

Interesting.

I tried to express this same idea in a lightning talk I gave last year I gave called "Steam Punk Programming" ( http://skillsmatter.com/podcast/home/steam-punk-programming, not FBP specific but only 7 minutes long).

We're drowning in complexity.  It all needs to be stripped away so that we can find simplicity and elegance.

Regards, 

Ged

[Paul Morrison]

Yup, both of these posts are spot on!  Thanks for posting these.

I had bought in to the idea that, if you build a better mousetrap, the world will beat a path to your door (who said that?), so I couldn't understand why FBP was taking so long to take off!  Then I read Kuhn's http://en.wikipedia.org/wiki/The_Structure_of_Scientific_Revolutions , and things became a lot clearer!  Sometimes the previous generation has to actually die off before accepted ideas can be jettisoned and new directions adopted...

A small anecdote: in the very early days of FBP (1968 or 1969) I came across a related approach  buried deep inside an IBM access method called QTAM (Queued Teleprocessing Access Method) where nobody could see it without reading the internals documentation!  And that probably went back a further 5 years or so - and remember in those days documentation was paper, or sometimes microfiche,  so you couldn't just post an idea on the Internet and get instant responses!

--
http://jpaulmorrison.blogspot.com/

[Ged Byrne]

Paul,

What are your thoughts on Christensen's "Disruptive Innovation":

" A disruptive technology or disruptive innovation is an innovation that helps create a new market and value network, and eventually goes on to disrupt an existing market and value network (over a few years or decades), displacing an earlier technology. The term is used in business and technology literature to describe innovations that improve a product or service in ways that the market does not expect, typically first by designing for a different set of consumers in the new market and later by lowering prices in the existing market. "

https://mail.google.com/mail/u/0/?shva=1#inbox/135ce15b654d5ef9

Do you see FPB as being disruptive?  It's key benefit is that it lowers the price of understanding software where the price is in terms of specialised knowledge required.  I believe that this is the scenario you describe in the opening of the book.

If that is the case then it is not in the interests the current practitioner to adopt FBP.  Developers want to be craftsmen so it is not in their interest to embrace the "Software Industrial Revolution" that Cox spoke of.  While it will enrich society, it will lower the wage of the programmer.

If FBP is to take off it will have to be made accessible outside the walls of software development.  It will have to be packaged in a way that will make it accessible to those who do not consider themselves programmers.

Regards, 

Ged

[Paul Morrison]

Hi Ged,

Interesting term!  I gave some examples in my book where we used FBP to encapsulate specialized knowledge, so I agree it lowers the need for specialized knowledge on the part of application developers in general.  Lowering the price of understanding software and improving the maintainability of applications should provide a huge overall benefit to the companies using FBP, so you seem to be asking where the resistance is coming from...   I may be too close to it to comment, but I do remember a programmer telling me (in the 70s, I think) that he didn't hold with structured programming :-(

My feeling is that programmers with specialized knowledge tend to like being able to encapsulate this knowledge in reusable components - one programmer in our shop certainly did, and documented his feelings in writing!  Then there are the programmers like Rej, mentioned in the Introduction, whose motivation is to satisfy his/her customers with reliable code, preferably using as little programming effort as will suffice to get a quality job done.   I also think there is a role in the new (!) FBP world for craftsmen - but by this I mean people who subscribe to the idea of beauty or elegance (either consciously or unconsciously) in their work - as I said in my book, they can be the ones producing (beautiful) components.   So are there programmers out there who would rather produce a spaghetti tangle of code, so that they are assured of job security (they hope)?  I don't know, but I hope they are relatively few, and further that companies realize that such people are more liabilities than assets!

--
http://jpaulmorrison.blogspot.com/

[Paul Morrison]

Re elegance, there seem to be some interesting ideas here:
http://web.eecs.utk.edu/~mclennan/papers/Elegance.html

Comments?

[Ged Byrne]

Paul,

Thanks for that I like it a lot.  It gives the definition of Elegance that I think we are aiming for.

The question is, can the programmer be a craftsman using OO (or Structured)?  I don't believe they can.

The Software Craftsmanship is working hard to achieve this goal: http://manifesto.softwarecraftsmanship.org/main

I'm a great support of Software Craftsmanship.  I signed up to the manifesto and I regularly attend meeting here in london.

I believe it's principles to be necessary, essential even.

However, I do not think they are sufficient.

Let me explain.  One of the founders of Software Craftsmanship is Robert C Martin: http://en.wikipedia.org/wiki/Robert_Cecil_Martin

Is "Uncle Bob" able to build software guided by a sense of asthetic?  Apparently not:

If you look inside of FitNesse, you’ll find that there are lots of structures and decisions that don’t seem to make a lot of sense at first reading. There are complexities and abstractions that will leave you shaking your head.

For example. We generate all our HTML in code. Yes, you read that correctly. We write Java code that constructsHTML. And yes, that means we are slinging angle brackets around.

To be fair, we’ve managed to move most of the angle bracket slingers into a single module that hides the HTMLconstruction behind an abstraction barrier. This helps a lot, but cripe who would sling angle brackets when template system are so prevalent? I hope nobody. But FitNesse was not conceived at a time when template systems made sense (at least to us).

Fear not, I am working through the Fitnesse code replacing the HTML generation with Velocity templates. It’ll take some time, but I’ll get it done. The point is, that just like every other software system you’ve seen, FitNesse is a collection of historical compromises. The architecture shows the scars of many decisions that have since had to be reversed or deeply modified.

https://sites.google.com/site/unclebobconsultingllc/clean-code-and-battle-scarred-architecture

Since it is not possible to follow a sense of the asthetic instead the work to improve the code has to be guided by calculations based on a mathematical model:

CRAP is a metric that is applied to each function in the system. The formula for CRAP is: CRAP = comp(f)^2. X (1 – cov(f)/100)^3. + comp(f)

Where comp(f) = the cyclomatic complexity of the function f. and cov(f) = the unit test coverage of function f.

So a function’s CRAP will be small iff the cyclomatic complexity is low and the test coverage is high. CRAP will behuge if cyclomatic complexity is high, and there is no coverage.

What does this have to do with architecture? Read on…

I work very hard to keep the ratio of crappy methods near .1%. Of the 5643 methods in FitNesse, only 6 are crappy, and five of those I have no control over.

ibid

In the "Who Cares About Elegance?" article Bruce J. MacLennan claims that an analytical approach like this will be insufficient to achieve elegance:

One reason is that mathematical analysis is always incomplete. The engineer must make a decision about which variables are significant and which are not, and an analysis may lead to incorrect conclusions if this decision is not made well. Also, equations are often simplified (e.g., made linear) to make their analysis feasible, and this is another potential source of error. Because of these limitations, engineers that depend on mathematical analysis may overdesign a structure to compensate for unforeseen effects left out of the analysis. Thus the price of safety is additional material and increased cost (i.e. decreased efficiency and economy).

http://web.eecs.utk.edu/~mclennan/papers/Elegance.html#designer

Does the experience of FitNesse bare this to be true?  

Yes it does.  As quoted above the code is "a collection of historical compromises. The architecture shows the scars of many decisions that have since had to be reversed or deeply modified."  The conslusion:

That scarring makes the system hard to understand. It complicates the job of adding features and fixing bugs. It decreases the effectiveness of the developers who work on FitNesse. And though I work hard to massage the scars and bandage the wounds, the war goes on.

But I can keep the CRAP out! I can keep the code so clean and simple at the micro level, that the poor folks who try to make sense out of the macro scale aren’t impeded by huge deeply nested functions that aren’t tested!

https://sites.google.com/site/unclebobconsultingllc/clean-code-and-battle-scarred-architecture

"Uncle Bob" believes that the solution lies in better maths: A calculus for software

I disagree, and I suspect others here do as well.  The solution for software is the same solution as it is for engineering, as Billington explains through MacLennan:

expert designers restrict their attention to designs in which the interaction of the forces is easy to see. The design looks unbalanced if the forces are unbalanced, and the design looks stable if it is stable.

The general principle is that designs that look good will also be good, and therefore the design process can be guided by aesthetics without extensive (but incomplete) mathematical analysis. Billington expresses this idea by inverting the old architectural maxim and asserting that, in structural design, function follows form. He adds (p. 21), ``When the form is well chosen, its analysis becomes astoundingly simple.'' In other words, the choice of form is open and free, so we should pick forms where elegant design expresses good design (i.e. efficient and economical design). If we do so, then we can let aesthetics guide design.

The same applies to programming language design. By restricting our attention to designs in which the interaction of features is manifest - in which good interactions look good, and bad interactions look bad - we can let our aesthetic sense guide our design and we can be much more confident that we have a good design, without having to check all the possible interactions.

http://web.eecs.utk.edu/~mclennan/papers/Elegance.html#designer

Being guided by our aesthetic senses requires us to be guided by our senses: principally sight.  The key to ensure elegance in design is making the structure of the code visible.  That is what FBP does.  More importantly it visualises the right thing: flow, not structure.

However, it is hard to help others see this.  They are invested in an approach.  They believe that the key to maintainable software is code coverage, not aesthetic elegance.  It is almost impossible to change their minds: http://www.farnamstreetblog.com/2012/02/status-quo-bias-in-decision-making/

If you cannot convince the current generation of practitioners then what can you do?  One approach is to wait for the next generation.

An alternative approach is to introduce programming to a whole mass of people who are not yet practitioners.  I believe that the visual nature of FBP and the simple elegance is enables opens up programming to people who cannot get to grips with traditional programming - just as the WIMP UI made desktops accessible to a wider audience who could not get to grips with the command line.

The WIMP UI did not replace the command line, there are probably more Unix users now than there ever where.  They are, however, a tiny minority compared to Windows users.

Regards, 

Ged

[Paul Morrison]

On 01/03/2012 4:08 PM, Ged Byrne wrote:
> An alternative approach is to introduce programming to a whole mass of
> people who are not yet practitioners. I believe that the visual
> nature of FBP and the simple elegance is enables opens up programming
> to people who cannot get to grips with traditional programming - just
> as the WIMP UI made desktops accessible to a wider audience who could
> not get to grips with the command line.

I agree! I think I said somewhere that the people who adapt best to FBP
are a) people who are brand new, or b) who have been around long enough
to get disenchanted with the conventional ways of doing things, or c)
who are outside programming altogether, as you say. It has also been
said that we are most strongly affected by the first language we
learn... so catch them young! E.g. Logo, Scratch, etc. In my own
case, my first machines weren't even computers - they were "unit record"
( http://en.wikipedia.org/wiki/Unit_record_equipment ), which was, as I
say in the book, a dataflow approach...

[Ged Byrne]

Is that where the expression "unit testing" comes from?

On 1 March 2012 23:42, Paul Morrison <paul.m...@rogers.com> wrote:

[...] In my own case, my first machines weren't even computers - they were "unit record" ( http://en.wikipedia.org/wiki/Unit_record_equipment ), which was, as I say in the book, a dataflow approach...

[Paul Morrison]

Ummm, no!  See  http://en.wikipedia.org/wiki/Unit_test .   BTW that's another nice feature of FBP - that you really can unit test, by building a simple scaffolding around a component.  Also you can stick some kind of display component on a connection, and see what is going across it.  In my book, I talk about centre-out development, in addition to top-down and bottom-up :-)

[Forrest Oliphant]

FBP has been alive and well in the form of Quartz Composer (visuals), Pure Data and Max/MSP (audio), and texture/lighting tools in various 3D packages. Working with these inspired my meemoo.org project.

I haven't gotten my hands on Paul's FBP book yet, does he cover these?

- Forrest

[Paul Morrison]

Well, I wouldn't say "cover" - mention, yes, at least for Max/MSP and Pure Data - in a section of Chap. 27 , which has been added in the 2nd edition, under the heading Music and Art Department...  I missed Quartz, though!  I call this chapter "The FBP Explosion", as there has been a veritable explosion of FBP-derived and FBP-similar projects over the last 15 years or so, and I'm sure I missed some important ones...

BTW, Forrest, I assume you know that the 2nd edition is available in ebook format: Kindle from Amazon and epub from Lulu.  Cheaper, and downloading takes seconds :-)  Just a suggestion!

--
http://jpaulmorrison.blogspot.com/

[Paul Morrison]

Ged Byrne wrote:
>
> If FBP is to take off it will have to be made accessible outside the
walls
> of software development. It will have to be packaged in a way that will
> make it accessible to those who do not consider themselves programmers.
>

That's why I mentioned Scratch ( http://scratch.mit.edu/ ), pointed out
to me by Bob Corrick, in an earlier post. Scratch looks promising, as
Logo did a generation earlier, if we can add some kind of fixed
capacity connections to it... On a more general level, there is an
interesting article in the latest American Scientist on what makes Angry
Birds so successful - and how Rovio is building on it. Hint: it lets
grandparents and grandchildren bond over a computer game :-)

Lets have some more discussion!

[Sam Watkins]

> what makes Angry Birds so successful - and how Rovio is building on
> it. Hint: it lets grandparents and grandchildren bond over a
> computer game :-)

You can play it with one hand on the bus, silly sound effects,
'3 star' challenge, and almost anyone at any age can pass
the early levels -> win.

To mention something more on-topic, I did some work on a web graph
editor using Raphael JS vector library (http://raphaeljs.com/).

I shouldn't link to this at such an early stage, but thought a post
just about Angry Birds would be a bit light!

http://sam.nipl.net/code/amps-js/test.html

I'm only just getting started! Can only move nodes and the page around.
Aiming for smooth zoom / rotate soon, then I can do the arcs.

Raphael JS is really a brilliant little library.

I should especially say thanks for lib Cairo (chi-rho / Xr), used in
both mozilla and webkit/chrome now, and most everywhere else.
I hope to write a version of my editor in C, using Cairo API directly.

Sam

[Adrian Heilbut]

WireIt also seems like quite a nice framework (on top of html canvas
and YUI) for building a web-based graph editor:
http://neyric.github.com/wireit/

Adrian

[Vladimir Sibirov]

Thanks for the link, Adrian! Now I finally see what is used in Pypes (http://pypes.org) to edit FBP graphs.

2012/3/22 Adrian Heilbut <ahei...@gmail.com>