[erlang-questions] your first choice?

[David Welton]

> 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.

It doesn't even need to be about a monopoly, but about just getting
something out there and figuring out if there's a viable business
there at all.

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

You don't necessarily get that, so sometimes it's best to get up and
running quickly and start learning.  Maybe out of 5 features you had
in mind, the customers love 1 and buy your product for it, and don't
care much about the other 4.  It's difficult to know that a priori.

> 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.

You actually may not need to know the framework that intimately.
There are a whole slew of problems that you could solve with pretty
much any old thing out there, given how bad existing solutions are.

> My claim is that any interesting problem has high risk.

For a business, at least, in a lot of cases the risk is 'market' risk,
though: http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2325 -
which may not correspond to an 'interesting problem' in terms of
technology at all.  You could use PHP and MongoDB and whatever other
icky tech, and it'd probably work out if you get that one key thing
that makes people want to buy your product.

As a well-known example from the world of bootstrapped businesses:
http://www.bingocardcreator.com/ which has been amply discussed
online.  He originally made it as a downloadable Java program, then
redid it as a Rails web application. Realistically, I'm sure he could
have used pretty much any old thing he knew well enough: the
'interesting' part of BCC is not the technology, but the marketing he
put into it.

>  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.

>From that point of view, even tools carry risks.  Twitter started with
Ruby on Rails, which, much as it's nice for some things, is manifestly
the wrong thing to be using for what they do.  Postgres, which I
happen to like a lot, is the wrong thing for some problems.  Erlang
itself is the wrong tool if you need every last bit of performance
from your CPU to crunch numbers.  And yet Erlang is still probably not
a bad starting place if you don't know that ahead of time: you could
use it to manage the number crunching code, and you're likely to get
some kind of system up and running a bit quicker than if you hand code
it in C.

> 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.

Backing away from the abstractions, the guy asked about creating a web
application.  That's a known problem and involves some of the
following:

* A web server.
* Something to connect it to to run code dynamically, rather than
simply serve static web pages.
* Some kind of templating system.
* Some kind of data store.

Having a starting place that does all of that is a good jumping off
point for working on whatever it is that is actually interesting to
customers.  Having something to start from also means you will
discover sooner, rather than later, if it's not adequate for what you
need, and give you firmer ideas about what you actually do need.

This is also an information asymmetry problem: people who are just
getting started are the ones least able to evaluate a bunch of
disparate tools, so giving them something that at least *works* out of
the box is going to save them time and give them a leg up to a point
where they are more comfortable, understand more things, and are able
to start making any decisions about replacing bits and pieces or doing
things differently.

-- 
David N. Welton

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

http://www.dedasys.com/