A generic example, indeed. :)
;;; In Common Lisp
(defgeneric do-operation (op)
(:method ((op (eql op-001)) ...) ...)
(:method ((op (eql op-002)) ...) ...)
...
(:method ((op (eql op-150)) ...) ...)
(:method ((op t) ...) ...) ;; default method
)
(and add a :before method for the few lines of setup, or put
those in a separate interface function.)
The methods could be defined separately (even dynamically)
with DEFMETHOD forms.
It's not a class hiding in a function, it's a generic function
hiding in an ordinary function.
Paul
David Wallace wrote:
> According to Andrew McDonagh <····@us.com>:
>
>>500 line functions usually mean its a class hiding as a function.
>>
>>there is simply no good reason for such a long function. they are hard
>>to read and therefore prone to code duplication and errors.
>>
>>sure counting lines is silly, but writing functions this long is more silly.
>>
>>i tend to write functions that are around 7 +/- 2 lines of code.
>>
>>post any such large function and we can show how it would be improved
>
>
> Not too hard, I think. Generic example (obviously a real
> example would have meaningful enum values, etc., but this should
> provide the general idea):
>
> void do_operation(enum op_type operation, ...)
> {
> /* a few lines of setup, then... */
>
> switch(operation) {
>
> case OP_001:
> /* OP_001 action */
> break;
>
> case OP_002:
> /* OP_002 action */
> break;
>
> ...
>
> case OP_150:
> /* OP_150 action */
> break;
>
> default:
> /* default action */
> }
> return;
> }
>
> That's 600+ lines counting white space, even if each action is only
> 1 line. Sometimes you really do have large flat case structures.
> Have at it.
Kaz Kylheku wrote:
> As a rule of thumb, I try to write mine so they don't extend past the
> closing parenthesis.
Thank you, Abraham Lincoln. :-)
("How long should a man's legs be?" "Long enough to reach the
ground.")
--
Gareth McCaughan
.sig under construc
"Kaz Kylheku" <···@ashi.footprints.net> writes:
> As a rule of thumb, I try to write mine so they don't extend past the
> closing parenthesis.
I've found that a high percentage of functions that break this rule
wind up having bugs.
--
Fred Gilham ······@csl.sri.com
...every candid Reader will easily understand my Discourse to be
intended only in Defence of *nominal* Christianity, the other having
been for some time wholly laid aside by general Consent, as utterly
inconsistent with all our present Schemes of Wealth and Power.
--- Jonathan Swift
"Kaz Kylheku" <···@ashi.footprints.net> wrote in message
·····························@o13g2000cwo.googlegroups.com...
> As a rule of thumb, I try to write mine so they don't extend past the
> closing parenthesis.
>
The problem with this is that not all languages are designed
around this model. Also, I wonder if you actually meant,
curly brace?
Also, the question is not simply about the size of functions/methods,
but also needs to address the size of classes that contain those
methods/functions.
In any case, the answer to this question cannot be in terms of
lines of code, language constructs, or the size of the display.
Rather, it has to be decided in terms of the old-fashioned concerns
of coupling and cohesion. These concerns are relevant to both
methods and classes. In other words, it is a question that relates
to levels of modularity.
Each module should be as single-minded as possible. In some
cases, a method will be one or two lines long. In other,
much rarer cases, it may be a hundred lines long.
In the object world, when we think in terms of methods, we realize
that query methods are likely to be short while modifier methods
may be a bit longer. Often, modifier methods are made more
understandable by separating out conditional statements into query
methods. This has the effect of making an otherwise long modifier
method much shorter.
For active objects, this is more problematic. For those kind of objects,
we have the additional overhead of context switching to consider. An
active object might have methods that include a queue, have blocking
semantics, pre-emptible regions, non-pre-emptible regions, and a lot
of other characteristics that introduce new problems related to object
and method size.
However, for both passive and active objects, and for methods in both
kinds of objects, the old-fashioned guidelines from coupling and cohesion
still seem the best approach to deciding the size of a module.
Richard Riehle
········@sbcglobal.net wrote:
> "Kaz Kylheku" <···@ashi.footprints.net> wrote in message
> ·····························@o13g2000cwo.googlegroups.com...
>
>>As a rule of thumb, I try to write mine so they don't extend past the
>>closing parenthesis.
>>
> ... Each module should be as single-minded as possible. In some
> cases, a method will be one or two lines long. In other,
> much rarer cases, it may be a hundred lines long.
> ...
> Richard Riehle
There is a widespread view that small modules are good. But maybe not...
I recently visited the world of software quality and testing again to
see if there had been any substantial advances in recent years. (A: No).
One interesting thing came up that surprised me. A study that related
function/method size to density of bugs found that the number of bugs
rose dramatically as the function/method size fell below a few hundred
statements. They looked into this and found it was due to interface
errors which are roughly proportional to the number of functions. So
more smaller functions/methods means more bugs.
They found the optimum was about 1,000 statements! I don't have the
reference but if someone wants it I will go back to the bookshop and
hunt for it.
Looking at Java/C# code in particular one is struck by the amount of
overhead/rubbish per unit of actual working code. A class may have 100
lines of rubbish and only 2-3 lines of unique code. Much of the rubbish
is interfacing.
This extra code is not harmless. It is supposed to do nothing special
but it might do something it is not supposed to do, if there is a coding
error, or if someone has edited it. So you have to test it.
In that sense programs with a lot of "excise" (pointless overhead code)
have excess entropy compared to the entropy they need to perform the
function they are supposed to perform. This makes them expensive to
build and maintain.
In languages like Java you have "design" patterns, which are usually
coding patterns. You code the same kind of think repeatedly to do
similar things. The trouble is, you have to manually sustain the
integrity of the pattern.
In lisp you would write a macro instead. Java/C# programmers often tend
to use code generators. Of course someone migt edit the generated code,
so in terms of maintenance you still bear the full brunt of the
redundant complexity. Templates are another example of a hack to get
around the basic problem.
Tim Josling
Tim Josling wrote:
> There is a widespread view that small modules are good. But maybe not...
Modules should be reduced, not necessarily small. And the small modules rule
is subtly different from the short methods rule. At the very least, one
should split a method for no other reason than it is long (and no other
reduction is useful). Don't bother to split modules.
> I recently visited the world of software quality and testing again to
> see if there had been any substantial advances in recent years.
> (A: No).
Care to defend that?
> One interesting thing came up that surprised me. A study that related
> function/method size to density of bugs found that the number of bugs
> rose dramatically as the function/method size fell below a few hundred
> statements. They looked into this and found it was due to interface
> errors which are roughly proportional to the number of functions. So
> more smaller functions/methods means more bugs.
>
> They found the optimum was about 1,000 statements! I don't have the
> reference but if someone wants it I will go back to the bookshop and
> hunt for it.
That can't be possible, and its internal reasoning does not withstand
examination. The interface between two methods can be very small - a few
parameters. However the interface between two blocks within the same large
method is very wide. Any block can mutate any variable that it can access,
affecting many other blocks. So if the arbiter for bug risk is width of
interface, the super-method would appear to be higher risk.
I think that study had some other inertia or momentum, such as a
GOTO-oriented language, which obscured the cost of poor encapsulation.
> Looking at Java/C# code in particular one is struck by the amount of
> overhead/rubbish per unit of actual working code. A class may have 100
> lines of rubbish and only 2-3 lines of unique code. Much of the rubbish
> is interfacing.
Uh, I think we can safely blame the language there.
> In lisp you would write a macro instead...
> ...Templates are another example of a hack to get
> around the basic problem.
If the language made classes into first class objects, you can pass the
class by name into client modules. That reduces the need for extra
linguistic features, such as macros or templates.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
"Phlip" <·········@yahoo.com> writes:
> Tim Josling wrote:
>
> > I recently visited the world of software quality and testing again to
> > see if there had been any substantial advances in recent years.
>
> > (A: No).
>
> Care to defend that?
>
Well UML seems to be pretty much rehashed 1980's terminology, and SEI
doesn't seem to offer much of anything more than the software
engineering panaceas of the early 90's.
Gregm
Greg Menke wrote:
> Well UML seems to be pretty much rehashed 1980's terminology, and SEI
> doesn't seem to offer much of anything more than the software
> engineering panaceas of the early 90's.
Generic agreement. Fortunately (for you), they have little to with testing!
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
"Phlip" <·········@yahoo.com> writes:
> Greg Menke wrote:
>
> > Well UML seems to be pretty much rehashed 1980's terminology, and SEI
> > doesn't seem to offer much of anything more than the software
> > engineering panaceas of the early 90's.
>
> Generic agreement. Fortunately (for you), they have little to with testing!
>
quote from the op;
> I recently visited the world of software quality and testing again to
> see if there had been any substantial advances in recent years.
Show me the software engineering consultant that doesn't harp at length
about quality and testing in the same breath as the engineering spiel.
Usually the feature that makes "this" software engineering discipline so
much better than last year's is that this one incorporates quality and
testing features in addition to the new better reusability features.
Gregm
Phlip wrote:
> Tim Josling wrote:
>
>>I recently visited the world of software quality and testing again to
>>see if there had been any substantial advances in recent years.
>
>
>>(A: No).
>
>
> Care to defend that?
>
It is difficult to demonstrate a negative proposition.
Looking through numerous books I didn't see anything that hadn't been
there 10 years ago. If I missed something significant I would like to
know about it!
What I was hoping for was some beakthroughs on areas like
- How to focus testing to reduce the cost without excessive risk.
- Techniques to allow you to predict error rates and severities.
Tim Josling
Tim Josling wrote:
> What I was hoping for was some beakthroughs on areas like
>
> - How to focus testing to reduce the cost without excessive risk.
> - Techniques to allow you to predict error rates and severities.
Test-Driven Development was around 20 years ago, but...
- nobody was promoting it the right way
- it was advertised as "cleanroom" etc.
- executives were told it was hard
- IDE venders were pushing debuggers
- no unit test frameworks were widely distributed
About "promoting it the right way", the point is to run all tests after
every 1~10 edits, and never let the code stray too far from a passing state.
This seems really obvious, but I certainly wish someone had told me it 20
years ago.
This kind of testing reduces costs because it permits feature requests in
any order. That lets you pursue business targets. Feature requests can
implement and change code freely because the risk of a runaway bug hunt is
very low. Under Debugger-Driven Development, you never know which feature
request is the one that will cause a total party in the debugger, with lots
of runaway bugs, and churn where fixing bugs causes new bugs. Under TDD, you
can always just hit Undo and return to a state where all the tests pass.
Teams have overwhelmingly found this technique, coupled with simple Best
Practices like frequent releases, continuous integration, and pair
programming, to reduce the defect rate to zero per quarter. No need to
predict it: It's just zero.
I'm interested what books you looked thru that missed this technique.
Read Code Complete 2nd Edition for a good survey of this stuff. And, yes, it
says TDD is one of the biggest advances of the last 10 years.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: How long should a function be?
Date:
Message-ID: <87zmu6tgs9.fsf@qrnik.zagroda>
Testing is helpless with ensuring correct memory synchronization
between threads. Bugs in this area are non-reproducible (a bug might
manifest in 1/1000 of runs), non-local (each function works fine in
isolation), and misbehavior of the whole program doesn't give a clue
where is the bug to be fixed.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> Testing is helpless with ensuring correct memory synchronization
> between threads. Bugs in this area are non-reproducible (a bug might
> manifest in 1/1000 of runs), non-local (each function works fine in
> isolation), and misbehavior of the whole program doesn't give a clue
> where is the bug to be fixed.
Strictly speaking, non-debuggability doesn't interfere with
the ability of testing to *ensure* correct synchronization.
It may interfere with the ability to *achieve* correct synchronization.
It's also not clear that in a properly designed system it's
necessarily undebuggable (ref: http://www.st.cs.uni-sb.de/papers/issta2002/ ).
Paul
Marcin 'Qrczak' Kowalczyk wrote:
> Testing is helpless with ensuring correct memory synchronization
> between threads. Bugs in this area are non-reproducible (a bug might
> manifest in 1/1000 of runs), non-local (each function works fine in
> isolation), and misbehavior of the whole program doesn't give a clue
> where is the bug to be fixed.
The "prove a negative" list includes...
- security
- crypto
- hackproofness
- concurrency
- data integrity
- hardware reliability
Each of those have a list of possible fixes.
- get permission to ignore the problem
- don't use threads!!!
- buy don't build
- architect a fix and test the architecture
Let's take the example of hackproofness. To prevent SQL insertion attacks on
input strings...
* merge all data input channels into a unique few
* split the code into layers - MVC or similar
- encode input strings and escape their quotes in one place
The items marked with a * can emerge via refactoring to remove duplication.
So the remaining item is as easy to retrofit as it is to architect-in.
About the "misbehavior of the whole program", if you run all tests after
every 1~10 edits, then you know a failure implicates the most recent test,
even if it is not expressive.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
"Phlip" <·········@yahoo.com> wrote in message
·························@newssvr33.news.prodigy.com...
>
> Each of those have a list of possible fixes.
>
> - get permission to ignore the problem
> - don't use threads!!!
> - buy don't build
> - architect a fix and test the architecture
>
Not one of those suggestions is realistic.
1) Ignore the problem? Yikes! I am astonished that anyone would
even make such a suggestion. Perhaps I misunderstand what you
really meant by that.
2) Don't use threads? We often do take this path by desiging with cyclic
executives. However, this solution introduces a whole new set of
problems. I'm sure you know what they are.
3) Buy don't build? In DoD software systems where COTS has become a
problem, this solution is proving to be sometimes unmanageable. How do
we determine that software we buy, when high reliability is not optional,
that a COTS software product is going to work as advertised, consistently?
Testing? That's part of it? Inspection? Essential. Used elsewhere
without
ill-effect? A good reference can be helpful. Other approaches? Yes.
I know
you will be aware of them already.
4) Architecture is the key to good software, regardless of whether one is using
an
agile approach or a planned approach. I have seen research on this where
the
long-term maintenance of a well-architected software system remains durable
over
an extended period where lots of amendments, including additions, are made
to
that software. I have also seen the research for systems that undergo this
same
stress where the original architecture was poorly designed.
Richard Riehle
Richard Riehle wrote:
> > Each of those have a list of possible fixes.
> >
> > - get permission to ignore the problem
> > - don't use threads!!!
> > - buy don't build
> > - architect a fix and test the architecture
> >
> Not one of those suggestions is realistic.
I suspect you are responding to the From line instead of the posts here.
> 1) Ignore the problem? Yikes!
Do you see where I said "get permission"? If I have a boss who says "Yikes"
each time I escalate some important issue, I'm going to attempt the Replace
Boss Refactor.
Again, I did not read the rest because I knew where it was going.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
Phlip wrote:
> Read Code Complete 2nd Edition for a good survey of this stuff. And, yes, it
> says TDD is one of the biggest advances of the last 10 years.
>
I read "Code Complete" quite a while ago though. I agree it is a good
book. Samewise TDD is good - allow refactoring and reduces bugs - but
not new - and nor does it reduce the cost of testing much, as far as I
can see.
I analysed a number of large projects and testing was in the order of
85-90% of the cost. Counting unit testing, integration testing,
usability testing, system testing, performance testing, etc. This really
should be more of a priority than it is. For example Microsoft is
supposed to pay its testers about 10% less than developers.
Tim Josling
Tim Josling wrote:
> One interesting thing came up that surprised me. A study that related
> function/method size to density of bugs found that the number of bugs
> rose dramatically as the function/method size fell below a few hundred
> statements. They looked into this and found it was due to interface
> errors which are roughly proportional to the number of functions. So
> more smaller functions/methods means more bugs.
>
> They found the optimum was about 1,000 statements! I don't have the
> reference but if someone wants it I will go back to the bookshop and
> hunt for it.
I'd be very interested in this.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Quoth Pascal Costanza <··@p-cos.net>:
> Tim Josling wrote:
>
>> One interesting thing came up that surprised me. A study that
>> related function/method size to density of bugs found that the
>> number of bugs rose dramatically as the function/method size fell
>> below a few hundred statements. They looked into this and found it
>> was due to interface errors which are roughly proportional to the
>> number of functions. So more smaller functions/methods means more
>> bugs.
>> They found the optimum was about 1,000 statements! I don't have the
>> reference but if someone wants it I will go back to the bookshop and
>> hunt for it.
>
> I'd be very interested in this.
I'd guess that this is a _highly_ language-specific result,
particularly likely to apply to COBOL/FORTRAN, and, to somewhat lesser
extent, C/C++. Although it sounds more like the pathology I'd expect
in Ada code...
There are languages that have more-or-less "anal retentive"
interfacing schemes that should help avoid such. In particular, I
would expect the Hindley-Milner type inference system used in some of
the functional languages (ML, for instance) to help with this.
Lisp code could easily go either way:
- If you're writing "everything is a list" code, I'll bet Lisp
code could be pretty vulnerable.
- On the other hand, code where objects have pretty specific
types, whether as DEFSTRUCTs or DEFCLASSes, ought to do better.
I'd put the most money on it being a study involving code written in
either COBOL, FORTRAN, or Ada...
--
let name="cbbrowne" and tld="gmail.com" in String.concat ·@" [name;tld];;
http://linuxfinances.info/info/x.html
I don't suffer from insanity, I enjoy every minute of it!
"Christopher Browne" <········@acm.org> wrote in message
····························@news20.bellglobal.com...
> Quoth Pascal Costanza <··@p-cos.net>:
>
> I'd guess that this is a _highly_ language-specific result,
> particularly likely to apply to COBOL/FORTRAN, and, to somewhat lesser
> extent, C/C++. Although it sounds more like the pathology I'd expect
> in Ada code...
>
You clearly don't know much about Ada. We create code in
Ada that is as lean, as efficient, and as well-engineered as you
might produce in whatever your favorite language might be.
Richard Riehle
In the last exciting episode, <········@sbcglobal.net> wrote:
> "Christopher Browne" <········@acm.org> wrote in message
> ····························@news20.bellglobal.com...
>> Quoth Pascal Costanza <··@p-cos.net>:
>>
>> I'd guess that this is a _highly_ language-specific result,
>> particularly likely to apply to COBOL/FORTRAN, and, to somewhat lesser
>> extent, C/C++. Although it sounds more like the pathology I'd expect
>> in Ada code...
>>
> You clearly don't know much about Ada. We create code in
> Ada that is as lean, as efficient, and as well-engineered as you
> might produce in whatever your favorite language might be.
Ah you misread me. The contention was that it was preferable for
functions to be quite long because short functions would lead to a lot
of debugging of the interfacing between functions.
It seems reasonable to be the case for Ada because Ada functions
involve relatively verbose static type statements. That fits with the
claim; if breaking out functionality into extra functions requires
writing _and debugging_ extra code, this has a cost, and will
encourage building larger functions.
--
wm(X,Y):-write(X),write(·@'),write(Y). wm('cbbrowne','gmail.com').
http://linuxdatabases.info/info/spreadsheets.html
"But life wasn't yes-no, on-off. Life was shades of gray, and
rainbows not in the order of the spectrum."
-- L. E. Modesitt, Jr., _Adiamante_
"Christopher Browne" <········@acm.org> wrote in message
·······················@news20.bellglobal.com...
> In the last exciting episode, <········@sbcglobal.net> wrote:
> > "Christopher Browne" <········@acm.org> wrote in message
> > ····························@news20.bellglobal.com...
> >> Quoth Pascal Costanza <··@p-cos.net>:
> >>
> > You clearly don't know much about Ada. ...
>
> Ah you misread me. The contention was that it was preferable for
> functions to be quite long because short functions would lead to a lot
> of debugging of the interfacing between functions.
>
> It seems reasonable to be the case for Ada because Ada functions
> involve relatively verbose static type statements. That fits with the
> claim; if breaking out functionality into extra functions requires
> writing _and debugging_ extra code, this has a cost, and will
> encourage building larger functions.
> --
Sorry for the misreading of your intention. In my experience, we do
write shorter functions in Ada when it is appropriate under the
high cohesion guidelines. I have not seen any need for building
larger functions in Ada. The functions do operate on application
specific types, but that does not require that those functions be
longer. There is certainly nothing in the language to encourage
one to write complex, multi-purpose functions instead of single-minded
functions (or procedures).
So, I am not sure what you mean by the need for "building larger
functions."
Richard Riehle
A long time ago, in a galaxy far, far away, <········@sbcglobal.net> wrote:
> "Christopher Browne" <········@acm.org> wrote in message
> ·······················@news20.bellglobal.com...
>> In the last exciting episode, <········@sbcglobal.net> wrote:
>> > "Christopher Browne" <········@acm.org> wrote in message
>> > ····························@news20.bellglobal.com...
>> >> Quoth Pascal Costanza <··@p-cos.net>:
>> >>
>> > You clearly don't know much about Ada. ...
>>
>> Ah you misread me. The contention was that it was preferable for
>> functions to be quite long because short functions would lead to a lot
>> of debugging of the interfacing between functions.
>>
>> It seems reasonable to be the case for Ada because Ada functions
>> involve relatively verbose static type statements. That fits with the
>> claim; if breaking out functionality into extra functions requires
>> writing _and debugging_ extra code, this has a cost, and will
>> encourage building larger functions.
>> --
> Sorry for the misreading of your intention. In my experience, we do
> write shorter functions in Ada when it is appropriate under the
> high cohesion guidelines. I have not seen any need for building
> larger functions in Ada. The functions do operate on application
> specific types, but that does not require that those functions be
> longer. There is certainly nothing in the language to encourage
> one to write complex, multi-purpose functions instead of single-minded
> functions (or procedures).
>
> So, I am not sure what you mean by the need for "building larger
> functions."
Functions are longer in Ada than in other languages if only because of
the verbosity of the parameter and variable declarations that other
languages commonly elide, ignore, or infer.
(defun foo (this that other)
"Do stuff with this, that, and other"
(loop for this_i in this
for that_i in that
for other_i in other
do (something-involving this_i that_i other_i)))
fits the whole set of parameter declarations into a single line, and
doesn't need any special declarations for the three loop variables.
In contrast, the Ada code would involve something like
procedure foo
(this: in Words.Word;
that: in Words.Word;
other: in Integers.Integer) is
this_i: Word;
that_i: Word;
other_i: Integer;
begin
loop
exit when this.GotLastWord;
this_i := this.Get;
that_i := that.Get;
other_i := other.Get;
do_something_with (this_i, that_i, other_i);
end loop;
end foo;
The "extra stuff" needed in Ada is the six lines of declarations of
the six objects. In effect, simply declaring the objects in Ada takes
more code than is involved in the entire Lisp function (six lines
long).
In some Lisp implementations (CMU/CL comes to mind), strong type
validations can be done despite the fact that the above function
definition never stated types for "this, that, other".
I do see that verbosity as a negative factor. It's well and good for
documenting an API, but when the program winds up with nearly 3x the
lines of code, that makes it harder to fit an entire function on
screen, and my window on seeing the code is THE valuable thing when
trying to understand what's going on.
Regrettably, we have seen the world go into a battle between C++,
Perl, and Java. C++ having something of the "it's a big language"
property of Ada, but with *way* too many competing factors turning it
into a ball of mud. Perl's got the "I can do it in one line!" thing
going, but way too much other ugliness.
If Ada and Objective C were "duking it out" instead of C++ sitting
where it is, we would probably have a little less cruddy software out
there. On the other hand, if Ada became the hot, in-language... :-)
--
select 'cbbrowne' || ·@' || 'gmail.com';
http://linuxdatabases.info/info/languages.html
"If Ada became the hot, in-language you would see a lot more bad code
in Ada."
-- Thaddeus L. Olczyk <······@interaccess.com>, comp.lang.C++
Christopher Browne <········@acm.org> writes:
> In contrast, the Ada code would involve something like
>
> procedure foo
> (this: in Words.Word;
> that: in Words.Word;
> other: in Integers.Integer) is
> this_i: Word;
> that_i: Word;
> other_i: Integer;
> begin
> loop
> exit when this.GotLastWord;
> this_i := this.Get;
> that_i := that.Get;
> other_i := other.Get;
> do_something_with (this_i, that_i, other_i);
> end loop;
> end foo;
To be fair, you are doing list-processing here, which is Lisp's
particular fort�, and you have written the Ada procedure more
verbosely than is necessary. Keeping do_something_with as a call to
another procedure, you could have written foo as
procedure foo (this, that: Words.Word;
other: Integers.Integer) is
begin
while not this.GotLastWord loop
do_something_with (this.Get, that.Get, other.Get);
end loop;
end foo;
--
Leif Roar Moldskred
Got Sfik?
Leif Roar Moldskred <···············@online.no> wrote:
> To be fair, you are doing list-processing here, which is Lisp's
> particular fort�, and you have written the Ada procedure more
> verbosely than is necessary.
I will admit to not knowing anything about Ada beyond how to spell it, but
I think the general point is valid. Different languages impose different
amounts of overhead in writing a new function (I'm not talking function
call execution overhead, but how many lines of source code you need to
type).
In something like C++, adding a new method (even a private one) to a class
will typically require touching two files (the implementation and the
interface). Touching the interface header file may trigger a cascade
reaction causing you to recompile every source file that includes it.
These are the sorts of things which often dissuade people from refactoring.
Roy Smith wrote:
> In something like C++, adding a new method (even a private one) to a class
> will typically require touching two files (the implementation and the
> interface). Touching the interface header file may trigger a cascade
> reaction causing you to recompile every source file that includes it.
> These are the sorts of things which often dissuade people from
refactoring.
If you turn that around, refactoring dissuades people from excessive
coupling. So the symptom - long compile times after short changes - leads to
the solution - refactoring to escalate interfaces free of details that
frequently change. CF "Dependency Inversion Principle".
Also, long-function refactors should entirely be inside a .cpp file. Extract
Method Refactor should produce local 'static' functions, not private
methods, for even more logical and physical encapsulation.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
Phlip wrote:
> Roy Smith wrote:
>
>
>>In something like C++, adding a new method (even a private one) to a class
>>will typically require touching two files (the implementation and the
>>interface). Touching the interface header file may trigger a cascade
>>reaction causing you to recompile every source file that includes it.
>>These are the sorts of things which often dissuade people from
>
> refactoring.
>
> If you turn that around, refactoring dissuades people from excessive
> coupling. So the symptom - long compile times after short changes - leads to
> the solution - refactoring to escalate interfaces free of details that
> frequently change.
Making a virtue out of necessity?
The whole point of "agile" is not spending half your time on perfection,
given that one will regularly be tossing ones code base like a salad as
one improves ones understanding of the problem at hand. Instead one gets
the code Pretty Good (no gross/deliberate violation of sound design) and
then moves on to the next functional challenge (and education).
The idea of designing everything before coding is dead. Never works.
Code is the design (wish I had the URL).
kenny
--
Cells? : http://www.common-lisp.net/project/cells/
Cello? : http://www.common-lisp.net/project/cello/
Cells-Gtk? : http://www.common-lisp.net/project/cells-gtk/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
> Making a virtue out of necessity?
Maybe I wasn't clear. You don't refactor without _several_ reasons to attend
to code. "It ain't decoupled" is only one.
Refactoring ain't rework. If some code somewhere is crufty, but you never
need to add features to it, you have no need to clean it up. Make a virtue
of optimizing your development tasks.
> The whole point of "agile" is not spending half your time on perfection,
> given that one will regularly be tossing ones code base like a salad as
> one improves ones understanding of the problem at hand. Instead one gets
> the code Pretty Good (no gross/deliberate violation of sound design) and
> then moves on to the next functional challenge (and education).
>
> The idea of designing everything before coding is dead. Never works.
> Code is the design (wish I had the URL).
Some teams write excess paperwork to communicate. Some programmers pride
isolation to defend their creative process (and their anxiety while
debugging). So some projects plan their designs for a long time, and some
projects reduce their paperwork burden by only planning interfaces, and
allowing programmers to implement unplanned modules in isolation.
Test coverage makes inspiration, intuition, spontaneity, and collaboration
safe. Relentless testing changes the kinds of communication a project can
leverage to get things done. Everyone knows Agile teams reduce their
paperwork burden, from requirements gathering to source comments. Common
work areas, Shared Code Ownership, self-documenting tests, and laziness are
only parts of the reason.
Time spent "perfecting" an object model before implementing it delays
feedback, so use a "good enough" object model, and implementation procedures
that frequently review the model and maintain its flexibility. Agile
processes use constant team interactions to target a balance between too
little and too much formality.
Agile teams set a very low threshold before changing code. Formal
documentation could never hit a moving target. "Design Smells" are feelings
or attitudes about code quality, which may or may not link to rational
explanations. Engineers who smell them are required (in the presence of
tests and reviewers) to refactor and follow their nose to any improvement.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
·························@twister.nyc.rr.com...
>
> The whole point of "agile" is not spending half your time on perfection,
> given that one will regularly be tossing ones code base like a salad as
> one improves ones understanding of the problem at hand. Instead one gets
> the code Pretty Good (no gross/deliberate violation of sound design) and
> then moves on to the next functional challenge (and education).
>
> The idea of designing everything before coding is dead. Never works.
> Code is the design (wish I had the URL).
>
The agile approach is certainly worthwhile for some kinds of projects. In my
world, "pretty good" is not good enough. We cannot deploy code for certain
kinds of embedded systems that are "pretty good", or "good enough for now."
It would be rather impolite of us to say, after the first few accidental deaths
or maimings, "Well, we got pretty close to the right solution. We learned
a lot from this effort. We're pretty sure we won't kill as many people with
the next software accident."
No. The code is not the design. The design is the design. We have to define
requirements, functional, non-functional, and derived reqiurements before we
start laying down code. We need a sound architectural foundation. We need
to have some clear idea of what problem we are supposed to solve.
Agile methods may be OK for some projects, but there are still a great many
applications for which it is inappropriate and sometimes, dangerous.
Richard Riehle
From: Christopher C. Stacy
Subject: Re: How long should a function be?
Date:
Message-ID: <uzmudcez1.fsf@news.dtpq.com>
<········@sbcglobal.net> writes:
> Agile methods may be OK for some projects, but there are still a great many
> applications for which it is inappropriate and sometimes, dangerous.
What methodology is used to guarantee that the specification of every
last little piece of the embedded system is absolutely correct before
any coding begins? And how is it that the software coded from these
specifications is written in such a way that it does not need debugging?
Inquiring minds want to know, because that's not how embedded systems
have worked in my experience. Instead, you get specifications that
frequently evolve, particularly after demos, and you are faced with
system hardware that does not conform to its device specifications.
(I am thinking of military weapons and safety equipment, C3I,
and the like, as well as more mundane things like telephone
switching equipment, robots, and operating system drivers).
> It would be rather impolite of us to say, after the first few accidental deaths
> or maimings, "Well, we got pretty close to the right solution. We learned
> a lot from this effort. We're pretty sure we won't kill as many people with
> the next software accident."
How would this come about from an "agile" approach to development?
It seems more likely the result of slavishly attempting to
implement some given specification, without regard to reality.
Or maybe I'm missing the point of this "agile" stuff?
As far as I can tell, it's just some hype about a cookbook of
recommendations for coping with incomplete and changing specifications.
The specific "agile" recommendations like pair programming,
and guidelines for how to consider generality in the design modules,
just sounds like normal practices to me. Agility seems like an
excellent idea during the early stages of embedded systems development.
Of course, at some later point you nail down the specifications better;
that's based on all the agile and experimental code that you worked out.
Then you can go back and "refactor" (I hate that buzzword) the software
to ensure that it conforms to what will be the real final specs.
And doesn't "agile" development involve testing?
"Christopher C. Stacy" <······@news.dtpq.com> wrote in message
··················@news.dtpq.com...
> <········@sbcglobal.net> writes:
> > Agile methods may be OK for some projects, but there are still a great many
> > applications for which it is inappropriate and sometimes, dangerous.
>
> What methodology is used to guarantee that the specification of every
> last little piece of the embedded system is absolutely correct before
> any coding begins? And how is it that the software coded from these
> specifications is written in such a way that it does not need debugging?
>
> Inquiring minds want to know, because that's not how embedded systems
> have worked in my experience. Instead, you get specifications that
> frequently evolve, particularly after demos, and you are faced with
> system hardware that does not conform to its device specifications.
> (I am thinking of military weapons and safety equipment, C3I,
> and the like, as well as more mundane things like telephone
> switching equipment, robots, and operating system drivers).
>
I am also speaking about similar kinds of systems.
Your concerns, and those of many agiilists seem to revolve around the
idea that we cannot know the real requirements until we have deployed
the software and watched it work for a bit. There is certainly a lot of
stress testing done on the software and hardware before it is deployed.
The famous incident of the program that turned the aircraft upside down
when the software detected that it had crossed the Equator was discovered
in a flight trainer -- not in a real airplane.
There is nothing wrong with evolving a software product. Some ideas
from agile methods (e.g., pair programming, prioritizing features, etc.)
have real value. I am accustomed to using Ada, a language that,
when used as it supposed to be used, gives one greater assurance that
specifications are working long before anyone begins to program the
algorithms. Of course, no language, by itself, can ensure that the
requiements were correct in the first place.
Agile methods today, just as did planned methods before them, seem
to me to oversimplify the difficulties of building serious software. The
waterfall people, the spiral model enthusiasts, and the RUP advocates,
all come to realize that, in the words of Brooks, "There is no silver
bullet." I realize the agility is an attempt to solve the very problems
inherent in those methods. But software development is far more
complex, as you well know. I sometimes think of software in terms
of Newton's Third Law of Motion.
Newton: "For every action, there is an equal opposite reaction."
Riehle: "For every [software] solution, there is a corresponding
set of new problems."
The agilists, not all of them, are sometimes a little naive about the solutions
they
bring to software. They need to take a careful look at the problems being
created, as well. Barry Boehm's book, "Balancing Agility and Discipline,"
provides some interesting perspectives on "agile" versus "planned" software.
One of my concerns is with phrases such as, "the code is the design," a
dangerous doctrine, when considered by itself. What is the role of
architecture in design? Good architectures do not simply evolve with
the code any more than the architecture of a well-built sky-scraper
evolves with the girders.
I also worry about those who depend on testing (TDD) because no
amount of testing will ensure that the software is designed correctly. In
a design with mulitple concurrent tasks/threads/processes, especially
when those tasks communicate, we cannot test for the absence of
race conditions, eventual deadlock, eventual livelock, etc. This
requires careful design, mathematical analysis, and lots of inspection.
I recall an embedded system design where the programmer used a
data structure that worked fine during testing, over many iterations,
but which began to slow the system over time. It was the kind
of amateurish mistake that would not have occurred if the design
had specified the operating constraints of the system.
Agile methods, when combined with good software architecture design,
and seasoned with the experience gleaned from using other methods,
can offer some excellent help in creating good software. The one thing
that agile doctrine emphasizes that any experience software developer
will graciously acknowledge is that "people build software, not processes."
In the final analysis, even the best engineering, the best languages, the
best testing, and the best processes (if there are any "best") will not
eliminate the need for people who are experienced in developing in
the domain for which the software is intended.
Richard Riehle
From: Christopher C. Stacy
Subject: Re: How long should a function be?
Date:
Message-ID: <ull5w33o1.fsf@news.dtpq.com>
<········@sbcglobal.net> writes:
> "Christopher C. Stacy" <······@news.dtpq.com> wrote in message
> ··················@news.dtpq.com...
> > <········@sbcglobal.net> writes:
> > > Agile methods may be OK for some projects, but there are still a great many
> > > applications for which it is inappropriate and sometimes, dangerous.
> >
> > What methodology is used to guarantee that the specification of every
> > last little piece of the embedded system is absolutely correct before
> > any coding begins? And how is it that the software coded from these
> > specifications is written in such a way that it does not need debugging?
> >
> > Inquiring minds want to know, because that's not how embedded systems
> > have worked in my experience. Instead, you get specifications that
> > frequently evolve, particularly after demos, and you are faced with
> > system hardware that does not conform to its device specifications.
> > (I am thinking of military weapons and safety equipment, C3I,
> > and the like, as well as more mundane things like telephone
> > switching equipment, robots, and operating system drivers).
> >
> I am also speaking about similar kinds of systems.
>
> Your concerns, and those of many agiilists seem to revolve around the
> idea that we cannot know the real requirements until we have deployed
> the software and watched it work for a bit.
Deployed? Where did I say anything remotely like that?
Christopher C. Stacy wrote:
> Or maybe I'm missing the point of this "agile" stuff?
> As far as I can tell, it's just some hype about a cookbook of
> recommendations for coping with incomplete and changing specifications.
If the specs don't change, "Agile" is still useful. As a design technique,
it finds a path towards a good design, where each step on that path is also
a good design that could be deployed and used.
The "non Agile" or "Agile is bad for Project X" idea is the idea that
certain projects must be designed in the absense of feedback. Don't delay
feedback - that's dangerous.
> Then you can go back and "refactor" (I hate that buzzword)
Deal. You refactor, just a little, continuously. That lowers the odds you'l
need a big refactor.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
From: Christopher C. Stacy
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <uhdgk33gh.fsf@news.dtpq.com>
"Phlip" <·········@yahoo.com> writes:
> Christopher C. Stacy wrote:
>
> > Or maybe I'm missing the point of this "agile" stuff?
> > As far as I can tell, it's just some hype about a cookbook of
> > recommendations for coping with incomplete and changing specifications.
>
> If the specs don't change, "Agile" is still useful. As a design technique,
> it finds a path towards a good design, where each step on that path is also
> a good design that could be deployed and used.
>
> The "non Agile" or "Agile is bad for Project X" idea is the idea that
> certain projects must be designed in the absense of feedback. Don't delay
> feedback - that's dangerous.
>
> > Then you can go back and "refactor" (I hate that buzzword)
>
> Deal. You refactor, just a little, continuously. That lowers the odds you'l
> need a big refactor.
I don't mean that I hate "refactoring", I mean that I think its
silly to have invented that buzzword to describe what's going on there.
The programming techniques described by the "agile" crowd are
just what some people have been doing for decades (only without
the buzzaords). I suppose it's nice that someone write a book
telling people something aout how to program computers, after
all this time. It just scares me to wonder that it was needed,
that's all.
From: Peter Seibel
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <m3is10lc9c.fsf@gigamonkeys.com>
······@news.dtpq.com (Christopher C. Stacy) writes:
> "Phlip" <·········@yahoo.com> writes:
>> Deal. You refactor, just a little, continuously. That lowers the
>> odds you'l need a big refactor.
>
> I don't mean that I hate "refactoring", I mean that I think its
> silly to have invented that buzzword to describe what's going on
> there.
Hmmm. What was the "real" word that "refactor" is a buzzword for?
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Hmmm. What was the "real" word that "refactor" is a buzzword for?
Here's how to cause lots of rework. Collect many requirements, then design
them all, then release them all. When you surprise the customer and get
change requests, you may need to edit some requirements. That requires
redesign, etc. This is an example of process waste.
Was that the word you were (smugly) thinking of?
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
From: Peter Seibel
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <m38y1wl7r8.fsf@gigamonkeys.com>
"Phlip" <·········@yahoo.com> writes:
> Peter Seibel wrote:
>
>> Hmmm. What was the "real" word that "refactor" is a buzzword for?
>
> Here's how to cause lots of rework. Collect many requirements, then
> design them all, then release them all. When you surprise the
> customer and get change requests, you may need to edit some
> requirements. That requires redesign, etc. This is an example of
> process waste.
Yes. Though I'm not sure why you're telling me.
> Was that the word you were (smugly) thinking of?
Huh? I'm not thinking of any word. I'm asking Christophe. He's the one
who called "refactor" a buzzword. I personally think "refactor" is a
fine word than names a concept (making changes to software that don't
affect it's functionality but do improve it's internal quality) that
deserves to have its own name.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
> > Was that the word you were (smugly) thinking of?
>
> Huh? I'm not thinking of any word.
Sorry; I'm a little sensitive today.
Christophe just meant that a project should flow and not give names to the
various aspects of that flow.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
Peter Seibel <·····@gigamonkeys.com> writes:
> "Phlip" <·········@yahoo.com> writes:
>
>> Was that the word you were (smugly) thinking of?
>
> Huh? I'm not thinking of any word. I'm asking Christophe. He's the one
> who called "refactor" a buzzword.
I'm aware that there is more than one Christophe in the forum in which
I'm reading this, but I believe this exact same confusion has occurred
before. You were, presumably, non-smugly asking Christopher C. Stacy
about the non-buzzword version of refactor; for what it's worth,
before the invention of "refactor" I'd probably have said "revise".
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>> "Phlip" <·········@yahoo.com> writes:
>>
>>> Was that the word you were (smugly) thinking of?
>>
>> Huh? I'm not thinking of any word. I'm asking Christophe. He's the one
>> who called "refactor" a buzzword.
>
> I'm aware that there is more than one Christophe in the forum in which
> I'm reading this, but I believe this exact same confusion has occurred
> before. You were, presumably, non-smugly asking Christopher C. Stacy
> about the non-buzzword version of refactor; for what it's worth,
> before the invention of "refactor" I'd probably have said "revise".
Bah, I actually went and checked which one I was replying to but
despite that still managed to leave off the "r". Sorry about that.
-Peter
P.S. FWIW, I still think "refactor" has a useful meaning that's
distinct from "revise" though "revise" is a lot closer than "rewrite".
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
"Phlip" <·········@yahoo.com> wrote in message
·······················@newssvr19.news.prodigy.com...
> Peter Seibel wrote:
>
>> Hmmm. What was the "real" word that "refactor" is a buzzword for?
>
> Here's how to cause lots of rework. Collect many requirements, then design
> them all, then release them all. When you surprise the customer and get
> change requests, you may need to edit some requirements. That requires
> redesign, etc. This is an example of process waste.
>
> Was that the word you were (smugly) thinking of?
>
Hmmm, active listening, followed by switching the subject. The work of
experts
The word is Hacking as in Hacking out the design
> --
> Phlip
> http://www.c2.com/cgi/wiki?ZeekLand
>
>
>
David Lightstone wrote:
> "Phlip" <·········@yahoo.com> wrote in message
> ·······················@newssvr19.news.prodigy.com...
> > Peter Seibel wrote:
> >
> >> Hmmm. What was the "real" word that "refactor" is a buzzword for?
> >
> > Here's how to cause lots of rework. Collect many requirements, then design
> > them all, then release them all. When you surprise the customer and get
> > change requests, you may need to edit some requirements. That requires
> > redesign, etc. This is an example of process waste.
> >
> > Was that the word you were (smugly) thinking of?
> >
> Hmmm, active listening, followed by switching the subject. The work of
> experts
>
> The word is Hacking as in Hacking out the design
>
>
I'm new to the thread but I'll still put my two cents.
In one of my multiple travels througt the internet in search for useful
information. I stumbled across programs that would analyze huge amounts
of code and find nonexplicit relationships in the code. In this case C
or C++, I can't remember.
This would be a very useful tool for the case of a new team taking over
legacy code that works and trying to make sense out of it. A lot of
people would argue that is much better to start from scratch because
technology changes ...blah blah blah. That all depends on the amount of
code and how much access do we have to the knowledge embeded on the
lines of the source code. This knowledge might be very valuable and we
might want to rescue it form the ashes.
Anyway, following the idea; Say we had several request of changes to
the code. A "refactoring" tool would allow a team of programmers to
slowly make design changes to the code until it's architecture took in
the changes nicely. This would not be a one time two step process, more
like complimentary activities in a process. If our code editors were
more interactive this design changes (refactorings) would be made part
of them.
OK, there you are.
PD. I do also dislike buzzwords, like any commonsensical programmer
should
arthernan wrote:
> This would be a very useful tool for the case of a new team taking over
> legacy code that works and trying to make sense out of it. A lot of
> people would argue that is much better to start from scratch because
> technology changes ...blah blah blah. That all depends on the amount of
> code and how much access do we have to the knowledge embeded on the
> lines of the source code. This knowledge might be very valuable and we
> might want to rescue it form the ashes.
>
> Anyway, following the idea; Say we had several request of changes to
> the code. A "refactoring" tool would allow a team of programmers to
> slowly make design changes to the code until it's architecture took in
> the changes nicely. This would not be a one time two step process, more
> like complimentary activities in a process. If our code editors were
> more interactive this design changes (refactorings) would be made part
> of them.
How much experience have you with tests?
If you were to pick between two generally equal projects to join, you would
pick the one that had wall-to-wall unit tests.
You use them to make changes safe.
If you want to add features, or upgrade the design, you can change the code
while never departing very far from running tests. This, in turn, makes the
odds of a big bug hunt very low. When tests fail, you have the option
Tests ARE a "refactoring tool". The "refactoring browsers" we have heard of
are just elaborate keyboard shortcuts. None of them are perfect, so you
should always run all the tests between each tiny step of a refactor. The
ability to do this generally leads to code is clean and doesn't need to be
refactored.
(And please don't feed the troll;)
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
> If you want to add features, or upgrade the design, you can change the
code
> while never departing very far from running tests. This, in turn, makes
the
> odds of a big bug hunt very low. When tests fail, you have the option
of hitting Undo until the tests pass again.
(And no programming after 10 pm, either!!)
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
"Phlip" <·········@yahoo.com> wrote in message
·························@newssvr31.news.prodigy.com...
>
> (And no programming after 10 pm, either!!)
>
In 1964, in an issue of IBM's magazine, THINK, there was an article that
included the phrase,
"The last act of a dying organization is to enlarge the rulebook."
The author, whose name I have forgotten due to the passage of time
since I first read the article, was focused on the kind of arbitrary
rules that people invent that have no scientific basis, no empirical
foundation, and no rationale beyond difficult to support anecdotes.
As an example, consider the company on the verge of bankruptcy
where the HR department suddenly institutes dress code standards,
along with other arbitrary rules.
This idea can also be applied to software practice. I have, during
my forty years of software practice, seen so many of these little rules
come and go that, were I to attempt a list of them, I would be writing
for at least three or four days non-stop. When modularity first became
a watchword, then a rule, the approaches to this were often so silly
that I cannot help but wonder what we might have been smoking.
Some of the most entertaining, and ridiculous, rules evolved after
Dijkstra's letter the CACM, "Go To Considered Harmful." The
many misinterpretations of that article (most people only read the
title rather than the well-reasoned content), led to such an
abundance of absurdity that, reflecting on the consequences, I
am sometimes reminded of the phrase from "bodice rippers",
"seduced and abandoned."
The list, as I noted earlier, would go on for a long time. Now we
have XP, Agile Modeling, RUP, TDD, and a whole host of new
methods, all of which have much to commend them. In the hands
of experienced, competent practitioners who understand how to
reason about risks and consequences, these are useful ideas. In
the hands of dogmatists, bureaucrats, and those looking for a quick
set of solutions to the complexity inherent in software, uncritical
adoption of these new methods can be dangerous.
Let's be a little careful about making up rules we cannot possibly
keep. Let's understand that, just as process does not build systems,
neither do rules. The whole point of agility is to give people the
tools, concepts, and methods necessary to build quality software,
not to dictate a new set of rules.
Someone once said that "Every political system contains within itself
the seeds of its own destruction." The same can be said of any
system when that system is carried to extreme (no pun on XP
intended).
Richard Riehle
From: xpyttl
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <3nFre.555$mD6.56@fe07.lga>
<········@sbcglobal.net> wrote in message
······················@newssvr13.news.prodigy.com...
> Some of the most entertaining, and ridiculous, rules evolved after
> Dijkstra's letter the CACM, "Go To Considered Harmful." The
> many misinterpretations of that article (most people only read the
> title rather than the well-reasoned content), led to such an
> abundance of absurdity that, reflecting on the consequences, I
> am sometimes reminded of the phrase from "bodice rippers",
> "seduced and abandoned."
hehe ....
Back then I was making the transition from Fortran-60 to PL/I (!). PL/I had
this marvelous 'on condition' statement that let me replace what would have
been goto's in Fortran with, basically, nothing. THe result was amazingly
opaque code that would suddenly transfer control to some other part of the
program for no apparent reason. It caused me to question just how bad goto's
really were.
Of course, there were all those Fortran zealots who wanted to incorporate a
"computed come from" to the language to avoid goto's.
..
xpyttl wrote:
> hehe ....
>
> Back then I was making the transition from Fortran-60 to PL/I (!). PL/I
had
> this marvelous 'on condition' statement that let me replace what would
have
> been goto's in Fortran with, basically, nothing. THe result was amazingly
> opaque code that would suddenly transfer control to some other part of the
> program for no apparent reason. It caused me to question just how bad
goto's
> really were.
InterCal has that licked with the "ComeFrom" statement.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
adaworks wrote:
> Phlip wrote:
> > (And no programming after 10 pm, either!!)
> >
> In 1964, in an issue of IBM's magazine, THINK, there was an article that
> included the phrase,
>
> "The last act of a dying organization is to enlarge the rulebook."
Thanks for the sermon, but the context:
I wrote a post that pointed out, again, that super-high iterations with
automated checks permit both TDD and SPARKS zealots to hit Undo to back out
of problems, preventing the need to debugging.
Then I forgot to finish the sentence, around 9:57 pm.
I replied to myself, finished the sentence, and pretended to supply a feeble
excuse, that I was now officially too tired to THINK, because it was after
10 pm. (I am aware that folks read USENET in times, and timezones, different
from the authors. Please spare me the next lecture.)
XP supports the explicit rule "They're just rules"; authors everywhere have
been softening the word "rule" to "guideline" or similar, and I'm honestly
quite offended that you are so motivated to find me shallow and derivative
enough to attempt to flatter the Agile Alliance masters with vain mockery by
seriously inventing such a stupid rule.
Program whenever you feel like it!
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
<·········@hotmail.com> wrote in message
·····························@g49g2000cwa.googlegroups.com...
>
>
> David Lightstone wrote:
>> "Phlip" <·········@yahoo.com> wrote in message
>> ·······················@newssvr19.news.prodigy.com...
>> > Peter Seibel wrote:
>> >
>> >> Hmmm. What was the "real" word that "refactor" is a buzzword for?
>> >
>> > Here's how to cause lots of rework. Collect many requirements, then
>> > design
>> > them all, then release them all. When you surprise the customer and get
>> > change requests, you may need to edit some requirements. That requires
>> > redesign, etc. This is an example of process waste.
>> >
>> > Was that the word you were (smugly) thinking of?
>> >
>> Hmmm, active listening, followed by switching the subject. The work of
>> experts
>>
>> The word is Hacking as in Hacking out the design
>>
>>
>
> I'm new to the thread but I'll still put my two cents.
>
> In one of my multiple travels througt the internet in search for useful
> information. I stumbled across programs that would analyze huge amounts
> of code and find nonexplicit relationships in the code. In this case C
> or C++, I can't remember.
Theoretically such tools certainly would be useful. I have never seen them
in action, so they are on par with the search for the Holy Grail.
(in this case a machine that can appear to think)
>
> This would be a very useful tool for the case of a new team taking over
> legacy code that works and trying to make sense out of it. A lot of
> people would argue that is much better to start from scratch because
> technology changes ...blah blah blah. That all depends on the amount of
> code and how much access do we have to the knowledge embeded on the
> lines of the source code. This knowledge might be very valuable and we
> might want to rescue it form the ashes.
The refactoring argument or rhetoric, depending on your perspective, is
based upon having a new development, not the restructuring of a legacy
system.
With a legacy system, you know a priori that which you must achieve and can
choose both a reasonable arthitecture and implementaion schedule. In the
proverbial refactoring (aka hacking) oriented development there are no
guarentees that the requirements can be achieved (because they may
substancially be changed mid -tream), that the candidate architecture is
scalable (nothing like mis-estimating the thruput requirements) or for that
matter even close to correct. (ie devoid of obvious race conditions).
The intent is little more than we will fix the problems as they are
discovered (sugar coated with a tenuous relationship to darwin and the
thousands of years it took for new species to evolve)
>
> Anyway, following the idea; Say we had several request of changes to
> the code. A "refactoring" tool would allow a team of programmers to
> slowly make design changes to the code until it's architecture took in
> the changes nicely. This would not be a one time two step process, more
> like complimentary activities in a process. If our code editors were
> more interactive this design changes (refactorings) would be made part
> of them.
>
>
>
>
> OK, there you are.
>
> PD. I do also dislike buzzwords, like any commonsensical programmer
> should
>
From: Paul Sinnett
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <HmSme.220$vS6.145@amstwist00>
Peter Seibel wrote:
> Hmmm. What was the "real" word that "refactor" is a buzzword for?
Rewrite.
From: Peter Seibel
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <m3is10j7a0.fsf@gigamonkeys.com>
Paul Sinnett <············@yahoo.co.uk> writes:
> Peter Seibel wrote:
>> Hmmm. What was the "real" word that "refactor" is a buzzword for?
>
> Rewrite.
I'm not sure that captures the notion of explicitly *not* changing the
functionality. You might say, "this program doesn't have the feature's
I need--I'm going to rewrite it". But you wouldn't say the same thing,
replacing "rewrite" with "refactor". Similarly, "refactor" importantly
implies that one is proceeding in small steps such that the program's
functionality is the same after each step--the program is never "in
pieces all over the floor" the way a program in the midst of being
rewritten often is.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Paul Sinnett writes:
>
> > Peter Seibel wrote:
> >> Hmmm. What was the "real" word that "refactor" is a buzzword for?
> >
> > Rewrite.
>
> I'm not sure that captures the notion of explicitly *not* changing the
> functionality. You might say, "this program doesn't have the feature's
> I need--I'm going to rewrite it". But you wouldn't say the same thing,
> replacing "rewrite" with "refactor". Similarly, "refactor" importantly
> implies that one is proceeding in small steps such that the program's
> functionality is the same after each step--the program is never "in
> pieces all over the floor" the way a program in the midst of being
> rewritten often is.
It's difficult to under-emphasize the importance of that last point. No
matter how big the refactor - from one design to the other - the program is
never too far away from a state where it can be integrated, featurized,
deployed, or delivered. If the tests don't care, the customer doesn't care
that an executable came from source with half one design and half another.
Rewrite don't mean that. It means you go back before going forward again.
Halfway thru a rewrite, you have no deliverable.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
Peter Seibel wrote:
> Paul Sinnett <············@yahoo.co.uk> writes:
>
>
>>Peter Seibel wrote:
>>
>>>Hmmm. What was the "real" word that "refactor" is a buzzword for?
>>
>>Rewrite.
>
>
> I'm not sure that captures the notion of explicitly *not* changing the
> functionality.
uh-huh, but "rewrite" has bigger problems than that. It is simply wrong,
conveying nothing of the specifics in mind when the term refactoring
caught on. It is a superset kinda thang, like saying "motion" is an
adequate substitute for "hopscotch". Refactoring means reshuffling
existing code, usually deleting some code no longer necessary because of
the design improvement.
Is that a rewrite? Sure, and hopscotch is motion.
How about "reorganize"? That is what companies call their upheavals
(also usually involving deletions).
kt
From: Paul Sinnett
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <C23ne.275$vS6.93@amstwist00>
Peter Seibel wrote:
> Paul Sinnett <············@yahoo.co.uk> writes:
>> Peter Seibel wrote:
>>
>>> Hmmm. What was the "real" word that "refactor" is a
>>> buzzword for?
>>
>> Rewrite.
>
> I'm not sure that captures the notion of explicitly *not*
> changing the functionality. You might say, "this program
> doesn't have the feature's I need--I'm going to rewrite it".
You might. But how are you going to re-write something that has
yet to be written (ie. the new features)?
The reason, I think, that the term "refactor" evolved, was to
distinguish what a writer means by re-write and what, for
example, a Hollywood exec. means: the latter being somewhat
ironic. What they mean is "we didn't like your story so we wrote
one of our own and cut and pasted some of your dialogue /
characters / scenes into it..."
The problem with trying to distinguish using the new term is that
it will be used in exactly the same way by exactly the same type
of insincere persons. "I refactored your function," meaning... I
think you can guess what it might mean.
I think of re-writing in the Hemingway sense:
Paris Review: How much rewriting do you do?
Hemingway: It depends. I rewrote the ending to A Farewell To
Arms, the last page of it, thirty-nine times before I was
satisfied.
Paris Review: Was there some technical problem there? What was
it that stumped you?
Hemingway: Getting the words right.
From: Peter Seibel
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <m3ekbnhz6k.fsf@gigamonkeys.com>
Paul Sinnett <············@yahoo.co.uk> writes:
> Peter Seibel wrote:
>> Paul Sinnett <············@yahoo.co.uk> writes:
>>> Peter Seibel wrote:
>>>
>>>> Hmmm. What was the "real" word that "refactor" is a buzzword for?
>>> Rewrite.
>> I'm not sure that captures the notion of explicitly *not* changing
>> the functionality. You might say, "this program doesn't have the
>> feature's I need--I'm going to rewrite it".
>
> You might. But how are you going to re-write something that has yet
> to be written (ie. the new features)?
The program has already been written (without certain features). Now
it can be rewritten (possibly with those features). What's the
problem?
> The reason, I think, that the term "refactor" evolved, was to
> distinguish what a writer means by re-write and what, for
> example, a Hollywood exec. means: the latter being somewhat
> ironic. What they mean is "we didn't like your story so we wrote
> one of our own and cut and pasted some of your dialogue /
> characters / scenes into it..."
Hmmm. Speaking with my writer's hat on when I say I'm going to
/rewrite/ something I usually mean I'm going to throw away what I've
got and start over from scratch. However if I said I was going to
/revise/ something, then that'd imply something more like what I do
when I refactor code. However I still think "refactor" has a stronger
implication of of "not changing the functionality" than "revise" does.
> The problem with trying to distinguish using the new term is that it
> will be used in exactly the same way by exactly the same type of
> insincere persons. "I refactored your function," meaning... I think
> you can guess what it might mean.
Well, just because people tend to ignore nice distinctions of meaning
(particularly when looking for euphemisms to describe their own
behavior) doesn't mean that there's no distinction to be made.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Paul Sinnett
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <w2rne.387$vS6.209@amstwist00>
Peter Seibel wrote:
> Hmmm. Speaking with my writer's hat on when I say I'm going to
> /rewrite/ something I usually mean I'm going to throw away
> what I've got and start over from scratch.
The equivalent method in refactoring is named "substitute
algorithm". If the new code fails to carry out some important
function of the original, then it's not a viable substitute. It's
also not a viable rewrite - for the same reason.
> However if I said I was going to /revise/ something, then
> that'd imply something more like what I do when I refactor
> code.
My understanding of /revise/ in this context is to change or
correct the meaning of something. I hope that's not what you had
in mind since it's not even close to the originally intended
meaning of refactoring.
> just because people tend to ignore nice distinctions of
> meaning (particularly when looking for euphemisms to describe
> their own behavior) doesn't mean that there's no distinction
> to be made.
I agree. But the same can be said of write, rewrite, and revise:
write ~ say something ~ code
rewrite ~ say the same thing a different way ~ refactor
revise ~ say something else ~ debug or modify
Paul Sinnett wrote:
> Peter Seibel wrote:
>
>> Hmmm. What was the "real" word that "refactor" is a buzzword for?
>
>
> Rewrite.
Perestrojca :)
Cheers
--
Marco
Marco Antoniotti wrote:
> > Rewrite.
>
> Perestrojca :)
Did that pass its tests?
If not, did they undo their changes and start again?
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
Marco Antoniotti wrote:
>
>
> Paul Sinnett wrote:
>
>> Peter Seibel wrote:
>>
>>> Hmmm. What was the "real" word that "refactor" is a buzzword for?
>>
>>
>>
>> Rewrite.
>
>
> Perestrojca :)
Excellent! But bloodless. My refactorings are more like the Cultural
Revolution.
kenny
--
Cells? : http://www.common-lisp.net/project/cells/
Cello? : http://www.common-lisp.net/project/cello/
Cells-Gtk? : http://www.common-lisp.net/project/cells-gtk/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> Marco Antoniotti wrote:
>> Paul Sinnett wrote:
>>
>>> Peter Seibel wrote:
>>>
>>>> Hmmm. What was the "real" word that "refactor" is a buzzword for?
>>>
>>>
>>>
>>> Rewrite.
>> Perestrojca :)
>
> Excellent! But bloodless. My refactorings are more like the Cultural
> Revolution.
Mao Ze Dong would have been proud of you! ;-)
David
--
David Trudgett
http://www.zeta.org.au/~wpower/
"... we think the price is worth it."
-- US Ambassador Madeleine Albright, when asked if the deaths of
half a million Iraqi children were a price worth paying for
sanctions
On Tue, 31 May 2005 07:12:06 +0200, Paul Sinnett
<············@yahoo.co.uk> wrote:
>Peter Seibel wrote:
>> Hmmm. What was the "real" word that "refactor" is a buzzword for?
>
>Rewrite.
Ah, but refactor isn't rewrite.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
From: Paul Sinnett
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <Nlxoe.638$vS6.606@amstwist00>
Ron Jeffries wrote:
>> Peter Seibel wrote:
>>> Hmmm. What was the "real" word that "refactor" is a
>>> buzzword for?
>>
>> Rewrite.
>
> Ah, but refactor isn't rewrite.
Is.
From: Arafangion
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <42a2a65d$1@dnews.tpgi.com.au>
Paul Sinnett wrote:
> Ron Jeffries wrote:
>
>>> Peter Seibel wrote:
>>>
>>>> Hmmm. What was the "real" word that "refactor" is a
>>>> buzzword for?
>>>
>>>
>>> Rewrite.
>>
>>
>> Ah, but refactor isn't rewrite.
>
>
> Is.
imho, refactoring *is* rewriting, but not necessarily all of an app.
In general, one aims to change the design a bit while modifying the code
as little as possible.
So if refactoring is doing the factoring again, what was the
original factoring? In mathematics, we speak of factoring,
but I cannot recall anyone deliberately using the term,
refactoring. I suppose we do refactor in mathematics,
but we usually simply do a continuous process of factoring.
So, how is refactoring different from continuous factoring?
It seems to me that those who speak of refactoring are actually
talking about continually simplifying the code, making modules
more cohesive, where appropriate, and getting control over
coupling issues. So, refactoring is probably just a process of
managing the cohesion and coupling of the code. This is not
particularly new. We have been doing it from the beginnings
of software. It is nice, I suppose, to have a special term for
it, though the choice of the word seems a little strange to me.
Richard Riehle
········@sbcglobal.net wrote:
> So if refactoring is doing the factoring again, what was the
> original factoring? In mathematics, we speak of factoring,
> but I cannot recall anyone deliberately using the term,
> refactoring.
It is just a metaphor. An agile programmer tackles a problem by tossing
off some reasonable code. They do not spend eighteen months collecting
requirements to determine all and every bit of functionality hence code
required. (In vain, I think we all know by now.) They get away with this
if they are using an agile language such as Common Lisp, which lets you
change a class hierarchy while a program is running and then continue,
as when a backtrace occurs and one realizes, doh!, I need this behavior
(but not that) from this other superclass. OK, it is not /that/ hard to
quit and restart, but it is a blast being able to slice and dice the
class hierarchy and then retry a function call with existing instances
of the affected classes. And, more relevantly, it is nice not having to
sit through a massive recompile/link of every line of code extant.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
Kenny Tilton wrote:
>
> ········@sbcglobal.net wrote:
> > So if refactoring is doing the factoring again, what was the
> > original factoring? In mathematics, we speak of factoring,
> > but I cannot recall anyone deliberately using the term,
> > refactoring.
>
> It is just a metaphor.
Of course I agree with you in spirit, but I "need" to bust on your verbiage
here.
"Refactor" is absolutely not a metaphor, it is a distinction. That's a
definition that continuously and unambiguously separates two groups. Any two
software engineers who know the definition (regardless whether they agree
with it) can observe a third engineer and determine if they are Refactoring
or not. The two will always reach the same conclusion, in isolation from one
another. Okay, now she's adding new code. Okay, now she's refactoring it.
> An agile programmer tackles a problem by tossing
> off some reasonable code.
For the newbs: "...with the _intent_ to refactor it, very soon. The
reasonable code is in a state ready to be refactored."
Some methodologies cut a design, and then debug until the behavior is right.
We test-first behavior, then refactor until the design is better. Nailing
down the behavior first, then drawing the lines of control together under
test, improves bug resistance.
> They do not spend eighteen months collecting
> requirements to determine all and every bit of functionality hence code
> required. (In vain, I think we all know by now.) They get away with this
> if they are using an agile language such as Common Lisp, which lets you
> change a class hierarchy while a program is running and then continue,
> as when a backtrace occurs and one realizes, doh!, I need this behavior
> (but not that) from this other superclass.
TDDers should stop and start an entire program, now and then, to make sure
the entire thing passes all tests in one batch.
> OK
"Okay" is a word, not an acronym, from the Wolof language in North Africa.
It entered English at a time when the USA's outsourced labor was not allowed
to learn to write, and it sounded like an acronym, so various newspapers
picked that up as a sly joke, which everyone back then would "get".
Dictionaries incorrectly start with this backronym, misinterpreting that
mileux. "OK" independently appeared as an acronym in many different and
widespread contexts during that period, indicating a common verbal origin.
> it is not /that/ hard to
> quit and restart, but it is a blast being able to slice and dice the
> class hierarchy and then retry a function call with existing instances
> of the affected classes. And, more relevantly, it is nice not having to
> sit through a massive recompile/link of every line of code extant.
But that's when I ink evil comics.
This explains a lot!
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
<········@sbcglobal.net> writes:
> It seems to me that those who speak of refactoring are actually
> talking about continually simplifying the code, making modules
> more cohesive, where appropriate, and getting control over
> coupling issues. So, refactoring is probably just a process of
> managing the cohesion and coupling of the code. This is not
> particularly new. We have been doing it from the beginnings
> of software. It is nice, I suppose, to have a special term for
> it, though the choice of the word seems a little strange to me.
Not at all.
Compare:
a*b*x + a*b*y = a*b*(x+y)
with:
(defun frob-orange (orange)
(do-stuff-1 orange)
(do-stuff-2 orange)
(do-orange-specific-stuff orange))
(defun frob-apple (apple)
(do-stuff-1 apple)
(do-stuff-2 apple)
(do-apple-specific-stuff apple))
===
(defun frob-fruit (self)
(do-stuff-1 self)
(do-stuff-2 self))
(defun frob-orange (self)
(frob-fruit self)
(do-orange-specific-stuff self))
(defun frob-apple (self)
(frob-fruit self)
(do-apple-specific-stuff self))
--
__Pascal Bourguignon__ http://www.informatimago.com/
Paul Sinnett <············@yahoo.co.uk> writes:
> Ron Jeffries wrote:
>> Ah, but refactor isn't rewrite.
>
> Is.
What is this, comp.lang.lisp or kindergarten? The extremos
have a very precise meaning in mind for the word "refactor",
and you're not liking it isn't gonna change anything.
Grow up.
Alain Picard wrote:
> Paul Sinnett <············@yahoo.co.uk> writes:
>> Ron Jeffries wrote:
>>> Ah, but refactor isn't rewrite.
>>
>> Is.
>
> What is this, comp.lang.lisp or kindergarten? ... Grow up.
What tragic irony! :-)
I apologise for underestimating the audience.
> The extremos have a very precise meaning in mind for the word
> "refactor", and you're not liking it isn't gonna change
> anything.
You assume that I don't like it. I do. I think it's a great
nonce-word. But it's being used as a buzzword whether I like
it or not. The question was, "what is it a buzzword for?"
I expect that the term "refactor" will be used and abused
in exactly the same way as the term "rewrite" has.
Ron Jeffries wrote:
> On Tue, 31 May 2005 07:12:06 +0200, Paul Sinnett
> <············@yahoo.co.uk> wrote:
>
>
>>Peter Seibel wrote:
>>
>>>Hmmm. What was the "real" word that "refactor" is a buzzword for?
>>
>>Rewrite.
>
>
> Ah, but refactor isn't rewrite.
>
People used to talk about "cleaning up" code. Now they talk about
refactoring.
Tim Josling
Tim Josling wrote:
> Ron Jeffries wrote:
>
>> On Tue, 31 May 2005 07:12:06 +0200, Paul Sinnett
>> <············@yahoo.co.uk> wrote:
>>
>>
>>> Peter Seibel wrote:
>>>
>>>> Hmmm. What was the "real" word that "refactor" is a buzzword for?
>>>
>>>
>>> Rewrite.
>>
>>
>>
>> Ah, but refactor isn't rewrite.
>
>
> People used to talk about "cleaning up" code. Now they talk about
> refactoring.
I can refactor perfect code, but I cannot clean it up.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
Kenny Tilton wrote:
> I can refactor perfect code, but I cannot clean it up.
The clean spot moves over time. What worked today might not be good enough
tomorrow.
> "If you plan to enter text which our system might consider to be
> obscene, check here to certify that you are old enough to hear the
> resulting output." -- Bell Labs text-to-speech interactive Web page
And the odds this will reduce our lawsuit exposure from irrate parents is..?
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
Phlip wrote:
> Kenny Tilton wrote:
>
>
>>I can refactor perfect code, but I cannot clean it up.
>
>
> The clean spot moves over time. What worked today might not be good enough
> tomorrow.
My point was that "cleaning up" cannot be a synonym for refactoring,
because sometimes I have a very nice function which I eventually
discover contains some subprocessing which is desirable as a standalone
function, or undesirable in calls by a new client. Then I take what had
been a prime to my mind and factor it, such that the original function
now takes a new parameter (to suppress the subprocessing) or it now
calls a new function to do the subprocessing, which new function is now
available to clients.
That is not cleaning up.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
From: Pascal Costanza
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <3gfsakFbpuu6U1@individual.net>
Tim Josling wrote:
> Ron Jeffries wrote:
>
>> On Tue, 31 May 2005 07:12:06 +0200, Paul Sinnett
>> <············@yahoo.co.uk> wrote:
>>
>>> Peter Seibel wrote:
>>>
>>>> Hmmm. What was the "real" word that "refactor" is a buzzword for?
>>>
>>>
>>> Rewrite.
>>
>> Ah, but refactor isn't rewrite.
>
> People used to talk about "cleaning up" code. Now they talk about
> refactoring.
"Cleaning up" is probably quite close. "Refactoring" has gotten the
specific meaning that a program doesn't change its behavior under a
refactoring, in the sense that all the tests of a test suite work as
before. It's possible to formalize this notion by providing
preconditions and postconditions under which a refactoring is
applicable. This in turn allows you to have automatic or semi-automatic
tool support. So, for example, you can move a method down an inheritance
hierarchy if all call sites call it through a respective subclass anyway
(that's the precondition). There are some limitations when your language
supports reflective calls, but in general this seems to work quite well.
As far as I can tell, this specific notion of "refactoring" is
relatively new.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
From: Paul Sinnett
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <ECAoe.656$vS6.394@amstwist00>
Pascal Costanza wrote:
> Tim Josling wrote:
>> People used to talk about "cleaning up" code. Now they talk
>> about refactoring.
>
> "Cleaning up" is probably quite close.
Yes. "Cleaning up" is also close to rewriting as writers use it
in the saying "writing is rewriting."
But if you step over into correcting errors then you're no longer
refactoring: you're debugging. Similarly you're no longer
rewriting: you're revising. In both cases you are changing the
literal meaning of the text.
> "Refactoring" has gotten the specific meaning that a program
> doesn't change its behavior under a refactoring, in the sense
> that all the tests of a test suite work as before. It's
> possible to formalize this notion by providing preconditions
> and postconditions under which a refactoring is applicable.
> This in turn allows you to have automatic or semi-automatic
> tool support.
There is some (very limited at the moment) semi-automatic support
for this in writing tools too. The main difficulty with such
tools is the flexibility of natural language in comparison with
programming languages. However, this is a difference of scale.
Most programming languages also share this feature to a lesser
degree. Somewhere in a programming language definition, you
will find the phrase "the result of this is undefined." A good
tool could present the user with several well defined (but not
necessarily compatible) alternatives.
> As far as I can tell, this specific notion of "refactoring" is
> relatively new.
The word refactoring is relatively new. The origin of the word is
somewhat hazy. But the idea of changing style without changing
content; changing form without changing function; changing
presentation without changing meaning, is so old that it has been
embodied in sayings, maxims, and proverbs. This idea is also
a fundamental part of mathematics (where the 'factor' part comes
from.) The meaning of refactoring will (over time) be defined by
how people use the term and people are generally using the term
as a buzzword for rewriting.
http://www.irregularwebcomic.net/cgi-bin/comic.pl?comic=687
However, the idea of inventing a word to make some precise
distinction is also not new. Here is what the other Fowler
wrote about that in 1908:
> Among other arts and sciences, that of lexicography happens to
> have found convenient a neologism that may here be used to
> help in the very slight classification required for the new
> words we are more concerned with�that is, those whose object
> is literary or general, and not scientific. A 'nonce-word'
> (and the use might be extended to 'nonce-phrase' and
> 'nonce-sense'�the latter not necessarily, though it may be
> sometimes, equivalent to nonsense) is one that is constructed
> to serve a need of the moment. The writer is not seriously
> putting forward his word as one that is for the future to have
> an independent existence; he merely has a fancy to it for
> this once. The motive may be laziness, avoidance of the
> obvious, love of precision, or desire for a brevity or
> pregnancy that the language as at present constituted does not
> seem to him to admit of. The first two are bad motives, the
> third a good, and the last a mixed one. But in all cases it
> may be said that a writer should not indulge in these unless
> he is quite sure he is a good writer.
--
H.W. Fowler (1858�1933). The King�s English, 2nd ed. 1908.
http://www.bartleby.com/116/103.html
Christopher C. Stacy wrote:
> I don't mean that I hate "refactoring", I mean that I think its
> silly to have invented that buzzword to describe what's going on there.
What's silly is changing the design of code at the same time as changing its
behavior. Explicitely doing only one or the other constrains your changes.
Hence, make a word for changing design while leaving behavior the same.
> The programming techniques described by the "agile" crowd are
> just what some people have been doing for decades (only without
> the buzzaords).
Sorry - here's why one as brain-damaged as me _needs_ those buzzwords.
Before those peesa-shit drippy fru-fru XP books came out, I tried _very_
hard to learn the good process that people had been doing for decades. What
I got were books like Booch's Orange book, which was incredibly unreadable.
These books said blah-blah-blah, and made both me and many people I worked
with think they were promoting pure Waterfall. (And I also failed to miss
the concept of virtual methods from reading that specific book, too!)
Don't let my playful self-deprecating attitude fool you - I am a _very_ good
reader. Anything from the Notebooks of Leonardo DaVinci to the Sirens of
Titan by Kurt Vonnegut, Jr...
> I suppose it's nice that someone write a book
> telling people something aout how to program computers, after
> all this time. It just scares me to wonder that it was needed,
> that's all.
What was needed was to say "do this, at this time, call it this, stop when
you get this". What was needed was a description of a healthy lifecycle,
from beginning to end, with a name for each component of that cycle, and
each component described at the necessary scale.
Some people started their careers and got lucky; they fell in with the right
team, under the right guru. Some did not, hence we need books on this topic.
Lots of them.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
From: Christopher C. Stacy
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <u7jhg2yo6.fsf@news.dtpq.com>
"Phlip" <·········@yahoo.com> writes:
> Sorry - here's why one as brain-damaged as me _needs_ those buzzwords.
> Before those peesa-shit drippy fru-fru XP books came out, I tried _very_
> hard to learn the good process that people had been doing for decades. What
> I got were books like Booch's Orange book, which was incredibly unreadable.
What do they teach in school?
From: Pascal Costanza
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <3g1bjuF9oh6dU1@individual.net>
Christopher C. Stacy wrote:
> The programming techniques described by the "agile" crowd are
> just what some people have been doing for decades (only without
> the buzzaords). I suppose it's nice that someone write a book
> telling people something aout how to program computers, after
> all this time. It just scares me to wonder that it was needed,
> that's all.
The practices described in Kent Beck's book about Extreme Programming
are described in a pattern-like form. That is, like in patterns as
discovered by Christopher Alexander (and abused in the well-known Design
Patterns book).
The good thing about patterns is a) that they describe well-known
working solutions to recurring tasks and b) that they can explain why
things work in non-obvious ways. (Design Patterns are vey boring in that
regard.)
Patterns are by definition highly unoriginal. If your reaction is that
they are obvious, then they are probably correct. However, patterns give
you a language to talk about what you do.
Furthermore, what's obvious to you may not be obvious to others.
Aggressive code refactoring without asking other programmers involved in
a project sounds highly dangerous to the uninitiated. It's good to know
how that danger is compensated for by other techniques.
The problem with XP and agile methodologies is that people have started
to use them without reflecting about them. This will create the same
problems like any other development process.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> The problem with XP and agile methodologies is that people have started
> to use them without reflecting about them. This will create the same
> problems like any other development process.
The book /Agile & Iterative Development: A Manager's Guide/ by Craig Larman
contains an amazing statistic. The more closely a team tried to follow
Waterfall, the more likely they were to fail.
I'm not so worried about folks following XP practices without reflecting on
them. Everyone get in the same room, and hit the test button after 1~10
edits. What's to reflect on?
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
From: Christopher C. Stacy
Subject: Re: Agility sucks [Was: How long should a function be?]
Date:
Message-ID: <u3bs42yf6.fsf@news.dtpq.com>
Pascal Costanza <··@p-cos.net> writes:
> Furthermore, what's obvious to you may not be obvious to others.
It's only obvious to me with a lifetime of hindsight, but I was
imagining (wildly?) that these sorts of practices were the
standard fare in undergraduate study of computer programming.
The fact that there are popular press books about it,
and hype and buzzwords, suggests otherwise, sadly.
"Christopher C. Stacy" <······@news.dtpq.com> wrote in message
··················@news.dtpq.com...
> <········@sbcglobal.net> writes:
> > Agile methods may be OK for some projects, but there are still a great many
> > applications for which it is inappropriate and sometimes, dangerous.
>
> What methodology is used to guarantee that the specification of every
> last little piece of the embedded system is absolutely correct before
> any coding begins? And how is it that the software coded from these
> specifications is written in such a way that it does not need debugging?
>
There is no methodology that "guarantees the specifcation of every little
piece of the embedded system is absolutely correct before any coding
begins." It is quite common to begin some coding early, once there
is a roadmap of where we want to go. Incremental development has
a long and respectable history.
Nevertheless, for large-scale projects, it is important to have as complete
a set of requirements as possible, along with a clear vision of what the
software should do when it is finished. Furthermore, a well-formed
concept of the overall architecture is important so the incremental
development does not simply ooze out of moment by moment
concepts of what the user(s) think is important.
For systems over 100,000 SLOC, where the systems engineering
process must be well-coordinated, the work of a lot of developers,
QA people, mathematicians, engineers, and others has to occur
in the right order. This requires some detailed planning and good
project management.
For these large projects, there is no single "user" representative
who understands all facets of the final set of programs at the
level of detail suggested by XP. Instead, the users are the
engineers responsible for various components of the total system,
including the software.
Many of the ideas of XP are useful, but there is a danger in relying
on them to the exclusion of good engineering practice. One of the
most dangerous of the XP practices is excessive dependence on
so-called "test-driven design" to the exclusion of well-defined
requirements, software models, and pre-defined constraints. Testing
is not now, now has it ever been a sufficient approach to ensuring
that the final software product is dependable. This is not to suggest
we should not test. It simply means testing is not enough.
One of the most important ideas in Agile Methods is one that we have
all known for a long time: people build software, not processes. Even
so, processes continue to be important, especially for projects that take
a long time to complete. The idea that we will produce deployable
software, on a large, complex system, in a week or two is something
of a joke -- but not a joke that is very funny when customers are misled
into believing such things.
Again, my concern is with large-scale software systems that involve large
development teams that take a long time to complete. Small systems
can easily follow the XP model religiously. I don't think it will scale
up to a system of a million lines of source code.
Experienced software professionals will choose the right tools for the
job at hand. They will also understand the need for deciding carefully
about what method will most effectively help them achieve the goals
of the project. Sometimes, Agile Methods will be the right choice.
Other times, some hybrid of Agile Methods and planned methods
will be the right choice. We can also choose from RUP, and other
incremental development methods. But, just as the earlier waterfall
people made the mistake of being too doctrinaire about their approach,
future project managers must beware of becoming excessively dogmatic
about the many variations of agility that are being proposed. They must
certainly be careful about promising too much from the use of those
methods. We have learned lessons from the past about this kind of
thing, each time some new approach to software development is
published.
Every solution produces a new set of problems. When we adopt a new
approach to solving the software development problem, we must look
carefully at the (often non-obvious) problems that accompany that solution.
The Agile Methods solution is no different, and it would be naive to think
it is.
Richard Riehle
> Inquiring minds want to know, because that's not how embedded systems
> have worked in my experience. Instead, you get specifications that
> frequently evolve, particularly after demos, and you are faced with
> system hardware that does not conform to its device specifications.
> (I am thinking of military weapons and safety equipment, C3I,
> and the like, as well as more mundane things like telephone
> switching equipment, robots, and operating system drivers).
>
> > It would be rather impolite of us to say, after the first few accidental
deaths
> > or maimings, "Well, we got pretty close to the right solution. We learned
> > a lot from this effort. We're pretty sure we won't kill as many people
with
> > the next software accident."
>
> How would this come about from an "agile" approach to development?
> It seems more likely the result of slavishly attempting to
> implement some given specification, without regard to reality.
>
> Or maybe I'm missing the point of this "agile" stuff?
> As far as I can tell, it's just some hype about a cookbook of
> recommendations for coping with incomplete and changing specifications.
> The specific "agile" recommendations like pair programming,
> and guidelines for how to consider generality in the design modules,
> just sounds like normal practices to me. Agility seems like an
> excellent idea during the early stages of embedded systems development.
> Of course, at some later point you nail down the specifications better;
> that's based on all the agile and experimental code that you worked out.
> Then you can go back and "refactor" (I hate that buzzword) the software
> to ensure that it conforms to what will be the real final specs.
> And doesn't "agile" development involve testing?
In comp.lang.lisp ········@sbcglobal.net wrote:
> Many of the ideas of XP are useful, but there is a danger in relying
> on them to the exclusion of good engineering practice. One of the
> most dangerous of the XP practices is excessive dependence on
> so-called "test-driven design" to the exclusion of well-defined
> requirements, software models, and pre-defined constraints. Testing
> is not now, now has it ever been a sufficient approach to ensuring
> that the final software product is dependable. This is not to suggest
> we should not test. It simply means testing is not enough.
I'm curious about your point here. What I've read of the XP approach
suggests that XPers' idea of "testing" is rather more, well, extreme
than most other folks'.
How much of your "well-defined requirements, software models, and pre-
defined constraints" could be expressed as automatable unit tests? (If,
that is, one cared to do so -- which I'm supposing the XP folks would.)
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
Karl A. Krueger wrote:
> adaworks wrote:
> > Many of the ideas of XP are useful, but there is a danger in relying
> > on them to the exclusion of good engineering practice. One of the
> > most dangerous of the XP practices is excessive dependence on
> > so-called "test-driven design" to the exclusion of well-defined
> > requirements, software models, and pre-defined constraints. Testing
> > is not now, now has it ever been a sufficient approach to ensuring
> > that the final software product is dependable. This is not to suggest
> > we should not test. It simply means testing is not enough.
>
> I'm curious about your point here. What I've read of the XP approach
> suggests that XPers' idea of "testing" is rather more, well, extreme
> than most other folks'.
The leading edge of XP theory is that designs should emerge via testing.
That means if you plan a design, you should only write such tests as force
that design to emerge via refactoring. Anything else - in theory - is higher
risk. You will risk a design more complex than tests can force to exist.
The trailing edge of all of software engineering is the idea - often
forgotten, often renewed - that collecting requirements in huge batches and
attempting to implement all of them is wrong. One must implement high
priority features, attempt to release them, get feedback on them, and use
them to learn which features are now at the next higher priority.
Both these ideals would appear to conflict with the ideal "don't write code
recklessly and endanger thousands of lives". There's nothing reckless about
exerting more discipline than other
Designing in the absense of tests is very hard. It is a false "discipline",
and it feels hard for a reason.
> How much of your "well-defined requirements, software models, and pre-
> defined constraints" could be expressed as automatable unit tests? (If,
> that is, one cared to do so -- which I'm supposing the XP folks would.)
The only ones worth attempting are the ones that can be tested. Given the
generic goal, "don't let anyone hack our server", test the line-item "all
input strings resist SQL insertion attacks."
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
"Phlip" <·········@yahoo.com> wrote in message
·························@newssvr19.news.prodigy.com...
>
> The only ones worth attempting are the ones that can be tested. Given the
> generic goal, "don't let anyone hack our server", test the line-item "all
> input strings resist SQL insertion attacks."
>
How will you devise a test that ensures the absence of a race-condition
when the occurrence of that race-condition may not happen until the
system has been operating continuously for 1000 or more hours?
Richard Riehle
adaworks wrote:
>
> Phlip wrote:
> > The only ones worth attempting are the ones that can be tested. Given
the
> > generic goal, "don't let anyone hack our server", test the line-item
"all
> > input strings resist SQL insertion attacks."
> >
> How will you devise a test that ensures the absence of a race-condition
> when the occurrence of that race-condition may not happen until the
> system has been operating continuously for 1000 or more hours?
How will you deliver without such a test?
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
"Phlip" <·········@yahoo.com> wrote in message
························@newssvr33.news.prodigy.com...
> adaworks wrote:
> >
> > Phlip wrote:
>
> > > The only ones worth attempting are the ones that can be tested. Given
> the
> > > generic goal, "don't let anyone hack our server", test the line-item
> "all
> > > input strings resist SQL insertion attacks."
> > >
> > How will you devise a test that ensures the absence of a race-condition
> > when the occurrence of that race-condition may not happen until the
> > system has been operating continuously for 1000 or more hours?
>
> How will you deliver without such a test?
>
You will design your code to prevent this from occurring. It is not
something you can test, as testing is normally understood.
There are a large number of things we do in software that cannot be
explicitly tested. This is why design is so important. We need to
apply mathematical methods in some cases. Inspection is essential
in other cases. Proven methods are sometimes required.
Dijkstra noted long ago that we cannot test for the absence of errors,
only for the presence of errors. This is why, for safety-critical software,
we find it important to add type safety to the set of approaches we
use in creating dependable software.
Total reliance on testing is a very naive approach to ensuring software
quality. Still, testing is an important part of the process. We don't
want to eliminate it. We simply need to understand that testing alone
cannot be relied upon for a dependable software product.
Richard Riehle
Richard Riehle wrote:
> You will design your code to prevent this from occurring. It is not
> something you can test, as testing is normally understood.
Of course not - you can't test a negative. You can, however, test that your
code matches your design.
> There are a large number of things we do in software that cannot be
> explicitly tested. This is why design is so important.
I fear too many eXtremos have tried to explain "emergent design", and this
has lead to you saying "tested" when you mean "forced to emerge under test
and without up-front design".
I posit the things that a useful definition for the things that can't is
"computer science", but everyone's a scientist...
> Total reliance on testing is a very naive approach to ensuring software
> quality.
Who totally relies on testing?
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
"Phlip" <·········@yahoo.com> wrote in message
·······················@newssvr31.news.prodigy.com...
> Richard Riehle wrote:
>
> > You will design your code to prevent this from occurring. It is not
> > something you can test, as testing is normally understood.
>
> Of course not - you can't test a negative. You can, however, test that your
> code matches your design.
>
You can test that the code you have written does what it is intended to do
under most circumstances. You cannot test to determine that the code will
always do what you want to do. Futhermore, it is difficult to apply a set
of tests that will notify you about malicious code, or code that was inserted
into the program that the designer never intended.
Confirmability is an important principle in software practice. Testing is only
one aspect of confirmability. My concern about Test-driven design is that
many of its devotees rely too much on it, to the exclusion of other, if you
wish,
supplemental, kinds of confirmability.
> > There are a large number of things we do in software that cannot be
> > explicitly tested. This is why design is so important.
>
> I fear too many eXtremos have tried to explain "emergent design", and this
> has lead to you saying "tested" when you mean "forced to emerge under test
> and without up-front design".
>
I see we agree about the importance of design. In particular, I worry about
"emergent design" in the absence of a well-reasoned architecture. Incremental
development has a long and respectable history. Most of us, I think, have
been
using this approach to software long before the current fads of Agility and XP
were introduced. The same is true of continuous testing. Many project
managers adopted the notion of immutable test scripts, even when they were
required to develop under "planned" methods such as cleanroon (where testing
is often deprecated until much later in the process).
> I posit the things that a useful definition for the things that can't is
> "computer science", but everyone's a scientist...
>
We need to move beyond the "scientist" model to the engineering model. Sadly,
few people who specify, design, or create software have any training in any
aspect of engineering. The future of good software practice lies in
engineering,
but not software engineering as commonly thought of today.
> > Total reliance on testing is a very naive approach to ensuring software
> > quality.
>
> Who totally relies on testing?
>
Entirely too many people. Apparently, you are not one of them. Certainly no
experienced software developer will rely entirely on TDD. However, a lot of
novices, and even some idealistic non-novices, are easily proselytized into
adopting the buzzwords without skepticism. Recent converts, to any kind of
dogma, are always annoying. When it comes to software, they are both annoying
and dangerous.
Richard Riehle
adaworks wrote:
> You can test that the code you have written does what it is intended to do
> under most circumstances. You cannot test to determine that the code will
> always do what you want to do. Futhermore, it is difficult to apply a
set
> of tests that will notify you about malicious code, or code that was
inserted
> into the program that the designer never intended.
To whom are you explaining this??
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
I thought I was replying to you, but the message is forum-wide,
so it is for anyone who cares to read it.
Richard Riehle
"Phlip" <·········@yahoo.com> wrote in message
·························@newssvr33.news.prodigy.com...
> adaworks wrote:
>
> > You can test that the code you have written does what it is intended to do
> > under most circumstances. You cannot test to determine that the code will
> > always do what you want to do. Futhermore, it is difficult to apply a
> set
> > of tests that will notify you about malicious code, or code that was
> inserted
> > into the program that the designer never intended.
>
> To whom are you explaining this??
>
> --
> Phlip
> http://www.c2.com/cgi/wiki?ZeekLand
>
>
········@sbcglobal.net wrote:
> "Phlip" <·········@yahoo.com> wrote in message
> ························@newssvr33.news.prodigy.com...
>>>How will you devise a test that ensures the absence of a race-condition
>>>when the occurrence of that race-condition may not happen until the
>>>system has been operating continuously for 1000 or more hours?
>>
>>How will you deliver without such a test?
>>
>
> You will design your code to prevent this from occurring. It is not
> something you can test, as testing is normally understood.
You could test it at some level though.
Run a version of the software that potentially creates the race
condition 200,000,000 times a second rather than the expected 15 times a
second. Maybe you could do this by stripping out the logic not relevant
to the race condition and driving the system to 100%. Run the test on a
16 CPU system instead of a 2 CPU system. Run at 100mhz instead of
2.5ghz. Put timing loops in the critical code to expand out the timing
windows.
Tim Josling
Tim Josling wrote:
> ········@sbcglobal.net wrote:
>
>> "Phlip" <·········@yahoo.com> wrote in message
>> ························@newssvr33.news.prodigy.com...
>>
>>>> How will you devise a test that ensures the absence of a race-condition
>>>
>>>
>>> How will you deliver without such a test?
>>>
>>
>> You will design your code to prevent this from occurring. It is not
>> something you can test, as testing is normally understood.
>
>
> You could test it at some level though.
>
> Run a version of the software that potentially creates the race
> condition 200,000,000 times a second rather than the expected 15 times a
> second. Maybe you could do this by stripping out the logic not relevant
> to the race condition and driving the system to 100%. Run the test on a
> 16 CPU system instead of a 2 CPU system. Run at 100mhz instead of
> 2.5ghz. Put timing loops in the critical code to expand out the timing
> windows.
Yes, there are techniques for coaxing race conditions into occurring
more frequently. But for sufficiently important software (anything
beyond a toy intended only for the personal use of the author) design is
definitely the way to go. Rare indeed is the threaded code which
contains only one race condition; it's none, or many. Once you've found
the first one, the only thing you can know for sure from that point on
is that the code was written by someone who didn't understand
concurrency, and the code can't be trusted.
--
Cameron MacKinnon
Toronto, Canada
Tim Josling wrote:
> Run a version of the software that potentially creates the race
> condition 200,000,000 times a second rather than the expected 15 times a
> second. Maybe you could do this by stripping out the logic not relevant
> to the race condition and driving the system to 100%. Run the test on a
> 16 CPU system instead of a 2 CPU system. Run at 100mhz instead of
> 2.5ghz. Put timing loops in the critical code to expand out the timing
> windows.
You couldn't easily run such complex tests after every 1~10 edits. Because
each edit should be checked, regardless of your religion, in theory you
could emulate everything and check the logic decoupled from its situation.
I'm not gonna volunteer to do all that emulating.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
"Cameron MacKinnon" <··········@clearspot.net> wrote in message
···························@rogers.com...
>
> Yes, there are techniques for coaxing race conditions into occurring
> more frequently. But for sufficiently important software (anything
> beyond a toy intended only for the personal use of the author) design is
> definitely the way to go. Rare indeed is the threaded code which
> contains only one race condition; it's none, or many. Once you've found
> the first one, the only thing you can know for sure from that point on
> is that the code was written by someone who didn't understand
> concurrency, and the code can't be trusted.
>
Excellent point. You clearly understand the important design issues
related to development of large-scale, concurrent software systems.
This is a special kind of problem domain that those who do not know
it are likely to approach with excessively naive solutions.
Richard Riehle
Cameron MacKinnon wrote:
> Tim Josling wrote:
>
>> ········@sbcglobal.net wrote:
>>
>>> "Phlip" <·········@yahoo.com> wrote in message
>>> ························@newssvr33.news.prodigy.com...
>>>
>>>>> How will you devise a test that ensures the absence of a
>>>>> race-condition
>>>> How will you deliver without such a test?
>>> You will design your code to prevent this from occurring. It is not
>>> something you can test, as testing is normally understood.
>> You could test it at some level though...
>
> Yes, there are techniques for coaxing race conditions into occurring
> more frequently. But for sufficiently important software (anything
> beyond a toy intended only for the personal use of the author) design is
> definitely the way to go. Rare indeed is the threaded code which
> contains only one race condition; it's none, or many. Once you've found
> the first one, the only thing you can know for sure from that point on
> is that the code was written by someone who didn't understand
> concurrency, and the code can't be trusted.
>
Design is good I agree and testing is no substitute for good design.
However Knuth's comment applies - "I don't know if this code works - I
have not tested it, only proven it correct." If Knuth has to test, most
of the rest of us certainly do.
Tim Josling
Tim Josling wrote:
> Design is good I agree and testing is no substitute for good design.
>
> However Knuth's comment applies - "I don't know if this code works - I
> have not tested it, only proven it correct." If Knuth has to test, most
> of the rest of us certainly do.
We are still missing the point. You can test that you designed to avoid race
conditions, but you can't test you won't race.
The former is generally good enough to survive refactors, but be forewarned.
The simplest design (maybe with the fewest threads to race) will be easier
to test, and more resistant to bugs at change time. So use design techniques
that enforce simplicity.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
adaworks wrote:
> Agile methods may be OK for some projects, but there are still a great
many
> applications for which it is inappropriate and sometimes, dangerous.
Which practice is dangerous?
- the most qualified customer representative works 40 hours a week
on the project
- the ability to safely change code is scrupulously maintained, even
if the code won't change
- pairs write all code
- pairs rotate frequently and ensure they understand all modules
- nobody works too late
- pairs delete code not required by tests
- the customer writes the high-level tests
- all tests must pass before checking in
- everyone works on the same codebase
- nobody changes anything with returning to a releasable
state as frequently as possible - many times an hour
If you mean "oh, Big Design Up Front might possibly detect the need to
prevent our software from killing people", I think I'd rather go with design
changes made in the presence of aggressive tests.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
········@sbcglobal.net wrote:
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> ·························@twister.nyc.rr.com...
>
>>The whole point of "agile" is not spending half your time on perfection,
>>given that one will regularly be tossing ones code base like a salad as
>>one improves ones understanding of the problem at hand. Instead one gets
>>the code Pretty Good (no gross/deliberate violation of sound design) and
>>then moves on to the next functional challenge (and education).
>>
>>The idea of designing everything before coding is dead. Never works.
>>Code is the design (wish I had the URL).
>>
>
> The agile approach is certainly worthwhile for some kinds of projects. In my
> world, "pretty good" is not good enough. We cannot deploy code for certain
> kinds of embedded systems that are "pretty good", or "good enough for now."
>
> It would be rather impolite of us to say, after the first few accidental deaths
> or maimings, "Well, we got pretty close to the right solution."
You seem to have forgotten that the issue was slow compile times which
could be solved (claimed someone) by writing better-decoupled code. No
one said anything about (a) shipping (b) buggy code.
I write less buggy code because I am not spending half my time fretting
over the decoupled perfection of my code to keep compile times down
during the long development of a serious application <digression> or
persuading a strong static typing compiler that I know what I am doing
</digression>.
Instead, I am gleefully refactoring away whenever I see a material
design flaw, so the design of my code steadily converges on perfection,
which is readily identified as "making development easier". Easy entails
correctness, in case you are about to dash off on another tangent.
Decoupling matters only when I am unable to reuse some code because.
Then I decouple. I gather others are decoupling in a desperate attempt
to get build times down. If build times are an issue, then I cannot
refactor at will, my code stops moving towards perfection (only gross
misdesign gets addressed), and development is always harder than it
should be. Worse, buggier code results. (Beautifully decoupled, tho.)
In effect, the argument that perfectly decoupled code is the "answer" to
slow build times misses the point I tried to make originally: making me
fret over perfectly decoupled code just moves the problem from build
times to programmer effort.
Me, I would rather nap during a long build than work harder.
kenny
Kenny Tilton wrote:
> The idea of designing everything before coding is dead. Never works.
> Code is the design (wish I had the URL).
Did you mean this one?
http://www.developerdotstar.com/mag/articles/reeves_design_main.html
--
Don't let school interfere with your education. -- Mark Twain
Ulrich Hobelmann wrote:
> Kenny Tilton wrote:
>
>> The idea of designing everything before coding is dead. Never works.
>> Code is the design (wish I had the URL).
>
>
> Did you mean this one?
>
> http://www.developerdotstar.com/mag/articles/reeves_design_main.html
>
Yep. Thx, kenny.
--
Cells? : http://www.common-lisp.net/project/cells/
Cello? : http://www.common-lisp.net/project/cello/
Cells-Gtk? : http://www.common-lisp.net/project/cells-gtk/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
>
>
> Phlip wrote:
>
>> Roy Smith wrote:
>>
>>
>>> In something like C++, adding a new method (even a private one) to a
>>> class
>>> will typically require touching two files (the implementation and the
>>> interface). Touching the interface header file may trigger a cascade
>>> reaction causing you to recompile every source file that includes it.
>>> These are the sorts of things which often dissuade people from
>>
>>
>> refactoring.
>>
>> If you turn that around, refactoring dissuades people from excessive
>> coupling. So the symptom - long compile times after short changes -
>> leads to
>> the solution - refactoring to escalate interfaces free of details that
>> frequently change.
>
>
> Making a virtue out of necessity?
>
> The whole point of "agile" is not spending half your time on perfection,
> given that one will regularly be tossing ones code base like a salad as
> one improves ones understanding of the problem at hand. Instead one gets
> the code Pretty Good (no gross/deliberate violation of sound design) and
> then moves on to the next functional challenge (and education).
>
> The idea of designing everything before coding is dead. Never works.
> Code is the design (wish I had the URL).
>
> kenny
>
Kent Beck's books
OR
http://64.233.167.104/search?q=cache:oWHR2_nNde4J:www.cc.gatech.edu/classes/AY2005/cs2340_spring/20-ExtremeProgramming.ppt+kent+beck+%22code+is+the+design%22&hl=en
OR
http://tinyurl.com/dg4tq
Tim Josling
"Christopher Browne" <········@acm.org> wrote in message
··························@news20.bellglobal.com...
>
> If Ada and Objective C were "duking it out" instead of C++ sitting
> where it is, we would probably have a little less cruddy software out
> there. On the other hand, if Ada became the hot, in-language... :-)
> --
Yes, Objective C is probably a better object-oriented version of C
than C++, at this point. From what I see of the evolution of C++,
every new feature is intended to fix something that is already broken
in the language.
I am impressed with some of the things that have been done with
C#. Microsoft was intelligent enough to let an experienced
language designer create the specification for the language.
As to Ada, I see what you mean, in terms of SLOC. However,
I rarely think of the size of a method/function/procedure as a
matter of SLOC. I am much more interested in measuring the
complexity of the unit. For example, does this function do one
thing only, or is it trying to do many things? This metric has
the benefit of being consistent across nearly every language. The
fact that one language may require a few more lines of source
code, a few more parentheses, extra curly braces, or some
syntactic sugar is not a particularly important issue. In fact, from
an enginering perspective, the number of SLOC is a non-issue that
tends to trivialize the more important considerations in software
metrics.
Richard Riehle
········@sbcglobal.net wrote:
> ... In fact, from
> an enginering perspective, the number of SLOC is a non-issue that
> tends to trivialize the more important considerations in software
> metrics.
>
> Richard Riehle
>
This would seem obvious but there seems to a consistent message from
productivity studies that productivity in lines of code per hour is
constant across a wide range of languages.
I recently read up on six sigma/lean/complexity, and one of the messages
was that a system should not have complexity that no-one would "pay" for.
As an example, if when adding a function you have to edit two files with
basically the same information - the header and the source file, that
seems to be complexity, cost and opportunities for errors that a
customer would not value. Same deal updating the UML then updating the
design code then the header file, then the code.
Similarly every time you write a superfluous line of source code it is
an opportunity to make an error, or for the program to behave different
than what you wanted.
So all these things have a cost.
Having said that I would agree with the main point to the extent that
higher level design problems are as or more important than code /
micro-design problems.
Tim Josling
Tim Josling wrote:
> This would seem obvious but there seems to a consistent message from
> productivity studies that productivity in lines of code per hour is
> constant across a wide range of languages.
Sometimes such studies confuse "more lines of code" with "more
productive"...
> Similarly every time you write a superfluous line of source code it is
> an opportunity to make an error, or for the program to behave different
> than what you wanted.
Right. Which means running tests while removing lines of code is a powerful
design technique.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
Tim Josling wrote:
> This would seem obvious but there seems to a consistent
> message from productivity studies that productivity in
> lines of code per hour is constant across a wide range of
> languages.
Please be aware that lines of code per hour is NOT a measure
of productivity. A simple example brings out the problem.
Consider measuring the productivity of a furniture
maker. One might count how many chairs he makes a week. That
would be a measure of productivity. One might also measure
how many cubic feet of wood he uses. Using wood is a
cost. One might be measuring it because one wants him to cut
his wood with more cunning and thus waste less and reduce
wood consumption per chair. As Benjamin Franklin put it: a
penny saved is a penny earned.
Suppose that one has to compare the productivity of two
furniture makers and are in a great hurry. Wood consumption
figures are to hand. Counts of chairs made are not. One
could take a big gamble, hoping that both furniture makers
are equally efficient in their consumption of raw material,
and use wood consumption as a proxy for chairs made. Then
one says Fred is more productive than Pete because he used
more wood. God help you if you base a bonus scheme on wood
used. Both Fred and Pete will get through a lot and your
costs will rise, but the number of chairs produced will not.
The analogy to the immaterial world of software is
subtle.
The thing that is analoguous to having a chair to
sit on is having the program do the right thing when you
click a button on the user interface. Instead of a material
object we can count, we desire a behaviour, which is present
or absent from the code.
The thing that is analogous to using up the stock of wood is
filling the source tree with lines of code. When the
customer wants a small change to what the program does, you
would rather be making 10 changes in 10000 lines of code
than 100 changes in 100000. Lines of code are a cost. They
are a potentially crippling cost. Too many lines of code and
you cannot economically make changes to your code and the
customer will go else where. You could also think of lines
of code as hiding places for bugs. Too many lines of code
and you will never find your bugs.
I could accept the claim that
... a consistent message from productivity studies that
productivity proxyed by lines of code per hour ...
^^^^^^^
but I would tend to shrug and move on. Productivity studies
that don't use a direct measure of productivity, but rely
instead on resources consumed as a proxy for output produced
might be giving useful information, or they might not.
The important point to grasp is that they are subjective
pieces of opinion even though the presence of measured numbers
gives them the surface form of objective facts. Do I go with
Kenny Tilton's opinion that Lisp makes him more productive?
Ought I to prefer to place my trust in a productivity
studies that proxy output by resource consumption? In spite
of the measured numbers, it is a judgement call, not a fact.
I'm having to chose between one persons opinion that Lisp
makes him more productive and some-one else's opinion that we
can get away with using resource consumption as a proxy for
output without being grossly mislead.
Abelson and Sussman teach their students to use Scheme to
write interpreters for domain specific languages. Graham
encourages his readers to use Common Lisp to implement
domain specific languages with source-to-source
transformations. In both cases the underlying theory of
productivity improvement is that the program, by being
written in the domain specific language, is shorter.
Does measuring programmer productivity, using lines of code
as a proxy for programmer output shed any light on these
theories? No. The measurement methodology factors out the
hoped for improvement in productivity.
The dominant paradigm for thinking about and researching
programmer productivity depends on a methodological
leap-of-faith that prevents it from assessing the most
promising approach to productivity improvement. I find this
hugely frustrating.
Alan Crowe
Edinburgh
Scotland
On Sat, 04 Jun 2005 17:15:36 +0100, Alan Crowe wrote:
> Tim Josling wrote:
>> This would seem obvious but there seems to a consistent
>> message from productivity studies that productivity in
>> lines of code per hour is constant across a wide range of
>> languages.
>
> Please be aware that lines of code per hour is NOT a measure
> of productivity. A simple example brings out the problem.
[snip]
That's an excellent analogy - great stuff.
Also consider the fact that I spent all day yesterday *removing* 200 lines
of code from a colleague's program (started out at around 650LOC). Did I
do a negative amount of work? The program in question still passes all of
its unit tests and does exactly the same job, but now we have a hope of
being able to modify it since I can fit the whole thing easily in my head.
Best wishes,
Bill.
William Bland wrote:
> On Sat, 04 Jun 2005 17:15:36 +0100, Alan Crowe wrote:
>
>
>>Tim Josling wrote:
>>
>>>This would seem obvious but there seems to a consistent
>>>message from productivity studies that productivity in
>>>lines of code per hour is constant across a wide range of
>>>languages.
>>
>>Please be aware that lines of code per hour is NOT a measure
>>of productivity. A simple example brings out the problem.
>
> [snip]
>
> That's an excellent analogy - great stuff.
>
> Also consider the fact that I spent all day yesterday *removing* 200 lines
> of code from a colleague's program (started out at around 650LOC). Did I
> do a negative amount of work?
Good point! (I just wanted an excuse to show off my new .sig)
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
William Bland schrieb:
> ... but now we have a hope of
> being able to modify it since I can fit the whole thing easily in my head.
Exactly this is the point that should be to changed.
How has a language be designed to maximize "easily fit in my head"?
The nearest language to human thoughts I found till now is lisp.
stefan
"lin8080" <·······@freenet.de> wrote in message
······················@freenet.de...
> How has a language be designed to maximize "easily fit in my head"?
> The nearest language to human thoughts I found till now is lisp.
>
This varies with size of program and complexity of the problem domain.
Lisp is certainly a good language (I am more accustomed to Scheme, but
same idea) for many kinds of problems. C works well for small programs
that can be understood by a few people. C++ is a good choice for larger
software systems where object technology is appropriate. Ada scales
up well for producing code that is understandable in very large-scale
software that needs to be maintained over a long lifetime. Perl is a
really good choice when you are solving simple problems and do not
want the system to get in your way. Smalltalk is great when you just
want to have fun building good software that works.
We learn to choose the right tool for the right job. On large-scale,
concurrnent software systems where the goal is high reliability of
the final code, I have found Ada to be useful for creating readable,
easily maintained (and, easily "refactorable"), that allows me to
"design a little, code a little, test a little, deploy a little." But, even
though I prefer Ada for such software, I recognize the importance
of choosing other languages under other circumstances.
The important thing is to reason carefully about choice of language
before making that choice. It is essential that, as software professionals,
we do not become so enamoured of a given language that we delude
ourselves into believing that only our favorite language is correct for
every problem that presents itself.
Richard Riehle
Alan Crowe wrote:
> Consider measuring the productivity of a furniture
> maker. One might count how many chairs he makes a week. That
> would be a measure of productivity. One might also measure
> how many cubic feet of wood he uses. Using wood is a
> cost.
Supposed we measured our Gross Global Product in terms of how much oil we
burn every day. ;-)
(And now if you'l excuse me, I'm about to drive 4 miles to get pizza, and
coffee, to avoid doing the dishes...;)
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
Alan Crowe wrote:
> Tim Josling wrote:
>
>>This would seem obvious but there seems to a consistent
>>message from productivity studies that productivity in
>>lines of code per hour is constant across a wide range of
>>languages.
>
>
> Please be aware that lines of code per hour is NOT a measure
> of productivity. A simple example brings out the problem.
>
>...
>
> Alan Crowe
> Edinburgh
> Scotland
I completely agree. Lines of Code is a bad productivity measure. What
you want is productivity measured in function points or some
code-independent measure.
What the studies showed however was that programmers can write and debug
(produce) the same number of lines of code per hour across a wide range
of languages. I'm sorry I didn't make that clear.
Therefore "Lines of Code" matters because more lines per unit of
usefulness means less real productivity. If your language requires
writing copious amounts of spam-code your productivity will suffer.
One bad IMHO solution to this problem is the use of code generators.
Tim Josling
········@sbcglobal.net wrote:
> I am impressed with some of the things that have been done with
> C#. Microsoft was intelligent enough to let an experienced
> language designer create the specification for the language.
I'm not impressed. Like Java, C# is semi-type-safe, which to me is
worse having no type safety at all. And like Java, C# code is very
difficult to inspect for defects. Look at this code:
private void ReadMyFile()
{
XmlTextReader r = new XmlTextReader("myfile.xml");
while (r.Read())
{
}
}
See the bug?
A lot of programmers don't. The reader has to be closed, or else a
file handle will be leaked. There is no way to tell without going off
to read the documentation of XmlTextReader. In C++ the code would
read:
XmlTextReader r("myfile.xml);
...
and you would expect the XmlTextReader destructor to perform whatever
cleanup was required. If you saw instead:
XmlTextReader *r = new XmlTextReader("myfile.xml");
then there would be a bug, but it would be obvious.
> As to Ada, I see what you mean, in terms of SLOC. However,
> I rarely think of the size of a method/function/procedure as a
> matter of SLOC. I am much more interested in measuring the
> complexity of the unit. For example, does this function do one
> thing only, or is it trying to do many things? This metric has
> the benefit of being consistent across nearly every language. The
> fact that one language may require a few more lines of source
> code, a few more parentheses, extra curly braces, or some
> syntactic sugar is not a particularly important issue. In fact, from
> an enginering perspective, the number of SLOC is a non-issue that
> tends to trivialize the more important considerations in software
> metrics.
You are right that SLOC is not the main issue. It's expressiveness:
the ability to factor out duplication so that requirements changes can
be effected in a single place. C# is not very expressive. Instead,
the duplication of a couple dozen lines of boilerplate code is required
for common tasks like defining a value class.
kevin cline wrote:
>
> ········@sbcglobal.net wrote:
>
>>I am impressed with some of the things that have been done with
>>C#. Microsoft was intelligent enough to let an experienced
>>language designer create the specification for the language.
>
>
> I'm not impressed. Like Java, C# is semi-type-safe, which to me is
> worse having no type safety at all. And like Java, C# code is very
> difficult to inspect for defects. Look at this code:
>
> private void ReadMyFile()
> {
> XmlTextReader r = new XmlTextReader("myfile.xml");
> while (r.Read())
> {
> }
> }
>
> See the bug?
>
> A lot of programmers don't. The reader has to be closed, or else a
> file handle will be leaked. There is no way to tell without going off
> to read the documentation of XmlTextReader. In C++ the code would
> read:
>
> XmlTextReader r("myfile.xml);
> ...
>
> and you would expect the XmlTextReader destructor to perform whatever
> cleanup was required.
Hang on, you can't go equating one Languages idioms as a cause of bugs
in other languages. You may certainly find yourself writing buggy code
like above because you haven't made the conceptual change from C++ to
Java - or vice-versa, but others don't.
As a seasoned Java programmer I know that anything that opens a stream,
has to be told to explicitly close it - its Java's idiom.
>If you saw instead:
>
> XmlTextReader *r = new XmlTextReader("myfile.xml");
>
> then there would be a bug, but it would be obvious.
>
it would to most Java programmers I know.
"Andrew McDonagh" wrote:
KC>> and you would expect the XmlTextReader destructor to perform whatever
KC>> cleanup was required.
>
>
> Hang on, you can't go equating one Languages idioms as a cause of bugs in
> other languages. You may certainly find yourself writing buggy code like
> above because you haven't made the conceptual change from C++ to Java - or
> vice-versa, but others don't.
>
I think the point it that as r goes out of lexical scope (after ReadMyFile),
you would expect the XmlTextReader destructor to close the file handle. I
would see the bug as being the Reader class itself.
Surely this violates the (wooly) idea of constructor/destructor mirroring
and also fails to minimise suprise to the programmer.
The example I have in my head is a Writer class that performs database
locking. My code locking up a database would be (to me at least) a
non-obvious failure.
> As a seasoned Java programmer I know that anything that opens a stream,
> has to be told to explicitly close it - its Java's idiom.
>
Where is the benefit? I can see the extra code I've got to type, and I can
see the extra time I must spend checking. What do I gain this way? Or,
what would I lose if the handle _was_ properly closed for me?
>
>>If you saw instead:
>>
>> XmlTextReader *r = new XmlTextReader("myfile.xml");
>>
>> then there would be a bug, but it would be obvious.
>>
Yes.
>
> it would to most Java programmers I know.
>
Good, because the majority of Java software that did file I/O would suck.
How much time do the Java guys you know estimate they spend fixing problems
like this?
(I'm not bashing Java by the way. I think it's cool - not for the language,
but for the ability to compile and classload over the wire. Very lispy, but
a shame that hardly anybody does this)
Jamie
Jamie Border wrote:
> "Andrew McDonagh" wrote:
>
> KC>> and you would expect the XmlTextReader destructor to perform whatever
> KC>> cleanup was required.
>
>>
>>Hang on, you can't go equating one Languages idioms as a cause of bugs in
>>other languages. You may certainly find yourself writing buggy code like
>>above because you haven't made the conceptual change from C++ to Java - or
>>vice-versa, but others don't.
>>
>
>
> I think the point it that as r goes out of lexical scope (after ReadMyFile),
> you would expect the XmlTextReader destructor to close the file handle. I
> would see the bug as being the Reader class itself.
I think the point is that Java do not have destructors.
No destructors = no Automatic stream closing in this example.
Java Developers quick understand that anything going out of scope MAY be
eligible for GC. But then again if someone else has a reference to the
object it won't be GC. They also know that just because an object MAY be
GCed, doesn't mean it actually will be - its a JVM decision.
Java developers know this fact. They also realise that they can't rely
upon idioms from other languages as often there is no comparison within
Java.
>
> Surely this violates the (wooly) idea of constructor/destructor mirroring
> and also fails to minimise suprise to the programmer.
See above.
>
> The example I have in my head is a Writer class that performs database
> locking. My code locking up a database would be (to me at least) a
> non-obvious failure.
>
>
>>As a seasoned Java programmer I know that anything that opens a stream,
>>has to be told to explicitly close it - its Java's idiom.
>>
>
>
> Where is the benefit? I can see the extra code I've got to type, and I can
> see the extra time I must spend checking. What do I gain this way? Or,
> what would I lose if the handle _was_ properly closed for me?
>
>
>>>If you saw instead:
>>>
>>> XmlTextReader *r = new XmlTextReader("myfile.xml");
>>>
>>>then there would be a bug, but it would be obvious.
>>>
>
>
> Yes.
>
>
>>it would to most Java programmers I know.
>>
>
>
> Good, because the majority of Java software that did file I/O would suck.
Why?
> How much time do the Java guys you know estimate they spend fixing problems
> like this?
Who?
The good developers who have made the mental shift from their previous
language to Java?
or the developers who have?
>
> (I'm not bashing Java by the way. I think it's cool - not for the language,
> but for the ability to compile and classload over the wire. Very lispy, but
> a shame that hardly anybody does this)
>
> Jamie
>
>
Cool - I'm not bashing any language - I've used several and have no real
preference - I am bashing the notion that because one language does not
support the idioms of another language - its a problem that causes bugs.
I'd say its the developers fault for the bugs - not the language
idioms(or lack of).
Andrew
Andrew McDonagh wrote:
> Java developers know this fact. They also realise that they can't rely
> upon idioms from other languages as often there is no comparison within
> Java.
If the comparable idiom were complete and coherent, that wouldn't be a
problem.
Instead, Java has two idioms. In Java...
- memory uses an idiom different from other resources
- the memory system is not optional or adjustable
- memory might not free when necessary
- the system for freeing resources couples each object's
cleanup system to all of its clients, redundantly
All because the inventors of Java wanted to advertise "you don't need
destructors!"
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
"Andrew McDonagh" wrote:
JB>> I think the point it that as r goes out of lexical scope (after
ReadMyFile),
JB>> you would expect the XmlTextReader destructor to close the file handle.
I
JB>> would see the bug as being the Reader class itself.
AMcD> I think the point is that Java do not have destructors.
OK, so I was tired and I should have said:
"as r holds an external reference, and nothing holds a reference to r you
would expect the GC to favour rapid collection, causing the finalize method
of XMLTextReader or the relevant superclass to close the file handle."
When I had to write Java, if I had to guarantee destruction at a certain
point, I'd call my hand-rolled "destroy" method, which would run right up
the inheritance tree doing all the stuff that couldn't wait until
finalization.
This was so cumbersome that I gave up, and stuck pages of notes to the side
of the monitor, so that I remembered to do the right thing.
That said, I do like some of Java's features (classloading over network,
anonymous inner classes).
Jamie
> Andrew
Jamie Border wrote:
> When I had to write Java, if I had to guarantee destruction at a certain
> point, I'd call my hand-rolled "destroy" method, which would run right up
> the inheritance tree doing all the stuff that couldn't wait until
> finalization.
>
> This was so cumbersome that I gave up, and stuck pages of notes to the
side
> of the monitor, so that I remembered to do the right thing.
Apologies for gloating, but that is incredible. First you describe
re-building a language feature from scratch to avoid its bugs. Then you
describe a textbook case of coupling the client to the servant code.
In Ruby:
open("file.txt", "r") do |f|
processLines(f)
end
The do...end is a block that passes into open(). Ruby makes the Execute
Around Pattern very easy with block closures. The open() method only calls
its block if it can open the file (meaning the 'if' only happens once,
inside open()). And open() closes the file after calling the block (meaning
the exception safe 'ensure' block only happens once, inside open()).
All of C++ RAII and Java 'finally' blocks are a pitiful excuse to add
linguistic support for just a few applications of the Execute Around
Pattern. If the language designers had instead enabled block closures, those
languages would have the option to support exception safety and robust
destruction via elegance and transparency. And all their functions would get
super short!
Excuse me, I have to go inspect the lifespan of a "smart" pointer now...
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
> Apologies for gloating, but that is incredible. First you describe
> re-building a language feature from scratch to avoid its bugs. Then you
Yes. Gloat away. Unfortunately I was working with a number of (fellow?)
monkeys who were unable to grasp the problems caused by file-never-closed
and database-globally-locked situations.
> describe a textbook case of coupling the client to the servant code.
Yes, that is so. But when chief monkey says "my Java guys are plenty
clever, thank you very much", this begins to look like a good workaround.
For example, instead of handling many different cases of
failure-to-close-files or whatever, I could have the automated testing
scripts match the creation and destruction of the affected objects in a
sensible way.
Don't tell me you've never had to write pathetic code for good reasons
(financial) :-)
> In Ruby:
>
> open("file.txt", "r") do |f|
> processLines(f)
> end
>
> The do...end is a block that passes into open(). Ruby makes the Execute
> Around Pattern very easy with block closures. The open() method only calls
> its block if it can open the file (meaning the 'if' only happens once,
> inside open()). And open() closes the file after calling the block
> (meaning
> the exception safe 'ensure' block only happens once, inside open()).
Yes. In this case, I would use WITH-OPEN-FILE, which provides the same kind
of behaviour in Lisp.
Macros make this kind of thing easy for me to do in Lisp, which is one of
the reasons I like to use it. Your Ruby code does look beautiful though...
>
> All of C++ RAII and Java 'finally' blocks are a pitiful excuse to add
> linguistic support for just a few applications of the Execute Around
> Pattern. If the language designers had instead enabled block closures,
> those
> languages would have the option to support exception safety and robust
> destruction via elegance and transparency. And all their functions would
> get
> super short!
Yes.
>
> Excuse me, I have to go inspect the lifespan of a "smart" pointer now...
Hell, why not go all the way and lobotomize it with a 'destroy' method :-)
Jamie
>
> --
> Phlip
> http://www.c2.com/cgi/wiki?ZeekLand
>
>
Jamie Border wrote:
> "Andrew McDonagh" wrote:
>
> JB>> I think the point it that as r goes out of lexical scope (after
> ReadMyFile),
> JB>> you would expect the XmlTextReader destructor to close the file handle.
> I
> JB>> would see the bug as being the Reader class itself.
>
> AMcD> I think the point is that Java do not have destructors.
>
> OK, so I was tired and I should have said:
>
> "as r holds an external reference, and nothing holds a reference to r you
> would expect the GC to favour rapid collection, causing the finalize method
> of XMLTextReader or the relevant superclass to close the file handle."
>
Maybe, but the finalize method is not actually guaranteed to be called
by the GC. WRT to Java's finally methods, I actually agree with Phlip.
> When I had to write Java, if I had to guarantee destruction at a certain
> point, I'd call my hand-rolled "destroy" method, which would run right up
> the inheritance tree doing all the stuff that couldn't wait until
> finalization.
I'd argue that having the BlarBlarReaders and Writers do the file
opening and closing may actually be part of the problem.
If we moved the responsibility of file opening and closing into a
separate class, and then made XmlTextReader class only be responsible
for reading FROM a file.
Additionally, by having no explicit file opening() within the ctor, its
plain to see that we have to open() and therefore close() manually. This
gives us the benefit that WE control when the file manipulations occurs,
rather than leaving it to the GC discretion.
E.g. Modifying Kevin Cline's code...
private void ReadMyFile()
{
XmlFile file = new XmlFile("myFile.xml");
file.open();
XmlTextReader r = new XmlTextReader(file);
while (r.Read())
{
}
file.close();
}
Andrew
>
> I'd argue that having the BlarBlarReaders and Writers do the file opening
> and closing may actually be part of the problem.
>
> If we moved the responsibility of file opening and closing into a separate
> class, and then made XmlTextReader class only be responsible for reading
> FROM a file.
>
> Additionally, by having no explicit file opening() within the ctor, its
> plain to see that we have to open() and therefore close() manually. This
> gives us the benefit that WE control when the file manipulations occurs,
> rather than leaving it to the GC discretion.
Yes. I was kind of hinting that having to rely on the GC being
a) deterministic
b) fast
c) sensible
Is a pretty poor show.
As an aside, in C# I can say:
...
using (Thing MyThing = new Thing (alpha, beta))
{
// Do stuff with MyThing
}
// MyThing is _guaranteed_ disposed now.
Which is kind of neat. I wonder if there's anything that stops JVM from
working the same way (assuming I had a "using" keyword in Java)...
>
> E.g. Modifying Kevin Cline's code...
>
> file.open();
[...]
> file.close();
Sane. Two additional lines of code. Hours less debugging.
Jamie
>
> Andrew
Many people don't know this . . . when the Java project was still
called Oak they lost a month and a half of work when they first tried
to put in the garbage collector . . . one of the major architectural
challenges of Java, one that actually laid the foundation for its
entire security structure, was to make sure the JVM would never
garbage collect the whole Java project. It was not easy.
:-)
--
Fred Gilham ······@csl.sri.com
The PTPL (People's Trotskyist Programming League) believes that
hackers are elitist and that all software should be created by the
masses flailing away at millions of keyboards. I didn't have the
heart to tell them that this has already been tried and the result is
called Linux.
Andrew McDonagh wrote:
> As a seasoned Java programmer I know that anything that opens a stream,
> has to be told to explicitly close it - its Java's idiom.
<monthly anti-java-ramble>
Strange then that the same people assume that you can't treat
memory the same way, as people do in C++ or other C dialects ;)
When programming in C, my problem never was lack of GC, and I
never had real advantage through the so-called features of Java.
Sure, it's nice to write foo instead of str->foo, but then I'd
rather use something decent like Objective C, with the same feature.
</monthly anti-java-ramble>
--
Don't let school interfere with your education. -- Mark Twain
Christopher Browne wrote:
> I'd put the most money on it being a study involving code
> written in either COBOL, FORTRAN, or Ada...
I read the study this morning and it covered all those, plus
various versions of assembler, C, and PASCAL. The interesting
thing was that there was no variation among languages. It would
appear the result is an artifact of humans rather than an
artifact of the language.
It may be that lisp or ML might escape this effect through some
loophole but unless somebody gathers the evidence we'll never know.
Christopher Browne wrote:
> I'd put the most money on it being a study involving code
> written in either COBOL, FORTRAN, or Ada...
I read the study this morning and it covered all those, plus
various versions of assembler, C, and PASCAL. The interesting
thing was that there was no variation among languages. It would
appear the result is an artifact of humans rather than an
artifact of the language.
It may be that lisp or ML might escape this effect through some
loophole but unless somebody gathers the evidence we'll never know.
Christopher Browne wrote:
> Quoth Pascal Costanza <··@p-cos.net>:
>
>>Tim Josling wrote:
>>
>>>One interesting thing came up that surprised me. A study that
>>>related function/method size to density of bugs found that the
>>>number of bugs rose dramatically as the function/method size fell
>>>below a few hundred statements. They looked into this and found it
>>>was due to interface errors which are roughly proportional to the
>>>number of functions. So more smaller functions/methods means more
>>>bugs.
>>>They found the optimum was about 1,000 statements! I don't have the
>>>reference but if someone wants it I will go back to the bookshop and
>>>hunt for it.
>>
>>I'd be very interested in this.
>
> I'd guess that this is a _highly_ language-specific result,
> particularly likely to apply to COBOL/FORTRAN, and, to somewhat lesser
> extent, C/C++. Although it sounds more like the pathology I'd expect
> in Ada code...
I have skimmed through the papers by Les Hatton
(http://www.leshatton.org/ ), and one of my immediate reactions was:
These are all languages without garbage collection.
There is one specific paper about how OOP doesn't really pay off, but it
is about C++ (so without a garbage collector).
Of course, I can't predict how this would change the results, but my gut
feeling tells me that a garbage collector should improve the results
considerably, including wrt smaller units of code.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Stefan Ram wrote:
> The real significant productivity advance we've
> had in programming has been from languages which manage
> memory for you automatically.
>
> http://www.joelonsoftware.com/articles/APIWar.html
Of course, there's no reason you can't put C in that category
as well (with conservative collectors that have been available
since the late 1980s.) I'm a bit surprised these aren't used
more often; does the conservatism lead to too many unfreed
dead objects?
Paul
In article <······················@dls.net>,
Paul F. Dietz <·····@dls.net> wrote:
> Of course, there's no reason you can't put C in that category
> as well (with conservative collectors that have been available
> since the late 1980s.) I'm a bit surprised these aren't used
> more often; does the conservatism lead to too many unfreed
> dead objects?
I think for the majority of stuff that's written in C/C++ it would work
just fine and be preferable to manual management. I suspect what gets
in the way most of the time is the conservatism of the developer, not
the collector.
(There are certainly counterexamples to this - the w3m web browser is
written with the Boehm GC. From http://www.w3m.org/story.html: "Boehm
GC is a garbage collector for C and C++. I began to use this library
when I implemented table, and it was great. I couldn't implement table
and form without this library.")
-bcd
After takin a swig o' Arrakan spice grog, Pascal Costanza <··@p-cos.net> belched out:
> Christopher Browne wrote:
>> Quoth Pascal Costanza <··@p-cos.net>:
>>
>>>Tim Josling wrote:
>>>
>>>>One interesting thing came up that surprised me. A study that
>>>>related function/method size to density of bugs found that the
>>>>number of bugs rose dramatically as the function/method size fell
>>>>below a few hundred statements. They looked into this and found it
>>>>was due to interface errors which are roughly proportional to the
>>>>number of functions. So more smaller functions/methods means more
>>>>bugs.
>>>>They found the optimum was about 1,000 statements! I don't have the
>>>>reference but if someone wants it I will go back to the bookshop and
>>>>hunt for it.
>>>
>>>I'd be very interested in this.
>> I'd guess that this is a _highly_ language-specific result,
>> particularly likely to apply to COBOL/FORTRAN, and, to somewhat lesser
>> extent, C/C++. Although it sounds more like the pathology I'd expect
>> in Ada code...
>
> I have skimmed through the papers by Les Hatton
> (http://www.leshatton.org/ ), and one of my immediate reactions was:
> These are all languages without garbage collection.
>
> There is one specific paper about how OOP doesn't really pay off, but
> it is about C++ (so without a garbage collector).
>
> Of course, I can't predict how this would change the results, but my
> gut feeling tells me that a garbage collector should improve the
> results considerably, including wrt smaller units of code.
It would be interesting to see a successor paper that added Java to
the mix, then.
In effect, Java ought to be somewhat similar to C++ (with something of
a Modula-3 flavour, in view of that being the derivation of its
exception system), which *does* have GC.
The unfortunate thing is that it appears to me that Java usage all to
often heads in the direction of obliviousness, where naive usage
actually leads to downright *bad* usage.
A C programmer knows that memory has a cost, and you can be pretty
sure that a C program will make pretty strictly limited use of memory.
But when memory simply becomes "magically there," it seems all too
common for that to lead to a complete lack of care.
I'm involved with the Slony-I replication project, where the main
"engine" is implemented in C. The predecessor that we used, eRServer,
was implemented in Java, and definitely suffered from that "lack of
care." To wit, all the data being shoved from "source DB" to
"destination DB" turned into a stream of Java strings that were kept
in memory throughout the period of processing what was called a
"SYNC." If things fell behind, the Java process would grow
precipitously, to the point of it eventually blowing up if you
overran, oh, say, a 2GB limit.
There is a certain amount of "clarity of thought" that comes when
memory management is 'in your face' as it is in C; you are SO aware of
it that there is little risk of designing in silliness where data
structures will grow [completely unnecessarily!!!] in memory to
ridiculous degree.
It's easier to "design in silliness" of this sort when it's hard to
perceive the memory management activities.
But I may be missing the factor of the notion that really bad
programmers are likely to get attracted to whatever language is
"hottest," and these days, Java's temperature is reasonably high...
--
output = reverse("moc.liamg" ·@" "enworbbc")
http://linuxdatabases.info/info/memorymgmt.html
"Q: Someone please enlighten me, but what are they packing into NT5 to
make it twice the size of NT4/EE? A: A whole chorus line of dancing
paperclips." -- <·······@otter.mbay.net>
Christopher Browne <········@acm.org> wrote:
> A C programmer knows that memory has a cost, and you can be pretty
> sure that a C program will make pretty strictly limited use of memory.
On the other hand, correctly accounting for memory can be so painful,
people sometimes just allocate huge amounts and don't worry about the
details:
char big_buffer[100000] /* nobody will ever need more than 100k */
this not only leads to excessive memory use, but is a common cause of
buffer overflow bugs as well.
Clinging to sanity, Roy Smith <···@panix.com> mumbled into her beard:
> Christopher Browne <········@acm.org> wrote:
>> A C programmer knows that memory has a cost, and you can be pretty
>> sure that a C program will make pretty strictly limited use of memory.
>
> On the other hand, correctly accounting for memory can be so painful,
> people sometimes just allocate huge amounts and don't worry about the
> details:
>
> char big_buffer[100000] /* nobody will ever need more than 100k */
>
> this not only leads to excessive memory use, but is a common cause of
> buffer overflow bugs as well.
The case that the replication software has been hitting is where an
"intelligent" approach involves there being only a minimal amount of
data in memory at all.
- You're reading from a database, inside a serialized transaction;
- That data gets shoved into a transaction in another database;
There is no reason for the data to persist in the replication
software's memory for more than an instant. All you *actually* need
is a bit of buffer space. 64K is likely to be more than adequate (and
sometimes provably necessary, as you may be able to establish that you
*will* get data in 64K chunks...).
--
(format nil ···@~S" "cbbrowne" "acm.org")
http://linuxfinances.info/info/
"Interfaces keep things tidy, but don't accelerate growth: functions
do." -- Alan Perlis
Christopher Browne wrote:
> But I may be missing the factor of the notion that really bad
> programmers are likely to get attracted to whatever language is
> "hottest," and these days, Java's temperature is reasonably high...
It certainly makes my iBook warm up more than usual, by making it
work much harder to get anything done.
--
Don't let school interfere with your education. -- Mark Twain
Pascal Costanza wrote:
> I have skimmed through the papers by Les Hatton
> (http://www.leshatton.org/ ), and one of my immediate reactions was:
> These are all languages without garbage collection.
>
> There is one specific paper about how OOP doesn't really pay off, but it
> is about C++ (so without a garbage collector).
Exception-safe C++ must collect its garbage (_all_ garbage, not just
storage) without redundant code statements.
> Of course, I can't predict how this would change the results, but my gut
> feeling tells me that a garbage collector should improve the results
> considerably, including wrt smaller units of code.
Exception-safety also leads to shorter methods. However...
Stefan Ram wrote:
> I found a PDF-URI:
>
> http://www.leshatton.org/Documents/Ubend_IS697.pdf
Of course I can't read all of it (who can?), but that paper appears to
discuss component size, not method size. This might mean module size. So we
need to ask those who have /Code Complete/ (1st Edition) to quote Steve
McConnell on whether he actually meant method size.
A relevant quote: 'Suppose, that a particular functionality requires 1000
"lines" to implement, where a "line" is some measure of complexity. The
immediate implication of the earlier discussion is that, on reliability
grounds, it is far better to implement it as 5 x 200 line components (i.e.
each fitting in cache) rather than 50 x 20 line components for example.'
The author neither confirms nor denies a component is a function, because he
aims for language neutrality.
The paper appears to agree with the rationale for the 'friend' keyword in
C++. (Please _PLEASE_ notice I am _NOT_ saying the paper, or anything else,
seems to agree with C++!!!)
The friend keyword, among other module techniques (available in many
languages, not just C++) permits classes within a module to widen their
interfaces to each other, and this permits the entire component to narrow
its interface with the outside world.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
From: Marcus Breiing
Subject: Re: How long should a function be?
Date:
Message-ID: <hq9nzak8cni3w@breiing.com>
* Pascal Costanza
> Of course, I can't predict how this would change the results, but my
> gut feeling tells me that a garbage collector should improve the
> results considerably, including wrt smaller units of code.
His empirical evidence doesn't disagree that fault rate per unit is
smallest for the smallest units. However, as you grow unit size,
initially faults per unit increase only logarithmically, thus fault
density (faults/lines) sinks, up to a point (which he argues is
related to the programmer's short term memory capacity) when
faults/unit starts to grow quadratically.
So, if I understand the paper correctly, I'd expect GC to topple the
"longer units win (up to a point)" result only if GC is a
disproportionately large improvement for very small units, and less of
an improvement for larger ones, because you'd have to disrupt the
only-logarithmic increase of faults per unit. I don't think that GC
has this property.
Marcus
Marcus Breiing wrote:
> * Pascal Costanza
>
>>Of course, I can't predict how this would change the results, but my
>>gut feeling tells me that a garbage collector should improve the
>>results considerably, including wrt smaller units of code.
>
> His empirical evidence doesn't disagree that fault rate per unit is
> smallest for the smallest units. However, as you grow unit size,
> initially faults per unit increase only logarithmically, thus fault
> density (faults/lines) sinks, up to a point (which he argues is
> related to the programmer's short term memory capacity) when
> faults/unit starts to grow quadratically.
>
> So, if I understand the paper correctly, I'd expect GC to topple the
> "longer units win (up to a point)" result only if GC is a
> disproportionately large improvement for very small units, and less of
> an improvement for larger ones, because you'd have to disrupt the
> only-logarithmic increase of faults per unit. I don't think that GC
> has this property.
OK, let me be a little bit more vague, then. ;)
Les Hatton's papers seem to cover languages that have a number of
characteristics in common: No garbage collection, static type systems
with explicit types ("manifest typing"), and a certain "closeness" to
the machine level. I.e., they are all members of the (to be very broadly
understood) Algol family of languages instead of the (to be equally very
broadly understood) Lisp family of languages with garbage collection,
type systems with implicit types (sometimes dynamic, sometimes static)
and a tendency towards abstracting away from the machine level.
This is an ad-hoc characterization that very likely misses a number of
important aspects, including the fact that this is more of a continuum
than a sharp categorization of languages. Nevertheless, I think the
tendency in the papers seems to be clearly in the Algol direction than
the Lisp direction.
I wouldn't be surprised if the results would be somewhat different if
there was more variety wrt language features.
I explicitly mentioned the OOP/C++ example foremostly because to me, OOP
without garbage collection clearly misses an important aspect of OOP.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
In article <·················@ram.dialup.fu-berlin.de>,
Stefan Ram <···@zedat.fu-berlin.de> wrote:
>Pascal Costanza <··@p-cos.net> writes:
>>I have skimmed through the papers by Les Hatton
>>(http://www.leshatton.org/ ), and one of my immediate reactions was:
>>These are all languages without garbage collection.
>>There is one specific paper about how OOP doesn't really pay off, but it
>>is about C++ (so without a garbage collector).
>
> The significance of garbage collection - This thought was
> also expressed by Joel Spolsky, who wrote:
>
> A lot of us thought in the 1990s that the big battle would
> be between procedural and object oriented programming, and
> we thought that object oriented programming would provide
> a big boost in programmer productivity. I thought that,
> too. Some people still think that. It turns out we were
> wrong. Object oriented programming is handy dandy, but
> it's not really the productivity booster that was
> promised. The real significant productivity advance we've
> had in programming has been from languages which manage
> memory for you automatically.
>
>http://www.joelonsoftware.com/articles/APIWar.html
Of course. Object-oriented programming has one advantage
for large groups: mediocre programmers can be encapsulated.
Outside of that, it's a productivity sink. Henry Ledgard
published empirical results to this effect in CACM a few
years ago.
--bks
Stefan Ram wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>I have skimmed through the papers by Les Hatton
>>(http://www.leshatton.org/ ), and one of my immediate reactions was:
>>These are all languages without garbage collection.
>>There is one specific paper about how OOP doesn't really pay off, but it
>>is about C++ (so without a garbage collector).
>
>
> The significance of garbage collection - This thought was
> also expressed by Joel Spolsky, who wrote:
>
> A lot of us thought in the 1990s that the big battle would
> be between procedural and object oriented programming, and
> we thought that object oriented programming would provide
> a big boost in programmer productivity. I thought that,
> too. Some people still think that. It turns out we were
> wrong. Object oriented programming is handy dandy, but
> it's not really the productivity booster that was
> promised. The real significant productivity advance we've
> had in programming has been from languages which manage
> memory for you automatically.
>
> http://www.joelonsoftware.com/articles/APIWar.html
>
Possible counter-example: Java. Java has garbage collection but I am not
aware of massive productivity benefits, having written a fair bit and
observed a lot more.
Maybe you need a certain combination of things to hit critical mass of
productivity. Garbage collection, pointer/array checking/overlay
prevention, a development environment that understands the code
including good refactoring tools, code sharing technology, testing
technology, fast edit/test cycle, executable models, etc.
Tim Josling
Stefan Ram wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>>They found the optimum was about 1,000 statements! I don't have the
>>>reference but if someone wants it I will go back to the bookshop and
>>>hunt for it.
>>
>>I'd be very interested in this.
>
>
> I found a PDF-URI:
>
> http://www.leshatton.org/Documents/Ubend_IS697.pdf
>
The above paper finds an optimum at 200-400 LOC (not 1000):
> The most reliable systems may result from systems with component
> sizes grouped around the 200-400 line mark. Bigger and smaller
> average component sizes appear to degrade this reliability.
A clearer statement of the data would be:
"below 250 LOC the number of faults remained constant at about 1".
The U-shaped curve ("fault density" vs "Average size in statements") is
to some degree an artifact of extrapolating to smaller numbers while
holding a constant fault value of 1. Were one to extrapolate to zero
LOC, one would obtain an infinite fault density (1/0), indicating that
writing no code would result in the greatest fault density.
Traditional COBOL and FORTRAN do not allow the developer to dynamically
allocate memory (everything is statically defined). Of course we always
wrote our own FORTRAN-callable subroutines to allocate/deallocate/GC
memory!8-))
So the presence/absence of GC probably would not affect the outcome.
From: Robert Uhl
Subject: Re: How long should a function be?
Date:
Message-ID: <m3ekbo2x74.fsf@4dv.net>
"Michael D. Kersey" <········@hal-pc.org> writes:
>
> The U-shaped curve ("fault density" vs "Average size in statements")
> is to some degree an artifact of extrapolating to smaller numbers
> while holding a constant fault value of 1. Were one to extrapolate to
> zero LOC, one would obtain an infinite fault density (1/0), indicating
> that writing no code would result in the greatest fault density.
Well, since writing no code won't solve the problem, that's certainly a
fault:-)
--
Robert Uhl <http://public.xdi.org/=ruhl>
This is the day which the Lord has made, let us rejoice and be glad in it.
Robert Uhl wrote:
> "Michael D. Kersey" <········@hal-pc.org> writes:
>
>>The U-shaped curve ("fault density" vs "Average size in statements")
>>is to some degree an artifact of extrapolating to smaller numbers
>>while holding a constant fault value of 1. Were one to extrapolate to
>>zero LOC, one would obtain an infinite fault density (1/0), indicating
>>that writing no code would result in the greatest fault density.
>
>
> Well, since writing no code won't solve the problem, that's certainly a
> fault:-)
>
Can we be certain of that, though?
I've seen more than a few systems that would be better had they not been
written!
Robert Uhl wrote:
> "Michael D. Kersey" <········@hal-pc.org> writes:
>
>>The U-shaped curve ("fault density" vs "Average size in statements")
>>is to some degree an artifact of extrapolating to smaller numbers
>>while holding a constant fault value of 1. Were one to extrapolate to
>>zero LOC, one would obtain an infinite fault density (1/0), indicating
>>that writing no code would result in the greatest fault density.
>
>
> Well, since writing no code won't solve the problem, that's certainly a
> fault:-)
>
Well I have seen methods with no code. They exist for the sake of
consistency or something like that. Presumably if such a method created
a bug the rate of bugs to function points would properly be said to be
infinite.
I am told that IBM had a utility program IEFBR14(1) whose spec was "do
nothing", and which has had at least two fixes.
Tim Josling
(1) IEF is a prefix for the product the program was packaged under. BR
14 is the assembler instruction to branch to the address in register 14,
which holds the return address
Tim Josling <····························@nospam.com> writes:
> I am told that IBM had a utility program IEFBR14(1) whose spec was "do
> nothing", and which has had at least two fixes.
>
> (1) IEF is a prefix for the product the program was packaged under. BR
> 14 is the assembler instruction to branch to the address in
> register 14, which holds the return address
Actually, it needed 4 versions: http://catless.ncl.ac.uk/Risks/6.14.html#subj1
--
__Pascal Bourguignon__ http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------
Stefan Ram wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>>They found the optimum was about 1,000 statements! I don't have the
>>>reference but if someone wants it I will go back to the bookshop and
>>>hunt for it.
>>
>>I'd be very interested in this.
>
>
> I found a PDF-URI:
>
> http://www.leshatton.org/Documents/Ubend_IS697.pdf
Thanks a lot!
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
<········@sbcglobal.net> writes:
> "Kaz Kylheku" <···@ashi.footprints.net> wrote in message
> ·····························@o13g2000cwo.googlegroups.com...
>> As a rule of thumb, I try to write mine so they don't extend past the
>> closing parenthesis.
>>
> The problem with this is that not all languages are designed
> around this model. Also, I wonder if you actually meant,
> curly brace?
He did not.
> Also, the question is not simply about the size of functions/methods,
> but also needs to address the size of classes that contain those
> methods/functions.
And the reason he did not is, in his world, methods are not
"contained" in classes.
Aaah, the joys of crossposting. :-/
I stand corrected. I see, now, that this discussion is about
LISP and its close relatives. Thus the "closing parenthesis"
guideline.
I am more accustomed to Scheme than LISP, but I still subscribe
to the notion that functions should be as single-minded as possible,
even in languages built over the parenthesis model. The valuable
lessons of cohesion do not vanish simply because one is not using
assignment statements. In fact, I think the cohesion rules may be
even more essential in the production of readable LISP/Scheme
code.
Then again, the object-oriented developer can always consider LMI,
where the concepts of cohesion and coupling do apply.
Richard Riehle
"Alain Picard" <············@memetrics.com> wrote in message
···················@memetrics.com...
> <········@sbcglobal.net> writes:
>
> > "Kaz Kylheku" <···@ashi.footprints.net> wrote in message
> > ·····························@o13g2000cwo.googlegroups.com...
> >> As a rule of thumb, I try to write mine so they don't extend past the
> >> closing parenthesis.
> >>
> > The problem with this is that not all languages are designed
> > around this model. Also, I wonder if you actually meant,
> > curly brace?
>
> He did not.
>
> > Also, the question is not simply about the size of functions/methods,
> > but also needs to address the size of classes that contain those
> > methods/functions.
>
> And the reason he did not is, in his world, methods are not
> "contained" in classes.
>
> Aaah, the joys of crossposting. :-/
>
From: Christopher C. Stacy
Subject: Re: How long should a function be?
Date:
Message-ID: <uvf52em1b.fsf@news.dtpq.com>
<········@sbcglobal.net> writes:
> I am more accustomed to Scheme than LISP, but I still subscribe
> to the notion that functions should be as single-minded as possible,
> even in languages built over the parenthesis model.
What is the "parenthesis model"?
"Christopher C. Stacy" <······@news.dtpq.com> wrote in message
··················@news.dtpq.com...
> <········@sbcglobal.net> writes:
> > I am more accustomed to Scheme than LISP, but I still subscribe
> > to the notion that functions should be as single-minded as possible,
> > even in languages built over the parenthesis model.
>
> What is the "parenthesis model"?
The LISP family of functional languages.
I actually believe that LISP and its close relatives, including
the other functional languages, are the most effective approach
to a large class of software problems. It is always, of course,
a matter of selecting the right tool for the right job.
Richard Riehle
From: Christopher C. Stacy
Subject: Re: How long should a function be?
Date:
Message-ID: <upsvae3vf.fsf@news.dtpq.com>
<········@sbcglobal.net> writes:
> "Christopher C. Stacy" <······@news.dtpq.com> wrote in message
> ··················@news.dtpq.com...
> > <········@sbcglobal.net> writes:
> > > I am more accustomed to Scheme than LISP, but I still subscribe
> > > to the notion that functions should be as single-minded as possible,
> > > even in languages built over the parenthesis model.
> >
> > What is the "parenthesis model"?
>
> The LISP family of functional languages.
Your understanding of Lisp seems at first glance to be somewhat
different from mine, and I would like to ask you to elaborate on
what you are talking about. (I don't know how much we might end
up agreeing, but I am very curious what you think about Lisp,
and also how you came to your understandings about it.)
I still don't understand what you mean by "parenthesis model".
Lisp uses parenthesis as the primary syntax punctuation,
like some other languages use curly braces and semicolons.
But what is this "model" that you refer to?
I am also not sure what you mean by "functional language".
Lisp of course has function calling, but so does Algol;
Lisp functions usually return values, but often the values
are discarded, because these function calls were purely
imperative statements. (It's just that there isn't any
different syntax for "statements" versus "functions".
And parenthesis are also used in Lisp for things that
are not function calls at all.) Lisp has first-class function
objects, but it has never been a "pure" "functional language".
Lisp is, in fact, pretty much all about side-effects.
> In any case, the answer to this question cannot be in terms of
> lines of code, language constructs, or the size of the display.
> Rather, it has to be decided in terms of the old-fashioned concerns
> of coupling and cohesion. These concerns are relevant to both
> methods and classes. In other words, it is a question that relates
> to levels of modularity.
> Each module should be as single-minded as possible. In some
> cases, a method will be one or two lines long. In other,
> much rarer cases, it may be a hundred lines long.
I am still not clear on what you mean by "single-minded".
Lisp has always been about "generic" functions that dispatch
on the latent type of their arguments in order to determine
what to do. (For example: arithmetic operators that accept
many types, sequence operators that accept either lists or
vectors, IO functions that accept several kinds of designators,
such as streams or strings or file pathnames, and of course
user-written CLOS generic function methods.)
Lisp's run-time type orientation frees the programmer from having
to make any early commitments about the type of the arguments.
This is one primary way in which Lisp supports evolutionary
and exploratory programming.
If you're just trying to say that a function with a given name
should have some well-defined semantics, of course anyone would
agree with that. But I don't see how, absent language constructs,
that relates to code size in a way that is different from legs
that ought to reach the ground or lengths of string.
It seems to me that different languages provide different
ways of achieving (and encouraging) modularity, and that
those differences -- the language constructs -- are exactly
what is important in determining what a "module" will
encompass and how large it will be.
For example, you were concerned that the source code for a
class definition would be too large if too many methods
were defined in it. But in Lisp, class definitions have
no lexical relation whatsoever to method definitions.
> In the object world, when we think in terms of methods,
> we realize that query methods are likely to be short
> while modifier methods may be a bit longer.
It seems to me that it is often the other way around: query
methods may be longer, because they must take specification
parameters to narrow the search and implement them.
But modifier methods just take the desired object,
sometimes along with a new value. In the case where both
kinds of methods take specifications, they would tend to be
about the same size. I just don't see a clear rule here that
suggests that one kind of method would always be likely be
significantly longer.
> Often, modifier methods are made more understandable by
> separating out conditional statements into query methods.
> This has the effect of making an otherwise long modifier
> method much shorter.
I am not sure what you're thinking there. A modifier method
generally doesn't need to perform any queries -- it already
has the object in hand which needs modifying. Wouldn't this
method generally consist of just doing some instance variable
assignments (which might themselves be method calls)?
Mostly I am curious about your theory of Lisp, how you
think it works, your experience with it, why your
understanding of it seems so different from my own,
and how this came to be.
"Christopher C. Stacy" <······@news.dtpq.com> wrote in message
··················@news.dtpq.com...
> <········@sbcglobal.net> writes:
>
> > "Christopher C. Stacy" <······@news.dtpq.com> wrote in message
> > ··················@news.dtpq.com...
> > > <········@sbcglobal.net> writes:
> > > > I am more accustomed to Scheme than LISP, but I still subscribe
> > > > to the notion that functions should be as single-minded as possible,
> > > > even in languages built over the parenthesis model.
> > >
> > > What is the "parenthesis model"?
> >
> > The LISP family of functional languages.
>
> Your understanding of Lisp seems at first glance to be somewhat
> different from mine, and I would like to ask you to elaborate on
> what you are talking about. (I don't know how much we might end
> up agreeing, but I am very curious what you think about Lisp,
> and also how you came to your understandings about it.)
>
> I still don't understand what you mean by "parenthesis model".
> Lisp uses parenthesis as the primary syntax punctuation,
> like some other languages use curly braces and semicolons.
> But what is this "model" that you refer to?
>
> I am also not sure what you mean by "functional language".
> Lisp of course has function calling, but so does Algol;
OK, contemporary Lisp is not a pure functional language. I am
not trying to disparage Lisp. As I indicated earlier, it is a good
language for a lot of problems. I am more accustomed to Scheme,
which puts me on the defensive with many Lisp enthusiasts.
I do see the parentheses as a bit more than a syntax notation, but
we don't need to quibble about that. If you are troubled by my
choice of the word "model", perhaps some other word will do,
such as "protocol." I sometimes refer to the C family languages
as being built over a "curly brace" protocol. Once again, this
is not intended to suggest that curly braces make a language
bad. Although, I have heard that there is an impending
world-wide shortage of curly braces, and programmers who
insist on using C++, Java, etc., may suddenly find themselves
unable to complete their work. Parentheses and semicolons,
on the other hand, seem to be plentiful so Lisp, Eiffel, and
Modula programmers will still be able to produce plenty of
code far into the future.
Richard Riehle
<········@sbcglobal.net> wrote:
> I have heard that there is an impending
> world-wide shortage of curly braces, and programmers who
> insist on using C++, Java, etc., may suddenly find themselves
> unable to complete their work. Parentheses and semicolons,
> on the other hand, seem to be plentiful so Lisp, Eiffel, and
> Modula programmers will still be able to produce plenty of
> code far into the future.
Pythonistas have you all beat. All we need to keep going is whitespace.
If we ever run out of virgin whitespace, we can always start recycling it
from old fortran and cobol programs.
From: Edi Weitz
Subject: Re: How long should a function be?
Date:
Message-ID: <ud5r9lvvc.fsf@agharta.de>
On Sun, 29 May 2005 13:33:39 -0400, Roy Smith <···@panix.com> wrote:
> Pythonistas have you all beat. All we need to keep going is
> whitespace. If we ever run out of virgin whitespace, we can always
> start recycling it from old fortran and cobol programs.
I wouldn't be too sure, though. Maybe Guido will at one point in the
future decide that virgin whitespace and recycled whitespace aren't
the same thing syntactically.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
In article <·············@agharta.de>, Edi Weitz <········@agharta.de>
wrote:
> On Sun, 29 May 2005 13:33:39 -0400, Roy Smith <···@panix.com> wrote:
>
> > Pythonistas have you all beat. All we need to keep going is
> > whitespace. If we ever run out of virgin whitespace, we can always
> > start recycling it from old fortran and cobol programs.
>
> I wouldn't be too sure, though. Maybe Guido will at one point in the
> future decide that virgin whitespace and recycled whitespace aren't
> the same thing syntactically.
I can just imagine all these fancy high-priced programming boutiques
springing up in the better neighborhoods advertising they only use
"extra-virgin whitespace".
Edi Weitz wrote:
> On Sun, 29 May 2005 13:33:39 -0400, Roy Smith <···@panix.com> wrote:
>
>>Pythonistas have you all beat. All we need to keep going is
>>whitespace. If we ever run out of virgin whitespace, we can always
>>start recycling it from old fortran and cobol programs.
>
> I wouldn't be too sure, though. Maybe Guido will at one point in the
> future decide that virgin whitespace and recycled whitespace aren't
> the same thing syntactically.
Whoa, you're evil! Don't say this so loud - someone might think it's a
good idea... ;)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8C9DBE87EF213E5DD073AFB9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Edi Weitz wrote:
> On Sun, 29 May 2005 13:33:39 -0400, Roy Smith <···@panix.com> wrote:
>
>
>>Pythonistas have you all beat. All we need to keep going is
>>whitespace. If we ever run out of virgin whitespace, we can always
>>start recycling it from old fortran and cobol programs.
>
>
> I wouldn't be too sure, though. Maybe Guido will at one point in the
> future decide that virgin whitespace and recycled whitespace aren't
> the same thing syntactically.
Well, certainly I can imagine this in Stroustrup's c++2000 proposal. It
fits nicely with his "space" and "missing space" operators...
>
> Cheers,
> Edi.
>
PM
--------------enig8C9DBE87EF213E5DD073AFB9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with MultiZilla - http://enigmail.mozdev.org
iD8DBQFCmjUHP96qek/rA6ERAvtIAKDK4CIse5NbLb1YEgbmvNi8ZNQbSQCfS6Bj
VtE1EXhqf2mnKUy/3Dy7QQI=
=6Nll
-----END PGP SIGNATURE-----
--------------enig8C9DBE87EF213E5DD073AFB9--
From: Christopher C. Stacy
Subject: Re: How long should a function be?
Date:
Message-ID: <u8y1xe3l6.fsf@news.dtpq.com>
<········@sbcglobal.net> writes:
> OK, contemporary Lisp is not a pure functional language.
Nor was the original implementation on the IBM and PDP-1,
nor any of the follow-on implementations in the 1960/70s
leading directly contemporary (1980s) implementations.
(I believe that people may have invented some dialect of
Lisp somewhere along the way which was purely functional.
But I don't know what it was called. I am just imagining
it likely that there might have been some experiment or
pedagogical example along those lines. But if it did exist,
it was never used by the community of Lisp programmers.)
> I am not trying to disparage Lisp. As I indicated earlier,
> it is a good language for a lot of problems. I am more
> accustomed to Scheme, which puts me on the defensive
> with many Lisp enthusiasts.
I didn't assume that you were trying to disparage Lisp
(especially since you had already mentioned, I think,
that you thought it was good for something).
Scheme is not purely functional, either.
It has variables and mutable data structures just like Lisp.
Not as many standard data types in Scheme, though.
> I do see the parentheses as a bit more than a syntax notation,
> but we don't need to quibble about that. If you are troubled by
> my choice of the word "model", perhaps some other word will do,
> such as "protocol." I sometimes refer to the C family languages
> as being built over a "curly brace" protocol. Once again, this
> is not intended to suggest that curly braces make a language bad.
But what I am wondering is: what is your "model" or "protocol"
of parenthesis (or curly-braces) which causes you to believe that
"functions should be as single-minded as possible, even in
languages built over the parenthesis model"?
I may not be clear on what "single-minded" means.
How does it relate (negatively, I guess) to the
tradition of "generic" functions in Lisp?
I do not see that you are pronouncing languages "good" or "bad".
······@news.dtpq.com (Christopher C. Stacy) writes:
> (I believe that people may have invented some dialect of
> Lisp somewhere along the way which was purely functional.
> But I don't know what it was called. I am just imagining
> it likely that there might have been some experiment or
> pedagogical example along those lines. But if it did exist,
> it was never used by the community of Lisp programmers.)
ACL2 is a purely functional extended subset of Common Lisp. It has a
very active community of users, although those users are probably more
interested in verifying the substrates we write general purpose
programs on, rather than writing those general purpose programs.
From: Christopher C. Stacy
Subject: Re: How long should a function be?
Date:
Message-ID: <umzqc1fu5.fsf@news.dtpq.com>
Carl Shapiro <·············@panix.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > (I believe that people may have invented some dialect of
> > Lisp somewhere along the way which was purely functional.
> > But I don't know what it was called. I am just imagining
> > it likely that there might have been some experiment or
> > pedagogical example along those lines. But if it did exist,
> > it was never used by the community of Lisp programmers.)
>
> ACL2 is a purely functional extended subset of Common Lisp. It has a
> very active community of users, although those users are probably more
> interested in verifying the substrates we write general purpose
> programs on, rather than writing those general purpose programs.
ACL2 uses some function names from Common Lisp. but ACL2 does not
have an evaluation model that is like Lisp; it's a theorem prover.
That makes it radically different from any "Lisp implementation".
······@news.dtpq.com (Christopher C. Stacy) writes:
> ACL2 uses some function names from Common Lisp. but ACL2 does not
> have an evaluation model that is like Lisp; it's a theorem prover.
> That makes it radically different from any "Lisp implementation".
ACL2 is a programming language and you can write programs in ACL2 as
you would in many other purely functional programming languages, your
expectations of theorem provers notwithstanding. If you have not yet
made up your mind on this matter, I would encourage you to search for
the phrase "acl2 programming language" through Google. The "I'm
Feeling Lucky" button will likely direct you to a good starting place.
From: Christopher C. Stacy
Subject: Re: How long should a function be?
Date:
Message-ID: <uekbo195a.fsf@news.dtpq.com>
Carl Shapiro <·············@panix.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
> > ACL2 uses some function names from Common Lisp. but ACL2 does not
> > have an evaluation model that is like Lisp; it's a theorem prover.
> > That makes it radically different from any "Lisp implementation".
>
> ACL2 is a programming language and you can write programs in ACL2 as
> you would in many other purely functional programming languages,
I didn't say you couldn't write programs in it.
I said it doesn't implement the EVAL model that defines "Lisp".
> your expectations of theorem provers notwithstanding. If you have
> not yet made up your mind on this matter,
On the matter of whether it's Lisp? Or the matter of whether one
could write a program in this language (about which I said nothing)?
> I would encourage you to search for the phrase "acl2 programming
> language" through Google. The "I'm Feeling Lucky" button will
> likely direct you to a good starting place.
Yes, that's exactly what I had already read.
Did my response say something incorrect?
······@news.dtpq.com (Christopher C. Stacy) writes:
> Yes, that's exactly what I had already read.
> Did my response say something incorrect?
Yes, you have. It's your assertion that ACL2 "does not have an
evaluation model that is like Lisp".
From: Christopher C. Stacy
Subject: Re: How long should a function be?
Date:
Message-ID: <uacmc114d.fsf@news.dtpq.com>
Carl Shapiro <·············@panix.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > Yes, that's exactly what I had already read.
> > Did my response say something incorrect?
>
> Yes, you have. It's your assertion that ACL2 "does not
> have an evaluation model that is like Lisp".
By "an evaluation model like Lisp", I mean one that's like
the first LISP implementation, or LISP 1.5, or BBN/INTERLISP,
or MACLISP and all its numerous descendants and relatives, MDL,
Scheme, Common Lisp, etc. It does not include languages that
do things like lazy or partial evaluation and return unresolved
symbolic answers.
I was looking at one of the first ACL2 examples presented
when I went to the home page, which was:
(lookup 'z (mc (s 'mult 5 y) 29))
=> (+ y y y y y).
This is symbolic execution because not all of the
parameters are known.
But you can also say (+ 1 2) and get back 3, I think.
ACL2 is capable of evaluating programs and return definite answers,
so maybe (except for the pure functional aspect) it is like Lisp.
I made up the term "evaluation model"; I was thinking that Lisp
is a language defined by what happens when you pass things to the
"evaluator", which is usually available through EVAL.
But ACL2 doesn't have EVAL, so we have to look at some other
entrypoint. If you type in (+ X Y) at the ACL2 toplevel,
I think you'll get a kind of unbound variable error.
So maybe that's the same as in Lisp.
I don't think it's very accurate to describe ACL2 as a
"subset of Common Lisp" and giving the impression that
it's anything much like programming in CL. ACL2 has such
a tiny subset of Common Lisp, there are lots of differences,
and the semantics of the operators often cannot be the same
as in Common Lisp. For example, the semantics of EQ are
that "at least one of the arguments to eq must be a symbol".
(Maybe that says that something is very different about
the evaluator, after all?) Being a pure functional language,
there's no SETF/SETQ, and no mutable data stuctures, of course.
Does ACL2 handle iteration? It sounds like ACL2 only has recursion.
The standard functions in ACL2 are limited and often don't have all
the arguments as in CL (for example, POSITION versus POSITION-EQ).
ACL2 doesn't have lambda list keywords (like &OPTIONAL).
Writing macros seems harder (no backquote, GENSYM, no environment).
ACL2 lacks some of the most fundamental primitives constructs of
Common Lisp (or any "Lisp"), such as EVAL, APPLY, FUNCALL, or LAMBDA.
The introductory documentation says:
----
ACL2 is an automated reasoning system [...] the successor to
the Nqthm (or Boyer-Moore) logic and proof system and its
Pc-Nqthm interactive enhancement. The acronym ACL2 actually
stands for ``A Computational Logic for Applicative Common Lisp''.
The syntax of ACL2 is that of Common Lisp; ACL2 specifications
are "also" Common Lisp programs in a way that we will make clear
later. In less formal language, the ACL2 logic is an integrated
collection of rules for defining (or axiomatizing) recursive
functions, stating properties of those functions, and rigorously
establishing those properties. Each of these activities is
mechanically supported.
[...]
Second, many ACL2 specifications are executable.
In fact, recursive functions written in ACL2 are Common Lisp
functions that can be submitted to any compliant Common Lisp
compiler and executed (in an environment where suitable
ACL2-specific macros and functions are defined).
----
The last paragraph seems to be suggesting that some ACL2 programs,
while they look like Lisp, cannot be executed by the Lisp implementation
that it claims to be "a subset" of, even when programmed with the
appropriate macros and functions. The "specification" language is a
subset of Common Lisp, yet some programs written in ACL2 language are
not possible to evaluate in Lisp. This suggests that ACL2 has some
other idea of what to do with input, something different than Lisp,
something different than EVAL. I wonder, what are these programs?
Or what else is this supposed to mean?
At the least, ACL2 does has Lisp syntax, and has a few functions with
the same names as in Common Lisp, and some ACL2 programs also happen
to be valid Common Lisp programs. In the end, whether ACL2 is "Lisp"
is largely a question of user communities. I submit that it has a
very different user community. Certainly, programming in ACL2 is not
really very much like programming in the historical and current Lisp
languages that I cited at the beginning. But those radical differences
are the entire point of ACL2, aren't they?
ACL2 is very interesting, and doubtless useful for some things.
cheers,
Chris
P.S. For newbies.
This sub-thread is a side-note to a claim by someone that
the original implementations of Lisp was pure functional.
As already explained, that's just not historically true.
But I was pretty sure that someone had invented a pure
functional language that was based on Lisp, and Carl Shapiro
provided the example of ACL2. In case there's any confusion
about historical placement, ACL2 dates from the late 1990s.
When most people refer to "Lisp", they are not thinking of
a language like ACL2. They are thinking of one of the members
of the family directly descended for the original, such as
Common Lisp, Emacs Lisp, or Scheme. People who self-identify
as being a "Lisp programmer" almost always mean Common Lisp.
See <http://www.nhplace.com/kent/PS/Lambda.html>
Lisp programmers get a little bent out of shape about
mischaracterizations of the language that they spend
all their time working in. Unfortunately, because of
its neat notation and function-oriented style, Lisp is
often abused by academics trying to illustrate some point
of computational theory, leaving students with the idea
that they have seen the real programming language "Lisp".