Having been immersed in Smalltalk for a long time, something that I'm very conscious of when approaching other languages* is just how little reading of code tends to be involved, and what we do read often tends to be small fragments in books and articles.
(* Perhaps I should say, "other development systems" - it's not strictly a language issue - but I'm going to use the word language anyway.)
Smalltalk systems tend to give you a view of your own code as just being a small part of a much larger whole (including standard things like the collection classes, and any other libraries or frameworks you've loaded), and which you are to some extent expected to go explore and read the implementation. Most other languages give you more a clean-slate view, where your own code is the only thing presented to you, at least by default.
I forget who said it, but I've heard a remark along the lines that, "When I write PHP, I've got 3 or 4 web browser tabs open on the documentation. When I write Smalltalk, I've got 3 or 4 class browser windows open [on the implementation]", and this is my experience as well. I gradually learnt to write clear, concise and (hopefully) well organised code through osmosis by these means, and while it was a valuable experience for me, it also took a lot of time.
Having clear examples of small-scale idiomatic code (as in this book) might well be a big help in shortening the learning process.
Which just leaves the other end of the scale:
- How do we give good examples of code organisation in the large?
- How best can we integrate them in to some sort of learning path?
- How do we classify such examples according to the problem space they're well suited for? (Code organisation appropriate for a web framework may not be appropriate for an OS kernel, etc.)
Having been immersed in Smalltalk for a long time, something that I'm very conscious of when approaching other languages* is just how little reading of code tends to be involved, and what we do read often tends to be small fragments in books and articles.
(* Perhaps I should say, "other development systems" - it's not strictly a language issue - but I'm going to use the word language anyway.)
Smalltalk systems tend to give you a view of your own code as just being a small part of a much larger whole (including standard things like the collection classes, and any other libraries or frameworks you've loaded), and which you are to some extent expected to go explore and read the implementation. Most other languages give you more a clean-slate view, where your own code is the only thing presented to you, at least by default.
I forget who said it, but I've heard a remark along the lines that, "When I write PHP, I've got 3 or 4 web browser tabs open on the documentation. When I write Smalltalk, I've got 3 or 4 class browser windows open [on the implementation]", and this is my experience as well. I gradually learnt to write clear, concise and (hopefully) well organised code through osmosis by these means, and while it was a valuable experience for me, it also took a lot of time.
Having clear examples of small-scale idiomatic code (as in this book) might well be a big help in shortening the learning process.
Which just leaves the other end of the scale:
- How do we give good examples of code organisation in the large?
- How best can we integrate them in to some sort of learning path?
- How do we classify such examples according to the problem space they're well suited for? (Code organisation appropriate for a web framework may not be appropriate for an OS kernel, etc.)