Learn You Some Erlang: Three new chapters available(learnyousomeerlang.com)

44 pointsby bandris17 lat temu21 comments

Learn You Some Erlang: Three new chapters available

http://learnyousomeerlang.com/modules

4 comments

thejay17 lat temu

Great for those of us who are still learning erlang.

On this token does anyone have any tutorial that actually goes through building a complete erlang program and not snippets of code here and there?

mr_dbr17 lat temu

http://www.stifflog.com/2007/05/09/erlang-for-the-practical-...

Not the best tutorial ever, but I found it helpful.. It describes a fairly simple, but non-trivial task (creating an RSS feed from your email inbox, generating the RSS feed, and directly interacting with the POP3 protocol over SSL)

Also, most of the code will require slight modification to work with the most recent version of Erlang. This seems like a bad thing, but it forces you to actually understand the code and determine what broke, rather than just copy-and-pasting everything.. For example, the regexp module had changed name, so I prodded around the erlang library code to see where it went, and if the arguments had changed - in doing so I realised how simple (most of) the code was, something I wouldn't have done if the tutorial was "better"..

thejay17 lat temu

Great link, thanks! Not the biggest complete-app example but certainly shows me how things could/should stick together.

cosmohh17 lat temu

there is a getting started tutorial here: http://erlang.org/download/getting_started-5.4.pdf

morbidkk17 lat temu

even am a noob here. But this is good resource http://www.erlang.org/course/course.html.

mononcqc17 lat temu

Hey, I hope you guys enjoy these chapters as much as you enjoyed the first ones (the reviews were pretty good!)

I'm still accepting criticism and fixes if you see any mistake or whatever. Have a nice read :)

gtani17 lat temu

You did a really nice job. The language needed a gentle intro.

Cesarini/Thompson book is excellent, aside from typo's but it's like drinking from a firehose. Good for people who like ruby, python, scheme DSL / metaprogramming tricks, challenging for everybody else.

One thing, can you give more vertical space between lines in source code listings (the bits in Courier font; also listing of shell/interpreter sessions). They're jammed tightly together in Firefox 3.0.14, winXP SP 3.

systems17 lat temu

The syntax is bit radical, I spent like 10 minutes online before getting why

    1> 1+1

returns nothing, its because its missing a . (i.e. a dot) it should be

    1> 1+1 .
    2

which returns 2 as expected

mononcqc17 lat temu

If you go back to http://learnyousomeerlang.com/starting-out-for-real :

In the Erlang shell, expressions have to be terminated with a period followed by whitespace (line break, a space etc.)

Maybe I should try to make it even more apparent (or add a picture). I can remember being stumped by the same thing when I first got to try the shell.

gtani17 lat temu

one of the trickiest things i found about basic erlang syntax was difference between "," and "and" and "andalso" as guard clause separators.

mononcqc17 lat temu

You'll be glad to know I explain the differences in the Syntax in function chapter of the book. http://learnyousomeerlang.com/syntax-in-functions#guards-gua...

Scroll down to the 'note' to see it. I don't explain 'and' vs 'andalso' though, but they are mentioned in an earlier chapter: 'and' will evaluate both its arguments, but 'andalso' will only do so when needed.

I still don't understand why Erlang doesn't allow the nesting of "," and ";" (which would make 'andalso' and 'orelse' useless in guards). There seems to be no plan to change that, even if big names [in the community] like Richard O'Keefe would like the same thing.

gtani17 lat temu

reading this thread a few times helped

http://www.nabble.com/Reading%2C-Learning%2C-Confused-to1854...

mononcqc17 lat temu

Yeah, it's where I got the difference too. I decided to add it to LYSE after that.

gtani17 lat temu

one other thing i noted:

(Modules page just above "More about modules") you talk about compiling to Hipe, but it doesn't say that you ahve to ./configure it in. This seems to be a common configure:

./configure --enable-hipe --enable-smp-support --enable-threads

silentbicycle17 lat temu

This (and several other syntactic / stylistic quirks) made vastly more sense after I learned Prolog, FWIW. Erlang was originally implemented in Prolog, by someone who wanted to make a variant of Prolog with better support for concurrency, so it's not surprising that Erlang inherited several of its surface details.

As introductions go, _The Art of Prolog_ is also a great book (like SICP great), and spends a lot of time on the logic programming paradigm and its big ideas rather than Prolog-specific details. _Clause and Effect_ by Clocksin is a _The Little Schemer_-like intro, though its style is a little more conventional.

mahmud17 lat temu

It kept that from Prolog. Which is also responsible for atoms needing to begin with a lowercase letter if they're not quoted, and variables with an uppercase.

davidw17 lat temu

The description I read for it is "ant turd tokens". Erlang is cool and quite powerful, but realizing you put a , where you needed a . can be frustrating, especially when cutting and pasting code around.

jerf17 lat temu

Don't forget semicolon, when neither a period nor a comma is enough, so you just decide to put both in. And also the places where you must not have any of them, or else, even if it looks like it might be good.

The biggest (IMHO) justifiable complaint against Python's indentation-sensitive syntax is that it makes copying and pasting harder (in editors that don't support it or with people who don't know the indentation commands...), but I've had more luck copying-and-pasting Python (with no adjustment) than I have Erlang. With Python you have good odds that you're on the same indentation in both source and dest, with Erlang the odds that you're going to screw up ",;. " (and note the space in that quote on the end, it's part of the set) approach 100% in my experience.

Nice language in many ways... shame about the syntax.

mononcqc17 lat temu

I've always found the rules quite simple, once you think of everything as expressions (and not lines):

"." ends an expression in the shell.

In modules, "." ends forms. Forms are module attributes and function declarations. Forms are technically not expressions as they don't return anything. This is why they are terminated in a different manner than the rest. Given forms =/= expressions, It could be argued that the shell's use of "." is what's not standard here.

"," separates expressions:

  C = A+B, D = A+C

Note that 'if ... end', 'case ... of ... end', 'begin ... end', 'fun() ... end' and 'try ... catch ... end' are all considered expressions as they return a single value. As an example, it's possible to do

  Var = case ... of ... end

to get a single value out of it. As such, you might see conditional expressions followed by ",".

";" Has two roles: separating different function clauses:

  fac(0) -> 1;
  fac(N) -> N * fac(N-1).

And separating different branches of expressions like 'if ... end', 'case ... of ... end' etc.:

  if X < 0   -> neg;
     X > 0   -> pos;
     X == 0  -> zero
  end

It's probably the most confusing one because the last branch doesn't need to have the ";" following it: it separates them, not ends them. As such, you might encounter code written the following way, which is arguably more readable:

  if X < 0   -> neg
   ; X > 0   -> pos
   ; X == 0  -> zero
  end

This makes things a bit more explicit. Because function clauses contain expressions, you might see a 'case' construct followed by ";", too (and similarly for nested constructs like the aforementioned 'try ... catch ... end' and others).

So as you can see, "." is for Forms, and ",;" are for separating language constructs/expressions. This is why You can see an if expression's 'end' done the three following ways: 'end.', 'end,' and 'end;'. Depending on where the expression is, it will be followed by different stuff.

You need to see it more like a template you can fill in than "here, let me put an end to this line!":

  head1(Args) [Guard] ->
      Expression1,Exp2,...,ExpN;
  head2(Args) [Guard] ->
      Expression1,Exp2,...,ExpN;
  headN(Args) [Guard] ->
      Expression1,Exp2,...,ExpN.

I don't see the rules as complex; they make sense, but you need to get used to them. If you think about it, things like 'for(int i = 0; i >= x; i++){ ... }' (or even 'for(...);') have a weird syntax when compared to most other constructs in languages supporting them. We're just so used to them we don't mind them anymore.

jerf17 lat temu

It's actually not the strangeness that throws me any more; I've programmed in Erlang enough that I'm not spending much time thinking about it anymore. (I am that rare bird: Someone what has actually programmed Erlang professionally. :) ) But the copying and pasting bothers me.

Also, to put it in a C context, when you do:

    if (condition) 
       thing();
    else
       other_thing();

you frequently want to put debugging code in the "thing()" clause, and so eventually many people (including me) adopt a style of always using the braces, after getting bitten a few time. Erlang basically mandates the lack of braces, so I'm always getting annoyed by adding a statement here or there, or twiddling a function definition. It's a constant low-level annoyance that never stops me from using it for what it is good for (because it is oh-so-good at it), but it doesn't have to be there.

davidw17 lat temu

They make sense once you get them, sure, but I still think that ';' or 'end' or {} are a lot easier.

[deleted]17 lat temu