[erlang-questions] your first choice?

[David Welton]

> Never pick a "framework", since they always limit you in the long run. If I
> *had* to, I would research nitrogen or n2o.

"In the long run, we are all dead." - John Maynard Keynes

Normally, jlouis is a source of great advice and tons of wisdom about
Erlang and programming in general, but I will respectfully disagree in
this case.

First of all, let me say that it does depend on what you're out to
accomplish and in what time frame.

If you just want to get *something* up and running, a framework can be
a wonderful starting point. For many startups, for instance, the
important thing is finding product-market fit, and the faster you have
something in front of people, the faster you can start trying to
discern whether it's something they'll buy.  If you take a long time
building something carefully by hand, piece by piece, carefully
crafted and thought through, you may run through all your time/money
and discover that what you built was not what people actually wanted.
It's basically a "worse is better" situation.

Certainly a framework might be a hindrance at some point in the
future, but if you get to that point, you probably have some money and
resources to rectify the situation.

Other startups are more about technological, rather than market risk -
can the thing be built at all?  If it can, there's surely a market for
it.  The canonical example of this is a "cure for cancer".  In that
case, perhaps more up-front design is needed!

In some ways, a framework is just a bunch of components that work
together that anyone approaching a similar problem will end up putting
together in a similar way in any case.  For instance, with a database,
you'll very likely want something like poolboy and something like fuse
involved, sooner or later.  Not having to wire that up yourself is
simply a time saver.

And; once again, if it's just a learning project, you can do whatever
you feel maximizes your learning experience.  That sort of thing has
different goals than a project with business requirements.

-- 
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/