It seems to me that there are two schools when it comes to deciding what type of examples should be included in a book. There is the "big application", which requires you to understand the requirements for an application which will be developed thoroughout the boook. And then there is the "Easy examples, please" school, which presents new features by using very simple examples.
Now, everyone has different opinions on this matter, but I am definitely with the "Easy examples" side. I dont want to understand the requirements for an application, I want to learn a language. These requirements are a distraction from the real goal.
And I think that you have been doing a great job until I started reading Chapter 9, which starts with " this chapter presents a simple algebra of two- dimensional layout elements". This is when I stopped trying to understand the examples in the chapter.
I think you should seriously consider rewrite the chapter with another example. I know, the code is not rocket science, it can be understood if you make an effort. But the thing is that I dont want to. I want to learn Scala, and I am not interested in "algebras of two dimensional layout elements".
In fact, there is an example which confirms my point of view. In page 178, you include the code for the besides method, the one which uses zip. Then you explain what zip does by using another example, a pretty easy to understand one. And the reason is that besides is not easy to understand.
I have similar feelings about the example in Chapter 11 (manipulating arithmetic expressions as examples of case classes and pattern matching). I see the phrase "arithmetic expressions" and switch off.
Well, the examples are tied to one another in several chapters ... I miss some 2D boxes diagrams for the visually deprived ... The utility of the chapter is not fully realized until much later, so something to make it more "attractive" would be good.
Actually I'm not so put off by these examples, I've had some education in Lisp and examples there were actually of the same type as the algorithmic and box layout examples. I think its more or less inherent to functional programming, but I agree that it remains a bit academic. It would be nice though if a few examples could be brought on to "real business" like use cases, possibly in combination with an orm tool like hibernate. Combinations of clusures and the hql/ejb-ql/jpa-ql will be very powerful, although you run big risk of chasing the topic starter away.
I agree with the school of thought of having simple examples. I have programming experience in a few languages, including Java, but I am not a guru. Seems I need to study some of the examples very hard to make sense out of them. It gives me a headache! :-( Just remember the KISS: => Keep It Simple Stupid Thanks!
Previous Topic
