Definition of "elegance" in programming
Patrick Doyle
this definition:
Elegance: The exploitation of emergent behaviour to express
possibly complex logic using a small number of simple
concepts.
I have tried to make this as specific as possible, in order to give
us something to discuss here. :-)
To me, the key is emergent behaviour: explicitly listing a horde of
possibilities and handling each one in a special way is not elegant;
finding a simple scheme whereby each possibility is handled automatically
is elegant. "If" statements, in general, are not elegant; dynamic
dispatch, pattern-matching, etc. are elegant.
Gotos might seem "elegant" by this definition at first, since it is
a single, simple concept; but it has no emergent behaviour. It
simply does what it says it will do, conferring no incidental
benefits. Structured programming, on the other hand, is elegant
because it uses a few simple concepts (sequencing, conditionals,
loops) to structure code in such a way that any flow control can
be expressed, *and* the program becomes more comprehensible
thanks to single-entry, single-exit. Both of these things are
emergent behaviour.
Does anyone have any thoughts on this?
--
--
Patrick Doyle
doy...@ecf.toronto.edu
[ FAQ: http://www.paragon-software.com/comp.object.moderated.faq/ ]
[ * No Flames, No Spam, No Nonsense: Just OO discussion * ]
Tim Ottinger
>
> I was thinking about "elegance" in programming, and I came up with
> this definition:
>
> Elegance: The exploitation of emergent behaviour to express
> possibly complex logic using a small number of simple
> concepts.
> Does anyone have any thoughts on this?
Only heartfelt agreement.
In some places, I've heard managers arguing that we don't
need "elegant" solutions slowing us all down. In reality,
they were thinking "sophisticated" or "fancy", where elegance,
as you give it, is about simplicity. .
Now, there is a difference between "intuitive" and "elegant",
and your definition avoided the trap of associating them.
I applaud that. The solution may not be obvious on the face
of it (though there is no reason to desire it to be otherwise)
because it handles a complex problem in a simple way.
Maybe a fully-working, predictable, provable solution
which is greatly less complex than the problem
it solves is innately "elegant"?
I also like it because it doesn't confuse "elegance" with
"terseness", nor does my previous paragraph. Instead, it
isn't how many lines of code that defines elegance, but
how much the complexity is effectively reduced.
FSMs are innately elegant (though I've seen some mixed-
up FSMs that werent) because they reduce a complex
set of behaviors to a really simple table, and they
eliminate a world of if-else conditional branches that
might otherwise be necessary.
Tim
--
--------- There is no craftite conspiracy -------------
Tim Ottinger Object Mentor OO Training and
otti...@oma.com www.oma.com Mentoring
-------------------------------------------------------
We can interpret a bad temper as a sign of inferiority.
-- Alfred Adler
Jens Lundell
Tim Ottinger <otti...@oma.com> wrote:
> Maybe a fully-working, predictable, provable solution
> which is greatly less complex than the problem
> it solves is innately "elegant"?
This reminds me of the following situation: Which is the most "elegant" way of
(for example) making a number of GUI components invisible?
A. while ("complex expression returning next component a to make invisible")
a.setVisible(false);
B. firstComponent.setVisible(false);
secondComponent.setVisible(false);
thirdComponent.setVisible(false);
...
...
I bet a lot of people thinks A is more elegant even though B executes faster,
is easier to understand, and easier to implement. Of course it depends on how
many components you have, how complex the while expression is, and how likely
the set of components/visibility condition is going to change.
-Jens
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Stefan Seefeld
>
> Patrick Doyle wrote:
> >
> > I was thinking about "elegance" in programming, and I came up with
> > this definition:
> >
> > Elegance: The exploitation of emergent behaviour to express
> > possibly complex logic using a small number of simple
> > concepts.
> [...]
> > Does anyone have any thoughts on this?
>
> Only heartfelt agreement.
>
> In some places, I've heard managers arguing that we don't
> need "elegant" solutions slowing us all down. In reality,
> they were thinking "sophisticated" or "fancy", where elegance,
> as you give it, is about simplicity. .
Hmm, I think elegance comes with insight. An excelent understanding of
the problem domain is the basis for an elegant solution. It's the same as for
example in mathematics. There are a couple of equations which I find simply
beautiful because they are simple but express amazingly complex concepts.
The point seems to be as Einstein said "make it as simple as possible but
not simpler".
I think this applies to abstraction quite well. Finding the optimal level of
abstraction when designing class trees for example is a frustrated problem.
Putting to many different concepts into a class is bad, making base classes too
general ('Universe', 'World', 'Object') is not better.
Patterns for example can be *very* elegant because their use necessitates much
undestanding of the interrelationships of all involved classes/objects.
> Now, there is a difference between "intuitive" and "elegant",
> and your definition avoided the trap of associating them.
Yeah, everyone claims to have intuition but *good* intuition is trained by reality
and experiments only.
> Maybe a fully-working, predictable, provable solution
> which is greatly less complex than the problem
> it solves is innately "elegant"?
How do you compare the complexity of the problem and the complexity of the solution ??
I think people tend to describe it this way because 'problem' is called something which
has not yet been understood while the solution springs out of the problem when it is
really investigated. (the old thread about orthogonality of problem and solution space :-).
I see this more dynamic, more temporal.
Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seef...@magellan.umontreal.ca
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
Patrick Doyle
>Patrick Doyle wrote:
>>
>> I was thinking about "elegance" in programming, and I came up with
>> this definition:
>>
>> Elegance: The exploitation of emergent behaviour to express
>> possibly complex logic using a small number of simple
>> concepts.
>[...]
>> Does anyone have any thoughts on this?
>
>Only heartfelt agreement.
Thanks, Tim. I knew I could count on you for a comment on such
an abstract topic, even if nobody else replies. :-)
>In some places, I've heard managers arguing that we don't
>need "elegant" solutions slowing us all down. In reality,
>they were thinking "sophisticated" or "fancy", where elegance,
>as you give it, is about simplicity.
Yes, that's a good point.
Another that I meant to add to my original post is that it explains
why people tend to favour orthogonality: the number of situations
covered by orthogonal concepts is exponential in the number of
concepts, so a great deal of ground can be covered by a few
concepts. (However, as the Perl people will remind us,
orthogonality--and even elegance, perhaps--are not everything.)
>Now, there is a difference between "intuitive" and "elegant",
>and your definition avoided the trap of associating them.
>I applaud that. The solution may not be obvious on the face
>of it (though there is no reason to desire it to be otherwise)
>because it handles a complex problem in a simple way.
Yes, indeed. Have a look at monads some time. :-)
--
--
Patrick Doyle
doy...@ecf.toronto.edu
John D Salt
wrote:
>Patrick Doyle wrote:
>>
>> I was thinking about "elegance" in programming, and I came up with
>> this definition:
>Only heartfelt agreement.
[more snips]
>FSMs are innately elegant
I agree with Tim on the predisposition of STDs towards elegance,
and very strongly agree with the emphasis on simplicity.
I also like Patrick's definition; but it seems to me to be a definition
of something more than elegance. I like the "Hacker's Dictionary"
definition of elegance, and, especially, the St-Exupery definition
it quotes:
"A designer knows he has achieved perfection not when there is
nothing left to add, but when there is nothing left to take
away."
Now, I think there is always going to be an element of aesthetic
judgement here -- "One instinctively knows when something is
right", to quote an old Sherry ad. As Tim points out, this
is _not_ the same thing as the "immediately obvious" answer,
but I think it's an answer that will be obviously right once
you've seen it.
The exploitation of emergent behaviour -- which I would like
to think that O-O systems show at their best -- seems to me
to be a further step, and one which probably requires
elegance as a precondition. It also seems to me to merit a
new and separate name of its own.
All the best,
John.
--
John D Salt Dept of IS & Computing,| Barr's Law of Recursive Futility
Brunel U, Uxbridge, Middx UB8 3PH | [BLORF]: If you are smart enough
Disclaimers: I speak only for me. | to use one of these... you can
Launcher may train without warning.| probably manage without one.
Robert C. Martin
Jens Lundell wrote in message <7fg7r5$32n$1...@nnrp1.dejanews.com>...
>> which is greatly less complex than the problem
>> it solves is innately "elegant"?
>
of
>(for example) making a number of GUI components invisible?
>
>A. while ("complex expression returning next component a to make
invisible")
> a.setVisible(false);
>
>B. firstComponent.setVisible(false);
> secondComponent.setVisible(false);
> thirdComponent.setVisible(false);
> ...
> ...
>
>I bet a lot of people thinks A is more elegant even though B executes
faster,
>is easier to understand, and easier to implement. Of course it depends on
how
>many components you have, how complex the while expression is, and how
likely
>the set of components/visibility condition is going to change.
Component visibility, or component *enabling* (the greying out of
buttons
and menu items) changes frequently in many applicatons. Getting this
under
control is an interesting problem. Since 1984 I have been using
explicit
finite state machines for this purpose. Each state of the FSM
represents a
different pattern of enabled and disabled components. Each user gesture
(button click, menu item click, etc) is an event into that FSM.
There is elegance in this kind of structure. For more information see
"Taskmaster" in the 'publications' section of my website.
Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
TINCC.
Tim Ottinger
> Hmm, I think elegance comes with insight. An excelent understanding of
> the problem domain is the basis for an elegant solution. It's the same as for
> example in mathematics. There are a couple of equations which I find simply
> beautiful because they are simple but express amazingly complex concepts.
Yes, the complexity of the solution is very low, but the
utility is for very complex problems. I've seen situations,
OTOH, where understanding the complex problem led people to
write really complex code that was fragile, brittle, ugly.
So understanding the problem isn't the sole basis for
an elegant solution, but part of it. There is some kind of
reduction that's part of the process.
> > Maybe a fully-working, predictable, provable solution
> > which is greatly less complex than the problem
> > it solves is innately "elegant"?
>
> How do you compare the complexity of the problem and the complexity of the solution ??
There's the rub. In some cases, like the equations you mention,
you *know* that the equation is simple because of the number of
terms and operations. You know that the leverage is for very
complex concepts. How do you know? How are you measuring?
> I think people tend to describe it this way because
> 'problem' is called something which has not yet been
> understood while the solution springs out of the problem
> when it is really investigated. (the old thread about
> orthogonality of problem and solution space :-).
> I see this more dynamic, more temporal.
If you think that "complex" means "ill-undestood" maybe. But
that's not what complex means. If something is complex, it
involves many entities and relationships and forces. No matter
how much you understand biochemistry, it's a complex topic.
If you had perfect understanding and it became intuitive to
you, it would still be complex. Complexity has nothing to do
with how well you understand a thing. It has to do with how
intricate the thing is.
--
Tim
--------- There is no craftite conspiracy -------------
Tim Ottinger Object Mentor OO Training and
otti...@oma.com www.oma.com Mentoring
-------------------------------------------------------
We can interpret a bad temper as a sign of inferiority.
-- Alfred Adler
Tim Ottinger
>
> This reminds me of the following situation: Which is the most "elegant" way of
> (for example) making a number of GUI components invisible?
>
> A. while ("complex expression returning next component a to make invisible")
> a.setVisible(false);
>
> B. firstComponent.setVisible(false);
> secondComponent.setVisible(false);
> thirdComponent.setVisible(false);
> ...
> ...
I can't see that either is more elegant than the other. The complexity
of
the problem is translated either directly or indirectly into an
equally
complex solution.
> I bet a lot of people thinks A is more elegant even though B executes faster,
> is easier to understand, and easier to implement. Of course it depends on how
> many components you have, how complex the while expression is, and how likely
> the set of components/visibility condition is going to change.
Is "flexibility" a component of "elegance" ? It's certainly
a component of "good", but "elegant"?
--
Bradley K. Sherman
Patrick Doyle <doy...@ecf.toronto.edu> wrote:
>I was thinking about "elegance" in programming, and I came up with
>this definition:
If the maintenance programmers don't curse the day you
were born, your code is elegant.
--bks
m...@spam.not
Some solutions are almost as difficult to
deal with as the problems they solve.
I would define elegance as the ratio of
those two difficulties. In my mind that is
an elegant definition.
Andrey V Khavryutchenko
>>>>> "BKS" == Bradley K Sherman writes:
BKS> In article <FAAGA...@ecf.toronto.edu>, Patrick Doyle
BKS> <doy...@ecf.toronto.edu> wrote:
>> I was thinking about "elegance" in programming, and I came up with this
>> definition:
BKS> If the maintenance programmers don't curse the day you were born, your
BKS> code is elegant.
By that moment is usually too late ;)
We should recognise the elegance (or its absence) before the inevitable
happens.
--
SY, Andrey V Khavryutchenko http://www.kbi.kiev.ua/~akhavr
Freelance Software Engineer
Good judgment comes from experience, and a lot of that comes from
bad judgment.
Frank Westphal
>
> "A designer knows he has achieved perfection not when there is
> nothing left to add, but when there is nothing left to take
> away."
For me, in the light of this (very nice!) definition, elegance
often means that I need the simplest solution I can get away with.
>From a design POV, I look for high patterns density, symmetry,
code formatting and code that reads good, i.e., that stays on top
of my bag of tricks.
For an interesting view on elegant code, see Jim Coplien's
series of Nature of Order-related articles for C++ Report,
starting with the article called Space: The Final Frontier.
http://www.bell-labs.com/~cope/
Frank
--
Frank Westphal | "The difference between theory and practice is
west...@acm.org | in theory somewhat smaller than in practice."
Frank Westphal
>
> If the maintenance programmers don't curse the day you
Yeah!, most of the other responses have been concentrating on the
complexity issues, while I too think that a truely elegant program
tells a certain story. It's kind of related to Don Knuth's idea
of Literate Programming, that every "stupid" would be able to write
programs that a compiler could understand, but that only the true
"masters" would be able to write solid code that other human beings
could understand immediately.
Somehow related to this topic is Kent Beck's notion of smelly code.
In his Best Practice Patterns book, he gives detailed advice about
those inner code qualities and how to listen to the code.
Stefan Seefeld
>
> Stefan Seefeld wrote:
> > Hmm, I think elegance comes with insight. An excelent understanding of
> > the problem domain is the basis for an elegant solution. It's the same as for
> > example in mathematics. There are a couple of equations which I find simply
> > beautiful because they are simple but express amazingly complex concepts.
>
> Yes, the complexity of the solution is very low, but the
> utility is for very complex problems. I've seen situations,
> OTOH, where understanding the complex problem led people to
> write really complex code that was fragile, brittle, ugly.
> So understanding the problem isn't the sole basis for
> an elegant solution, but part of it. There is some kind of
> reduction that's part of the process.
Exactly. Let me try it again. To abstract means to take away, so let's compare
abstraction to time series analysis: you are given a whole bunch of values, a sequence
of measurements. Plotted as a trajectory, it looks ugly, it's all noise. So you start
to filter it. You take the mean of two (or four or...) successive values and plot the
new sequence. After doing so a couple of times, suddenly you recognize some pattern.
The signal emerges. Hey, you say, I've already seen this. Its a sinus, a harmonic
oscillation. You continue with your filtering and the signal disappears, the resolution
of your generated sequences are to low now.
It seems to me that this kind of approach is very much the same in design. The aim
is not to strive off complexity but to look at the optimal level of abstraction to
perceive some special quality of the whole (which you can only see at this very level
of resolution). Elegance has a lot to do with looking for this optimal level.
> > > Maybe a fully-working, predictable, provable solution
> > > which is greatly less complex than the problem
> > > it solves is innately "elegant"?
> >
> > How do you compare the complexity of the problem and the complexity of the solution ??
>
> There's the rub. In some cases, like the equations you mention,
> you *know* that the equation is simple because of the number of
> terms and operations. You know that the leverage is for very
> complex concepts. How do you know? How are you measuring?
It's the truth which is contained in this equation, the relationship of objects
(variables, operators) in it which is 'simple'.
Hmm, I seem to have another division of problem<->solution then most of you. To be
able to write down the equation almost *is* the solution (the only step missing is
to actually solve the equation). But the main problem in studying the problem is
the analysis which *leads* to the equation because writing down the equation means
abstract from the real entities (which are certainly not numbers and operators) so
you are left with this specific relations encoded in the equation.
So even though you know that things are quite complex, at this very level of abstraction
you can describe the objects in question by quite simple relationships. This simplicity
doesn't divide the problem and the solution but the totality of things you initially
perceive and the abstraction you get at while investigating.
> > I think people tend to describe it this way because
> > 'problem' is called something which has not yet been
> > understood while the solution springs out of the problem
> > when it is really investigated. (the old thread about
> > orthogonality of problem and solution space :-).
> > I see this more dynamic, more temporal.
>
> If you think that "complex" means "ill-undestood" maybe. But
> that's not what complex means. If something is complex, it
> involves many entities and relationships and forces. No matter
> how much you understand biochemistry, it's a complex topic.
at an appropriate level of abstraction even an enzymatic reaction
or the reaction pathway of hormones becomes simple. It all depends on what you
want the model to preserve as information (it's resolution).
> If you had perfect understanding and it became intuitive to
> you, it would still be complex. Complexity has nothing to do
> with how well you understand a thing. It has to do with how
> intricate the thing is.
Absolutely. Complexity is part of the objective nature of a thing. But the
abstract qualites are too. You don't invent these, you detect them.
Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seef...@magellan.umontreal.ca
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
Marc Girod
Tim> If you think that "complex" means "ill-undestood" maybe. But
Tim> that's not what complex means. If something is complex, it
Tim> involves many entities and relationships and forces. No matter
Tim> how much you understand biochemistry, it's a complex topic.
Tim> If you had perfect understanding and it became intuitive to
Tim> you, it would still be complex. Complexity has nothing to do
Tim> with how well you understand a thing. It has to do with how
Tim> intricate the thing is.
I could not disagree more.
You probably know of Brad Cox's "No Silver Bullet Revisted" to support
my view (http://www.virtualschool.edu/cox/AmProTTEF.html).
Other traditional arguments are how complex division was for Romans,
and the relative complexity of tic-tac-toe and "number scrabble" (in
"The Sciences of the Artificial" or "The Psychology/Design of Everyday
Things").
I believe your model of understanding is wrong, if you believe
something may be "well understood". I can only recommend some more
reading... "Zen or the Art of Motorcycle Maintenance"? "The Society of
Mind"?
Think at what different people do understand when they claim they
understand something well.
Think at the various understandings there has been throughout history
of some laws of physics, and how well people have believed they
understood.
Understanding is building a representation. The complexity of the
model is in reverse dependence to the expressive power of the
underlying abstractions. Our satisfaction with this model is bound to
its stability: how well it resists to experience.
It is only when the model fails that we need to reconsider the
abstractions. Until then, we are blind ("Understanding Computers and
Cognition").
Best Regards!
Marc
--
Marc Girod Hiomo 5/1 Voice: +358-9-511 23746
Nokia Telecommunications P.O. Box 320 Mobile: +358-40-569 7954
NWS/NMS/NMS for Data 00045 NOKIA Group Fax: +358-9-511 23580
Finland marc....@ntc.nokia.com
Jeffrey L Straszheim
Marc Girod wrote:
> >>>>> "Tim" == Tim Ottinger <otti...@oma.com> writes:
> Tim> If you think that "complex" means "ill-undestood" maybe. But
> Tim> that's not what complex means. If something is complex, it
> Tim> involves many entities and relationships and forces. No matter
> Tim> how much you understand biochemistry, it's a complex topic.
> Tim> If you had perfect understanding and it became intuitive to
> Tim> you, it would still be complex. Complexity has nothing to do
> Tim> with how well you understand a thing. It has to do with how
> Tim> intricate the thing is.
<snip>
> Other traditional arguments are how complex division was for Romans,
> and the relative complexity of tic-tac-toe and "number scrabble" (in
> "The Sciences of the Artificial" or "The Psychology/Design of Everyday
> Things").
I really think you are talking about two different things here.
He said "if you had perfect understanding." Now, this is a
hypothetical; he never said that anyone could have such understaning,
merely that if such existed it still would not address complexity.
In other words, in the mind of god, something with one-hundred-
million moving parts still has one-hundred-million moving parts.
> I believe your model of understanding is wrong, if you believe
> something may be "well understood". I can only recommend some more
> reading... "Zen or the Art of Motorcycle Maintenance"? "The Society of
> Mind"?
I didn't see the original poster present a "model of understanding."
He did suggest that complexity was an objective state that is
independent of understanding.
> Think at what different people do understand when they claim they
> understand something well.
> Think at the various understandings there has been throughout history
> of some laws of physics, and how well people have believed they
> understood.
Very well; however, something with one-hundred-million moving part
continues to have one-hundred-million moving parts regardless
of the understanding of the past or present. If we can model it
with a system that has one-hundred lines of code then lucky us,
but there are phenomena in nature that cannot be reduced this
way.
<snip>
{I won't comment on your assertion that we are "blind".}
--
--Jeffrey Straszheim
---Systems Engineer, Programmer
----stimuli AT shadow DOT net
Stefan Seefeld
> > Other traditional arguments are how complex division was for Romans,
> > and the relative complexity of tic-tac-toe and "number scrabble" (in
> > "The Sciences of the Artificial" or "The Psychology/Design of Everyday
> > Things").
>
> I really think you are talking about two different things here.
> He said "if you had perfect understanding." Now, this is a
> hypothetical; he never said that anyone could have such understaning,
> merely that if such existed it still would not address complexity.
> In other words, in the mind of god, something with one-hundred-
> million moving parts still has one-hundred-million moving parts.
>
> > I believe your model of understanding is wrong, if you believe
> > something may be "well understood". I can only recommend some more
> > reading... "Zen or the Art of Motorcycle Maintenance"? "The Society of
> > Mind"?
>
> I didn't see the original poster present a "model of understanding."
> He did suggest that complexity was an objective state that is
> independent of understanding.
Exactly. And we are mixing this notions of objective complexity and
complexity of the model. Sticking to this distinction, I like the aspect
the other anonymous author brought into play: that elegance has to do with
the ratio between those two complexities, the simplicity of the model,
normalized by the complexity of the problem. I admitt that this isn't always
possible because there are situations where reduction isn't possible
as in others. However, to come back to my other mail, I think that this reduction
is nothing but the process of abstraction involved in every modelling activity.
Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seef...@magellan.umontreal.ca
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
Brian Postow
>>
>> I was thinking about "elegance" in programming, and I came up with
>> this definition:
>>
>> possibly complex logic using a small number of simple
>> concepts.
>[...]
>> Does anyone have any thoughts on this?
>
>Only heartfelt agreement.
>
[munch munch]
I pretty much agree as well. However for me, there is one major part
of elegance that has been left out of this discussion: the
language. For me a large part of what determines whether a program is
elegant or not, is the language it was written in. In particular, the
paradigm. I realize that this is c.o.m, and we are all assuming OOP,
but lets broaden for a minute.
Different algorithms are more elegant in different paradigms. For
example, doing in-place quick-sort is really messy in a functional
language, but very neat in an OO one.
I think that this concept is actually already present in the original
definition. If you consider it to be talking about the emergent
behavior that comes out of the language constructs OF A PARTICULAR
LANGUAGE, then my thoughts fall out of the definition for free. My
main issue is actually remaining pure, within the paradigm, not using
assignments in functional languages, or passing function pointers in
C, etc
To take it one step further, I sort of disagree a little with
whomever said that goto was NEVER elegant. In a paradigm where goto is
allowed (ie, assembler like programs) slick things done with goto CAN
be very elegant. In anything thats structured, of course, using goto
will cause you to go straight to hell. B-) But this still comes out of
the original definition...
Marc Girod
getting out-of-topic,
>>>>> "SS" == Stefan Seefeld <seef...@magellan.umontreal.ca> writes:
SS> Jeffrey L Straszheim wrote:
SS> Exactly. And we are mixing this notions of objective complexity
SS> and complexity of the model.
That's my point: the notion of "objective complexity" is a plain
conjecture.
- It is not backed by experience.
- It is not endorsed by the sources I cited
- It is not useful for building scientific models (ones that might be
proven wrong)
"Objective" is a misnomer (see "Women, Fire and Dangerous Things")
What is at stake here is "global" vs "local". OO is definitely
concerned with the local aspects.
Best Regards!
Marc
--
Marc Girod Hiomo 5/1 Voice: +358-9-511 23746
Nokia Telecommunications P.O. Box 320 Mobile: +358-40-569 7954
NWS/NMS/NMS for Data 00045 NOKIA Group Fax: +358-9-511 23580
Finland marc....@ntc.nokia.com
Thaddeus L. Olczyk
thing. Elegance in programming is not as important as elegance in
design ( and architecture).
Tim Ottinger
>
> >Patrick Doyle wrote:
> >> Elegance: The exploitation of emergent behaviour to express
> >> possibly complex logic using a small number of simple
> >> concepts.
> >[...]
> >> Does anyone have any thoughts on this?
> >
> >Only heartfelt agreement.
>
> [munch munch]
>
> I pretty much agree as well. However for me, there is one major part
> of elegance that has been left out of this discussion: the
> language. For me a large part of what determines whether a program is
> elegant or not, is the language it was written in. In particular, the
> paradigm. I realize that this is c.o.m, and we are all assuming OOP,
> but lets broaden for a minute.
Maybe you're not saying "the language", but "the use
of the language'.
I'm never entirely sure what "exploitation of emergent
behavior" means or how to recognize it on sight. It could
be a word choice problem, not conceptual. I don't know.
I think there's something there that's good. But I can't
claim to really understand the statement. I do get the
part about "expressing possibly complex logic using a
small number of simple concepts", which is more easily
grasped.
Maybe you are right that, having talked about reduction,
it's a good time to dust off the original definition
and see if we can't get a good common understanding of
it. Or at least we'll see if you all can explain it to
me.
>From your post (elided, sorry) it seems that this has
something to do with using the existing facilities
and possibly building on them. I can't tell for sure.
--
--------- There is no craftite conspiracy -------------
Tim Ottinger Object Mentor OO Training and
otti...@oma.com www.oma.com Mentoring
-------------------------------------------------------
We can interpret a bad temper as a sign of inferiority.
-- Alfred Adler
Tim Ottinger
>
> Jeffrey L Straszheim wrote:
>
> > I didn't see the original poster present a "model of understanding."
> > He did suggest that complexity was an objective state that is
> > independent of understanding.
Yes. What I said was that even *if* you had perfect understanding,
it would still be complex. I didn't say that was possible. Nor did I
say that there was no simplicity to be found at any point. I'm not
a biochemist, and I don't play one on TV, but I know that there
are things like pH levels that are unifying concepts -- no organ
works if it's very far off. No one organ has the complexity of
them all (possible exception of brain).
But some topics are objectively complex. As I understand it (and
I can give no details: I don't know and there's an NDA besides)
modern color photocopiers have a complexity of timing that is
pretty awesome, for example.
> Exactly. And we are mixing this notions of objective complexity and
> complexity of the model. Sticking to this distinction, I like the aspect
> the other anonymous author brought into play:
Actually, the same anonymous author. But that's neither here nor
there...
> that elegance has to do with
> the ratio between those two complexities, the simplicity of the model,
> normalized by the complexity of the problem. I admitt that this isn't always
> possible because there are situations where reduction isn't possible
> as in others. However, to come back to my other mail, I think that this reduction
> is nothing but the process of abstraction involved in every modelling activity.
When I see a solution that's much simpler than the problem, but
works in every case, then I see elegance. Simplicity is given by
Meyer as being one of the most critical features for reliable
systems, and I think that's probably right. Simplicity lends itself
to high performance, too. If someone has the gift to look at a
complex situation, break it down to a small number of factors
that really matter, understand this in the multidimensionality
of software (timing, structure, robustness, etc) and provide
a simple solution, it's always a beautiful thing. I wish I
could improve my ability to do so.
But we shouldn't kid ourselves that this eliminates complexity
from the problem. It only helps us to deal with it.
The thing would be to find a way to clearly measure the complexity
of a problem and the complexity of a solution. I can only do that
by feel right now, or by counting rules and participants I suppose.
I don't do the counting, but I suppose I could. Maybe I should.
Stefan Seefeld
> > I pretty much agree as well. However for me, there is one major part
> > of elegance that has been left out of this discussion: the
> > language. For me a large part of what determines whether a program is
> > elegant or not, is the language it was written in. In particular, the
> > paradigm. I realize that this is c.o.m, and we are all assuming OOP,
> > but lets broaden for a minute.
>
> Maybe you're not saying "the language", but "the use
> of the language'.
>
> I'm never entirely sure what "exploitation of emergent
> behavior" means or how to recognize it on sight. It could
> be a word choice problem, not conceptual. I don't know.
>
> I think there's something there that's good. But I can't
> claim to really understand the statement. I do get the
> part about "expressing possibly complex logic using a
> small number of simple concepts", which is more easily
> grasped.
programming languages have been created consciously to describe certain
aspects of reality. So I fully agree with the original author that to
describe a certain phenomenon, there might be a language of choice, which
is more adapted to the special kind of problem it describes. It is possible
to describe the problem in most languages, but most of them will do it a bit
awkward because others are designed for the problem.
Sure, the skilful usage of it is important, too.
The aspect I really like is the emergance and adaptation of our means of
expression (language) induced by the problem we have to deal with.
Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seef...@magellan.umontreal.ca
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
Tim Ottinger
>
> Hello Stefan, Jeffrey, and the moderator who thinks that we are
> getting out-of-topic,
>
> conjecture.
> - It is not backed by experience.
> - It is not endorsed by the sources I cited
> - It is not useful for building scientific models (ones that might be
> proven wrong)
What is O(1), O(N), O(Log N)? Are these the accepted complexity
metrics? Aren't those accepted. The notion is of solution
complexity -- is it doing more work than it has to, and how
do you know what's really the amount of necessary work?
Applying it to problems is harder.
>
> "Objective" is a misnomer (see "Women, Fire and Dangerous Things")
> What is at stake here is "global" vs "local". OO is definitely
> concerned with the local aspects.
I'm certainly not interested in any 'what is reality', 'what
is truth', 'what is beauty' conversations here, so I won't go
there. What I can say is that those things tend not to make
good disprovable models now.
But say that we claim complexity can be understood on a working
level. Say that there is a problem statement that is more-or-less
acceptable, and that a solution which produces the appropriate
results is "correct".
Say that the problem statement is that you have to compare
two ranges of like types (dates, integers) and determine if
the ranges overlap. This is a cheezy old example, but let's go
with it for now.
What is the complexity? Well, there is the concept of overlapping,
where there is a subset of one range which is a subset of the other
range as well. There are two different ranges. Each range is
defined by two endpoints, and includes all the possible domain values
from the first through the last. Our brains do this automagically:
do [1..9] and [2..3] overlap? Yep. You didn't need to read all the
way to the question mark. But it's got a complexity we could
describe in terms and operations. Our brains do it by knowing all
of the elements in each set. We could try to mimic that...
An inelegant solution would be to build a loop like this:
overlap = false
for i in range(1,9):
for j in range (2,3):
if i == j:
overlap = true
break
return overlap
It has a lot of problems, one being artificial simplicity. We
don't know that the ranges will always be 1..9 and 2..3. The
routine lacks necessary flexibility. We have to add terms to
the picture:
def overlaps(r1start,r1end,r2start,r2end):
overlaps = false
for i in range(r1start,r1end):
for j in range(r2start,r2end):
if i == j:
overlaps = true
break
return overlaps
That's slighty more complex, but it eliminated some artifical
simplicity. But now there are more variables, while the operation
stays the same. But there's a problem. Where's a guarantee that
the 'start' value is the lower of the two? Could this cause a
problem? I saw it implemented this way:
if ( r1start < r1end and r2start < r2end)
# ... loop and compare
else if ( r1start < r1end and r2start > r2end)
#... loop and compare
else if ( r1start > r1end and r2start > r2end)
# ... loop and compare
else if ( r1start > r1end and r2start < r2end)
# ... loop and compare elided from this point on
and as an afterthought:
else if ( r1start == r1end and r2start < r2end)
else if ( r1start == r1end and r2start > r2end)
else if ( r1start < r1end and r2start == r2end)
else if ( r1start > r1end and r2start == r2end)
and the inevitable:
else if ( r1start == r2start or r1end == r2end )
and possibly:
else if ( r1start < r2start and r1end > r2end)
else if ( r2start < r1start and r2end > r1end)
Okay, well, now the solution is complex. There are four loose
terms, there are operations of varying strengths (<, ==, and, or)
applied to cover all permutations. It's explicit, though...
The solution is more complex than the problem? Maybe. It's
certainly more complex than the solution needs to be.
Create a Range type, which will ensure that start < end.
The assumption simplifies the code here, moving the complexity
of managing the ordering of endpoints to the range type.
By putting the handling of ordering at the point of range
construction, we eliminate a dependency on the integrity
(or lack thereof) in all user routines. We provide a single-
point of maintenance for a greatly simplifying concept. Then
we're back to the original loop and compare.
This is the kind of stuff that DBC is built on. The simplifications
make the code less complex, while covering all eventualities in
the problem statement. It does so by building a precondition on
the ranges, and by doing the simplest check on the ranges.
In C++, that would need to be a template to allow multiple
types to be used. That adds solution complexity in the syntax,
but it's not a biggie (I have one on my web page if you want
it: http://www.oma.com/ottinger/Range.h).
But we can do better yet (and I did in the C++ version):
def overlaps(r1, r2):
overlaps = true
if ( r1.end < r2.begin or r2.end < r1.end )
overlaps = false
return overlaps
The test for *not* overlapping is very simple. You don't
have to know all the members. You only have to know whether
either range ends before the other begins. If so, then
there's no overlap. The complement ("not non-overlapping")
is the answer you want.
That could be done with a single statement, but the 'not'
operation is confusing for a lot of people and changes the
complexity very little.
To me, you can see the complexity difference in the code, and
see a solution that could have been solved with much labor being
equally-well-solved using less effort.
The problem could be said to include all of the if-else
conditions. The test cases for the class certainly had to
consider all the boundary conditions. The solution is clearly
of less complexity than the problem *as presented*.
--
Tim
--------- There is no craftite conspiracy -------------
Tim Ottinger Object Mentor OO Training and
otti...@oma.com www.oma.com Mentoring
-------------------------------------------------------
We can interpret a bad temper as a sign of inferiority.
-- Alfred Adler
Stefan Seefeld
>
> Hello Stefan, Jeffrey, and the moderator who thinks that we are
> getting out-of-topic,
>
>
> SS> Jeffrey L Straszheim wrote:
>
> SS> and complexity of the model.
>
> That's my point: the notion of "objective complexity" is a plain
> conjecture.
>
> - It is not backed by experience.
So don't you think that 'complexity' is a good measure to distinguish
a living being and a stone ? I mean, there *are* differences. It's not
just in your mind or a question on how you perceive it.
> - It is not endorsed by the sources I cited
> - It is not useful for building scientific models (ones that might be
> proven wrong)
Sorry, but if I want to model a balistic curve of a thrown stone or the
trajectory of a flying bird, there are certain differences. It would definitely
better if I took them into acount. I could easily approximate the stone
by a point mass, subject to an external force, but would have difficulties
when trying to figure out what makes the bird fly in one direction and then
in another...
> "Objective" is a misnomer (see "Women, Fire and Dangerous Things")
> What is at stake here is "global" vs "local". OO is definitely
> concerned with the local aspects.
No, full disagreement. A model is always an image of a subset of reality.
May be you are refering to this subset as 'local', however, this doesn't
change the fact that even this subset is real, objective. It's the model
we create (first only in our mind) which is not.
Later on, when constructing a solution (after having created it in our mind)
we *objectify* it, making it as real as the thing we originally intended to
model.
Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seef...@magellan.umontreal.ca
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
Tim Ottinger
>
> All these posts, and not one person points out the most important
> thing. Elegance in programming is not as important as elegance in
> design ( and architecture).
Which says what? That if the design is good it doesn't matter
how you write the code? I'm not sure I parse it. Programming
is design, so you design low-level and high-level and it all
has to be programmed.
It's important that the elegance appears in the code, but if
the code is "pretty" it doesn't much matter.
Where do we not need simple, flexible answers? Where don't
we need them well-expressed?
All that having been said, is a well-designed but poorly-
implemented system better off than an ill-designed but
well-implemented system? I don't know if we have the
data points for that one, even at the gut level. What
we can say is that anything done well is better than
the same thing done poorly, but that's an inane thing
to say.
Help me out here.
--
Tim
--------- There is no craftite conspiracy -------------
Tim Ottinger Object Mentor OO Training and
otti...@oma.com www.oma.com Mentoring
-------------------------------------------------------
We can interpret a bad temper as a sign of inferiority.
-- Alfred Adler
Brian Postow
Stefan Seefeld <seef...@magellan.umontreal.ca> wrote:
>Tim Ottinger wrote:
>programming languages have been created consciously to describe certain
>aspects of reality. So I fully agree with the original author that to
>describe a certain phenomenon, there might be a language of choice, which
>is more adapted to the special kind of problem it describes. It is possible
>to describe the problem in most languages, but most of them will do it a bit
>awkward because others are designed for the problem.
>Sure, the skilful usage of it is important, too.
There is that, but its more than that, IMHO. Even if you want to do
something very simple, something that you can do elegantly in any
language, the WAY YOU DO IT may be determined by the language. I'm
sure that the Worfian hypothesis is lurking in the background here
somewhere too... You can write an elegant sort function in any
language. The question is what sort do you write?
Patrick Doyle
wrote:
>
>I'm never entirely sure what "exploitation of emergent
>behavior" means or how to recognize it on sight. It could
>be a word choice problem, not conceptual. I don't know.
I meant that an elegant system uses behaviour which is not explicitly
specified. For instance, in the state machine example, each state
represents some knowledge about the past sequence of events; but
this knowledge is not explicitly stated in the state machine. It
is "emergent" from the state transitions.
Or, with polymorphism, the dynamic dispatch is not explicitly stated.
It is emergent from the language rules combined with the class
hierarchy.
One more thing: emergent behaviour is more than merely implicit. A
system exhibiting emergent behaviour properly handles cases which
were never considered during its design. For instance, when I
design a class hierarchy and use polymorphism, I have some idea
what kind of things a client class will do, but an elegant
design should also cover the cases that I never considered.
Have you ever had that feeling, when using a class you designed
a few days before, where you think "what a great job I did with
that class!"? Often, if you do manage to create an elegant
class design, you'll find that it's surprisingly easy to use
later on in the project. Conversely, an inelegant design tends
to surprise you with its inflexibility and difficulty to use.
(I've had my share of those. :-)
A another example of elegance is Design by Contract. When you specify
contracts, you implicitly make certain sequences of feature calls
illegal. For instance, the contracts for a stack might make this
illegal:
create
push goober
pop
pop
The elegant thing about this is that the designer of the stack
did not have to consider this sequence and explicitly make it
illegal.
--
--
Patrick Doyle
doy...@ecf.toronto.edu
Patrick Doyle
Thaddeus L. Olczyk <olc...@interaccess.com> wrote:
>
>All these posts, and not one person points out the most important
>thing. Elegance in programming is not as important as elegance in
>design ( and architecture).
Care to elaborate on why this is so? It's not obvious to me.
Thaddeus L. Olczyk
wrote:
>I was thinking about "elegance" in programming, and I came up with
>this definition:
>
> Elegance: The exploitation of emergent behaviour to express
> possibly complex logic using a small number of simple
> concepts.
>
>I have tried to make this as specific as possible, in order to give
>us something to discuss here. :-)
>
>To me, the key is emergent behaviour: explicitly listing a horde of
>possibilities and handling each one in a special way is not elegant;
>finding a simple scheme whereby each possibility is handled automatically
>is elegant. "If" statements, in general, are not elegant; dynamic
>dispatch, pattern-matching, etc. are elegant.
>
>Gotos might seem "elegant" by this definition at first, since it is
>a single, simple concept; but it has no emergent behaviour. It
>simply does what it says it will do, conferring no incidental
>benefits. Structured programming, on the other hand, is elegant
>because it uses a few simple concepts (sequencing, conditionals,
>loops) to structure code in such a way that any flow control can
>be expressed, *and* the program becomes more comprehensible
>thanks to single-entry, single-exit. Both of these things are
>emergent behaviour.
>
>Does anyone have any thoughts on this?
>
Sorry for posting my reply so late.
The definition of "elegance" in programming is simple:
1) Low coupling.
2) high cohesion.
3) highly local ( see the Antcohesion thread).
Beyond this I have criteria:
when you write some software artifact that is then assigned
to some programmer with about one tenth the skill
( it has to be about that, someone with your skill would recognise
the difficulty) for maintanance.
You've worked hard on the code, but made it so easy
to make additions and to modify it that the maintanance programmer
comes out and declares it's so easy to write, and he doesn't see why
you worked so long on it.
Unfortunately it's elegant, but it's also bad for your career.
( On a similar vien, I once had a math prof who showed a proof to his
friends. They all would reply "cute trick". One day he went to a
conference and showed the theorem to everyone without proof and
said," I'll buy a drink for anyone who can prove it by the party
tomorrow night". No had proved it by the party, and several people
walked up to him and asked for the proof. WHen showed it they all
said "beautiful.")
Marco Dalla Gasperina
> I don't buy the objective measure of elegance as the ratio of problem
> to solution complexity. Maxwell's equations are (probably) elegant, but
> to me they're infinitely complex.
> Elegance must be an aesthetic judgment. That's what makes finding
> elegance pleasing.
Cool stuff, all.
I tend to agree with Dave here... I find elegance has more to with
the 'depth' of the solution. A problem can have an answer, but maybe
there is an answer which solves a more general case of the problem.
That solution is more elegant. Is the fact that it may be 'simpler'
be just a side effect (e.g. requires fewer variables)?
Somehow the applicability of the solution to things not intended
has something to do with elegance. But that's just me.
marco
Dave Harris
> Yes. What I said was that even *if* you had perfect understanding,
> it would still be complex. I didn't say that was possible. Nor did I
> say that there was no simplicity to be found at any point. I'm not
> a biochemist, and I don't play one on TV, but I know that there
> are things like pH levels that are unifying concepts -- no organ
> works if it's very far off. No one organ has the complexity of
> them all (possible exception of brain).
If you describe the brain and some other organ (of similar mass) by
specifying the complete quantum state of every subatomic wavicle, they'd
come out roughly equally complex. When you say the brain is more
complicated, you are not considering them in such detail. You are already
making abstractions and using a model. That model is subjective.
(This sounds very similar to the "objects exist in the real world"
debate.)
Simplicity is always a point of view. In a sense, it's always external. It
comes when two pieces interact, and one piece can ignore the internal
complexity of the other. Then it's reasonable to ask, given this point of
view, this interface, these inputs and outputs, what's the simplest model
for them, and for what goes behind it?
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."