How long should a function be?
Roy Smith
full of mostly good advice) just now and came upon section 5.5, "How Long
Can a Routine Be?". McConnell argues (with supporting references) that
longer is better, and seems to be saying that 150-200 lines is the sweet
spot.
Now, this really blew my mind. For years, I've been firmly in the "shorter
is better" camp, and generally consider a screenful (say, somewhere in the
range of 40-60 lines) about the upper limit you want to be shooting for.
McConnell is arguing for something 2-5 times that.
I know line counting is a sort of silly metric to get hung up on, but this
still seems surprising. If somebody brought a 200 line function to a code
review, I'd be rolling my eyes and making rude comments before we even got
started.
The book is 12 years old, but I don't think this kind of stuff has changed
radically since then. Or maybe it has?
Jack Klein
comp.software-eng:
Judging functions by their length only is just plain wrong. Like you,
I believe in short functions whenever possible, but there are always
exceptions to all rules.
In some cases there are pure computational functions with little or no
conditional logic that would gain nothing in understandability or
maintainability by being arbitrarily broken into smaller functions.
The more important issue is complexity and code paths. If getting it
all done in one function means eight nested levels of if..else
if...else, it is almost certainly better to break some of those levels
out into functions of their own.
And sometimes the sheer complexity of what can be a single expression
screams to be a function of its own, especially if it is used
repeatedly. Here is an example from a file I code reviewed yesterday,
a little squeezed to avoid line wrap:
if((!(mcm_mcd_data[drive].motion_config.stopping_device_config &
SDC_BRAKE1) || mcm_mcd_data[drive].motion_status.brake1.powered ) &&
(!(mcm_mcd_data[drive].motion_config.stopping_device_config &
SDC_BRAKE2) || mcm_mcd_data[drive].motion_status.brake2.powered ) )
This expression appeared four times in four functions in a single
source file.
I flagged it with a "comment" entry, one of the types in our process,
which the programmer can ignore or choose to act on the next time that
particular file is modified. I said the expression would be better
moved to a static function in the source code file with a name like
bool is_drives_brake_ok(drive_t drive).
I have seen 25 line functions that would benefit from rafactoring,
and, rarely, 500 line functions that did not need it.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Bradley K. Sherman
Make it as long as you want, just keep it less than 80 columns wide
with proper white space.
--bks
Andrew McDonagh
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
Jonathan Allan
> ... just keep it less than 80 columns wide ...
Oh, please! Punched cards are dead except for a few museum pieces.
Unless you're working on an antique or using a column dependent language,
why on Earth should you be limited to 80 columns wide? With the easy
availability of inexpensive multi-monitor systems (I'm sitting behind a
pair of flat panels at the moment ;-), ridiculously wide is possible
and might even be helpful.
Jonathan
--
Jonathan Allan
Neither Mayo Clinic nor I speak for each other unless we explicitly
say so. You should assume I am speaking only for myself.
Please remove the antispam ".6809" to reply direct to me. Thanks!
Bradley K. Sherman
Jonathan Allan <Allan.J...@6809.mayo.edu> wrote:
>Bradley K. Sherman wrote:
>
>> ... just keep it less than 80 columns wide ...
>
>Oh, please! Punched cards are dead except for a few museum pieces.
>
>Unless you're working on an antique or using a column dependent language,
>
>why on Earth should you be limited to 80 columns wide? With the easy
>availability of inexpensive multi-monitor systems (I'm sitting behind a
>pair of flat panels at the moment ;-), ridiculously wide is possible
80 is arbitrary and is probably too big. For reading off a computer
screen, 40-45 columns is optimal (look at how Blogging is done).
I think it would be too draconian to force programmers to live with
that restriction, but in general, narrow listings are easier to read.
123456789012345678901234567890123456789012345
for ( row = 0; row < MAXROW; row++ )
for ( col = 0; col < MAXCOL; col++ )
foo[row][col] = bar;
123456789012345678901234567890123456789012345
Why would you ever need more width than that?
--bks
Carlos
thousands of files, you will need literal and variable names more
descriptive than MAXROW and row/col. I have ones that are over 40 chars
on their own, they may be part of a similarly named class/structure and
be being passed into a function, that's way over 80 chars already before
adding that the function may itself be part of a class/package, take
more than one parameter and ignoring any casting requirements.
Phlip
> Judging functions by their length only is just plain wrong. Like you,
> I believe in short functions whenever possible, but there are always
> exceptions to all rules.
What usually happens is you follow other design guidelines - such as
suppressing duplicated definitions of behavior - and you get short methods
as a side-effect. There are those who call the result "Contractive
Delegation".
Bradley K. Sherman wrote:
> Make it as long as you want, just keep it less than 80 columns wide
> with proper white space.
Ha ha.
Oh, wait. Are you serious??
Bradley K. Sherman wrote:
> Why would you ever need more width than that?
You should merge all duplication you can, so long as the result is
expressive and readable. [Like I said, that simple rule tends to whomp long
functions.]
If you can't think of a way to merge duplication and remain readable (or you
can't think of any way at all), you should at least put the duplicating
elements next to each other. This practice tends to form little readable
tables. If you then align the columns, you can scan down them easily.
Such tables blow margins.
Otherwise, you are correct in your implication that one line should do only
a few things, and should be readable in one scan.
> Jack Klein wrote:
> I have seen 25 line functions that would benefit from rafactoring,
> and, rarely, 500 line functions that did not need it.
Andrew McDonagh wrote:
> 500 line functions usually mean its a class hiding as a function.
However, becoming a class is not _necessarily_ a benefit. ;-)
Carlos wrote:
> In a complex piece of software spread over numerous packages and
> thousands of files, you will need literal and variable names more
> descriptive than MAXROW and row/col. I have ones that are over 40 chars
> on their own, they may be part of a similarly named class/structure and
> be being passed into a function, that's way over 80 chars already before
> adding that the function may itself be part of a class/package, take
> more than one parameter and ignoring any casting requirements.
However, when you refactor, you should seek duplication in many ways,
including squinting at the general shapes of methods, looking for common
patterns, and including looking at common elements within long variable
names. AlicesTeaParty() could become Alices::Tea.Party().
Notice to Roy Smith: [Almost] everyone here is actively discussing actively
_refactoring_ live code. At the time of Code Complete 1st Edition, changing
design without changing behavior was frowned upon as rework, so if a long
method works, leave it alone.
I have no idea how such a fine author as McConnell could have called so long
a method a "sweet spot".
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
Donald McLean
> In a complex piece of software spread over numerous packages and
> thousands of files, you will need literal and variable names more
> descriptive than MAXROW and row/col. I have ones that are over 40 chars
> on their own, they may be part of a similarly named class/structure and
> be being passed into a function, that's way over 80 chars already before
> adding that the function may itself be part of a class/package, take
> more than one parameter and ignoring any casting requirements.
>
I would venture to guess that there is a point of diminishing returns on
the length of identifiers and I would be willing to bet that it is
probably shorter than 40 characters.
UnclesSecondCousinsLeftHandedBrothersDog
UnclesSecondCousinsLeftHandedBrothersCat
I don't know about you, but I'm going to be tired of reading the
identifier long before I can tell them apart. AND I would be willing to
bet that Robert Martin would agree with me.
Jonathan Allan wrote:
> Bradley K. Sherman wrote:
>
>> ... just keep it less than 80 columns wide ...
>
> Oh, please! Punched cards are dead except for a few museum pieces.
>
> Unless you're working on an antique or using a column dependent language,
>
> why on Earth should you be limited to 80 columns wide? With the easy
> availability of inexpensive multi-monitor systems (I'm sitting behind a
> pair of flat panels at the moment ;-), ridiculously wide is possible
>
> and might even be helpful.
What about people with poor eyesight who can't use anything smaller than
18 point fonts? What if you have a person at a customer site working on
a laptop? You're making an assumption that just because something is a
really good idea (wide dual monitor configurations) that it will always
be so or that it will always be possible.
And you know what they say about assumptions.
Jonathan Allan
>
> What about people with poor eyesight who can't use anything smaller than
> 18 point fonts? What if you have a person at a customer site working on
> a laptop? You're making an assumption that just because something is a
> really good idea (wide dual monitor configurations) that it will always
> be so or that it will always be possible.
>
> And you know what they say about assumptions.
Sure.
I wasn't assuming anything however. I've been in the laptop situation
myself and your point is well taken. However, I would point out that
most modern programming editors can use a proportional font instead
of a fixed width font, which eliminates the whole concept of columns
from the get go and potentially makes code more readable as well.
I wasn't reacting to the keeping code narrow for readability purposes,
I was reacting to the fixing of a particular width with roots in the
Bad Old Days (tm).
Bradley K. Sherman
Jonathan Allan <Allan.J...@6809.mayo.edu> wrote:
>myself and your point is well taken. However, I would point out that
>most modern programming editors can use a proportional font instead
>of a fixed width font, which eliminates the whole concept of columns
>from the get go and potentially makes code more readable as well.
The documentation, maybe, but lord save us from finding matching
syntax markers in proportional fonts.
--bks
David Wallace
According to Andrew McDonagh <ne...@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.
--
Dave Wallace (Remove NOSPAM from my address to email me)
It is quite humbling to realize that the storage occupied by the longest
line from a typical Usenet posting is sufficient to provide a state space
so vast that all the computation power in the world can not conquer it.
Phlip
> switch(operation) {
>
> case OP_001:
> /* OP_001 action */
> break;
>
> case OP_002:
> /* OP_002 action */
> break;
>
> ...
>
> case OP_150:
> Have at it.
How about:
jumpTable[operation](...);
?
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
Andrew McDonagh
> David Wallace wrote:
>
>
>>switch(operation) {
>>
>>case OP_001:
>>/* OP_001 action */
>>break;
>>
>>case OP_002:
>>/* OP_002 action */
>>break;
>>
>>...
>>
>>case OP_150:
>>Have at it.
>
>
> How about:
>
> jumpTable[operation](...);
>
> ?
>
damn you beat me to it....
Andrew McDonagh
Phlip beat me to the punch...
the techniques name being:
'Replace conditional dispatcher with Command
http://www.industriallogic.com/xp/refactoring/conditionDispatcherWithCommand.html
also, various other approaches include:
'Replace conditional with polymorphism'
http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html
'Replace conditional dispatcher with Command
http://www.industriallogic.com/xp/refactoring/conditionDispatcherWithCommand.html
'Replace Type Code with State/Strategy'
http://www.refactoring.com/catalog/replaceTypeCodeWithStateStrategy.html
'Replace Type Code with Subclasses'
http://www.refactoring.com/catalog/replaceTypeCodeWithSubclasses.html
Bradley K. Sherman
The switch statment is much, much clearer than pawing through 150 separate
pieces of code each surrounded by a thin, thin shell of syntactic sugar.
I've never understood this reaction against switch statements which
are so elegant compared to the maniacal decompositions suggested.
--bks
Phlip
> The switch statment is much, much clearer than pawing through 150 separate
> pieces of code each surrounded by a thin, thin shell of syntactic sugar.
I also said, "If you can't think of a way to merge duplication and remain
readable (or you
can't think of any way at all), you should at least put the duplicating
elements next to each other. This practice tends to form little readable
tables."
If your string of cases is a readable table, we are in violent agreement.
Very violent.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
EventHelix.com
I think the recommended size is 30 to 40 lines with a max of 100.
Deepa
--
EventStudio 2.5 - http://www.EventHelix.com/EventStudio
Auto Layout and Generate Sequence Diagrams in PDF and MS Word
Roy Smith
"EventHelix.com" <event...@gmail.com> wrote:
> Have a look at Code Complete 2nd Edition.
>
> I think the recommended size is 30 to 40 lines with a max of 100.
Interesting. So what changed? Did McConnell just have a change of heart,
or was there new research published between the two editions which led him
to a different conclusion?
Phlip
> EventHelix.com wrote:
>
> > Have a look at Code Complete 2nd Edition.
> >
> > I think the recommended size is 30 to 40 lines with a max of 100.
>
> Interesting. So what changed? Did McConnell just have a change of heart,
> or was there new research published between the two editions which led him
> to a different conclusion?
Smalltalkers claim 3.
--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
Paul Dietz
;;; 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
Kaz Kylheku
closing parenthesis.
adaw...@sbcglobal.net
A function should be as short as possible, but not shorter.
Richard Riehle
Fred Gilham
"Kaz Kylheku" <k...@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 gil...@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
EventHelix.com
theorentical maximum length is one screen full (i.e. 50 to 100 lines).
He goes on to say that at one point IBM limited the maximum length
of a function to 50 lines.
Deepa
--
EventStudio 2.5 - http://www.EventHelix.com/EventStudio
Auto Layout and Generate Call Flow Diagrams in PDF and MS Word
H. S. Lahman
> I was browsing my copy of Code Complete (which I generally consider to be
> full of mostly good advice) just now and came upon section 5.5, "How Long
> Can a Routine Be?". McConnell argues (with supporting references) that
> longer is better, and seems to be saying that 150-200 lines is the sweet
> spot.
>
> Now, this really blew my mind. For years, I've been firmly in the "shorter
> is better" camp, and generally consider a screenful (say, somewhere in the
> range of 40-60 lines) about the upper limit you want to be shooting for.
> McConnell is arguing for something 2-5 times that.
The length depends on what the subject matter is and what the
development paradigm is. For example, in OO development methods tend to
be trivially short because one religiously applies separation of
concerns and seeks highly cohesive object and responsibility abstractions.
However, the OO paradigm also encapsulates processing that is defined at
a wider scope than the business rules for the problem in hand (e.g.,
algorithmic processing that is defined as an operations research
algorithm). So one could have a single method with a few hundred lines.
[Or the method could simply dispatch to an entire realized subsystem
(e.g., a linear programming package), which would likely be the solution
for an algorithm exceeding a few hundred lines.]
FWIW, I was never a fan of large functions even back in my Hacker Days
in the '70s doing ad hoc procedural development. Avoiding them was one
of the reasons one did functional decomposition. OTOH, modularization
and isolation of invariant (stable) code could justify larger functions
for pretty much the same reason as in OO development -- it is logically
indivisible relative to the problem solution.
[Apocryphal anecdote. One day, ca '85, a guy came to me for advice
because the BLISS compiler threw an error at him he had never seen. The
error essentially indicated the compiler had blown its stack space. I
looked at the offending code and discovered the function was > 1800
executable statements and it was one of several of similar length in the
file. As it happens, our BLISS compiler optimized across functions at
file scope and it simply lost track of things. So my answer was: Don't
Do That. He got very annoyed that the compiler wasn't allowing him to
code "in an optimal fashion".]
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
adaw...@sbcglobal.net
"Kaz Kylheku" <k...@ashi.footprints.net> wrote in message
news:1117139610.6...@o13g2000cwo.googlegroups.com...
> As a rule of thumb, I try to write mine so they don't extend past the
> closing parenthesis.
>
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
Tim Josling
> "Kaz Kylheku" <k...@ashi.footprints.net> wrote in message
> news:1117139610.6...@o13g2000cwo.googlegroups.com...
>
>>As a rule of thumb, I try to write mine so they don't extend past the
>>closing parenthesis.
>>
> 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
Phlip
> 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
Pascal Costanza
> 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/
Greg Menke
"Phlip" <phli...@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
Phlip
> 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
Greg Menke
"Phlip" <phli...@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
Alain Picard
> "Kaz Kylheku" <k...@ashi.footprints.net> wrote in message
> news:1117139610.6...@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. :-/
adaw...@sbcglobal.net
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" <Alain....@memetrics.com> wrote in message
news:87fyw6v...@memetrics.com...
Christopher C. Stacy
> 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 Browne
> 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!
Paul Sinnett
> 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.
Paul Sinnett
> 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
adaw...@sbcglobal.net
"Christopher Browne" <cbbr...@acm.org> wrote in message
news:0vbme.35287$Ot6.1...@news20.bellglobal.com...
> Quoth Pascal Costanza <p...@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...
>
Ada that is as lean, as efficient, and as well-engineered as you
might produce in whatever your favorite language might be.
Richard Riehle
adaw...@sbcglobal.net
"Christopher C. Stacy" <cst...@news.dtpq.com> wrote in message
news:uvf52e...@news.dtpq.com...
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
Christopher C. Stacy
> "Christopher C. Stacy" <cst...@news.dtpq.com> wrote in message
> news:uvf52e...@news.dtpq.com...
> > <adaw...@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.
Pascal Costanza
> Pascal Costanza <p...@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.
>
>
>
> http://www.leshatton.org/Documents/Ubend_IS697.pdf
Thanks a lot!
Pascal Costanza
> Quoth Pascal Costanza <p...@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.
Christopher C. Stacy
> I would venture to guess that there is a point of diminishing returns
> on the length of identifiers and I would be willing to bet that it is
> probably shorter than 40 characters.
>
> UnclesSecondCousinsLeftHandedBrothersDog
> UnclesSecondCousinsLeftHandedBrothersCat
>
> I don't know about you, but I'm going to be tired of reading the
> identifier long before I can tell them apart. AND I would be willing
> to bet that Robert Martin would agree with me.
Here are some long identifiers from various programs.
C Compiler:
make-bit-fetch-operator
var-set-but-not-referenced
*size-of-machine-fef-constant-area*
sum-argument-list-stack-requirements
estimate-stack-requirements-for-deref
machine-dependent-boolean-to-integer-form
Graphics files utility:
write-image-to-file-in-format
with-graphics-identity-transform
define-hardcopy-screen-destination
pathname-default-image-file-format-name
graphics-make-raster-array-with-correct-width
Mail reader:
domain-host-indicator
address-original-string
colon-atom-colon-address
address-distribution-list
add-parse-grammar-production
parse-addresses-in-smtp-reply
unknown-user-object-in-address
addresses-in-brackets-with-route
Window system:
*x-querytextextents*
gcontext-server-state
with-buffer-request-and-reply
pattern-call-with-drawing-parameters
highlighting-boxes-mouse-sensitive-boxes
displayed-presentation-shares-superiors-boxes-valid
Operating system guts:
%make-physical-address
read-merlin-eco-registers
logior-bus-interrupt-mask
*slave-buffer-base-address*
initialize-system-disk-event
%%merlin-i-VME-interrupt-mask
*storage-background-disk-event*
*VMEbus-interrupt-status-length*
8032-incoming-frame-target-length
%%merlin-VME-option-bus-request-level
%scsi-ccs-esk-illegal-logical-block-address
%interrupt-mode-high-priority-sequence-break
Those are certainly not the longest ones I could come up with;
they're just typical examples plucked quite randomly.
These are all quite readable with no problem whatsoever.
I submit that rules about how long identifiers ought to be,
and how much the human eye can read, are highly influenced
by the programming language. In C or Java, you wind up with
HardToReadStuDLYCaseWhichIsNotLike words that you normally read.
There's lots of opportunity for subtly making certain miStakes.
But in languages like Lisp (the above examples), you tend to make
your identifiers longer and more spelled out, because they are
not case-sensitive, and they have a nice breaking character.
No problem on the eyes.
The following don't seem hard to read (at least, not
because of mistakes stemming from casification mistakes
nor from getting tired of picking out the words):
uncles-second-cousins-left-handed-brothers-dog
uncles-second-cousins-left-handed-brothers-cat
Chris
Marcus Breiing
> 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
Paul Sinnett
> In C or Java, you wind up with
> HardToReadStuDLYCaseWhichIsNotLike words that you normally
> read.
actually in C it's somewhat of a standard to break words with _
eg:
hard_to_read_studly_case_which_is_not_like
uncles_second_cousins_left_handed_brothers_dog
and in C++ you can use namespaces to keep things short:
eg:
namespace uncles_second_cousin
{
namespace left_handed_brother
{
Type dog;
Type cat;
}
}
now so long as you are using the correct namespace, dog or cat
will refer to:
uncles_second_cousin::left_handed_brother::dog
uncles_second_cousin::left_handed_brother::cat
without having to do all that typing / reading.
Christopher Browne
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
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." -- <mcg...@otter.mbay.net>
Paul F. Dietz
> 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
Roy Smith
> 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.
Phlip
> 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
Michael D. Kersey
> Pascal Costanza <p...@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.
Bradley K. Sherman
>>(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).
>
> 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
Pascal Costanza
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.
adaw...@sbcglobal.net
> In the last exciting episode, <adaw...@sbcglobal.net> wrote:
> > "Christopher Browne" <cbbr...@acm.org> wrote in message
> > news:0vbme.35287$Ot6.1...@news20.bellglobal.com...
> >> Quoth Pascal Costanza <p...@p-cos.net>:
> >>
>
> 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.
> --
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
adaw...@sbcglobal.net
> <adaw...@sbcglobal.net> writes:
>
> > "Christopher C. Stacy" <cst...@news.dtpq.com> wrote in message
> > news:uvf52e...@news.dtpq.com...
> > > <adaw...@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
Roy Smith
> 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.
Edi Weitz
> 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 "spam...@agharta.de" 5) "edi")
Brian Downing
Paul F. Dietz <di...@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
Pascal Costanza
> On Sun, 29 May 2005 13:33:39 -0400, Roy Smith <r...@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... ;)
Roy Smith
wrote:
> On Sun, 29 May 2005 13:33:39 -0400, Roy Smith <r...@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".
Christopher Browne
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@~S" "cbbrowne" "acm.org")
http://linuxfinances.info/info/
"Interfaces keep things tidy, but don't accelerate growth: functions
do." -- Alan Perlis
Christopher Browne
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 <olc...@interaccess.com>, comp.lang.C++
Petr Machata
> On Sun, 29 May 2005 13:33:39 -0400, Roy Smith <r...@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
Leif Roar Moldskred
> 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?
Roy Smith
> 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.
Phlip
> 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
Kenny Tilton
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
Christopher C. Stacy
> 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".
Phlip
> 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
adaw...@sbcglobal.net
>
> 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... :-)
> --
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
adaw...@sbcglobal.net
"Kenny Tilton" <kti...@nyc.rr.com> wrote in message
news:vmwme.14838$IX4....@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).
>
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
Ulrich Hobelmann
> 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
Christopher C. Stacy
> 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?
Ulrich Hobelmann
> 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
adaw...@sbcglobal.net
> <adaw...@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).
>
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
Phlip
> 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
Phlip
> 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
Christopher C. Stacy
> "Christopher C. Stacy" <cst...@news.dtpq.com> wrote in message
> news:uzmudc...@news.dtpq.com...
> > <adaw...@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
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.
Peter Seibel
> "Phlip" <phli...@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 pe...@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Phlip
> 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
Phlip
> 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
Pascal Costanza
> 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.
Phlip
> 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
Christopher C. Stacy
> 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?
Christopher C. Stacy
> 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.
Peter Seibel
> 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.
Phlip
>
> 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
Robert Uhl
>
> 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.
Carl Shapiro
> (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.
Christopher C. Stacy
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".
Kenny Tilton
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.
Kenny Tilton
adaw...@sbcglobal.net wrote:
> "Kenny Tilton" <kti...@nyc.rr.com> wrote in message
> news:vmwme.14838$IX4....@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
Carl Shapiro
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.
Christopher C. Stacy
> cst...@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?