perl is not a panacea! and this is exactly the issue.

Nobody has said perl is a panacea. What makes you think that this just applies to Perl?

everybuddy was written with 0 expandability, and it got rewritten twice 'cause no one could add simple things. heck, register.com is written in perl with 0 expandability and it was pure HELL trying to do things like, changing prices or changing behavior or writting api'

I'm unsure of the point you're trying to make here. Can you clarify?

If you write for one way of expanding, and it doesn't work out, you still have something to mold. if you don't plan at all, you wind up with silly things like, 500 line functions, duplication of code, or just ugly algorithms that require more rewriting than refactoring.

By definition if you end up with 500 line functions and tons of duplicate code you do not have a well factored program. Nobody is saying this is a good thing.

Unless I am misinterpreting you are saying that the code got to this unmaintainable state through lack of upfront planning and design. This may be true.

Two questions:

1. Does upfront design always lead to good code?
2. Is upfront design the only way to get to good code?

In my opinion the answers are "No" and "Yes" respectively.

Requirements change, often radically, during the lifetime of a project. Because of this design decisions made early in a project can turn out to be incorrect. This leads to code being thrown away and exactly the mangled codebase you were describing.

In my experience if you continually keep your program well factored (no duplication of code, no duplication of intent, etc.) it is better to add the infrastructure for a feature at the point it is needed, rather than adding the infrastructure upfront, for the reasons previously outlined.

You implied it in your reply about C.

If you write an API for your code, expandability is a lot easier. Hell, if you develop patterns and single points of change, expanding it a lot easier. That is planning.

And if you put no infraastucture in, then you wind up with a lot of duplication and lot of badly implimented "stuff", such as redundancies or odd chains of method calls.

With a well written program, an implied infrastucture evolves. Writing your programs as a bunch of one offs, as if the last program written didn't exist, then you have no expandability. Writing with the idea of what you'll be doing in the future, then you won't shoot yourself in the foot, nearly as hard.

You implied it in your reply about C.

I thought the line "However, that's not the issue is it?" immediately afterwards would make my intent clear :-)

I was just agreeing with you when you said "Look at the older code for everybuddy. It's in C. They don't do anything with any idea of expanding on their source code, till now".

There is a lot of existing code in the world. A lot of it is poor (be it C, Perl, C++ or whatever). However that was not, as far as I was concerned, the issue being discussed.

Apologies for the lack of clarity.

If you write an API for your code, expandability is a lot easier. Hell, if you develop patterns and single points of change, expanding it a lot easier. That is planning.

I've not said I don't develop an API. I've said that I don't add a feature to my code until it is needed.

Why would developing an API incrementally feature by feature, refactoring as you go, make future expansion harder than if you developed the entire API up front?

And if you put no infraastucture in, then you wind up with a lot of duplication and lot of badly implimented "stuff", such as redundancies or odd chains of method calls.

I have not said I don't put infrastructure in my code. I've said I don't put it in until it is needed.

I do not end up with a lot of 'badly implimented "stuff"' because I am careful to continually refactor my code as I go along. This is why I can easily add the necessary functionality when it is actually required.

With a well written program, an implied infrastucture evolves.

I thought that was the point I was trying to make :-)

Writing your programs as a bunch of one offs, as if the last program written didn't exist, then you have no expandability.

Why does creating the simplest possible well-factored program that solves the problem give you bad "expandability"?

Can you give some examples and explanations of how this happens? In my experience the opposite is true.

Writing with the idea of what you'll be doing in the future, then you won't shoot yourself in the foot, nearly as hard.

I've used a lot of different development methodologies over the years. Sometimes they've worked well. Sometimes they haven't.

When they don't work one reason for failure is, in my experience, poor handling of requirements change. Part of this is because doing lots of design up front can produce applications that are brittle in the face of requirements change.

In my experience taking a You Aren't Going To Need It approach produces applications that are far more robust in the face of requirements change. YMMV.