Anyone know any bottom-up software design tutorials on the net?
I just giving up from the top-down one,..
it's just.. just.. too overcomplicated I think..
Anyone know any bottom-up software design tutorials on the net?
I just giving up from the top-down one,..
it's just.. just.. too overcomplicated I think..
Just GET it OFF out my mind!!
What do you mean by "bottom-up"?
EDIT: Do you mean a book also teaching why to do things, not just how?
I just did a google image search on the subject and am now confident that you and google probably associate different meanings with the term
You aren't talking about lisp/scheme et al, right? As in remodeling the language to suit your needs?
I agree with Nyda. You've misunderstood the terms "bottom-up" and "top-down" it seems.
Everybody starts thinking "bottom-up" when they begin programming but as they get more experienced they begin to think "top-down". So if you are giving up "top-down" means you are going back to your earlier ways.
Here is a quote from one of the Stanford's open courses.
Source:http://see.stanford.edu/materials/ic...Lecture03.htmlOriginally Posted by Stanford professor Mehran Sahami
Not everything that can be counted counts, and not everything that counts can be counted
- Albert Einstein.
No programming language is perfect. There is not even a single best language; there are only languages well suited or perhaps poorly suited for particular purposes.
- Herbert Mayer
That's interesting. I had never heard of this distinction before. After reading a few paragraphs of the wikipedia article the distinction seems obvious to me, but maybe I have it wrong:
I would say the most elementary point where you should easily be able to conceive of things "top-down" would be when you are comfortable with what functions can do for you, so you could write pseudo-code like:
without having to write or think about function Y, beyond this pseudo-code.Code:datastructure X = function Y (input one, input two, input three)
Say function Y is asking the user a question and verifying their response.
A "bottom-up" conception might be to decide you first need to get some user input, and once you have that input you can figure out what to do with it.
I don't know if this necessarily will lead to a different outcome. In reality I think a huge component of software is adding things onto an existing product. Of course, you could approach that "top-down" or "bottom-up" too but once you start coding of any sort, you probably at least think of things to some degree both ways, which is to say "pause and plan" sometimes. I imagine this must be much less vague working as part of a team.
I would say the larger and more complex a project is, the more conscious I have been of taking a "top-down" approach. Also interesting that bottom-up is associated with OOP: I like objects, but in the same sense that I like functions and arrays. To me recognizing that an object is the solution implies I formulated a specific problem.
Finally IMO I would not sweat this too much, I think it is just a dialogical tool, like being able to say "I'll fly North" rather than "I will proceed to the airport and board a plane with a destination latitude > here".
Last edited by MK27; 08-10-2009 at 03:13 AM.
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
But whenever we talk about flexibilities, reusabilities and realibilies;
Everything become complex, too much work and the worst: increasing overhead.
Just GET it OFF out my mind!!
Well, that implies that you've only got about 10 minutes to solve the problem.
A lot of tools I wrote started out very specific -- they required an input file to be exactly so, then did one and only one thing and wrote the output in whatever way seemed like a good idea at the time. By the time I copied and pasted that code for the third time to deal with a slightly different input file that needed a slightly different output format, it was well worth my time to just delete them all and do something generic, flexible, and reusable. If you are actually using the programs you are writing on a daily (or even every-other-daily) basis, you will find out for yourself why people preach what they do, and it won't take you very long to do so.