<div dir="ltr"><div>@David: I agree with all of your points. Having been in this business for a long time, time-to-market is always of high priority, if you are in the game to make money. So, getting something up and running quickly, something that can be shown to potential customers, or better yet, VCs, is very important. I recently worked on a project that was done entirely in python/wsgi mainly because of time to market. That product would be better done in Erlang/OTP, but there was simply no time for the development team to take on that learning curve.<br><br></div><div>@Peter: I am in the same position you are. I desperately want to become proficient with Erlang, and have taken on a project to develop a web app, the particulars of which I am pretty familiar - I won't have a lot to learn about the "interesting problem", as I've been through all that before. So, my focus is on how to implement that in Erlang. I've only been working on this for a couple of months, and I don't really have a lot of time to spend on it due to the fact that I have a day job that keeps me too busy. Here's where I stand after going through the same process of discovery that you are going through. YMMV, of course:<br><br></div><div>I originally thought about doing this as a Haskell/Yesod project, but got bogged down in Haskell's infamous "dependency hell" issue. Yesod claims to be able to handle 100k+ concurrent web connections, which is why I first thought about going that way.<br><br></div><div>After getting frustrated with Haskell, I fell back to Erlang, which I already know, somewhat. I don't know enough to be hired to do Erlang for a paycheck yet, but I'm definitely trying to get to that level. At the same time, I discovered Elixir, which runs on the Erlang vm, and spent a couple of weeks looking at that. My impression of Elixir is that it looks promising, but is still rather immature, and will need some time to become industrial strength. So, once again, back to Erlang.<br><br></div><div>What I now have is the beginnings of a web server, written in Erlang, using gar1t's e2 framework (makes OTP easier) and his modlib (makes working with erlang's httpd module way easier). Here is my current tools/frameworks list:<br><br></div><div>Language: Erlang R17<br></div><div>Frameworks: e2 on top of OTP<br></div><div> modlib for the web framework.<br></div><div>Data storage: Riak 2.0.4 - storage of metadata. Storage of user data TBD.<br></div><div>JSON - I hate XML.<br></div><div>Eclipse rather than IntelliJ, simply because I've been using Eclipse for about 15 years.<br></div><div>Linux. I hate MS worse than XML. But that's a "religious" issue which we really don't need to discuss, cuz it will get us nowhere.<br><br></div><div>I would be happy to share my experiences with you as I progress through this project. Drop me a line any time.<br><br></div><div>Thanks all,<br><br></div><div>Michael<br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 20, 2015 at 10:49 AM, David Welton <span dir="ltr"><<a href="mailto:davidnwelton@gmail.com" target="_blank">davidnwelton@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Indeed, the great lure of frameworks are they make prior choices for you<br>
> under the pretense the choices are correct and useful for your problem. By<br>
> making the decisions quickly, you get a minimum viable product faster and<br>
> have a shorter time to market. In turn, you gain the de-facto monopoly<br>
> anyone hopes to get.<br>
<br>
</span>It doesn't even need to be about a monopoly, but about just getting<br>
something out there and figuring out if there's a viable business<br>
there at all.<br>
<span class=""><br>
> So you need prior knowledge of what problem you need to solve, or it is<br>
> square pegs through rounds holes all the way down.<br>
<br>
</span>You don't necessarily get that, so sometimes it's best to get up and<br>
running quickly and start learning. Maybe out of 5 features you had<br>
in mind, the customers love 1 and buy your product for it, and don't<br>
care much about the other 4. It's difficult to know that a priori.<br>
<span class=""><br>
> 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.<br>
<br>
</span>You actually may not need to know the framework that intimately.<br>
There are a whole slew of problems that you could solve with pretty<br>
much any old thing out there, given how bad existing solutions are.<br>
<span class=""><br>
> My claim is that any interesting problem has high risk.<br>
<br>
</span>For a business, at least, in a lot of cases the risk is 'market' risk,<br>
though: <a href="http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2325" target="_blank">http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2325</a> -<br>
which may not correspond to an 'interesting problem' in terms of<br>
technology at all. You could use PHP and MongoDB and whatever other<br>
icky tech, and it'd probably work out if you get that one key thing<br>
that makes people want to buy your product.<br>
<br>
As a well-known example from the world of bootstrapped businesses:<br>
<a href="http://www.bingocardcreator.com/" target="_blank">http://www.bingocardcreator.com/</a> which has been amply discussed<br>
online. He originally made it as a downloadable Java program, then<br>
redid it as a Rails web application. Realistically, I'm sure he could<br>
have used pretty much any old thing he knew well enough: the<br>
'interesting' part of BCC is not the technology, but the marketing he<br>
put into it.<br>
<span class=""><br>
> In turn, any<br>
> interesting problem is unknown by definition. Hence, you don't know a priori<br>
> if your framework fits the problem in any way, and learning one is more or<br>
> less hit-or-miss. You may get a lucky strike, but it was definitely not by<br>
> considerate aiming of the weapon.<br>
<br>
</span>From that point of view, even tools carry risks. Twitter started with<br>
Ruby on Rails, which, much as it's nice for some things, is manifestly<br>
the wrong thing to be using for what they do. Postgres, which I<br>
happen to like a lot, is the wrong thing for some problems. Erlang<br>
itself is the wrong tool if you need every last bit of performance<br>
from your CPU to crunch numbers. And yet Erlang is still probably not<br>
a bad starting place if you don't know that ahead of time: you could<br>
use it to manage the number crunching code, and you're likely to get<br>
some kind of system up and running a bit quicker than if you hand code<br>
it in C.<br>
<span class=""><br>
> This is why I prefer tools to frameworks. For a risky problem, the freedom<br>
> of picking tools for the job dwarf the advantage of using a framework. I<br>
> thrive much better by gluing my own solution together.<br>
<br>
</span>Backing away from the abstractions, the guy asked about creating a web<br>
application. That's a known problem and involves some of the<br>
following:<br>
<br>
* A web server.<br>
* Something to connect it to to run code dynamically, rather than<br>
simply serve static web pages.<br>
* Some kind of templating system.<br>
* Some kind of data store.<br>
<br>
Having a starting place that does all of that is a good jumping off<br>
point for working on whatever it is that is actually interesting to<br>
customers. Having something to start from also means you will<br>
discover sooner, rather than later, if it's not adequate for what you<br>
need, and give you firmer ideas about what you actually do need.<br>
<br>
This is also an information asymmetry problem: people who are just<br>
getting started are the ones least able to evaluate a bunch of<br>
disparate tools, so giving them something that at least *works* out of<br>
the box is going to save them time and give them a leg up to a point<br>
where they are more comfortable, understand more things, and are able<br>
to start making any decisions about replacing bits and pieces or doing<br>
things differently.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
David N. Welton<br>
<br>
<a href="http://www.welton.it/davidw/" target="_blank">http://www.welton.it/davidw/</a><br>
<br>
<a href="http://www.dedasys.com/" target="_blank">http://www.dedasys.com/</a><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>