[erlang-questions] Practical Erlang
pat eyler
blogging about another new Erlang book (from O'Reilly
this time), and one of the authors (Francesco Cesarini)
dropped by to add his confirmation to O'Reilly's.
... It is a fact. "Practical Erlang Programming" will
be published by O'Reilly. ...
Yay! I'll blog more as I have more info
http://on-erlang.blogspot.com/2008/02/not-just-rumour.html
--
thanks,
-pate
-------------------------
Duty makes us do things, Love make us do things well.
http://on-ruby.blogspot.com http://on-erlang.blogspot.com
http://on-soccer.blogspot.com
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Vat Raghavan
I hope it covers gen_server, gen_fsm, et.al. in good detail, that's the big thing that's missing from joe's book, and i don't understand.
--vat
----.signature----
Without the hope that things will get better, that our inheritors will know a world that is fuller and richer than our own,
life is pointless, and evolution is vastly overrated
-- Delenn
http://on-erlang.blogspot.com/2008/02/not-just-rumour.html
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Francesco Cesarini
There will be a chapter on behaviors, but unfortunately, not with the
level of detail you are asking for. Our main goal is to cover Erlang in
depth. Make sure that newbies struggling with recursion can easily
understand it or developers being exposed to pattern matching for the
first time use it optimally. The contents of the book are pretty much
outlined by the introductory Erlang courses Jan-Henry and I have been
giving in the last decade, and based on the knowledge and experience
gained when teaching. We know which students struggle where, and try to
address it in the book. We plan to cover less than Joe, but more in
depth. In these lines, we are very interested in hearing what others
feel we should include in such a book.
We have lots of ideas on OTP, but that in itself is a completely
different beast we hope to tackle as soon as this book is out. So hope
you have a bit of patience and bear with us....
Regards,
Francesco
PS. The correct title is "Practical Erlang Programming"
--
http://www.erlang-consulting.com
Vat Raghavan wrote:
> that is great news and i'm really excited to hear it!
> I hope it covers gen_server, gen_fsm, et.al. in good detail, that's the big thing that's missing from joe's book, and i don't understand.
>
> --vat
>
> ----.signature----
> Without the hope that things will get better, that our inheritors will know a world that is fuller and richer than our own,
> life is pointless, and evolution is vastly overrated
> -- Delenn
>
>
> ----- Original Message ----
> From: pat eyler <pat....@gmail.com>
> To: Erlang <erlang-q...@erlang.org>
> Sent: Wednesday, February 20, 2008 12:50:09 PM
> Subject: [erlang-questions] Practical Erlang
>
> It's nice to get worf from the horses mouth. I've been
> blogging about another new Erlang book (from O'Reilly
> this time), and one of the authors (Francesco Cesarini)
> dropped by to add his confirmation to O'Reilly's.
>
> ... It is a fact. "Practical Erlang Programming" will
> be published by O'Reilly. ...
>
> Yay! I'll blog more as I have more info
>
> http://on-erlang.blogspot.com/2008/02/not-just-rumour.html
>
>
_______________________________________________
Brian Cully
> In these lines, we are very interested in hearing what others
> feel we should include in such a book.
>
> We have lots of ideas on OTP, but that in itself is a completely
> different beast we hope to tackle as soon as this book is out. So hope
> you have a bit of patience and bear with us....
Unfortunately, what I would really like is something akin to an OTP
Illustrated. OTP is by far the hardest thing I have to wrap my head
around. Proper use of supervisor tree, best practices on function
placement, common idioms, etc.,.
A lot of the other stuff you can pick up pretty quickly from the man
pages an existing sources, but for some reason I have a hard time
getting very far into OTP.
My biggest problems all tend to revolve around optimal use of those
libraries and understanding the culture they promulgated.
-bjc
t ty
t
David Mercer
programming languages, Erlang itself is just another language. What sets it
apart is the OTP libraries that have been built to create reliable,
fault-tolerant, scalable systems. Another book on just the Erlang
programming language would not find a place on my bookshelf.
DBM
Benjamin Tolputt
> Unfortunately, what I would really like is something akin to an OTP
> Illustrated. OTP is by far the hardest thing I have to wrap my head
> around. Proper use of supervisor tree, best practices on function
> placement, common idioms, etc.,.
>
This is something I agree is an issue for people (such as Biran &
myself) getting into Erlang. I understand the appeal of a book
describing the basics of a language. For the author, it has a much
broader market (i.e. all those who don't know the language), and for the
beginner it doesn't make assumptions on their knowledge of the language.
The problem with these books is that they only take you so far. Most
decent developers I have worked with can pick up a language in a
style/genre they are familiar with within a few days (i.e. a C++
programmer can pick up the syntax/semantics of Java pretty damn quick, a
Lisp programmer tends to pick up Erlang syntax/semantics in around the
same time). The issue isn't the language, but the best use of the
language library building blocks (or even knowing of their existence).
Let's take Java as an example. Sure, there are a literal tonne of books
on the syntax/semantics of Java. However, there is around the same
amount of books describing various libraries/frameworks one can use with
Java. Erlang currently already has a good book on the syntax/semantics -
Joe's Programming Erlang. I don't need another one of those on my shelf.
What I need is a book that shows me how to get the most out of the
Erlang library building blocks - namely OTP.
Regards,
B.J.Tolputt
Benjamin Tolputt
> Erlang currently already has a good book on the syntax/semantics -
> Joe's Programming Erlang. I don't need another one of those on my shelf.
I should note that the above has nothing to do with what I think
upcoming book will be in terms of quality. It may be much better than
Joe's (though I can't tell that until it comes out). It's just that, no
matter how good it is, with Joe's book already out there - it's not
going to be a must read for me.
Sorry, I realised the quoted comment could be taken the wrong way when I
read it coming back in to the inbox from the mailing list.
Dave Bryson
> I don't need another one of those on my shelf.
> What I need is a book that shows me how to get the most out of the
> Erlang library building blocks - namely OTP.
I agree. This is exactly the kind of book I'm looking for - one that
goes deeper into OTP, and Concurrent programming.
With the material available on the Erlang site and the definitive
guide from Joe Armstrong I don't need another basic book.
Dave
Jan Henry Nystrom
> On Feb 21, 2008, at 5:41 PM, Benjamin Tolputt wrote:
>> I don't need another one of those on my shelf.
>> What I need is a book that shows me how to get the most out of the
>> Erlang library building blocks - namely OTP.
>
> I agree. This is exactly the kind of book I'm looking for - one that
> goes deeper into OTP, and Concurrent programming.
>
> With the material available on the Erlang site and the definitive
> guide from Joe Armstrong I don't need another basic book.
We have to take on thing at the time. If we were to cater to everyones
demands in this one book it would be too heavy to get of the bookshelf,
let alone read comfortably. We are very aware of the different needs
for books, but we believe that this one is needed and that it will
help to pave the way for a OTP-book, and more others to follow.
/Cheers Henry (co-author of Practical Erlang Programming)
>
> Dave
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
--
Jan Henry Nystrom <j...@erlang-consulting.com>
Training Manager @ Erlang Training and Consulting Ltd
http://www.erlang-consulting.com
Thomas Lindgren
--- Brian Cully <bcu...@gmail.com> wrote:
> Unfortunately, what I would really like is
> something akin to an OTP
> Illustrated. OTP is by far the hardest thing I have
> to wrap my head
> around. Proper use of supervisor tree, best
> practices on function
> placement, common idioms, etc.,.
Isn't Joel Reymont writing a book on more advanced
topics? That might be what you're looking for, once it
turns up.
I guess the choice of audience is because O'Reilly
(ironically enough, given that they turned down Joe's
previous book proposal) want/need to sell to Erlang
beginners, rather than to those who level up from
Joe's PragProg book.
Best,
Thomas
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
Francesco Cesarini
in line with the comments, which are much appreciated, these are my
thoughts.
When I walk into a book store, I do not want to see one or two Erlang
books, I want to see a whole section dedicated to them. Many books on
basic Erlang, Industrial SW design, Mnesia, OTP, drivers, Concurrent
Programming, Erlang web applications, Erlang and IM, handbooks,
cookbooks, and more.
We are not aiming at a book which is of better quality than Joe's, nor
as a book to replace Joe's. That comment stood out, and I hope I am
taking it out of context. Those who have met Joe will know his book is a
reflection of his character and enthusiasm. We see ours as a complement
for those who want to read more about Erlang in depth.
We are very interested in writing a book on OTP. We have the material
and the examples which we know work. But we want to do it in the right
order by first writing a book on Erlang. As none of us has ever written
a book, starting with Erlang makes sense. From there, we will be better
prepared to tackle OTP. As everyone says, OTP is much harder to learn
than Erlang. I can add that the same applies to teaching and explaining
it. I am sure this can be extended to writing about it.
Our hope is not to preach to the converted and sell books to everyone
who already is on this mailing list. We are instead hoping on giving a
helping hand in doubling the users on this list, thus creating a larger
market for an OTP book. This will hopefully result in a proposal
O'Reilly deems as interesting, for which there is not only a need for,
but also a market. We will certainly be referencing these emails when we
submit it. In the meantime, I encourage others to start writing even
more books on the subject, including OTP. From what I know, there are
quite a few in the pipeline, but not enough to motivate a whole section
at Barnes & Noble or Waterstone's.
As mentioned previously if you have any feedback on what you might want
to see in a basic Erlang book, we are very interested in hearing it.
Regards,
Francesco
--
http://www.erlang-consulting.com
t ty
fess
From: http://dukesoferl.blogspot.com/ [ http://
dukesoferl.blogspot.com/2008/02/so-guys-erlang-consulting-and-
training.html ]
> I applaud Francesco, and Jan-Henry in getting another book out there.
> Obviously they have learned from their history areas where new
> comers to
> erlang have troubles, and they're making a book to plug that hole.
> They are of course asking you to look back on your experience
> coming into erlang, think about what concepts you had troubles with
> and let them know
Here are some dumb hicups I encountered on my way into erlang:
How to debug.
Somehow I glossed over in joes book the bit pointing out
that [ $m,$a,$t,$c,$h | Tail ] is the same as [ "match" | Tail ]
which is so much nicer.
Why are people always reversing lists, and why don't they just append
with, List ++ [Item]
Why io:lists are cool, why deep lists are cool, flatten later.
Uh, ways of handling strings, since the one "way" is so debatable.
how to debug the oh so clear error messages that come back from things.
the earlier you get what "bad match" vs function clause is, the better,
as well as the other standard tuples that once you learn to read
you forget how horribly frustrating they were to begin with so you
forget to teach the newbs about it.
the concepts of failing and relying on those oh so clear error messages,
how best to clear those error messages up.
the concepts of failing early and restarting, [ which you don't want
to do until you get used to knowing where something broke reading
those error tuples. ]
How incredibly useful guards are, [ and use dialyzer ]
handy guard tricks to make your guards better.
-define(is_string(String), begin is_list(String), is_integer(hd
(String)) end )
-define(is_deeplist(List), begin is_list(List), is_list(hd(List)) end )
what's the deal with andalso orelse vs commas and semicolons.
I hope those help, those are at least some newbie topics which I can
remember having little moments of realization about.
And of course shortly after all that newbie stuff, I want more in
depth info on OTP,
we did a lot of digging into code to figure out what was going on
with code_change,
and even then who knows if our concepts are correct, So I agree
with the angst
that anyone doing a next book, please do that. even a next wiki page,
more more more. thanks.
--fess
Kostis Sagonas
>
> Here are some dumb hicups I encountered on my way into erlang:
>
> that [ $m,$a,$t,$c,$h | Tail ] is the same as [ "match" | Tail ]
> which is so much nicer.
It's actually good that you missed this in Joe's book because it is not
the same...
Instead, [ $m,$a,$t,$c,$h | Tail ] is the same as "match" ++ Tail
This is exactly the problem in people getting so much used in IO lists:
they end up thinking that flattened vs. unflattened lists are the same.
They are not.
Cheers,
Kostis
fess
On Feb 22, 2008, at 12:02 PM, Kostis Sagonas wrote:
> fess wrote:
>> that [ $m,$a,$t,$c,$h | Tail ] is the same as [ "match" | Tail ]
>> which is so much nicer.
>
> It's actually good that you missed this in Joe's book because it is
> not the same...
>
> Instead, [ $m,$a,$t,$c,$h | Tail ] is the same as "match" ++ Tail
haha, I can't believe I wrote that that way, thanks for the
correction,
that's what I meant.
Yes, I have made deeplists when I didn't want to. that's another
gotcha.
--fess
Joel Reymont
>
> Unfortunately Joel has decided to drop the project.
>
> http://twitter.com/wagerlabs/statuses/659726302
I want to point out that did not drop the project. I dropped the book but
I'm posting the "book" to my blog. Take a look at the Introduction to the
Erlang FFI and Parsing Binaries with Erlang, for example.
Posting hardcore stuff to the blog allows me much more freedom
and the revenue from consulting projects that come as a result
far outweighs any possible book revenues.
Thanks, Joel
Francesco Cesarini
> Posting hardcore stuff to the blog allows me much more freedom
> and the revenue from consulting projects that come as a result
> far outweighs any possible book revenues.
>
for the fun and experience of doing it while knowing it will help spread
Erlang to new users (When choosing a publisher, unrivaled dissemination
and distribution channels is the reason we decided to go for O'Reilly).
I hope Joel will some day collect all the articles from his blog into a
book.
Francesco
--
http://www.erlang-consulting.com
t ty
t
Mickaël Rémond
Posting hardcore stuff to the blog allows me much more freedomand the revenue from consulting projects that come as a resultfar outweighs any possible book revenues.I can second that. One does not write an Erlang book for the money, but
for the fun and experience of doing it while knowing it will help spread
Erlang to new users (When choosing a publisher, unrivaled dissemination
and distribution channels is the reason we decided to go for O'Reilly).
I hope Joel will some day collect all the articles from his blog into a
book.