macOS Swift Programming Topics

[ArtOfWarfare]

I've mentioned a few times now that I'd like to write a book on Swift. The target audience is anyone learning Swift, whether they already know how to program already or not, and whether they're learning because they'd like to go onto making iOS apps or OS X apps.

I've read Apple's The Swift Programming Language cover to cover, and I've gone back over some great books on learning other programming languages, including Learn C The Hard Way, Learn Python the Hard Way, How to Design Programs (a book on Lisp/Scheme/Racket), and Obj-C Programming, from Big Nerd Ranch.

I've also spent several hours playing with Swift in Xcode 6's playground.

So, I've been thinking about how I should organize topics within the book, and I've come up with this list of chapter subjects so far (anything after "For Completeness:" on a line is something that seems like you could easily get away with not knowing, but I include them just for the sake of covering everything about Swift):

00 - Setup and explaining the book
01 - Arithmetic and Comments
02 - For Completeness: Binary literals, hexadecimal literals, bitwise operators
03 - if-else
04 - Strings and String Interpolation
05 - let and Naming (note that you can easily cover the above topics without any lets or vars).
06 - Booleans, Logical Operators, and Ternaries
07 - Number Types, Type Annotation, and var (intentionally covered late, in the hope that learners get used to using constants and only use vars on things that actually need to be vars)
08 - Basic Switches and Cases, For Completeness: fall though, break, and if-else if-else (if-else if-else shouldn't be necessary with the improved Switches and Cases in Swift).
09 - For-In Loops with Ranges, break, continue, and labels.
10 - For Completeness: for-condition-increment loops, while loops, do-while loops, and semicolons (All unnecessary relics from past languages).
11 - Arrays
12 - Dictionaries
13 - Functions and Scope
14 - For Completeness: Custom Operators (Unnecessary, and probably a bad idea).
15 - Optionals and Tuples
16 - Closures
17 - Using Methods (as opposed to making them)
18 - Structures and Stored Properties
19 - Optional Chaining (not really possible to cover before properties)
20 - Computed Properties and Lazy Properties
21 - Property Observers
22 - Writing Methods, For Completeness: self
23 - Mutating Methods
24 - Type Properties and Methods (static)
25 - Subscripts
26 - Generics
27 - Extensions
28 - Enums and Advanced Switches and Cases
29 - Classes, Identity Checks, and Automatic Reference Counting
30 - Initializers and Deinitilaizers
31 - Inheritance, Subclassing, Override, and Final
32 - Type Casting and Checking

This is a major point in the book, where I stop covering just Swift the Language and its Standard Library, and actually bring in some Cocoa Touch:

33 - Protocols and UITableView
34 - Drawing
35 - Animation

Up until this point, everything could be covered in Playgrounds, but at this point I want to swap to making interactive applications for iOS and OS X.

I'm not sure how to organize the topics, or what I specifically need to cover, but I had the following in mind:

- Debugging in Xcode with breakpoints and by inspecting variables.
- Storyboards
- XIBs
- Git
- Unit Testing
- Core Data (?)

Any suggestions for other things that I need to cover... maybe suggestions for rearranging what I want to cover?

 

[dejo]

Sorry but I find it strange that you want to write a book on Swift, considering this recent post of yours:

I don't bother with books, and I find the very existence of books on programming to be ironic.

 

[Cromulent]

Sorry but I find it strange that you want to write a book on Swift, considering this recent post of yours:

I saw that as well and found it a rather odd statement.

The number of essential books in Computer Science is staggering and there just isn't the same level of technical detail available on the web unfortunately. The advantage of books is that they are at least somewhat peer reviewed and thus one can trust the content more than what is found on some random blog somewhere by some unknown individual.

 

[ArtOfWarfare]

Sorry but I find it strange that you want to write a book on Swift, considering this recent post of yours:

My gripe is with physical books. I have suggested both Learn C The Hard Way and Learn Python the Hard Way by Zed Shaw on a regular basis. When someone is just beginning, they need more guidance and structure than that offered by random blog posts here and there.

 

[Cromulent]

My gripe is with physical books. I have suggested both Learn C The Hard Way and Learn Python the Hard Way by Zed Shaw on a regular basis. When someone is just beginning, they need more guidance and structure than that offered by random blog posts here and there.

I've never understood the hatred for physical books. For one you can read them anywhere without having to worry about battery life (great if you commute to work or like reading in bed) and secondly you actually own them and are not restricted by draconian DRM schemes.

If I have a choice between a physical book and an ebook I get the physical book every time.

 

[ArtOfWarfare]

I've never understood the hatred for physical books. For one you can read them anywhere without having to worry about battery life (great if you commute to work or like reading in bed) and secondly you actually own them and are not restricted by draconian DRM schemes.

If I have a choice between a physical book and an ebook I get the physical book every time.

Can't grep dead wood.

Plus physical books tend to be more expensive than ebooks when it comes to programming. And Zed Shaw's ebooks are DRM free (not sure about Big Nerd Ranch's).

Does anyone have any actual feedback based on the content of my starting post? If somebody wanted a job as a Swift Developer for you or your team and they said they knew everything about that list of topics, would that be adequate or is there more you would want them to know? Is there anything major missing in my list? Does it seem I should break things down differently or pick a different order? Obviously it's just a Table of Contents right now, but I figured I should start with a big picture of where I wanted to start and end up before I start writing the actual chapters.

 

[glenthompson]

If you want to cover basic programming concepts, write it so it's optional so someone with experience doesn't have to wade through the same old stuff.

Good examples and exercises that actually run.

A glossary - find an old COBOL programmer and ask them to mark any word they don't know and define it in the glossary.

Something I like are explanations of why you write things certain ways. One of my pet peeves in documentation. I know what you did from the code, tell me why you did it.

----------

I've never understood the hatred for physical books. For one you can read them anywhere without having to worry about battery life (great if you commute to work or like reading in bed) and secondly you actually own them and are not restricted by draconian DRM schemes.

If I have a choice between a physical book and an ebook I get the physical book every time.

I don't want a commute that drains my iPad battery. It's also a lot lighter than most programming books. Most of my tech books are bought from O'Reilly which are DRM free. It's also easier for my wife and me to share an ebook than a physical book.

 

[MattInOz]

How will what you suggest be any different any less dry than say Apple's Swift eBook?

It's a bit hard to answer that based on a Laundry list of language features arranged into chapters. The best books seem to me to be for focused on "Cause and Effect" using examples introducing features as the so the reader gets a concept of how and when to use parts of the language to solve a problem.

I'd say avoid anything Xcode, Cocoa or CocoaTouch for a later book in the series. Aim the first book so it can be completed in Terminal and the REPL or in a series of playgrounds.

 

[ArtOfWarfare]

How will what you suggest be any different any less dry than say Apple's Swift eBook?

It's a bit hard to answer that based on a Laundry list of language features arranged into chapters. The best books seem to me to be for focused on "Cause and Effect" using examples introducing features as the so the reader gets a concept of how and when to use parts of the language to solve a problem.

I'd say avoid anything Xcode, Cocoa or CocoaTouch for a later book in the series. Aim the first book so it can be completed in Terminal and the REPL or in a series of playgrounds.

I'm keeping it in the playground as much as possible. The only real limit I've found with playgrounds is they don't allow for interaction.

I get your point about keeping it from being as dry as Apple's manual, and that you can't judge how dry it is particularly well from a list of topics.

I'm going to try and keep the chapters very compartamentalized, where skipping one chapter won't have an impact on future chapters too much.

 

[ikir]

I could be interested, i want to learn to code, i know the very basics but never coded anything. Now with swift i'm very tempted to try.

 

[Dranix]

Isn't a book on Swift a little to early? After all the language syntax isn't even finished, yet...

 

[Cromulent]

Does anyone have any actual feedback based on the content of my starting post? If somebody wanted a job as a Swift Developer for you or your team and they said they knew everything about that list of topics, would that be adequate or is there more you would want them to know? Is there anything major missing in my list? Does it seem I should break things down differently or pick a different order? Obviously it's just a Table of Contents right now, but I figured I should start with a big picture of where I wanted to start and end up before I start writing the actual chapters.

One thing I would say about your proposed book content is don't fall for the trap that thinking a longer book is somehow better.

One of the best programming language books ever written (probably the best in fact) is "The C Programming Language" by Kernigan and Richie. It is about 250 pages long (if memory serves) and teaches you absolutely everything that you need to program in C. I would say it is probably the only C book one MUST own (if you don't own it go and buy it now, seriously).

Try and keep it short and concise. Lots of flowery prose isn't going to explain programming concepts any better than a short description. This seems to be a new trend in programming and it annoys me no end when you end up with 1000+ page tomes that describe a programming language in agonisingly long winded fashion. I find it just comes across as treating the reader like an idiot. Keep it short and well written.

If you are hitting 500+ pages you should probably stop and ask what you can cut out of the text. Oh and don't do that annoying American habit of being "chatty and friendly" in your writing style. I'm reading the book to learn a technical subject not to waste my time reading jokes that may / may not be funny.

 

[Parkin Pig]

One thing I would say about your proposed book content is don't fall for the trap that thinking a longer book is somehow better.

Try and keep it short and concise. Lots of flowery prose isn't going to explain programming concepts any better than a short description. This seems to be a new trend in programming and it annoys me no end when you end up with 1000+ page tomes that describe a programming language in agonisingly long winded fashion. I find it just comes across as treating the reader like an idiot. Keep it short and well written.

I totally agree - the 'Dummies' books are particularly guilty of being padded out with personal anecdotes about the author, his family, friends, and the chap he met on the bus. When I go to the bookstore, I start with the thinner books on a particular subject and work my way up until I find what I want.

 

[MeFromHere]

I applaud your idea. My first impression is that this isn't a book. It's two or three different books. Narrow your scope. Pick one book, write it, get feedback. Then write the next book, if you're still in the mood.

These would be very different books:

1. "Swift for Brand-New Programmers"
2. "Swift for Objective-C Programmers"
3. "Swift for Experienced Programmers who are New to Cocoa/Cocoa Touch"
4. "Swift for Java/C++/etc./etc./etc. Programmers", or "Swift as a Second Language"

People reading these books will have different goals. Trying to cram it all into one book will aggravate many readers. And your aptitude as a writer may be better for one of these books than for the others.

I'm thinking of the tedious "Professional C++" by Solter and Kleper. It tries to be Everything for Everyone. I open it occasionally, but never with enthusiasm.

Is there a need for any of these books? Probably. I think you pay attention to Stack Overflow sometimes. You can see the level of confusion about Swift over there. I've seen questions that need each of the book titles I described above.

Book #1 (brand-new programmers) might be a good opportunity. Apple sort of neglects this group. (They have more developers than they can take care of already, and they don't seem to put effort into getting tons more newbies.) The online (non-Apple) courses seem to mostly be more advanced, probably because Objective-C is such an awful first language. I'm thinking in particular of the Stanford courses from the last few years.

Swift seems to be WAY more accessible for a beginner, so you might have some success with this book. I suggest NOT thinking about a list of language topics, but instead a group of progressive "projects" to organize the book. You probably need to discard half -- maybe two thirds -- of your topic list.

What would go in book #2? Maybe stuff that was too advanced for the beginner book, but is useful for writing some kinds of real apps? You'd still have to restrict the scope; there are many kind of apps and no single book should try to cover all the frameworks for every type of app. Plus you probably lack the expertise to cover many areas in enough depth. This book assumes the reader has quite a bit of experience with the frameworks. I expect Apple will be very active in this space, and the audience is mostly developers who have access to all of Apple's developer stuff. It might be hard for this book to gain much traction.

Maybe there's an interesting variant of book #2. Scott Meyers wrote an excellent series of "Effective C++" books. They focus, in great depth, on areas where semi-experienced programmers make lots of mistakes. (C++ is the sort of language where these books are desperately needed.) But this kind of book needs an author like Meyers with very deep knowledge -- knowledge that I doubt anyone outside of Apple will have for a while. Maybe there's a book for someone to write called "Effective Swift".

Book #3 seems like a book for people who want to write software for Apple platforms, but want to avoid the nastiness of Objective-C. You'd be using Swift to teach the frameworks and environment, mostly through example projects. You'd ignore Objective-C as much as possible. Swift will be an easy ramp-up for most experienced programmers, compared to Objective C. The audience for this book might be pretty limited for a while, but if Swift takes off the audience will be large eventually.

Book #4 would be rather different from #3 -- if Swift found use for non-Apple platforms. I'm recalling the excellent (but now ancient) "Ada as a Second Language" books by Norman Cohen. How do you drop experienced C/C++/COBOL/Pascal/Fortran programmers into Ada? You show them how things they did in the old language are done in the new one. You show them how hard things become easier (or sometimes the other way 'round). You use things they already know VERY WELL to teach them new stuff. This is a very effective way to reach a targeted audience.

But the space where Swift will find use is likely to be ONLY Apple platforms, at least for a while. So I think book #4 has pretty much the same audience as book #3. One emphasizes the language, the other emphasizes the frameworks and environment.

For any of these books, start by defining the projects/concepts you want to teach. Introduce a language feature ONLY when you need it for a project. (This is especially important for beginning programmers.) Constantly ask yourself "Can I leave this out?". Unless you want to make a better reference manual than Apple makes.

Random comments about your topic list...

01. Arithmetic is BORING. What's your target audience that wants to start a book with arithmetic? (Unless your first project is a calculator.)

02. This is Swift, not C. You need move this to chapter 47, or tie it to a project that needs it. Or forget about a book for beginners.

Chapter 13 seems like the end of the beginner book. Maybe a few bits from later would be needed, but none jump out of the list at me. Put a big dividing line somewhere around here. When you cross the line, you lose a big hunk of audience.

I like breaking up chapters 7, 8, 9, and 10. But the more advanced parts should probably appear much later, in chapter 20-something. Look for examples that work well without the advanced parts.

Chapter 14, custom operators, likely belongs in some sub-sub-basement of Hell. Put it right after the chapter on "How to write awful code in Swift".

Chapter 15. I'm having trouble seeing why Optionals shares a chapter with Tuples. I have NOT used anything like Tuples, and I suspect they are a lot more useful than old-fashioned programmers like me will discover on our own. I'm looking forward to some good, non-contrived examples of Tuples in action. This might even belong in the beginner book. (I've lost track of the times I've seen first-semester C students try to return a tuple from a function, not knowing that they don't exist. And the lovely comma operator in C makes them SEEM to exist: "return (x, y, z);" is perfectly valid, and 99.44% useless.)

My gut tells me chapter 26, Generics, belongs earlier. Close to the beginning of the non-beginner book. But I'm biased; I think code duplication is one of the Great Evils and I always want to stamp it out.

Maybe you left out a few chapters: "WTF is Procedural Programming". "WTF is Object-Oriented Programming". "WTF is Functional Programming". Most of your audience will be missing one or more of these. These themes might help you organize the topics.

You may have some readers who are very miffed by the strict type checking in Swift. And other readers will try to find the missing chapter about pointers. Things like this are just WEIRD for a lot of programmers. Can you make it less weird for them?

----------

One of the best programming language books ever written (probably the best in fact) is "The C Programming Language" by Kernigan and Richie. It is about 250 pages long (if memory serves) and teaches you absolutely everything that you need to program in C. I would say it is probably the only C book one MUST own (if you don't own it go and buy it now, seriously).

I'll be flamed for this, but I think K and R is one of the WORST language books ever written. It's terribly weak on "human factors" issues that trouble typical C programmers -- probably because K and R were so far above "typical" that they just didn't see the problems. It shows you how to do stuff, but not always how to do it well. I think that in practice it is a great book for teaching how to write bad C.

In their defense, they had no way of knowing how much bad C was going to be written with their creation.

 

[Cromulent]

I'll be flamed for this, but I think K and R is one of the WORST language books ever written. It's terribly weak on "human factors" issues that trouble typical C programmers -- probably because K and R were so far above "typical" that they just didn't see the problems. It shows you how to do stuff, but not always how to do it well. I think that in practice it is a great book for teaching how to write bad C.

In their defense, they had no way of knowing how much bad C was going to be written with their creation.

I guess we'll have to agree to disagree on that point. Most of the code examples (with a couple of small exceptions) tend to use best practices and since that is what you learn from your code will often follow the same practices used in the book.

The problem with C is that you can write an entire book dedicated to best practices since there are so many edge cases with the language. So when writing a book about the language you have to make a choice between concentrating on the language and doing it in the best way possible (as I believe "The C Programming Language" does) or getting bogged down on best practices.