Hi Joe,<div><br></div><div>I couldn't agree more with your message. After all, choosing the right tool for the problem at hand is part of solving the problem.</div><div><br></div><div>CGS</div><div><br></div><div><br><br>
<div class="gmail_quote">On Mon, Jul 16, 2012 at 11:07 AM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, Jul 12, 2012 at 11:45 PM, CGS <<a href="mailto:cgsmcmlxxv@gmail.com">cgsmcmlxxv@gmail.com</a>> wrote:<br>
> Hi Jan,<br>
><br>
> Few thoughts here.<br>
><br>
>> You are hearing things in my email that were not there when I wrote it.<br>
><br>
><br>
> Sorry about that, but stating that "Erlang is just too damn difficult to do<br>
> the easy stuff" is what I read in your message, not inventing it. And you<br>
> said that just because of some applications (cowboy and rebar). Use erl with<br>
> -detach and -noshell options and you have a perfect executable without<br>
> breaking any sweat to learn how to make an application. All you need is to<br>
> read "man erl" (you can even google it if you don't have Linux). Of course<br>
> that's for beginners. Later on, you will learn to make applications with<br>
> everything you need, so, you will most of the time forget about those<br>
> options. :) Is that complex? Difficult? I don't suppose it's more difficult<br>
> than reading about the options of any given compiler.<br>
><br>
<br>
</div>I think the point is that in any language it's easy to do the things that<br>
that language was designed to do and difficult otherwise.<br>
<br>
Erlang was designed for (among other things) distributed programming -<br>
thus distributed programming is easy.<br>
<br>
Pid ! Message<br>
<br>
and<br>
<br>
receive<br>
Pattern1 -><br>
Action1;<br>
...<br>
end<br>
<br>
Are sufficient to write distributed programs (and a small amount of setup)<br>
<br>
This is ridiculously easy - I'm fighting with Objective C trying to do<br>
the same thing - I need to<br>
know about Grand Central Dispatch (GCD) and sockets and goodness knows what just<br>
to send a message between two machines. So in Objective C it's "really<br>
difficult to do easy stuff"<br>
On the other hand in Objective C it appears to be really easy to make<br>
a window throw in a few<br>
buttons and get them to do things when you click on them (which is<br>
really difficult to do in Erlang)<br>
<br>
I accept that Erlang is not good at processing images and things like<br>
that _ but it was never intended to be good at things like that ...<br>
<span class="HOEnZb"><font color="#888888"><br>
/Joe<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
>><br>
>><br>
>> I was reporting my experience, not blaming Erlang for anything. My<br>
>> experience is that the learning curve for the Erlang tools (coupled<br>
>> unfortunately with learning the Linux environment) was extremely steep - and<br>
>> ended up with me getting stuck because the tools failed to do what they<br>
>> claimed (in multiple ways) before I had the skills or knowledge to fix them.<br>
><br>
><br>
> Well, every tool may have the same doom. Those are called bugs and therefore<br>
> there are versions for each of them. One cannot think of every possibility,<br>
> can he/she? That doesn't mean the tool is stopping you in learning about<br>
> what is applied to. Moreover, in the Linux world, until one tool is accepted<br>
> as satisfactory (so, further tools are no more developed in that field),<br>
> there are a lot of alternative ones. You don't need to get stubborn in<br>
> having one and only that tool, especially when you are new in that field.<br>
><br>
>><br>
>><br>
>> Erlang the language is not the problem. The language is never the problem.<br>
>> Once the tool chain is working......<br>
><br>
><br>
> Search for the tool which suites your needs or ask if it is possible to get<br>
> new features which may support your needs in a given time. I tell you that<br>
> from my own experience because not once it happened to get the wrong tool<br>
> for my needs and after I managed to learn about that, I discovered it<br>
> doesn't do what others were thinking it may do. One example is SpiderMonkey<br>
> for CouchDB. CouchDB and SpiderMonkey are both great tools, but, in the<br>
> past, CouchDB had quite few problems in getting it work because of<br>
> SpiderMonkey. So, I googled it and I found a repository where I could find a<br>
> version of SpiderMonkey which was compatible with that version of CouchDB.<br>
> Now, CouchDB has no longer that problem anymore. But the conclusion remains:<br>
> search for the correct version of what you need.<br>
><br>
>><br>
>><br>
>> But consider this. Rebar can't be installed in a standard Ubuntu install<br>
>> of Erlang!!! WTF?<br>
><br>
><br>
> As far as I know (I am not using rebar because I am creating my own<br>
> installation scripts which is much faster than thinking how to do it using<br>
> rebar), rebar doesn't need any installation. I usually take it from the same<br>
> repository as the source I need to compile. Strangely enough, those projects<br>
> which do not provide rebar, they work with the latest version of rebar.<br>
> Never met your problem, but there are many problems I haven't met, so, I<br>
> don't deny your's. Indeed, bad experience for a newbie.<br>
><br>
>><br>
>><br>
>> Would you agree that that means at least one of those installs is<br>
>> inadequate for my needs? Its inadequate for anyone who wishes to use rebar<br>
>> and Erlang on Ubuntu/Debian.<br>
><br>
><br>
> I work under Ubuntu most of the time. It's my favorite Linux flavor (CentOS<br>
> is becoming the second, but I wouldn't recommend it at starting point). Few<br>
> times I had problems with it, but I do tend to install my own versions<br>
> instead of those from repos. They old and providing many crashes in the new<br>
> versions of applications which require them. Fedora may cope with this<br>
> problem, but you may have some other surprises there which may be more<br>
> troublesome if you don't know about Linux.<br>
><br>
>><br>
>><br>
>> Would you agree that giving newbies tools that are inadequate for their<br>
>> needs, does not help them scale their learning curve?<br>
><br>
><br>
> I do not understand your point. A software is not for a newbie or for a<br>
> veteran. A software is created to fill an empty spot in a certain field.<br>
> There are many other tools which you can start with and I don't suppose<br>
> somebody gave you the tool, but you picked it. All you can do is to ask<br>
> specific questions about the tool until you learn how to use it properly for<br>
> your needs. In this community (and quite a lot of others) there will be no<br>
> answer like RTFM or learn by yourself. There are many persons here who can<br>
> answer questions in a wide range of knowledge (from where can I find any<br>
> documentation about Erlang? to, I don't know, "why not using frames in<br>
> Erlang?" just to give an example which covers a subject way over my head).<br>
><br>
>><br>
>><br>
>> This is not meant as a criticism of the work people have done. Its a very<br>
>> hard problem, and I don't think there is an easy solution.<br>
><br>
><br>
> In my opinion, there are no easy or difficult solutions. There are only<br>
> smart solutions or using the brute force. :) When I am not smart enough, I<br>
> use brute force (it seems quite a natural choice at the beginning and I am<br>
> still using it in Erlang ;) ).<br>
><br>
>><br>
>><br>
>> PHP isn't there yet. PEAR is not widely used. The comments added to the<br>
>> manual are very helpful. PHP the language is astonishingly inconsistent.<br>
><br>
><br>
> I wouldn't know that. I know that PHP has an insanely large documentation<br>
> which I will never be able to know it by heart. :)<br>
><br>
>><br>
>><br>
>> Python boasts "batteries included". Whatever you want to do in Python,<br>
>> there are usually 6 modules that claim to do it - all poorly documented,<br>
>> some buggy. So do you spend your time investigating them, or writing a 7th<br>
>> that you know will do what you want?<br>
><br>
><br>
> Yeah, agree. I usually opt for the last solution as well if I feel smart<br>
> enough to do that. :)<br>
><br>
>><br>
>><br>
>> Experienced people have forgotten the misunderstandings they had as<br>
>> newbies - or they had an experienced person to guide them - so they are<br>
>> genuinely puzzled by the problems newbies face. The newbies can't help: they<br>
>> don't know what they don't know. Few technical people can write well, and<br>
>> all are busy with their projects. The result is a distinct lack of<br>
>> excellent, current documentation of the tools that can help newbies start to<br>
>> use Erlang.<br>
><br>
><br>
> Therefore there are a lot of others writing some beginner's guides. I<br>
> remember one of my starting documentations for Erlang was "Learn You Some<br>
> Erlang" (yes, Fred, I haven't had the opportunity to thank you for that, but<br>
> I do it now). Just try few of them. And if you want some code, I would<br>
> recommend to start with trapexit.<br>
><br>
>><br>
>><br>
>> It comes, slowly, with maturity and stability. Erlang the language is well<br>
>> documented. Its the docs for the supporting cast that is spotty. Which is a<br>
>> shame.<br>
><br>
><br>
> Just don't get discouraged. You still have the chance to criticize and hate<br>
> Erlang. :D<br>
><br>
>>><br>
>>> You blame Erlang for an application written in it which doesn't support<br>
>>> MS Windows... Well, that reminds me of a case of saying noSQL databases are<br>
>>> not good just because that person/team misunderstood the usage of a<br>
>>> particular noSQL database. Interesting how people try to generalize their<br>
>>> impressions to a category from a wrongly chosen example. Don't get me wrong,<br>
>>> I am not that good in Erlang to mock you, but I think you should ask someone<br>
>>> more knowledgeable before you to say something like "Erlang is just too damn<br>
>>> difficult to do the easy stuff." I do easy stuff in Erlang. It would<br>
>>> probably be more difficult to write a proper C code to do those simple<br>
>>> things (like proper threading, distributed applications and so on).<br>
>>><br>
>>> Now, the problem is what do you need cowboy for? If you need an webserver<br>
>>> for MS Windows which is written in Erlang, you can try Yaws (you have<br>
>>> installers here: <a href="http://yaws.hyber.org/download/" target="_blank">http://yaws.hyber.org/download/</a>). If you need a<br>
>>> Erlang-based webserver which you can integrate it in your application, you<br>
>>> will need either a Linux or Cygwin (for most of the open source projects,<br>
>>> but you can do it without if you use, for example, lhttpc -<br>
>>> <a href="https://bitbucket.org/etc/lhttpc/src" target="_blank">https://bitbucket.org/etc/lhttpc/src</a> - where you can modify the Makefile to<br>
>>> be compatible with MS VS or, for even less, a .bat file). I would avoid<br>
>>> installing Linux in a MS Windows box (I'd rather do it oppositely).<br>
>><br>
>> Agreed. Ubuntu host with LVM and software RAID, VBox with a windows guest.<br>
>> Plans are laid :)<br>
>><br>
>> Your other points are all good stuff. Thanks.<br>
>><br>
>> I am looking for a fast web server that had a permanent core(1) image that<br>
>> I could program, that was not under any run-away timer (Apache) and that can<br>
>> handle many simultaneous connections (i.e event driven architecture). One of<br>
>> the projects is a special type of chat room where silence might exist for<br>
>> long periods, and I don't want a fast heart-beat or unnecessary writes to<br>
>> disk.<br>
><br>
><br>
> I may recommend BOSH technique (<a href="http://xmpp.org/extensions/xep-0124.html/" target="_blank">http://xmpp.org/extensions/xep-0124.html/</a>)<br>
> rather than long polling. :)<br>
><br>
> Best of luck!<br>
><br>
> CGS<br>
><br>
>><br>
>><br>
>> Note 1 - Core is RAM to anyone under 50. ;)<br>
>><br>
>><br>
>>><br>
>>> Erlang under MS Windows works as nice as under Linux (as far as I could<br>
>>> play with it under MS Windows), but the installation under MS Windows is<br>
>>> much simpler (I would suggest for Linux to compile it from source with the<br>
>>> options you need rather than installing it from repositories). I don't know<br>
>>> what is your background in programming (and I don't want to know), but there<br>
>>> are nice tutorials on web for all the categories of programmers (coming from<br>
>>> OOP, functional or whatever else languages). Just get familiarized with<br>
>>> Erlang and after that make an impression of your own about the language<br>
>>> itself. I am also relatively new in Erlang and I consider I cannot afford to<br>
>>> make any statement about how good or not is Erlang. I know only that are<br>
>>> some nice things and some not so nice things in Erlang (I leave finding<br>
>>> examples to your experience).<br>
>><br>
>> Indeed. Erlang under windows is fine. The target server is Ubuntu, so<br>
>> developing on that platform has advantages. Particularly in view of the<br>
>> planned migration to Ubuntu as my main machine.<br>
>><br>
>> Regards<br>
>><br>
>> Ian<br>
>>><br>
>>><br>
>>> CGS<br>
>>><br>
>><br>
>><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<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>
><br>
</div></div></blockquote></div><br></div>