The Old Joel on Software Forum: Part 3 (of 5)

Programming bottom-up

anyone have any experience how this works out? like how can you manage proper top-down planning into programming bottom up?

questions abound after reading this piece bt Paul Graham

hxxp://www.paulgraham.com/progbot.html

eddy
Monday, December 22, 2003

I tend to program this way when creating classes. I find it's most helpful to think "What classes would make it trivially easy to build this software?" then go-ahead and build those classes. I almost always seem to create cleaner software using this approach than decomposing the problem in the top-down method.

Matthew Lock
Monday, December 22, 2003

so you apply bottom-up methods after you have done the initial planning and design of the required program?

eddy
Monday, December 22, 2003

I was always taught, many years ago to 'design top-down and program bottom-up'. While I was taught this in the 'Cobol' days, it sort of agrees with what Matthew said above.

David Freeman
Monday, December 22, 2003

I think this is how all programming works. Despite anyone's adherence to "top-down" or "bottom-up" design, in reality, all good design is a combination of the two.

Zahid
Monday, December 22, 2003

My normal mode of programming is bottom up, and I've never really had problems with it. Perhaps I don't understand this statement very well:

"...like how can you manage proper top-down planning into programming bottom up?"

Can you elaborate more on what you specifically see as the mismatch? I'm having a hard time understanding where you see potential problems.

bottom coder
Monday, December 22, 2003

I think Paul Graham choose poorly when he choose the expression 'Bottom Up Programming' because it always leads to this type of misunderstanding. He has overloaded the term.

It seems to me that he is actually talking about Domain Specific Programming, which is neither as new nor as exclusive to Lisp as he makes out. Anyway, here's how I see it.

Bottom up programming usually involves the order in which code is written. As expressed on the c2 wiki [1]

You have a specification at the top and an implementation at the bottom. In between is a vast gulf that you will eventually fill with code.

The Top down approach begins at the specification and works its way down to the implementation.

I think that the big advantage here is that you can check back to the specification at each layer, providing stubs for the lower processes.

You can say 'the specification requires X, Y and Z. This code will produce requirements X, Y and Z as long as the code below satisfies A, B and C. The specification is then moved down through the layers.

The bottom up approach starts at the implementation and works up towards

You write code that will achieve A, B and C. I can confirm this because it runs and satisfies my unit tests.

It seems that the best choice is somewhere in between. In some cases top down works best and in other bottom up work better.

Paul Graham is talking about something else entirely here:

"It's worth emphasizing that bottom-up design doesn't mean just writing the same program in a different order. When you work bottom-up, you usually end up with a different program."

He does this by implementing a new dialect of Lisp to fulfil the necessary requirements.

In the C2 wiki, this approach is given the more appropriate name of 'Domain Specific Programming.' [2]

Let’s take another look at our two extremes: the specification and the implementation.

The specification is written in a non-executable form of varying levels of formality. It may be one of Joel's irreverent specs scattered with Jokes to keep the reader interested. It may be strictly defined in a specification language such as the Z notation or UML.

Formal or otherwise these documents are targeted at a human reader.

The implementation language is in an executable form, in a language such as C, Java or VB. Each of these languages has syntax for manipulating items at the implementation level. C is geared toward implementing bytes and Java towards Objects.

With Domain Specific Programming the programmer seeks to implement a specification language. Rather than have implementation and specification and never the twain shall meet you implement a specification language.

Lisp is either very good at this, or very bad, depending on your perspective. Beyond the use of parenthesis Lisp has no syntax, which means that the specification reads just the same as any other Lisp code. Of course, for the majority of the human race this also makes it as incomprehensible as any other Lisp code :)

With mainstream languages such as Java or C the specification language is hindered slightly because the language's syntax can get in the way. It is difficult to use the languages built in constructs in your own domain specific language.

The traditional approach in C is to create your own parser using Flex/Bison [3]. Code Generation [4] is becoming popular, especially in Java circles.

At the other side Specification languages seek to become executable. Most modelling tools offer a form of Code Generation based on the existing specification languages. There are also efforts to create executable dialects such as xUML [5]

Rebol [6] seeks to make things simpler with its concepts of dialects and a friendlier syntax. Having struggled with one of its dialects (view) I think it still has some way to go.

Betrand Meyer [7] also expresses similar goals with his Eiffel language:

"[Eiffel] breaks down the difference between analysis, design, and programming. The same tools and concepts are applied throughout. "

It seems to me that a lot of people have been working towards a similar goal, and calling them different names. Paul Graham claims that he and his fellow Lispers are already there, waiting for the rest of use to catch up [8]. It seems to be quite a claim, and it is difficult to avoid the question 'so where are the goods' [9]?

[1] http://www.c2.com/cgi/wiki?BottomUpProgramming
[2] http://www.c2.com/cgi/wiki?DomainSpecificProgramming
[3] http://www.gnu.org/software/flex/manual/ http://www.gnu.org/software/bison/manual/
[4] http://http://facweb.cti.depaul.edu/ctiphd/ctirs02/online_proceedings/Mathew.htm
[5] http://www.manning.com/herrington/
[6] http://www.rebol.com/
[7] http://www.informit.com/content/articlex.asp?product_id={8EAB5105-33FC-42B0-8D8C-35CF6417C9D2}&st={EA7C8D03-4995-402D-B085-06E000F897B8}&session_id={3E8E3049-1A36-40E6-9490-0F58A780DAC1}
[8] http://www.paulgraham.com/diff.html
[9] http://www.paulgraham.com/iflisp.html

Ged Byrne
Monday, December 22, 2003

I've remembered a concrete example:

Shriram Khrishnamurthi's presentation 'The Swine Before PERL' available on TechNetCast[1] gives an excellent example of Domain Specific Programming.

You really need both the audio and the slides.

After plugging Dr Scheme for a while, he takes an example of a State Machine for handling Schemes complex CAR and CDR combinations.

He starts with a formal statemachine specification and some naive Scheme.

He then implements that statemachine specification language as a dialect in Scheme.

[1] http://technetcast.ddj.com/tnc_play_stream.html?stream_id=644 [1]

Ged Byrne
Monday, December 22, 2003

many thanks to Ged Byrne for all the links and explanation.

confusion arises because i thought that doing bottom-up seems to be hack and fix style of coding without prior planning and design.

looks like i was been too shallow :). any more people who would like to add more?

eddy
Monday, December 22, 2003

An analogy is building a car.

Top-down - here's a drawing of a car, go make it.
Bottom-up - here's a box of parts, go make me a car.

Someone earlier nailed it when he said you need to do both, design top-down & assemble it bottom-up.

In other words, you need to know what the car looks like (top-down), but build it with stock parts (bottom-up) where possible.

The fun comes in figuring out the middle.

AJS
Monday, December 22, 2003

I do not have a specific answer, but you can read about this subject in http://www.relisoft.com/book/proj/4implem.html

Excerpt :
"The implementation process should model the design process as closely as possible. This is why implementation should start with the top level components. The earlier we find that the top level interfaces need modification, the better. Besides, we need a working program for testing as soon as possible. "

GP
Monday, December 22, 2003

AJS,

Whichever approach you use, top-down or bottom-up, you still need to have had a car built before.

To give somebody a picture of a car, you have to know what a car looks like.

If you have a box of parts, then somebody must have made a car before so that you know what parts are needed. Not only that, but their must be enough parts being produced to justify the mass production of the component parts.

What do you do when you want to make something that nobody has ever made before. You don't know what it will look like and you don't know what you're going to need to make it?

Ged Byrne
Monday, December 22, 2003

I think in a language like Java, bottom-up takes a bit of expertise to pull off. Once you've gotten the bottom carved out, you look at the top level again and it's easy to realize, "Uh-oh, I baked in this assumption to my tools, but I need it to do that other thing!" Maybe the assumption will cause really bad performance in the context of how the program will actually use the tool, or you'll need a near rewrite to correct one small thing that pervades the tool.

Some mitigating practices aid bottom-up:
- Frameworks
- Agile practices
- AspectJ
- Patterns
- Generics
- Scouting

I kind of think this can be visualized as going down a tree, and bottom-up is like depth-first. You're still descending from the top, but you're learning as you go down.

Tayssir John Gabbour
Monday, December 22, 2003

I think that I won't take too much of my C++ programming advice from a book on Lisp. For one thing, the block structure delimiters don't have enough points on them, and there are too many of them to manage.

But mostly I don't pay a lot of attention to how lisp is written because I don't write any lisp and don't intend to start.

Clay Dowling
Monday, December 22, 2003

"Programming Bottom-up head your own is" for some it could said be

Master Yoda
Monday, December 22, 2003

nice posting so far, any more insights from other people?

btw any any one come across books that seems to use bottom up programming beside those written by Paul Graham? :)

eddy
Tuesday, December 23, 2003

Eddy,

There's a book by Peter Norvig - Paradigms of Artificial Intelligence Programming - that makes use of bottom-up techniques.

Bottom-up is a style when you DON'T know what you're doing. You just have a vague idea. And you sort of nudge and try and re-try.

It just so happens (historical accident) that it's quite fast to do such exploration in Lisp.

Slick
Friday, December 26, 2003