[erlang-questions] Onboarding programmers who are new to Erlang

[Leonard Boyce]

Thanks to all of you you provided feedback on this thread. There are
definitely some good suggestions.

One thing I did would like to point out is something referenced by
Daniel who pointed me to this link:
http://www.erlang.org/course/course.html
This *really* needs to be both edited and updated. It uses "built-in"
functions such as list(), integer() which do not seem to exist in
erlang, and it's full of obvious errors.
It does not really a great light on Erlang when the 'official'
examples would not work for someone just working their way through the
'4 - Day Course'

Example 1: Pattern Matching
http://www.erlang.org/course/sequential_programming.html#patterns

A = 10
Succeeds - binds A to 10

{B, C, D} = {10, foo, bar}
Succeeds - binds B to 10, C to foo and D
to bar

{A, A, B} = {abc, abc, foo}
Succeeds - binds A to abc, B to foo

{A, A, B} = {abc, def, 123}
Fails
[A,B,C] = [1,2,3]
Succeeds - binds A to 1, B to 2, C to 3
[A,B,C,D] = [1,2,3]
Fails

Example 2: Examples of Guards
http://www.erlang.org/course/sequential_programming.html#guardexample
number(X) - X is a number
integer(X) - X is an integer
float(X) - X is a float
atom(X) - X is an atom
tuple(X) - X is a tuple
list(X) - X is a list

Is there anywhere we can submit pull requests for editorial of the website?

Leonard

On Thu, Aug 28, 2014 at 9:48 PM, zxq9 <zxq9@REDACTED> wrote:
> On 2014年8月29日 金曜日 09:25:54 Leo Liu wrote:
>> On 2014-08-29 09:07 +0900, zxq9 wrote:
>> > After those bits of SICP, showing them the JSON parser example in Real
>> > World Haskell is a big winner. That single example and its commentary
>> > gives precisely the sort of background necessary to understand Joe's
>> > discussions in Programming Erlang.
>>
>> I am curious if any bits in Joe's book that are particularly
>> challenging. I don't want to miss anything important Joe has written.
>
> I don't think anything in Programming Erlang is hard, actually. But
> interpreting the discussions is difficult for someone who has never thought
> through the related issues, worked their own way around certain issues in
> another environment, or dealt with different programming environments.
>
> Joe talks about tradeoffs in many places, but not often at length. The
> commentary is very important to understanding why things are the way they are
> and what alternatives could have been chosen instead, but if you've never
> explored any of the alternatives you don't have the personal history to relate
> to the discussion at all. In that case all those brief, often insightful
> comments just flit by under the uncomprehending eye, contributing nothing to
> the learner's experience. I think about half the value of books like Joe's lie
> outside the scope of cut-and-dried Erlang/OTP knowledge. If we didn't care
> about that other half we would just read the Erlang docs directly from our
> first day with the language.
>
> Getting one's mind prepped by seeing two radically different (but still
> functional) environments in SICP and Real World Haskell (in addition to
> whatever imperative background the new guy has) is useful before reading Joe's
> book, IMO. Actually, I think re-reading SICP is even more interesting after
> reading PE and writing a bit of Erlang and C for a while.
>
> In the same vein, I also encourage my folks to play around with assembler and
> follow the "Programming from the Ground Up" examples, because it makes the
> computer a lot less mysterious, things Knuth says more comprehensible, C make
> a lot more sense, and full-blown environments like OTP really strike home in
> the sense that "I can now just focus on the problem my customer faces --
> that's amazing!" Without all that background I just don't see coders make
> intelligent tooling choices and often they do silly things like fixating on a
> specific language or runtime or whatever.
>
> Anyway, this is my perspective. I have customers with actual problems --
> things of value moving around, things they can't forget about, people they
> need to communicate with, etc -- I have no space for monolingual coders who
> know only one tool and are incapable of forming their own opinions about new
> tools/environments/situations. To do that, though, they really need a
> background more broad than a single book or language lest the lessons Joe has
> put down that go beyond Erlang syntax and address Erlang's nature be missed.
>
> -Craig
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions