I finally understand why I'm not allowed to use Lisp
Ben
don't use lisp. It took me a long time. It isn't a lack of
libraries, or the number of parentheses. The thing that kills a
language is powerful syntax and abstractions.
I work in C# (worst language EVER!) and I had to write some loops to
accumulate some values in some collections. I spent a good deal of
time looking for some standard accumulate function. Nothing. So I
decided to roll my own using generics and anonymous functions. My
manager looked at the code and asked "Who's going to maintain this?
How will they understand it?"
That's not the first time I've encountered these questions. I heard
it when I used function pointers in C. I heard it when I used
templates in C++. I heard it when I used Lisp for ANYTHING. :)
I can certainly understand concerns about over engineering a
solution. I've been the victim of many over complicated class
structures. I think there's a difference between complicating a
design and using the language syntax. When I simplified the
implementation from six independent functions to one that gets an
anonymous function, I thought I was making it easier. I didn't worry
that future developers would have to know ALL the syntax of the
language instead of just the set that intersects with C++.
I'm finding that regardless of the language used, many
"professional" developers have a serious issue with the more powerful
abstractions available to them. A language like Lisp that supports
the abstractions so naturally (as opposed to the syntactic mutilation
that happens in C#) is doomed.
Sorry about the rant. I am incredibly frustrated. How is C#'s poor
readability my fault? I didn't design or select the doggone language.
I hope our product's translators understand the languages they
translate. Maybe they figure knowing a few major words is enough, and
they can wing the rest! :)
-Ben
Ken Tilton
Ben wrote:
> Sorry about the rant. I am incredibly frustrated. How is C#'s poor
> readability my fault?
Or is it, How is the poor readability of your code C#'s fault? I have
seen impossibly dense COBOL code, code even its authors could not follow.
The big mistake is thinking Lisp is going to grow by first being adopted
in Tall Buildings. They are the drones, the lemmings, the sheep. They
follow where We the Blessed Gurus lead them. But this time it is to the
slaughterhouse, because the world needs only fifty Lisp programmers to
write All the Code.
hth,kt
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
Rainer Joswig
Ben <benb...@gmail.com> wrote:
> Well, I finally reached enlightenment. I understand why people
> don't use lisp. It took me a long time. It isn't a lack of
> libraries, or the number of parentheses. The thing that kills a
> language is powerful syntax and abstractions.
There is a certain amount of truth to it.
There is a huge difference working with a language
where you have to wait a year to get a new loop
statement from the language designer and compiler
implementer - or - where you do it yourself
in twenty minutes.
There is also a huge difference working with a tool
that stands between you and the code - or - working
with a language where you can manipulate the code
easily yourself.
This flexibility comes with costs. A Lisp developer needs
to be trained to use the extension features and not
go over board. There are principles one should follow:
* late binding / late decisions
* reflective code
* modular code
* composable code
* first class objects
* runtime error checking
and so on.
The flexibility can be learned. Working with code from
others that uses these features can also be learned.
A good development environment and understanding
of it is necessary.
The development style is very different from traditional
batch programming. This has to be learned.
So, we need an average or above programmer. Plus you
need people who can teach this. Bad teaching can
create huge damage. Lisp suffered a long time from
being a language for computer science courses.
There Lisp gets taught with all kinds of strange
concepts, but not with the purpose of learning programming
with Lisp (well, sometimes). You'd learn to represent
integer and some arithmetic with functions. Weird. ;-)
I 'real' life, most Lisp developers don't represent
numbers with functions. The 'shock' comes later
when you get in contact with a larger piece of
'research software'. There are at least two different:
one is written by competent research developers and
the other is written over years by students hacking
stuff without understanding it. When I saw
such a system developed by some competent
programmers, I didn't understand a thing. Much too
complicated. A few years later I would be able
to use it.
Working in a team helps. You'll get feedback if others
have to use your code.
Jonathan Allen
Would you care to share this bit of code with us?
Jonathan
Andrew Reilly
> Working in a team helps. You'll get feedback if others
> have to use your code.
Do many lisp users work in teams? I've gained the impression from
discussions here that the lone-coder image is more the rule [and it
certainly seems to be the case that that one can go a lot further in that
mode with lisp than anything else.] From the little scheme coding that
I've done so far, I think that I'd have to put a good deal more effort
into documentation (at least) before I'd be happy to have my current
project hacked-on by other programmers, although ultimately that will be
necessary. Maybe I should make more use of OO and packages/modules, and
lay off the functional abstraction a bit...
Cheers,
--
Andrew
James
and called it a language. Every time I think I'm starting to get the
hang of it, they add another turd to the pile, and it doesn't look
smell or taste like any of the other turds.
There's no rhyme or reason - it's not architecture, it's one turd on
top of another.
Ugly language. <shudder>
Lisp, on the other hand, is very easy to read. The parenthesis have
almost disappeared for me, and it's relatively easy to deduce what a
piece of code is supposed to do. Damn you Paul Graham for turning me
on to it! It's like seeing a pretty girl for the first time - now the
bitch I've been sleeping with is revealed as a hag...
:(
James
James
James
James
Googles groups ... <an error has occured...> sorry for the dupe posts
Ravi Gorrepati
free-form. Control Abstractions are structured by position; The
position in the list determines the kind of structure. This is very
hard to digest for most programmers whose eyes search for keywords.
Tim X
I wish I could say your wrong, but unfortunately, there is a good bit of truth
in what you say - at least from my experience. Only yesterday I was given some
code because it was supposed to do almost exactly what I've been asked to
create. The code consisted of many many lines similar to
if (col[0] != '') {
do-this
} else {
do-that
}
if (col[1] != '') {
do-this
} else {
do-that
}
if (col[2] != '') {
do-this
} else {
do-that
}
if .....
and on over an array of 30 elements. When you see this sort of code, you
understand why so many programmers don't understand the great power of lisp or
macros. I mean, this programmer didn't even understand a bloody loop, so what
chance is there of them understanding things like macros, CLOS or even get past
lisp parens?
The sad thing here is that when I arrived at this company, I was told that the
author of that bit of code was one of their /best/ programmers and I would do
well to use him as a mentor. This confused me until I realised that
1. Most managers wouldn't recognise well written software even if it bit them
in the ass
2. Some programmers are able to establish a higher degree of influence over the
system, not because they are good programmers, but rather because they are good
communicators who understand either the bigger picture or at least the picture
as seen by management.
3. Management, because it doesn't understand the long-term cost benefits of
well written code produced by experienced (and therefore more expensive)
programmers, concentrates on driving down the staff costs by employing recent
graduates and people with little experience to work in an environment where the
tools are dictated more by how easily you can get cheap staff rather than by
what will produce the best product in the long-term.
4. Management assumes that any software will have high maintenance costs. The
incorrect solution adopted is to either do anything to avoid creating your own
systems (i.e. the 'vendor solution') and/or make sure your programmers are as
cheap as possible. There has been no connection made between the high
maintenance costs and inexperienced programmers using poor tools.
All of this is made worse by the short-term management style which seems to be
prevalent these days. As a manager, your objective is to reduce the costs over
the immediate short-term to make you appear successful and able to climb the
greasy pole to the next higher position. Its irrelevant that your cost cutting
measures have resulted in major cost blowouts in 5+ years, when you have moved
on and are no longer accountable (your probably now the person that you
would/should have been accountable to anyway).
The extent to which this happens appears to be linked to the size of the
organisation you are in. I've found working for smaller organisations is often
far more rewarding as the people involved appear to be more aware, will stick
around for longer and therefore have a greater interest in long-term success
and often you are able to more readily exercise your skills and experience to
solve the problem, rather than be constrained by beurocratic ignorance!
Tim
--
tcross (at) rapttech dot com dot au
Alan Manuel K. Gloria
> Ben wrote:
> > Sorry about the rant. I am incredibly frustrated. How is C#'s poor
> > readability my fault?
>
> Or is it, How is the poor readability of your code C#'s fault? I have
> seen impossibly dense COBOL code, code even its authors could not follow.
>
> The big mistake is thinking Lisp is going to grow by first being adopted
> in Tall Buildings. They are the drones, the lemmings, the sheep. They
> follow where We the Blessed Gurus lead them. But this time it is to the
> slaughterhouse, because the world needs only fifty Lisp programmers to
> write All the Code.
of the Chosen Fifty.
Frank Goenninger DG1SBG
> Ben wrote:
>> Sorry about the rant. I am incredibly frustrated. How is C#'s poor
>> readability my fault?
>
> Or is it, How is the poor readability of your code C#'s fault? I have
> seen impossibly dense COBOL code, code even its authors could not
> follow.
>
Happened a few times when I was hacking C. I then put in some comment
like:
/* READ THIS CAREFULLY BEFORE CHANGING THE FOLLOWING CODE!
THIS CODE SEGMENT HAS BEEN OPTIMIZED. IT IS VERY UNLIKELY THAT YOU
WANT TO CHANGE IT. IF SO DO IT AT YOUR OWN RISK. THIS CODE IS
OPTIMIZED BEYOND READABILITY. IT MAY HAPPEN YOU DO NOT FULLY
UNDERSTAND WHAT IT DOES. IF YOU REACH THAT CONCLUSION YOU ARE ADVICED
TO BACK OFF FROM CHANGING THIS CODE SEGEMENT.
RESPECTFULLY
THE AUTHOR OF THIS CODE */
I never saw someone change those code sections... And it made me reach
Guru status actually quite fast.
;-)
Frank
John Thingstad
> The sad thing here is that when I arrived at this company, I was told
> that the
> author of that bit of code was one of their /best/ programmers and I
> would do
> well to use him as a mentor. This confused me until I realised that
>
> 1. Most managers wouldn't recognise well written software even if it bit
> them
> in the ass
> 2. Some programmers are able to establish a higher degree of influence
> over the
> 3. Management, because it doesn't understand the long-term cost benefits
> of
> well written code produced by experienced (and therefore more expensive)
> programmers, concentrates on driving down the staff costs by employing
> recent
> 4. Management assumes that any software will have high maintenance
> costs. The
> incorrect solution adopted is to either do anything to avoid creating
> Tim
Actually I think the manager is probably right and you are wrong.
You seem to suffer from the 'my language has x why doesn't language y have
x' syndrome.
See that a lot in Lisp too. Each language has it's idioms.
To use the language efficiently you have to think in those idioms not
translate from the practice you are used to from Lisp.
What you seem to miss is that Lisp is optimally efficient for a middle
sized program (20 000 - 100 000 lines say) written for a small number
of developers. If you have 20 programmers having all of them implementing
their own custom syntax is a nightmare. So it is not a style I would
recommend for
large programmes with many programmers.
Let's say you have 50 developers. You need to fix a bug in code you didn't
write.
You extract the file from CVS. You track down the offending code.
Now you discover that the problem is in a macro written in another module.
Changing that affects other uses as well.. so you need to write an new one
when you
have figured out what this guy was trying to do in the first place.
This can be more wasteful than helpful.
You could say the more homogeneous the style the easier to maintain
because it is easier
for another person to read and understand. This and not the amount of code
is more
important for maintaining the program.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Christopher Koppler
> Let's say you have 50 developers. You need to fix a bug in code you didn't
> write.
> You extract the file from CVS. You track down the offending code.
> Now you discover that the problem is in a macro written in another module.
> Changing that affects other uses as well.. so you need to write an new one
> when you
> have figured out what this guy was trying to do in the first place.
> This can be more wasteful than helpful.
Judging from experience, that paragraph applies to at least C and C++
as well.
> You could say the more homogeneous the style the easier to maintain
> because it is easier
> for another person to read and understand. This and not the amount of code
> is more
> important for maintaining the program.
Homogenous style? In a C project involving more than 20 programmers?
Good one :)
Each developer doing his own syntax will conceivably lead to problems
- I couldn't say, I've yet to find the opportunity to use Lisp in a
team.
But the better teams I've worked in were organized so as let the
better/older/lead developers do the design and the others do the brunt
of the coding. Shouldn't that work in Lisp teams as well? Letting them
who know what they're doing create the application-necessary
abstractions and design guidelines, and then letting the junior coders
use those abstractions and adhere to those guidelines?
John Thingstad
<klap...@chello.at> wrote:
>
> Each developer doing his own syntax will conceivably lead to problems
> - I couldn't say, I've yet to find the opportunity to use Lisp in a
> team.
> But the better teams I've worked in were organized so as let the
> better/older/lead developers do the design and the others do the brunt
> of the coding. Shouldn't that work in Lisp teams as well? Letting them
> who know what they're doing create the application-necessary
> abstractions and design guidelines, and then letting the junior coders
> use those abstractions and adhere to those guidelines?
>
Yes. But if you look at the post it is written by one of the rookie
programmers
who wanted to introduce new syntax for his code and the experienced
programmer
that refused him.
What I disagree is that this is C#'s fault.
I have experience with developing large systems in C++ but not in Lisp
yet so it is hard to tell. I do know that this is why designers like design
patterns. (Most programmers like me hate them I guess..)
Rainer Joswig
"John Thingstad" <john.th...@chello.no> wrote:
'small team' is fine. Smaller teams are better and more productive.
Lisp gives them lots of power. But 20 - 100k lines?
I think Lisp scales more. If you need that many lines of code.
>If you have 20 programmers having all of them implementing
> their own custom syntax is a nightmare.
But this is not how teams of programmers work. I had the 'pleasure'
to be the project leader of upto 20+ Java programmers (no joke).
Teams get organized by module, by architects, domain experts,
and so on. Not everyone introduces new architectures, even
if they want they have to discuss it with architects
or lead programmers.
> So it is not a style I would
> recommend for
> large programmes with many programmers.
> Let's say you have 50 developers. You need to fix a bug in code you didn't
> write.
> You extract the file from CVS. You track down the offending code.
Again this is not how larger groups work. Bugs tend to be
described in a bug-tracking tool and some programmer
has/gets/takes the task to fix that bug. There will be
tests and reviews. If it is a core module where changes
affect architecture and apis, you consult the architect
(if he/she isn't doing the job him/herself).
> Now you discover that the problem is in a macro written in another module.
> Changing that affects other uses as well.. so you need to write an new one
> when you
> have figured out what this guy was trying to do in the first place.
> This can be more wasteful than helpful.
> You could say the more homogeneous the style the easier to maintain
> because it is easier
> for another person to read and understand. This and not the amount of code
> is more
> important for maintaining the program.
I don't think scaling the one-programmer organisation
to a team of 20 or even fifty is that simple.
Larger teams tend to have some internal structure.
Rainer Joswig
Andrew Reilly <andrew-...@areilly.bpc-users.org> wrote:
> On Tue, 22 May 2007 19:32:36 +0200, Rainer Joswig wrote:
>
> > Working in a team helps. You'll get feedback if others
> > have to use your code.
>
> Do many lisp users work in teams?
If 'team' don't have to be not physically located in the
same room, then team work is dominant.
Just check out the open source Lisp projects that are popular,
most have more than one person submitting code. There are
lively discussions about fixes and changes on mailing
list and by other means.
In companies working on a project or product I guess two to ten people
is normal. I wouldn't really have a project where just one
person knows the code - that's a risk.
Also note that Lisp often creates a style of software
where the line between developers and users get blurry.
Users start hacking on the code and contribute.
Actually that is the secret weapon how to create
successful software communities. Open up the code
and let users contribute. It does not necessarily
mean to 'open source' it. Many 'users' of Lisp
code get some good hacking skills over time.
In Common Lisp there is often not the difference
between implementation and extension language.
> I've gained the impression from
> discussions here that the lone-coder image is more the rule [and it
> certainly seems to be the case that that one can go a lot further in that
> mode with lisp than anything else.] From the little scheme coding that
> I've done so far, I think that I'd have to put a good deal more effort
> into documentation (at least) before I'd be happy to have my current
> project hacked-on by other programmers, although ultimately that will be
> necessary. Maybe I should make more use of OO and packages/modules, and
> lay off the functional abstraction a bit...
>
> Cheers,
Jeff Rollin
Once again, apologies for my noobishness, but surely the way a team works is
for a senior developer(s) to do the top-level design of the whole shebang,
but leave the implementation details of each programmer's assigned work to
the programmer? Otherwise, wouldn't you effectively be using the junior
programmers as mere typists?
Jeff
Chris Russell
> Now you discover that the problem is in a macro written in another module.
> Changing that affects other uses as well.. so you need to write an new one
> when you
> have figured out what this guy was trying to do in the first place.
Or for a one off problem, you could macroexpand-1 the statement and
then patch it, leave the original in place as a comment, and, if it
wasn't simple misuse of the macro, put a note next to the macro
definition pointing to this fix.
Your solution is the same as rewriting a major library the first time
you have problems calling it.
fireblade
Kaizen :)
Most managers think that all languages are roughly the same, if only
thing you ever get exposed is c/c++/C#/java and some sql that's
roughly true but cross at the dark side :lisp ,prolog, forth,
erlang ... and things gets tricky. The main complaint against lisp
(beside that java has more outsourcing contracts) is that you need a
guru to code in lisp while anybody could code in java/c#/delphi which
is complete rubbish. If some programmer is unable to learn lisp and
only thing he could do is making fancy guis using the visual studio/
eclipse/delhi designer get rid of him :)
http://wiki.alu.org/Slobodan
>
> The extent to which this happens appears to be linked to the size of the
> organisation you are in. I've found working for smaller organisations is often
> far more rewarding as the people involved appear to be more aware, will stick
> around for longer and therefore have a greater interest in long-term success
> and often you are able to more readily exercise your skills and experience to
> solve the problem, rather than be constrained by beurocratic ignorance!
>
> Tim
> --
> tcross (at) rapttech dot com dot au
It depends on the atmosphere of the firm, I've been lucky to work only
for firms where coworkers share their knowledge and help each other.
Compared with horror stories I've heard from my friends like lay offs
of the 10% of worst performers EVERY YEAR I doubt that anybody will
tell anybody else something useful. Some smaller firms even allow you
to realise some of your ideas if they have a potential to be
profitable.
Larry Clapp
> On Wed, 23 May 2007 05:25:11 +0200, Tim X <ti...@nospam.dev.null> wrote:
>
>> The sad thing here is that when I arrived at this company, I was
>> told that the author of that bit of code was one of their /best/
>> programmers and I would do well to use him as a mentor. This
>> confused me until I realised that
>>
>> 1. Most managers wouldn't recognise well written software even if
>> it bit them in the ass
>> 2. Some programmers are able to establish a higher degree of
>> influence over the
>> 3. Management, because it doesn't understand the long-term cost
>> benefits of well written code produced by experienced (and
>> therefore more expensive) programmers, concentrates on driving down
>> the staff costs by employing recent
>> 4. Management assumes that any software will have high maintenance
>> costs. The incorrect solution adopted is to either do anything to
>> avoid creating
>> Tim
>
> Actually I think the manager is probably right and you are wrong.
> You seem to suffer from the 'my language has x why doesn't language
> y have x' syndrome.
No he's not. He's suffering from the "this language has X why didn't
programmer Y use it?" syndrome.
When X is C's "for" loop, you really have to question the competency
of programmer Y, and of the manager (Z) that says "Y is our best
programmer".
In Z's defense, if he never looks at the code, Y's code consistently
has the fewest bugs, then he could easily justify his statement. Y's
code exhibits bad design, in that it's rigid, fragile, and immobile,
but hey, it *works* (... in the hypothetical world of "few bugs").
-- L
Dan Bensen
> surely the way a team works is for a senior developer(s)
> to do the top-level design of the whole shebang,
Both top and bottom. Regarding the twenty-different-styles
issue, someone should be in charge of compiling one or more
libraries, both application-specific and [company|department]-wide.
Junior staff should be working in the middle, everyone using
the same conventions. That can be done in any language.
--
Dan
www.prairienet.org/~dsb/
fireblade
> Ben wrote:
> > Sorry about the rant. I am incredibly frustrated. How is C#'s poor
> > readability my fault?
>
> Or is it, How is the poor readability of your code C#'s fault? I have
> seen impossibly dense COBOL code, code even its authors could not follow.
>
Reminds of the old story before the computer era :
(foo) What mark you got on the literature test?
(bar) I failed.
(foo) Why?
(bar) Teach' couldn't understood my handwriting.
(foo) Why didn't you read it yourself for her.
(bar) I couldn't understand it too.
> The big mistake is thinking Lisp is going to grow by first being adopted
> in Tall Buildings. They are the drones, the lemmings, the sheep. They
> follow where We the Blessed Gurus lead them. But this time it is to the
> slaughterhouse, because the world needs only fifty Lisp programmers to
> write All the Code.
Thank you Java/C#/VB...
Wade Humeniuk
> Well, I finally reached enlightenment. I understand why people
> don't use lisp. It took me a long time. It isn't a lack of
> libraries, or the number of parentheses. The thing that kills a
> language is powerful syntax and abstractions.
>
Are you thinking Lisp has been killed? If you are, you are definitely
wrong. I have used C# and you can see the Lisp influences all over
it. Its there, you just have to see it.
There are lots of silly seemingly petty Laws made by the government.
There are not there to control the ones who obey the spirit and
intention of the bigger "law". The letter of the law is there to
control the ones who have no self control. Rules and laws are NOT
made for everybody.
I am sure you are good and decent, you strive to do a good job, apply
yourself, have an open mind. But you have to remember the Manager's
"laws" are not there to control you, but those who do not control
themselves like you. What is causing you grief is you think the
Manager is asking you to stop thinking and being creative. Its not
that at all.
Wade
Daniel Barlow
> 4. Management assumes that any software will have high maintenance costs. The
> incorrect solution adopted is to either do anything to avoid creating your own
> systems (i.e. the 'vendor solution') and/or make sure your programmers are as
> cheap as possible. There has been no connection made between the high
> maintenance costs and inexperienced programmers using poor tools.
You know, I'd be surprised to find that the effect of inexperienced
programmers on maintenance costs was particularly significant compared
with the effect of changing business needs.
Yes, there's _some_ effect, but from the corporate perspective the true
extent of the problem is hidden by making them work longer hours anyway
(yeah, eventually they'll burn out but luckily that's not management's
problem). Our culture rewards the heroes, not the people who manage
their work not to need heroics in the first place.
-dan
Tim X
> On Wed, 23 May 2007 05:25:11 +0200, Tim X <ti...@nospam.dev.null> wrote:
>
>> The sad thing here is that when I arrived at this company, I was told that
>> the
>> author of that bit of code was one of their /best/ programmers and I would
>> do
>> well to use him as a mentor. This confused me until I realised that
>>
>> 1. Most managers wouldn't recognise well written software even if it bit
>> them
>> in the ass
>> 2. Some programmers are able to establish a higher degree of influence over
>> the
>> 3. Management, because it doesn't understand the long-term cost benefits of
>> well written code produced by experienced (and therefore more expensive)
>> programmers, concentrates on driving down the staff costs by employing
>> recent
>> 4. Management assumes that any software will have high maintenance costs.
>> The
>> incorrect solution adopted is to either do anything to avoid creating Tim
>
> Actually I think the manager is probably right and you are wrong.
> You seem to suffer from the 'my language has x why doesn't language y have x'
> syndrome.
and how the hell can you interpret that from what I wrote. Where did I make any
refernce to lisp having features that made it better than some other language.
All I said was that anybody who couldn't appreciate/use a basic construct like
a loop is unlikely to appreciate/use even more abstract constructs like macros,
clos etc. I made no claims about the weaknesses of other languages or
speculation about the merits of different languages or their features.
> See that a lot in Lisp too. Each language has it's idioms.
> To use the language efficiently you have to think in those idioms not
> translate from the practice you are used to from Lisp.
>
My points were not language specific - the point was that good craftsmen can still produce good
work with bad tools, bad craftsmen will still produce bad with good tools. The
issues of working in a language your not familiar with are obvious and
uninteresting and nothing to do with what I wrote. At a stretch, I could try
and tie it in by arguing that the greater skill the programmer has the faster
they will adjust/learn the specifics of the language and adapt their use of it
accordingly.
> What you seem to miss is that Lisp is optimally efficient for a middle
> sized program (20 000 - 100 000 lines say) written for a small number
> of developers. If you have 20 programmers having all of them implementing
> their own custom syntax is a nightmare. So it is not a style I would recommend
> for
> large programmes with many programmers.
Again, totally unrelated and obvious. This same argument has been applied to most
languages in one form or another and is why larger development projects tend to
have more rigid style guides. Its not a pro or a con for CL any more than any
other language.
> Let's say you have 50 developers. You need to fix a bug in code you didn't
> write.
> You extract the file from CVS. You track down the offending code.
> Now you discover that the problem is in a macro written in another module.
> Changing that affects other uses as well.. so you need to write an new one
> when you
> have figured out what this guy was trying to do in the first place.
> This can be more wasteful than helpful.
and its no different to working on a C++ project with really badly designed
objects incorporating a twisted network of multiple inheritance lines or a perl
program with heaps of modules written by different people using different perl
styles or a badly written .NET application with weird DLL dependencies or
twisted project builds etc. Large projects are complex and difficult to manage
regardless of the language. Some languages may make some aspect easier, but
I've never yet found one that was perfect. However, I have found that the
greater the base skill level of those working ont he project, the easier things were.
> You could say the more homogeneous the style the easier to maintain because it
> is easier
> for another person to read and understand. This and not the amount of code is
> more
> important for maintaining the program.
>
This is just the "Programs should be written for people to understand not
machines" point of view. I don't disagree - its pretty self evident as long as
you understand it as a heuristic rather than a rule written in stone. Again,
not directly relevant to my point, though I would consider this to be an aspect
of a skilled and experienced programmer. This also has to be mediated by the
recognition that the more lines of code, the higher the probablility of a bug.
The aim is for clear and concise code. The original example I posted highlights
this. A long sequence of if/else statements that contributes 90 lines of code
is quite straight forward and easy to read. However, a 7 line loop that does
the same thing is just as easy to read for a skilled programmer and now you
only have 7 lines that may contain a bug.
I agree with most of what you wrote, but it is obvious and totally unrelated to
what I was arguing. Where the hell did I make any reference to style. You have
totally missed the point in your eagerness to push your own barrow. and have
misrepresented what I argued.
What I was saying concerned the ability of the programmer and managements
assessment of that ability and its worth. My only reference to lisp was in
reference to programmers being unlikely to apreciate its power when they didn't even
appreciate 'loops' in the abstract sense or at a practical level in the
language they do use. Essentially, if you haven't mastered the basics of
programming, such as the loop, you are unlikely to appreciate any language
which offers either greater power/flexibility or a different paradigm. This
isn't about lisp or any specific language. Its about the quality of the programmer
and managements ability to recognise and sponsor the development of skilled
programmers.
I mentioned the management aspect because I believe that a prerequisite for
developing a higher skill level amongst programmers is for those who employ
them to foster such development. Unfortunately, modern short term management
styles combined with a generally poor appreciation of programming and building
quality software tends to result in the opposite effect.
I actually have no particular interest in pushing any specific language. To
some extent, language is a bit like religion in that I think its really a private
choice. Unlike religion, I'm also likely to switch languages, depending on the
problem, the customer base, the money involved and my mood.
I also suspect that if we had a higher base skill level, we would find more
appreciation for the strengths and weaknesses of various languages and wold be
more likely to select the right tool at the right time. If we are lucky, this
would result in a positive feedback loop in which improve results gives
increased respect for our skills, which in turn would give us greater freedom
to use the tools and techniques we believe are best. Maybe then we wouldn't be
part of an industry which has a reputation of a project failure rate that most
quote at being between 60-70%.
Rainer Joswig
Daniel Barlow <d...@coruskate.net> wrote:
> Tim X wrote:
> > 4. Management assumes that any software will have high maintenance costs. The
> > incorrect solution adopted is to either do anything to avoid creating your own
> > systems (i.e. the 'vendor solution') and/or make sure your programmers are as
> > cheap as possible. There has been no connection made between the high
> > maintenance costs and inexperienced programmers using poor tools.
>
> You know, I'd be surprised to find that the effect of inexperienced
> programmers on maintenance costs was particularly significant compared
> with the effect of changing business needs.
>
> Yes, there's _some_ effect, but from the corporate perspective the true
> extent of the problem is hidden by making them work longer hours anyway
> (yeah, eventually they'll burn out but luckily that's not management's
> problem).
Letting inexperienced people work longer makes the problem worse.
From a corporate perspective this is visible, since
it costs real money and targets will be failed.
> Our culture rewards the heroes, not the people who manage
> their work not to need heroics in the first place.
I'm not so pessimistic. Lot's of project managers are not totally
stupid and there is lots of literature and seminars about these
topics. Example: Many have heard about 'Extreme Programming'
(http://www.extremeprogramming.org/)
and the concept of 'sustainable pace'
(http://www.extremeprogramming.org/rules/overtime.html ,
http://www.xprogramming.com/xpmag/whatisxp.htm#sustainable).
-> Agile Software Development
http://agilemanifesto.org/principles.html
>
>
> -dan
Tim X
I totally agree with both your point about changing business needs being the
higher cost and the fact we reward the heros rather than those who manage the
situation so as not to need a hero in the first place.
Daniel Barlow
> Letting inexperienced people work longer makes the problem worse.
> From a corporate perspective this is visible, since
> it costs real money and targets will be failed.
Only if you pay them overtime. Maybe this is normal (or required) in
your part of the world, but I think in much of the US and UK salary paid
to programmers is not related to hours worked. Maybe your (hypothetical
"your", not you personally) boss knows you're last out of the building
each night, but his boss probably doesn't, and it's not showing on the
balance sheet
> I'm not so pessimistic. Lot's of project managers are not totally
> stupid and there is lots of literature and seminars about these
> topics. Example: Many have heard about 'Extreme Programming'
Yes, I think it's getting better, and the XP school did very good work
popularising what "everyone already knew". But if we're talking about
the kind of place where production code can be written by people who
don't know how to use a loop, I think it'll take a while yet before
agile practices (or even just *good* practices) filter their way down
that far.
And when they do, their biggest wins will be in tracking and coping with
externally-imposed requirements change, not whether their programmers
are experienced.
-dan
Rainer Joswig
Daniel Barlow <d...@coruskate.net> wrote:
> Rainer Joswig wrote:
> > Letting inexperienced people work longer makes the problem worse.
> > From a corporate perspective this is visible, since
> > it costs real money and targets will be failed.
>
> Only if you pay them overtime. Maybe this is normal (or required) in
> your part of the world, but I think in much of the US and UK salary paid
> to programmers is not related to hours worked. Maybe your (hypothetical
> "your", not you personally) boss knows you're last out of the building
> each night, but his boss probably doesn't, and it's not showing on the
> balance sheet
In larger corporations it is typical that lots
of external consultants work for them. They will happily
send the bills, if their work is time&material.
Plus here in Germany the 'Betriebsrat'
will make sure that internal people don't work over time. If they
do this will be an argument to hire new people. If people
work over time they get compensations (money or extra
free days). It is typical the each employee has to
track the time with a central system. Sometimes even
externals have to track the time with the client's
system.
>
> > I'm not so pessimistic. Lot's of project managers are not totally
> > stupid and there is lots of literature and seminars about these
> > topics. Example: Many have heard about 'Extreme Programming'
>
> Yes, I think it's getting better, and the XP school did very good work
> popularising what "everyone already knew". But if we're talking about
> the kind of place where production code can be written by people who
> don't know how to use a loop, I think it'll take a while yet before
> agile practices (or even just *good* practices) filter their way down
> that far.
>
> And when they do, their biggest wins will be in tracking and coping with
> externally-imposed requirements change, not whether their programmers
> are experienced.
>
>
> -dan
Charlton Wilbur
DB> Yes, I think it's getting better, and the XP school did very
DB> good work popularising what "everyone already knew". But if
DB> we're talking about the kind of place where production code
DB> can be written by people who don't know how to use a loop, I
DB> think it'll take a while yet before agile practices (or even
DB> just *good* practices) filter their way down that far.
The core of the core of the problem is that management wants to
believe in the waterfall model of software development despite any
amount of evidence to the contrary, and that management believes in
the command-and-conquer model used by the American army in WWII: take
a lot of relatively unskilled people and solve the problem through
hierarchy.
The waterfall model doesn't work because nobody knows what the
requirements really are; some of this is an inability to think
abstractly, and some of it is that all the ramifications of the
requirements won't be discovered until the programmers are building
the system. And even if the requirements are known at first, they are
likely to change along the way.
The command-and-conquer model has as its fundamental assumption that
the workers at the bottom of the org chart are interchangeable and
best suited to relatively unthinking work, and that the higher you go
in the org chart the more decisionmaking authority you have. This
makes perfect sense in manufacturing, but not in information work: the
workers are usually the ones with the most knowledge and experience of
technical matters, and experience matters.
Agile development runs counter to these two management fantasies,
unfortunately. Progress is being made one retirement at a time.
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
Alan Crowe
> Do many lisp users work in teams? I've gained the impression from
> discussions here that the lone-coder image is more the rule [and it
> certainly seems to be the case that that one can go a lot further in that
> mode with lisp than anything else.]
You might be right but it is quite strange. Common Lisp has
some nice features for big teams including
1)The package system lets you parcel out the name space in
sophisticated ways
2)Built-in documentation strings
3)Elaborate type system together with implementations that
can do precise checking if compiler policy is set to
require it.
So you can document your code with elaborate type
declarations, thus telling others in the big team what is
going on, and generating test-time errors just because the
"documentation" wasn't being kept up to date if programmers
start stepping on each others toes.
4)Macros let the team guru help junior members by writing
macros for the team, not just themselves. It is natural to
think of macros helping experts be more productive. It is
tempting to think that tools for experts don't help with
big projects because you need to recruit lots of ordinary
programmers. I see a well designed macro encapsulating
cleverness, so that other programmers can use it. I expect
them to boost programmer productivity across the whole
team.
5)The tradition of writing names out in full, such as
update-instance-for-different-class, instead of using
cryptic abbreviations, (uifdc?) is a "big team" way of
working. I would expect it to be rather off putting to
lone wolves.
6)Reading Kent Pitman's Chapter in CLtL2 in becomes clear
(see 29.3.4 and 29.3.5) that the complications are there
to fix problems that had already been causing difficulties
on big projects with simpler error systems. One really
sees the "big team" lettering going all the way through
the rock.
Alan Crowe
Edinburgh
Scotland
Dan Bensen
>> 4. Management assumes that any software will have high maintenance
>> costs. The incorrect solution adopted is to either do anything
>> to avoid creating your own systems (i.e. the 'vendor solution')
>> and/or make sure your programmers are as cheap as possible.
>> There has been no connection made between the high
>> maintenance costs and inexperienced programmers using poor tools.
Daniel Barlow wrote:
> You know, I'd be surprised to find that the effect of inexperienced
> programmers on maintenance costs was particularly significant compared
> with the effect of changing business needs.
These are orthogonal issues. The total cost of maintenance is roughly
equal to total-amount-of-change * cost-per-unit-change. The second term
is much higher for bad programmers, especially when you take a long-term
total that includes the cumulative effects of the code turning into a
ball of mud. I don't think mediocre programmers are as cost-effective
as good hackers for moderately complex applications. Productivity can
differ by a factor of ten or more, but pay only differs by a factor of
maybe two or three.
--
Dan
www.prairienet.org/~dsb/
tth...@googlemail.com
> if (col[0] != '') {
> do-this} else {
> do-that
> }
>
> if (col[1] != '') {
> do-this} else {
> do-that
> }
>
This is common practice, e.g.
John Connors
> Well, I finally reached enlightenment. I understand why people
> don't use lisp. It took me a long time. It isn't a lack of
> libraries, or the number of parentheses. The thing that kills a
> language is powerful syntax and abstractions.
>
> accumulate some values in some collections. I spent a good deal of
> time looking for some standard accumulate function. Nothing. So I
> decided to roll my own using generics and anonymous functions. My
> manager looked at the code and asked "Who's going to maintain this?
> How will they understand it?"
> That's not the first time I've encountered these questions. I heard
> it when I used function pointers in C. I heard it when I used
> templates in C++. I heard it when I used Lisp for ANYTHING. :)
>
manager was actually right. C++ syntax just falls apart when used
this way. When things were rewritten the C/C++ way, things were much
cleaner.
On the other hand, I've seen "readability" used as an excuse by
lazy programmers against their more experienced colleages in the
sense "You have used a construct or technique I can't be bothered to
learn - please take it out and conform to the prevailing level of
ignorance."
It's partly a social/technical tradeoff, partly learning to work
"with the grain" of your language..
> I can certainly understand concerns about over engineering a
> solution. I've been the victim of many over complicated class
> structures. I think there's a difference between complicating a
> design and using the language syntax. When I simplified the
> implementation from six independent functions to one that gets an
> anonymous function, I thought I was making it easier. I didn't worry
> that future developers would have to know ALL the syntax of the
> language instead of just the set that intersects with C++.
>
> I'm finding that regardless of the language used, many
> "professional" developers have a serious issue with the more powerful
> abstractions available to them. A language like Lisp that supports
> the abstractions so naturally (as opposed to the syntactic mutilation
> that happens in C#) is doomed.
>
> Sorry about the rant. I am incredibly frustrated. How is C#'s poor
> readability my fault? I didn't design or select the doggone language.
>
> I hope our product's translators understand the languages they
> translate. Maybe they figure knowing a few major words is enough, and
> they can wing the rest! :)
>
> -Ben
>
--
+--------------------------------------------------------+
|Cyborg Animation Programmer | jo...@yagc.ndo.co.uk|
|http://badbyteblues.blogspot.com -----------------------|
+--------------------------------------------------------+
Ben
> Actually I think the manager is probably right and you are wrong.
He thought the same thing, dangit. :)
I was asked for the code, so here is the offending bit (names
changed to protect the innocent):
------
private bool AccumResults(Arg1 arg1, Arg2 arg2, Arg3 arg3)
{
return this.Accumulate(delegate(SomeObject so, bool result)
{ return result | so.SomeOperation(arg1,
arg2, arg3); });
}
// Function header. Must have function headers . . .
private bool AccumResults(Arg2 arg2, Arg4 arg4)
{
return this.Accumulate(delegate(SomeObject so, bool result)
{ return result | so.SomeOperation(arg2,
arg4); });
}
------
Actually, the C# isn't all that unreadable if you can get past the
multiple uses for the keyword delegate. I guess that's kind of lisp-
y. Use it here, it means one thing. Use it there, it means
another. :) But I still don't like C#!
I won't give my resume, but I've been programming for a while.
Mostly C++ (I'm JUST getting confident in lisp and I am far from
good) Clear concise code is important to me, and I'm pretty
disciplined about it. I'll grant that the actual implementation of
Accumulate is gnarly for someone not used to generics. That wasn't the
code that was objectionable (whoever was interested in that - email
me. I'd love to discuss it and get your input!)
Homogeneous style isn't that big a deal if other good practices are
followed, but I'm happy to obey whatever style guidelines are in place
for whatever project I'm on. My current team doesn't have one. They
mention creating one now and then in meetings. I always say the
guideline should prohibit classes that are 4000 lines long with a
dozen boolean flags before we start worrying about how we indent our
braces. Usually the discussion dies there.
You've probably noted I used two different brace matching styles in
the above code. I find the result more readable, but I wouldn't
object to changing it. But I won't go back to having a separate loop
for each of a bunch of similar functions with slightly different
signatures!
I don't think what I've done falls outside the bounds of standard
practice in any language, and is far from bizarre. It just makes use
of anonymous functions and generics. Just to bother you a little more
- I'm using a variation of the Composite pattern. :P
My code gets to stay in though, so I'm happier today! :)
-Ben
Ben
> Are you thinking Lisp has been killed? If you are, you are definitely
> wrong. I have used C# and you can see the Lisp influences all over
> it. Its there, you just have to see it.
>
Of course, you're right. I keep telling my coworkers that every
time they add a feature to C++ or C#, new keywords get created. We
need a language that lets you develop the syntax toward the problem
domain rather than a language with a hundred keywords. I'm honestly
running into trouble naming my variables, because C# has so many
keywords now.
And you're right about the laws too. I'm not being asked to conform
to a silly programming style. I was being asked to make sure I
thought about how it would be maintained, which is fair, if
condescending. :) I am just tired of being asked that every time a
new syntax style appears. That would not have been said about a dozen
duplicate loops, or a dozen nested conditionals. Something far more
likely to produce bugs.
It all worked out though.
-Ben
Ben
> wrong. I have used C# and you can see the Lisp influences all over
> it. Its there, you just have to see it.
>
Of course, you're right. I keep telling my coworkers that every
Ben
> wrong. I have used C# and you can see the Lisp influences all over
> it. Its there, you just have to see it.
>
Of course, you're right. I keep telling my coworkers that every
Ben
> wrong. I have used C# and you can see the Lisp influences all over
> it. Its there, you just have to see it.
>
Of course, you're right. I keep telling my coworkers that every
Ben
> wrong. I have used C# and you can see the Lisp influences all over
> it. Its there, you just have to see it.
>
Of course, you're right. I keep telling my coworkers that every
time they add a feature to C++ or C#, new keywords get created. We
need a language that lets you develop the syntax toward the problem
domain rather than a language with a hundred keywords. I'm honestly
running into trouble naming my variables, because C# has so many
keywords now.
And you're right about the laws too. I'm not being asked to conform
to a silly programming style. I was being asked to make sure I
thought about how it would be maintained, which is fair, if
condescending. I am just tired of being asked that every time a new
syntax style appears. That would not have been said about a dozen
duplicate loops, or a dozen nested conditionals - things far more
Glenn Willen
My suspicion is that this is slightly different -- that code appears to have
been automatically-generated by lex, not written by a human being. In that
case, it's quite reasonable to write things out in order to boost efficiency.
Plus, nothing in that example looks directly analogous to what was being
complained about before; there's nowhere that could be _trivially_ converted
into a loop (i.e. same condition being checked and only the index differs.)
-- Glenn Willen
DanM
> On the other hand, I've seen "readability" used as an excuse by
> lazy programmers against their more experienced colleages in the
> sense "You have used a construct or technique I can't be bothered to
> learn - please take it out and conform to the prevailing level of
> ignorance."
I think most experienced programmers have suffered such complaints:
http://c2.com/cgi/wiki?AllFeaturesShouldBeSimple
Larry Clapp
And some not so experienced. Circa 15 years ago, two years out of
college, I wrote a nice C program for GTE that used function pointers.
I found out later that somebody rewrote it to remove the function
pointers, remove the lookup table that contained them, and rewrote the
whole thing as a switch statement. (Or something like that. It's
been a while.) It made me sad.
It's never to early to be smarter than your co-workers. :-(
Charlton Wilbur
LC> And some not so experienced. Circa 15 years ago, two years
LC> out of college, I wrote a nice C program for GTE that used
LC> function pointers. I found out later that somebody rewrote it [...]
At one point, at a prior place of employment, I wrote a program that
did a depth-first search of a filesystem tree. I put in a comment "we
do a depth-first search here," figuring that at least a quarter of my
current and potential coworkers would have been likely to have
encountered that concept, and that the rest would have been savvy
enough to look it up or ask.
Some time later, after the program had been put into production and
was being used for something important, it started failing
intermittently. It turns out that the programmer who changed it
didn't understand what a depth-first search was, and hadn't bothered
to try to understand the code before he modified it to make it "more
efficient." (Wrong answers, twice as fast as right ones!)
Of course, it all wound up being my fault for using an advanced
computer science concept. (Given some of the code I saw there, from
that programmer, subroutines would have been an advanced computer
science concept. Function pointers or functions as first-class
objects would have melted his brain.)
Damien Kick
>>>>>> "DB" == Daniel Barlow <d...@coruskate.net> writes:
>
> DB> Yes, I think it's getting better, and the XP school did very
> DB> good work popularising what "everyone already knew". But if
> DB> we're talking about the kind of place where production code
> DB> can be written by people who don't know how to use a loop, I
> DB> think it'll take a while yet before agile practices (or even
> DB> just *good* practices) filter their way down that far.
>
> The core of the core of the problem is that management wants to
> believe in the waterfall model of software development despite any
> amount of evidence to the contrary, and that management believes in
> the command-and-conquer model used by the American army in WWII: take
> a lot of relatively unskilled people and solve the problem through
> hierarchy.
>
>
> The command-and-conquer model has as its fundamental assumption that
>
> Agile development runs counter to these two management fantasies,
> unfortunately. Progress is being made one retirement at a time.
The XP school did a very good job of popularizing the /buzzwords/ used
to explain that which "everyone already knew". At least in my part of
the world. We use an iterative, agile methodology in which we have to
produce estimates of the amount of work required to deliver the feature
in staff months <gesture of="Mythical Man Month"> before we even have
the formal requirements from the system engineering team. Then we plan
out all of the iterations from start to finish of the project. Yes, and
we're using an agile methodology. When the initial estimate is
inevitably wrong, this is "corrected" towards the end of the schedule by
throwing more bodies on the pile. Everybody knows that more men applied
to staff months of effort results in finishing sooner and with higher
quality, especially when those men being added were not involved from
the beginning of the project. And then at the end of the cycle, there
is the inevitable call to come up with better estimates so that we can
plan better.
I've tried complaining about the futility of this perpetual motion
machine ("Young lady, in this house we obey the laws of thermodynamics!"
- Homer Simpson). But I always get back the same story from management,
"How else are we supposed to tell our customers when we can deliver the
next release so that they know how to plan their marketing campaigns?"
Etc. But the thing that I don't understand is why The Customer even
bothers to believe any estimates from a software development company if
they are estimates of when the next big release will be ready, releases
taking something along the lines of a few months short of a year. I
would think that they would've caught on to the fact that this seems to
be about as accurate as a horoscope or palm reading. <sigh> I'm
exaggerating, of course, horoscopes are rarely that bad because they're
intentionally vague but releases typically are delivered late and over
budget. Of course <cough> they are *never* delivered with <cough>
substandard quality <cough> <cough>.
I'm envious of the situation at Google; or at least what I've read about
software development at Google <http://tinyurl.com/s3jbz> from Steve
Yegge's blog:
<blockquote>
Most people take it for granted that you want to pick a date. Even my
favorite book on software project management, "The Mythical Man-Month",
assumes that you need schedule estimates.
If you're in the habit of pre-announcing your software, then the general
public usually wants a timeframe, which implies a date. This is, I
think, one of the reasons Google tends not to pre-announce. They really
do understand that you can't rush good cooking, you can't rush babies
out, and you can't rush software development.
</blockquote>
I realize that the Google business model will not work in all cases. I
am not a business man nor do I play one on TV. I am not one to whom
anyone should go to construct a good business model. But from the geek
point of view (or perhaps just to this geek's point of view?) this game
of picking dates our of the air
<blockquote>
Everyone picks dates out of the air. "This feels like it should take
about 3 weeks." "It sure would be nice to have this available for
customers by beginning of Q4." "Let's try to have that done by tomorrow."
</blockquote>
can not possibly lead to good software. Well, I'm pretty sure that
Steve Yegge agrees with me, anyway. Are Google and grad school really
the only places which agree with us?
(ignore-errors
(let ((lisp-topic nil))
(obligatory-lisp lisp-topic)))
=> implementation-dependent
Charlton Wilbur
DK> But the thing that I don't understand is why The Customer even
DK> bothers to believe any estimates from a software development
DK> company if they are estimates of when the next big release
DK> will be ready, releases taking something along the lines of a
DK> few months short of a year. I would think that they would've
DK> caught on to the fact that this seems to be about as accurate
DK> as a horoscope or palm reading.
The Customer knows the estimates are unreliable and inaccurate, but
wants to believe, and so deludes himself so that he can maintain the
illusion of control.
Just as the manager knows the waterfall method doesn't work, but wants
to believe, and so deludes himself so that he can maintain the
illusion of control.
The programmers know that the waterfall method doesn't work, but
aren't so deluded as to think they have any control, and so nod and
smile at the manager and pretend everything is just peachy.
Slava Akhmechet
> Well, I finally reached enlightenment. I understand why people
> don't use lisp. It took me a long time. It isn't a lack of
> libraries, or the number of parentheses. The thing that kills a
> language is powerful syntax and abstractions.
Rephrased your argument means "most people aren't intelligent enough
to use it." I disagree. Many people who don't use Lisp have dealt with
far more complex things in their lives. I think it's a question of a
paradigm shift and the incredible amount of energy required to
overcome inertia.
Consider the following analogy. I was born to a (secular) jewish
family. Most of my relatives are jewish and for the longest time most
of my friends were eastern european jews. I watched Israeli news and
read Israeli papers. When one day I encountered people that suggested
Israeli policy in the infamous Israeli-Palestinian conflict is flawed
it did not occur to me for a second to entertain the possibility that
they could be right. It's not that I wasn't intelligent, or that I was
evil, or that the issue was too complicated for me to comprehend. I
had an incredible amount of inertia behind my world view - it took
over seven years of intense discussions for me to even consider
opening my mind to alternative opinions.
My experience of learning Lisp was suprisingly similar. Inertia is an
incredibly powerful force. Convincing a single human being to consider
possibilities that conflict with his world view can involve years of
daily discussions with dozens of people. Convincing two human beings
takes twice as much. And convincing tens of thousands takes an
astronomical amount of energy.
Acceptance of Lisp, like acceptance of the idea that the Earth is
spherical, is all about overcoming inertia. Just keep pounding. One
day we'll get there.
--
Regards,
Slava Akhmechet.
Pascal Costanza
None of them are believers. What they want is contracts that allow them
to sue each other.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Rainer Joswig
Pascal Costanza <p...@p-cos.net> wrote:
> Charlton Wilbur wrote:
> >>>>>> "DK" == Damien Kick <dk...@earthlink.net> writes:
> >
> > DK> But the thing that I don't understand is why The Customer even
> > DK> bothers to believe any estimates from a software development
> > DK> company if they are estimates of when the next big release
> > DK> will be ready, releases taking something along the lines of a
> > DK> few months short of a year. I would think that they would've
> > DK> caught on to the fact that this seems to be about as accurate
> > DK> as a horoscope or palm reading.
> >
> > The Customer knows the estimates are unreliable and inaccurate, but
> > wants to believe, and so deludes himself so that he can maintain the
> > illusion of control.
> >
> > Just as the manager knows the waterfall method doesn't work, but wants
> > to believe, and so deludes himself so that he can maintain the
> > illusion of control.
> >
> > The programmers know that the waterfall method doesn't work, but
> > aren't so deluded as to think they have any control, and so nod and
> > smile at the manager and pretend everything is just peachy.
>
> None of them are believers. What they want is contracts that allow them
> to sue each other.
>
>
> Pascal
I don't think that's fair. Much of the pre-planning
is due to financial and controlling departments.
They need estimates to plan ahead. Also if you have
an IT department with hundreds of people and
50% of them maintaining and developing software
you need to get an idea what they are doing in
the next 3,6,9,12 months. So their demand to get
estimates, plans and so forth comes down
the chain. Plus marketing/sales departments want
to know when products are ready, their numbers
go back into planning and so on. There are lots
of dependencies on all sides.
Also estimates are independent if you do waterfall
another approach. Not doing waterfall does not
mean you are doing no planning or no estimation.
Of course you do. You plan for horizons that are
predictable and you make estimates as soon as
you have reliable input and you know what you
have to build.
Let's assume you are doing a pricing system in Lisp.
You need to get out and get requirements. From
these requirements you'll develop ideas
what the software should do what components you
need, etc. Then you would do a few prototypes:
one for the core engine, one for the GUI,
one for the interfaces. Each of those prototypes
will be discussed with involved people. The
GUI would be discussed with potential users,
the core engine will discussed with architects,
interfaces will be discussed with EAI experts
and owners of the other systems. You may even
want to integrate the prototypes into one larger
prototype. The prototypes may go deep and broad
into the functionality. So you know how much
effort it is do develop some critical component
and you know how many components there are
and you have an idea what complexity each of these
components have. This gives you lots of useful data for
planning sessions. The approach to get early real
data and the approach that you work from realistic
prototypes gives you confidence that there are not
too many surprises.
The key is to get real work done as soon as possible
and not write design specs for a year
(which component has most business value?
which components have special non-functional requirements?
which component is most critical in terms of architecture?
which component is most critical in terms of
user acceptance?). That's exactly where you
can work with dynamic languages. They allow you
to get up to speed real soon and they allow you
to show something and to integrate customer feedback
early and in regular intervals.
This is exactly where Lisp or
some Smalltalk have advantages, they scale also
later when the application gets larger. People
have moved away from Smalltalk to Java for
those applications. Many Java applications will
crash under their own weight and they will
not be evolvable. My prediction is that Java
applications will be extremely costly to maintain
in the future. More than Cobol applications.
Charlton Wilbur
>> The Customer knows the estimates are unreliable and inaccurate,
>> but wants to believe, and so deludes himself so that he can
>> maintain the illusion of control. Just as the manager knows
>> the waterfall method doesn't work, but wants to believe, and so
>> deludes himself so that he can maintain the illusion of
>> control. The programmers know that the waterfall method
>> doesn't work, but aren't so deluded as to think they have any
>> control, and so nod and smile at the manager and pretend
>> everything is just peachy.
PC> None of them are believers. What they want is contracts that
PC> allow them to sue each other.
This might be more plausible if suing for breach of contract happened
often enough to change the process.
Damien Kick
>>>>>> "PC" == Pascal Costanza <p...@p-cos.net> writes:
>
> >> The Customer knows the estimates are unreliable and inaccurate,
> >> but wants to believe, and so deludes himself so that he can
> >> maintain the illusion of control. Just as the manager knows
> >> the waterfall method doesn't work, but wants to believe, and so
> >> deludes himself so that he can maintain the illusion of
> >> control. The programmers know that the waterfall method
> >> doesn't work, but aren't so deluded as to think they have any
> >> control, and so nod and smile at the manager and pretend
> >> everything is just peachy.
Well, if only it were as simple as nodding and smiling. Instead, in my
experience, it seems to work more along the lines of working late
nights, weekends, over holidays, and catching hell when a problem is
found after the release has been delivered to The Customer in the
component for which the initial estimate had greatly underestimated the
complexity of the change. If The Developer could just happily work
away, smiling and nodding, then things really would be peachy. I
suppose that the only reason that this model works economically is
because most programming jobs tend to be salaried jobs and therefore The
Developer bears the brunt of the cost of having pulled the wrong numbers
our of the air; i.e. she or he works the extra hours without receiving
extra compensation for it.
> PC> None of them are believers. What they want is contracts that
> PC> allow them to sue each other.
>
> This might be more plausible if suing for breach of contract happened
> often enough to change the process.
But in my industry, wireless telephony, there are penalties to be paid
for late delivery and these penalties are indeed applied often enough
that it is a very conspicuous driving factor in the decision making
process. I can understand why The Customer would sign up for something
like this but I don't quite understand why corporate pretends that we
can make estimates accurate enough on which to risk monetary penalties.
Obviously, everyone still ends up making money in the end but it
doesn't seem to me to be the most efficient means to achieving the ends.
Vassil Nikolov
On Wed, 23 May 2007 08:17:42 +0200, Frank Goenninger DG1SBG <dont-e...@nomail.org> said:
| ...
| Happened a few times when I was hacking C. I then put in some comment
| like:
| /* READ THIS CAREFULLY BEFORE CHANGING THE FOLLOWING CODE!
| THIS CODE SEGMENT HAS BEEN OPTIMIZED. IT IS VERY UNLIKELY THAT YOU
| WANT TO CHANGE IT. IF SO DO IT AT YOUR OWN RISK. THIS CODE IS
| OPTIMIZED BEYOND READABILITY. IT MAY HAPPEN YOU DO NOT FULLY
| UNDERSTAND WHAT IT DOES. IF YOU REACH THAT CONCLUSION YOU ARE ADVICED
| TO BACK OFF FROM CHANGING THIS CODE SEGEMENT.
| RESPECTFULLY
| THE AUTHOR OF THIS CODE */
| I never saw someone change those code sections... And it made me reach
| Guru status actually quite fast.
Hmmm...
See the "/* You are not expected to understand this */" (second)
section of http://cm.bell-labs.com/cm/cs/who/dmr/odd.html. The
other sections are worth reading as well. (De nos fabula...)
---Vassil.
--
The truly good code is the obviously correct code.
fireblade
> > The programmers know that the waterfall method doesn't work, but
> > aren't so deluded as to think they have any control, and so nod and
> > smile at the manager and pretend everything is just peachy.
>
Today you will wear clothes you don't want to wear
You'll drive somewhere you don't want to be ,and do things you don't
want to do.
Have a nice day.
Ratbert
http://www.dilbert.com/comics/dilbert/archive/dilbert-20070529.html
Thomas A. Russ
> Hmmm...
>
> See the "/* You are not expected to understand this */" (second)
> section of http://cm.bell-labs.com/cm/cs/who/dmr/odd.html. The
> other sections are worth reading as well. (De nos fabula...)
For an interesting comment from lisp code, there is the comments for
the original RATIONALIZE in the CMUCL sources:
;; Thanks to Kim Fateman, who stole this function rationalize-float
;; from macsyma's rational. Macsyma'a rationalize was written
;; by the legendary Gosper (rwg). Gosper is now working for Symbolics.
;; Guy Steele said about Gosper, "He has been called the
;; only living 17th century mathematician and is also the best
;; pdp-10 hacker I know." So, if you can understand or debug this
;; code you win big.
FWIW, here is the code as well:
(defun rationalize (x)
"Converts any REAL to a RATIONAL. Floats are converted to a simple rational
representation exploiting the assumption that floats are only accurate to
their precision. RATIONALIZE (and also RATIONAL) preserve the invariant:
(= x (float (rationalize x) x))"
(number-dispatch ((x real))
(((foreach single-float double-float #+long-float long-float))
;; Thanks to Kim Fateman, who stole this function rationalize-float
;; from macsyma's rational. Macsyma'a rationalize was written
;; by the legendary Gosper (rwg). Gosper is now working for Symbolics.
;; Guy Steele said about Gosper, "He has been called the
;; only living 17th century mathematician and is also the best
;; pdp-10 hacker I know." So, if you can understand or debug this
;; code you win big.
(cond ((minusp x) (- (rationalize (- x))))
((zerop x) 0)
(t
(let ((eps (etypecase x
(single-float single-float-epsilon)
(double-float double-float-epsilon)
#+long-float
(long-float long-float-epsilon)))
(y ())
(a ()))
(do ((xx x (setq y (/ (float 1.0 x) (- xx (float a x)))))
(num (setq a (truncate x))
(+ (* (setq a (truncate y)) num) onum))
(den 1 (+ (* a den) oden))
(onum 1 num)
(oden 0 den))
((or (= xx (float a x))
(and (not (zerop den))
(not (> (abs (/ (- x (/ (float num x)
(float den x)))
x))
eps))))
(integer-/-integer num den))
(declare ((dispatch-type x) xx)))))))
((rational) x)))
--
Thomas A. Russ, USC/Information Sciences Institute
BTW. That is code which I shamelessly appropriated for a Java
implementation of Rational Numbers.
Rob Warnock
+---------------
| For an interesting comment from lisp code, there is the comments for
| the original RATIONALIZE in the CMUCL sources:
| ;; Thanks to Kim Fateman, who stole this function rationalize-float
+---------------
Though note that, at least as of CMUCL-19c, it's now:
;;; RATIONALIZE -- Public
;;;
;;; The algorithm here is the method described in CLISP.
;;; Bruno Haible has graciously given permission to use this
;;; algorithm. He says, "You can use it, if you present the
;;; following explanation of the algorithm."
;;; ...[trimmed]...
Not sure why the change or what the differences are...
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Vassil Nikolov
On 01 Jun 2007 11:44:57 -0700, t...@sevak.isi.edu (Thomas A. Russ) quoted:
| ...
| ;; Guy Steele said about Gosper, "He has been called the
| ;; only living 17th century mathematician and is also the best
| ;; pdp-10 hacker I know." So, if you can understand or debug this
| ;; code you win big.
That is an interesting note. The people who understood and debugged
the code (as it were) of the real 17-th century mathematicians were
19-th century mathematicians such as Cauchy and Weierstrass.
Whether they actually won big I can't say, though.