|
|
|
|
i've been trying to learn programming for around 10 years since i started with this book. i still don't know how. every single course or book, even this one, just assumes i have a knack for "breaking down the problem", that top-down design is the "easy part". but that is exactly what i struggle with and nobody seems to be teaching it. every teaching is about "the computer", but i already learnt with this book. i haven't found a single one that explains "how to think". it's just many examples and "hopefully u end up getting it". that is not the case for me.
i don't know how to do top-down design. i really want to learn but i don't know how. people tell me "just practice more", "just build stuff", or whatever, but i cant practice something i can't do. i can only do a project if i already know how to do it, but if i don't and theres nothing to copy from, there's nothing i can do. how can i learn? i really need to know this now or i will fail uni. i'm in year 2 of CS and i haven't learnt anything. help please
|
|
Administrator
|
This course makes that assumption because it assumes that you have had a prior course in using a high-level, preferably object-oriented, language to solve small, but moderately complex, problems. It's that first course that should be emphasizing engineering problem solving skills, but sadly many of them don't -- and that's becoming even more commonly the case.
It's not something we can effectively teach in a forum like this, either, so this is just a very superficial treatment. The idea is to break a problem down into smaller, more manageable pieces that, when combined, solve the overall problem.
It's like if you wanted to design a car (or a house, or an office building, or an aircraft carrier, or a moon rocket). You break it down into major pieces like the frame, the body, the engine, the transmission, the electrical system, the braking system, and so on. You then decide how each of these interfaces to the others and don't worry about anything else at this level. You have to define how the transmission will mate to the engine, but the engine doesn't need to know what kind of filter the transmission is using and the transmission doesn't need to know that the engine is fuel injected. Once the interfaces are defined (and will very likely have to be redefined several times over the course of the project), the transmission designers can focus on designing a transmission that satisfies those interface requirements. They don't care that the body has an electric tail gate or that the brakes use two-rotor discs. They focus solely on the transmission. The same for the engine designers. But this process can be repeated. The engine designers can break the engine down into a cooling system, a lubrication system, a timing system, a fuel system, an exhaust system, and air induction system, and so on. They can define the interfaces between them and then send off teams to design each separately. And, if needed, they can do that again, breaking out individual components that are needed by these systems such as the water pump, the oil pump, the carburetor or fuel injectors. But a water pump can be broken down further, too, if needed. This can continue all the way down to the individual pieces like nuts and bolts or body panels and clip fasteners. If I'm responsible for designing the clip fastener, I don't need to know what kind of car it's going on (or even that it's going on a car), just what the interface is -- how thick the panel is going to be, what kind of screw does it need to accept, how far in from the edge will the hole be, etc. Similarly, the person designing the thing that will use the clip fasteners needs to know these things, but they don't need to know what material the clip fastener is made from.
|
|
|
thanks for replying. i understand the goal of breaking it down, but i feel like what you described is more "separation of concerns", which is similar to what the book teaches, but not so much "breaking it down".
what i want to know is what thought process is involved here that lets you "discover" the different parts of the car? how do could you go from "car" to "frame", "body", "engine", and so on, if you don't have a car to copy? how would you know that the car "needs" a transmission, an electrical system, and so on?
that is what i don't understand. how is this "breaking down" actually performed for "new" problems. and sorry for asking again. do you know any book or course that teaches this properly? your explanation is already more thorough than i've seen in some books and videos. is there any hope for me to learn?
|
|
|
#1 this is not the book/language/os etc to learn programming. Choose a mainstream simple learning language. I suggest python
#2. choose a simple project to build. Start with something simple and gradually build on it. A classic like a program that converts degrees centigrade to farenheit or back. Then add code that comments on the temperature, "phew thats hot", "nice" or "brr" depending on the temperature. Then make the comment different colors , blue for cold, red for hot etc. Then remember the history of what was converted. The allow the user to enter a city name and find out how to look its temperature up on the internet......
#3 alternately sign up for a free python course online
https://programming-23.mooc.fi/https://cs50.harvard.edu/python/
|
|
Administrator
|
This post was updated on .
toastur wrote
thanks for replying. i understand the goal of breaking it down, but i feel like what you described is more "separation of concerns", which is similar to what the book teaches, but not so much "breaking it down".
what i want to know is what thought process is involved here that lets you "discover" the different parts of the car? how do could you go from "car" to "frame", "body", "engine", and so on, if you don't have a car to copy? how would you know that the car "needs" a transmission, an electrical system, and so on?
that is what i don't understand. how is this "breaking down" actually performed for "new" problems. and sorry for asking again. do you know any book or course that teaches this properly? your explanation is already more thorough than i've seen in some books and videos. is there any hope for me to learn?
There is definitely a lot of 'art' and 'the burnt hand teaches best' to this. But that's true of most things in life.
I don't have to know how existing cars are built to know that I need to have some way to move it, some way to stop it, some way to control it, and some way for it to carry things. So now I can look at each in turn and explore ways to accomplish each. How do I stop the car? I might consider lots of different possibilities, ranging from forward facing rockets, to parachutes, to the Fred Flintstone approach. There are interactions between these things that matter (the interfaces). When considering how to move it, I might have considered rockets and having it skid along the ground, but eventually decided to use wheels. So now my 'how do I stop it' guys can consider the possibility of stopping the wheels and perhaps go that route, with a lot of possibilities.
You almost never come at any problem in life without some kind of background to draw upon. You've seen how other systems that do some of the same things work. The people that made the first motorcycle had bicycles for inspiration. Look at many of the early attempts at aviation and it's clear how people tried to take something familiar and adapt it straight across to this new goal (how many "flapping wing" designs were there in the beginning?). Many problems are going to involve lots of dead ends and choices that don't work out. That's the way it is. Look at the history of the Apollo program and you will see an evolution of ideas resulting in a final rocket that had very little in common with the original concepts.
Let's say that I wanted to do something I've never done before, like put in a septic system at a mountain cabin. I have only the vaguest notion of what a septic system entails, but I can already break it down into at least some functional parts (some of which might be wrong and others completely overlooked). I need to get stuff from the house to the septic system. I need to have some kind of a tank to hold it. I need to have some kind of filtration system to move stuff out of the tank and into the septic field (whatever that really is, I only know that it has one). I need a septic field.
I now have broken the problem into four pieces: Transport to tank, the tank, the filter, the septic field. If I can successfully accomplish those four things, I have a good chance of solving the problem. Now I can go and focus on each of those in turn, which will involve learning about them so that I can break each of them down into smaller chunks, if doing so is reasonable.
The common thread here is that you go from "I want to accomplish 'big-problem'" and ask yourself, "Okay, it I can solve 'little-problems' A through D, I probably am getting pretty close."
EDIT: Fix typos.
|
|
|
thanks i will check those out
|
|
Locked
