I’ve been thinking something similar Rainer. When we came to the first exercise I felt being a bit more specific would have helped avoid some head-scratching because I wasn’t 100% sure what was required of me (something like “do this and this which should result in this” would have helped avoid any doubt, for me at least).
I am also beginning to wonder whether the book had a different target audience in mind to perhaps who the majority of its readers might actually be?
For instance the bit about division. I will be the first to admit that I have forgotten most of what I learned in school even though Maths was actually my strongest subject and I was often top of the class, now, I am lost without a calculator! Although what’s in the book is technically correct 5 rem 3. > 2 the example might have been better explained with 7 rem 2. > 1 (7 divided by 2 equals 3 with a remainder of 1). I know it’s just a small thing but this example and an additional sentence could have helped explain it fully avoiding the need to search for a recap (again, for me and others like me who need that recap). Not sure if anyone else would agree mind - maybe everyone else reading it is little bit more academic than me
At the time I read your post I was actually re-reading the bit on funs, and I wondered, what led to the decision to use What and X for the variable names given we’re talking about items and quantities:
total([{What, N}|T]) -> shop:cost(What * N + total(T));
Again, for those who need things spelling out for them (like me!) maybe this would make things a little easier?
I know it seems like a tiny detail, but it just made me wonder, are the examples in the book intended to look familiar to people with a mathematics background? Were they the intended target? Or was it just Joe’s way of wanting us to think more in those terms …or just the way he happens to think himself?
Still none of this is detracting from how much I love the book
Sometimes I had the same feeling
I thought that’s just a thing that functional programmers do differently (more math-like) than oop programmers (which I am in my job). But just needed to read it twice and then I was ok with it.
I did the second exercise of chapter 5 now, 2 different versions:
I’m up to List Comprehensions so still quite a while behind you. I wanted to re-read part of the chapter but hopefully I’ll be able to catch up a bit tonight. Nice to see you are still flying thro it
Another maths orientated thing I spotted (and what left me scratching my head) is on page 54, where we encounter lists:filter(P,L)“which returns a new list of all the elements E in L such that P(E) is true”.
E is easy enough to figure out (elements) as is L (list) but what’s P stand for? Felt like I was missing something
On the quicksort example (which is as far as I’ve got atm) I was hoping to be walked through each step of the recursion too, just for that extra bit of reinforcement and clarification of what is going on exactly.
This did get me wondering whether it might be worth reading another Erlang book alongside this book - what’s better than someone teaching you something? Two people teaching you the same thing!
Filters are either predicates (functions that return true or false) or boolean expressions
I don’t think I’ve heard functions that return true or false being described as predicates before, at least not explicitly like this. (Would have been cool if this was mentioned nearer page 54 )
I usually find books are split into separate parts, which helps make it easy to match similar books together. So we could start Learn You Some Erlang for Great Good! (No Starch Press) (Paid/Free) at the end of part 2? (So after chapter 10)… or we can see how it goes for now? If things start getting hairy we could always start it sooner or if we find it’s not needed, hold off
That’s good to hear Rainer! It’ll give me chance to catch up
I’ll proceed with only reading this book at the moment, as long as I don’t get into bigger troubles
I shouldn’t start more things, already have too many spawned processes
Finished reading chapter 6, nothing exceptional here (ok, bad joke, it’s about exceptions).
Error handling isn’t the most exciting topic for me, but I like Erlangs ‘fail fast’ & ‘let it crash’ strategy.
Do we have a homeoffice thread? Or so far just the standing desk thread?
Haha, cool, I’ll stick with it too for now then - tho I haven’t had much time for it. Hope to catch up soon tho! Wel done on getting through chapter 6!!
Whoo hoo welcome to the club DG I am sure you will catch up to me pretty soon as this time of year is always hectic for me.
Unfortunately I haven’t had much time to get further into the book (sorry @Rainer!) but I keep meaning to post a thread about visualising recursions - I’ll try to do that soon and mention it in this thread How you getting on @Rainer - bet you’re way ahead now
I skipped exercise 6.2 as it’s not so interesting for me at the moment, and continued reading.
I’m now in middle of chapter 7, and it’s exciting
It’s about binaries and how we can pattern match on single bits, that’s cool stuff. Especially if I think how I’d do it in C++ and what amount of awkward code I’d produce…
On a side note: In one example the notation 16#12345678 is used, which I seem to have missed (or already forgotten again) in chapter 3. It means this is Base16 notation, which is HEX. Another example: 2#11 is binary and evaluates to the integer 3.
I’m so sorry for not being able to read anymore Rainer! This time of year is always a bit hectic for me, hopefully I’ll be able to get back to it soon Hopefully it’s given some time for @DevotionGeo to catch up as well
What do you think of the book so far? Dynamic code loading - I can’t wait to get to that!
My time is also very limited at the moment, but usually I’m reading a bit just before sleeping
I like the book, but the more I progress the more annoyed I get by C# (my daily business) I’m liking the Erlang syntax, which came unexpected
I continued with the exercises, so here’s the second (of three) part from 8.2:
I really wonder how someone experienced wold solve this. I used the process dictionary that was introduced in chapter 8 as a mutable data structure, but I think this can’t be considered ‘good practice’…