[erlang-questions] your first choice?

[Jesper Louis Andersen]

On Fri, Feb 20, 2015 at 2:37 PM, David Welton <davidnwelton@REDACTED>
wrote:

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

Indeed, the great lure of frameworks are they make prior choices for you
under the pretense the choices are correct and useful for your problem. By
making the decisions quickly, you get a minimum viable product faster and
have a shorter time to market. In turn, you gain the de-facto monopoly
anyone hopes to get.

The same can be said about astrology. If the constellations and planetary
bodies are just right, you will bathe in gold. If they are ever so slightly
off, you will bathe in lead. And nobody told the astrologers about Styx or
Cerberus, so they can't by definition have gotten the bodies right in their
charts.

The crux of my argument is based upon the prior choice of features. First,
you need prior knowledge of the framework itself. You need to know its
performance model: what is fast and what is slow. You need to know the
internal architecture. Otherwise, you are probably worse off than just
writing the code. A network effect is apparent: the more you work in a
framework, the more accumulated knowledge you have and the faster can you
build new stuff. The 10th Rails project is easier to write than the 1st.
Second, your problem has to match the frameworks framing, in the sense that
the problem space you are facing matches somewhat well with that of the
framework. As an example, it is hard to take the MVC pattern and fit into
an Event Sourcing/CQRS model. Of course you could learn a new framework,
but this requires prior knowledge as well.

So you need prior knowledge of what problem you need to solve, or it is
square pegs through rounds holes all the way down.

My claim is that any interesting problem has high risk. In turn, any
interesting problem is unknown by definition. Hence, you don't know a
priori if your framework fits the problem in any way, and learning one is
more or less hit-or-miss. You may get a lucky strike, but it was definitely
not by considerate aiming of the weapon.

This is why I prefer tools to frameworks. For a risky problem, the freedom
of picking tools for the job dwarf the advantage of using a framework. I
thrive much better by gluing my own solution together.

YMMV of course, depending on the task at hand and your prior knowledge.

-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150220/f5f6744d/attachment.htm>