Whither actual generality/customizability/flexibility?

I have yet to come across The Answer to being able to really truly do the Open-Closed principle. "I'm sorry, Zaphod, I just don't believe a word of it." Be it OO or FP or whatever, in my experience when a new functionality / requirement / realization comes along, there's nothing that can be done to prevent some inevitable need to crack open the bloody code and have at it.

Random example: Inheritance.

We have all experienced trying to plan ahead for change. Inevitably, when change comes, it is not the change we anticipated. We find that we have paid the price of generality and forward planning, but still have to modify the software to adapt to the change in requirements. Agile methodologies use this: they tell us to eschew generality, and instead make the software ready to embrace change by being changeable. Inheritance aids in this process by allowing us to write software in terms of the concrete, specific actions that the application needs now, and to abstract over them only when we know - because the change request is in our hands - that the abstraction is needed.

Except for how I haven't seen inheritance ever done right, such that there really isn't long term peril and sturm und drang that is going to come along with it, ball and chain style.

If you had to force rank the various ways people have tried to support something like Open-Closed, what would your list look like?

Open-closed

I don't believe in complicated solutions to basic problems. Imho there's only one way to be truly 'open to extension and closed to modification', namely the way mathematics does it: by having no implementation at all. As soon as you have something implemented, there is the potential for it to be the wrong manner of implementation for some circumstances; and the only way to get away from the wrongness is to give up that implementation. I just don't buy that some clever way of factoring things (some form of OO inheritance, say) can avoid that; the most it can do is obfuscate things enough to make it hard to say why things aren't going as smoothly as we want them to.

By John Shutt at Wed, 2016-02-24 01:25 | login or register to post comments

Mathematics doesn't avoid the problem

I think I might see what you're talking about, when you say "mathematics". You seem to claim that, if you have just a specification, that will be stable. I agree it can sometimes be an improvement, but I don't think that specifications are stable — see specification bugs.

Also, the way mathematics avoid the problem is by either never extending systems, or by rewriting them with each change.

For instance, IIUC, to solve *ONE* (huge) conjecture, Grothendieck rewrote a couple of mathematical disciplines using category theory (and inventing half of category theory and topos theory on the way).

More concretely, try evolving a system and a proof for it, when you *ACTUALLY* write a proof that has to hold. Or read Chlipala talking about it throughout its book.
http://adam.chlipala.net/cpdt/html/Cpdt.Intro.html

I don't expect all of these "facts" to be new to you, but I'm not sure how to reconcile these facts with your claims.

By Blaisorblade at Sat, 2016-02-27 02:22 | login or register to post comments

I suspect you're

I suspect you're overthinking it. It's been my experience of mathematics — independent of programming, say for example groups rings and fields — that it has perfect abstraction, with no inherent breakdown when going from the specific to the general nor from the general to the specific. If you did the same thing in programming you'd be dragged down by the implementation.

(Seems to me rewriting a couple of mathematical disciplines using category theory illustrates the point; it doesn't do any harm at all to the existing material.)

By John Shutt at Sat, 2016-02-27 03:59 | login or register to post comments

perfect abstraction

I guess your experience of mathematics is too limited. Alternate axiomatisations raise their ugly heads early. Later with rings, the abstractions are of less interest than finding representations.

As soon as you admit that modelling with representations is the game you're encoding .. er .. that is .. programming. And then the superficially clean and pure edifice collapses when you realise even the simple systems you used to think were pure are just representations.

In fact good representations admit pleasing theorems which is just another way of spelling optimisation.

By skaller at Sun, 2016-03-06 14:17 | login or register to post comments

miscue

I guess your experience of mathematics is too limited.

That you gathered that misimpression shows I'm not conveying my point successfully. I have, in the past, specifically cited the ubiquity of alternative axiomatizations as prime evidence for my point, so clearly there's a communications disconnect going on. The disconnect is of great interest to me, since this is a key element of my approach, though I'm not even sure yet quite how to go about identifying the nature of the disconnect.

By John Shutt at Sun, 2016-03-06 14:59 | login or register to post comments

Except you usually DO know

You usually do know what extensions you might one day make to your software, you usually DO know which part of your code is essential and which is implementation details.

You're not right 100% of the time, but using OO and being right 60% of the time is still a win, right?

I think it's an academic presumption to reject the good in search of impossible perfection. OO lets you organize your code into public and private apis. It's really another way of making small modules with a few other advantages.

Software engineering in organizations is horribly hard and probably mismanaged anyway. And the mismangement is probably obvious stuff. When managers are against documenting code because it takes too long, or against ever cleaning it up this isn't because schools aren't teaching good practice, it's because managers are stupid, shortsighted and it isn't safe to tell them the truth.

That's not a software engineering problem.

So yeah, your projects will go wrong in the real world, but that doesn't mean that we don't know good enough methods for designing software.

By Josh Scholar at Wed, 2016-02-24 02:04 | login or register to post comments

Basic research

I think it's an academic presumption to reject the good in search of impossible perfection.

That's an illusion. (Warranty does not cover misjudgements by individual researchers.) Somebody, frankly, has to be doing basic research, and academia plays a big role in that. Basic research calls for asking questions relentlessly, including how to improve anything that isn't already perfect (keeping in mind that perfection is unattainable). Properly, this isn't rejection of existing solutions, just restlessness necessary to basic research.

By John Shutt at Wed, 2016-02-24 02:34 | login or register to post comments

Generalisability

I think you start with specific code for a single function, over time and writing lots of similar code in a given domain the sensible abstractions will become apparent. You don't write an API for a problem domain you do not understand.

Fortunately a lot of work has been done on understanding the foundational patterns of mathematics (semi-groups, groups, rings, monoids etc.) and on foundational computing like containers, (single pass forward iterators, repeatable forward iterators, bidirectional iterators, indexed iterators, random access iterators, and multi-dimensional iterators like the bifurcating iterator for binary trees etc).

I would recommend reading Stepanov's "Elements of Programming".

By Keean Schupke at Wed, 2016-02-24 07:21 | login or register to post comments

yes but no

While I do sincerely appreciate all those things in and of themselves, nevertheless I am sad to say that my experience has been that I fail to find most of the stuff that supposedly addresses 'the issues' to ever really stand up in the face of (a) anything with a UI or (b) the median programmer. :-|

By raould at Wed, 2016-02-24 19:33 | login or register to post comments

Adam an Eve

Adobe's Adam and Eve were the results of applying Stepanov's techniques to UI programming in C++. http://stlab.adobe.com/asl_foreword.html
Sean Parent has done a lot of stuff actually applying the kind of generic programming talked about in "Elements of Programming".
See also https://github.com/sean-parent/sean-parent.github.io/wiki/Papers-and-Presentations

By Keean Schupke at Wed, 2016-02-24 21:53 | login or register to post comments

thank you

OK i sit/stand (hopefully happily in the long run) corrected, I shall attempt to go learn! Thanks for the references. I have indeed even heard of A&E before, but don't really know anything about it.

By raould at Wed, 2016-02-24 22:21 | login or register to post comments

Sean Parent Videos

There are several video lectures he has given, and I think they are all good. Inheritance is the Base Class of Evil, Better Code: Concurrency etc. If you search for "Sean Parent" on YouTube you should be able to find most of them easily.

Edit: Sean's keynote at CppCon has some material that addresses user-interface data structures: https://www.youtube.com/watch?v=sWgDk-o-6ZE.

By Keean Schupke at Wed, 2016-02-24 22:52 | login or register to post comments

Lambda the Ultimate

User login

Navigation