| Author |
Message |
|
| anderst |
 Posted: Wed Aug 15, 2007 9:51 am |
 |
|
|
User
Joined: 21 Nov 2006
Posts: 37
|
Hi all,
we had a new starter join us recently. When teaching him Erlang and giving him an introduction to OTP, he started working on his systems with a top down approach. He first put together the application structure, followed by the supervisor. When all of that was in place, he went ahead and started working on his gen servers and fsms.
I have always tackled it in the opposite way, starting with the libraries, gen servers, supervisors and leaving the application to last. This is what makes sense to me..
What is the general feeling out there? What do the experienced users vs the newbies feel?
Hilsen,
Anders |
|
|
| Back to top |
  
|
| Mazen |
| Posted: Wed Aug 15, 2007 12:44 pm |
|
|
|
User
Joined: 20 Jul 2006
Posts: 164
Location: London
|
Imho it makes more sense to set up the "framework", I.e. the application and supervision tree along with the (for now) empty children. When I know that all of that is working, I can start "filling out" the children with functionality which I can test pretty easy because all I need to do is to reload the new module(s) in the shell where I have started my application.
Bottom-up for me would be very strange because I think on a more abstract level first and drill down to solve bigger issues by breaking them down.
I would favour Top-down, but I don't know what is "better" because this is simply what has been working good for me  |
|
|
| Back to top |
|
| Ulf |
| Posted: Wed Aug 15, 2007 1:17 pm |
|
|
|
User
Joined: 04 Sep 2006
Posts: 42
Location: Göteborg
|
For me it depends of the situation and the nature of the project/application.
If it's me along, exploring new territory I often start bottom up. Test things, see if and how well they work and then start modeling the system and make a design, then create the application and off we go.
If it's a more known area for me and I can early see how I think the application will/should look then I start with setting up the application and the supervision tree as soon as possible because I think it makes it so much easier to start/stop/restart everything, load new code and so on.
But more often I tend to build it from the middle and out, getting it to run from start to end and then add more functionality around it, refactoring when needed. This way I think that I discover mistakes and bad design decisions earlier, before the bottom or top is already built and a change mean big changes in either one of them or both.
I more want to see it as my application evolves around its core rather then that it's built from top or bottom.
When working like that you have to be careful so that it doesn't turn out to be a spaghetti code of hacks. A good design and refactoring is something that I consider important in any software project.
It is also a way of working that might be hard to get customers to accept. |
|
|
| Back to top |
|
| anderst |
| Posted: Thu Aug 16, 2007 9:46 am |
|
|
|
User
Joined: 21 Nov 2006
Posts: 37
|
Hi Ulf,
your approach is what makes sense to me. What is the point of having a framework in place if your basic servers (or libraries) do not work? They just make the development and debugging harder. My approach is always starting with library functions. When they have been tested and work, I add the behaviours, starting with the workers (gen_servers, etc). The last thing I do is add the supervisor and application. I have found the turnaround and development time to be so much faster.
Hilsen,
Anders |
|
|
| Back to top |
|
| Mazen |
| Posted: Thu Aug 16, 2007 5:10 pm |
|
|
|
User
Joined: 20 Jul 2006
Posts: 164
Location: London
|
Ulf wrote:
But more often I tend to build it from the middle and out, getting it to run from start to end and then add more functionality around it
This is exactly what I mean by top-down... you get the overall "behaviour" working (typically the one you decided on in the highlevel design). Then you start adding meat to the bone.
Ulf wrote:
This way I think that I discover mistakes and bad design decisions earlier, before the bottom or top is already built and a change mean big changes in either one of them or both.
You would probably spot behavioural (bad design) faster from top-down since you are building your system/application on a set of principals for how it should work. When you have it working end-to-end (but without any real meat to the bone), I atleast, tend to see the problems earlier.
I guess it's a matter of how you think as a person so I don't think it really comes down to noobie vs elite users  |
|
|
| Back to top |
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
