[erlang-questions] Looking for slides of a lightning talk

[Joe Armstrong]

On Thu, Jul 12, 2012 at 11:45 PM, CGS <cgsmcmlxxv@REDACTED> wrote:
> Hi Jan,
>
> Few thoughts here.
>
>> You are hearing things in my email that were not there when I wrote it.
>
>
> Sorry about that, but stating that "Erlang is just too damn difficult to do
> the easy stuff" is what I read in your message, not inventing it. And you
> said that just because of some applications (cowboy and rebar). Use erl with
> -detach and -noshell options and you have a perfect executable without
> breaking any sweat to learn how to make an application. All you need is to
> read "man erl" (you can even google it if you don't have Linux). Of course
> that's for beginners. Later on, you will learn to make applications with
> everything you need, so, you will most of the time forget about those
> options. :) Is that complex? Difficult? I don't suppose it's more difficult
> than reading about the options of any given compiler.
>

I think the point is that in any language it's easy to do the things that
that language was designed to do and difficult otherwise.

Erlang was designed for (among other things) distributed programming -
thus distributed programming is easy.

     Pid ! Message

and

    receive
         Pattern1 ->
               Action1;
         ...
    end

Are sufficient to write distributed programs (and a small amount of setup)

This is ridiculously easy - I'm fighting with Objective C trying to do
the same thing - I need to
know about Grand Central Dispatch (GCD) and sockets and goodness knows what just
to send a message between two machines. So in Objective C it's "really
difficult to do easy stuff"
On the other hand in Objective C it appears to be really easy to make
a window throw in a few
buttons and get them to do things when you click on them (which is
really difficult to do in Erlang)

I accept that Erlang is not good at processing images and things like
that _ but it was never intended to be good at things like that ...

/Joe

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