Alan Kay did not invent OOP

I could have sworn I already had an article here.

There’s  story that’s occasionally pulled up from the ditches about some demo of technology that was supposed to be object-oriented, and some guy raises his hand and says “That’s not object oriented!”

“Well what would you know about object oriented?” the demonstrater replies

“I invented the term.” the interluder protests.

And scene.

This may have happened at Xerox PARC some years ago. And the guy who claimed to have invented the term probably was Alan Kay. But just because Alan Kay says he invented object oriented programming, that doesn’t actually mean he did.

First, let’s look at the common sense argument. The dominant languages that are classified as object oriented today are some static languages like C++, C#, and Java, as well as dynamic ones like Python and Ruby.

Alan Kay is also known for having said: “I invented OOP and C++ was not what I had in mind”. Well, if an inventor is saying he created X, and the most popular version of X is C++, and he’s saying C++ isn’t X… one of two things may be true:

• We’ve somehow come very far from the inventor’s original vision (which I believe Mr. Kay is implying here)
• Or the guy claiming to have invented X didn’t actually invent X

C++, in particular, is a good example in this common sense argument. It takes its roots from a very old language, Simula, which Wikipedia claims to the first object-oriented language.

To sum up the story so far, one of Alan Kay’s targets here – C++ – that he’s argued is not really object oriented, apparently derives quite closely from the first object-oriented language. Huh. So if C++ isn’t object oriented, neither was Simula?

That leads us into the second, historical argument. Of course, that’s weird, because Simula was one of Alan Kay’s own inspirations for Smalltalk, the language that never really took off that he bet his hat on and is now so cranky no one uses.

So there’s basically two different interpretations of what an object-oriented language is – one that includes C++, Simula and Smalltalk, and one that only includes Smalltalk. And of course, the guy who writes mostly in Smalltalk is quite happy to keep telling you he invented OOP and thus should be listened to.

Let’s talk about one final argument here – what if Alan Kay was merely saying he coined the term ‘object oriented’? So in this interpretation, Alan Kay isn’t going around trying to convince everyone he’s a genius and invented OOP and why don’t we all use Smalltalk, but rather, he merely coined a clever phrase to help other people.

Well, this runs afoul of the common sense argument again – what’s the use of coining a term if no one actually uses it that way. If most people think of C++, Java, and Smalltalk when they think of OOP, then you claiming you coined the term to only mean Smalltalk again runs afoul of two conclusions:

• It either doesn’t matter what you said because most people have used a substituted definition anyway
• Or you’re lying

In fact, doesn’t it all beg the question? If Alan Kay meant Object Oriented to mean Smalltalk, yet everyone else thinks it means C++ as well… well, who’s going around and spreading that ugly rumor?

In this world that Alan Kay is trying to present to us, he cleverly defines a term, then goes out to tell everyone what great work he’s done. And scoundrels like the people who designed C++ and Java try to ride his success. What ungrateful wretched tricksters, convincing us all that Object Orientation may not mean what Alan Kay is so sure it means!

And somehow, they were all so successful in convincing us that Object Orientation was something Alan Kay says it’s not, and Alan Kay was so unsuccessful, that that is why today we’re all confused.

That may be how things have happened. But let’s see what’s more likely – is it more likely that tricksters emerged to try and get their own languages adopted by hopping on the OO bandwagon “in name only”, meanwhile the one true and good language Smalltalk languishes… Or, is it more likely that OO was tied at the time more to what the inventors of C++ and Java claim it was tied to: Simula.

What we’re asking here is what a word meant in the 80’s, and while Alan Kay has made quite a fuss in the late 90’s and 00’s about what he meant then, he didn’t seem to be making much of a fuss in the 80’s when C++ and Java were being written up.

So let’s look at this version of events – here we have a whole bunch of languages being inspired by Simula: Smalltalk, Java, C++ and others. They all adopt a very similar view of the term ‘object oriented’ in that they have classes, objects, inheritance and the like. So far, so good.

Then some guy, Alan Kay, starts getting cranky that Smalltalk isn’t getting adopted and so starts trying to use what fame he had from Xerox to rewrite history.

Frankly, I believe the latter if only because it requires fewer tricksters. The first version of history requires everyone but Alan Kay trying to trick us, while the second only requires Alan Kay trying to trick us.

This is what frustrates me so much about this – we have some guy, using the fact that most other inventors are dead or in other non-English speaking countries, running around claiming his off the wall interpretation of OO is the one true way.

It’s like the ultimate archetypical asshole machismo asshole programmer, willing to ruin others careers and say terrible things to get his own time in the spotlight. He knows he isn’t going to be challenged because Simula was invented somewhere else, and he has a whole bunch of kids to try and teach his own version of history to. He exemplifies the lone genius programmer who is “smart and gets things done”, and perpetuates that myth in the middle of programming’s diversity and teamwork crisis.

Every time I hear the Alan Kay story, I think – someone else has just learned not to listen to others, not to work with others, not to give credit to others, to believe that everything’s been built by themselves and that every miscommunication is someone else’s fault. Culture is wrong, not me, and that’s why I don’t get along with everyone.

And that’s just fucking dangerous.

SYWTLTC: (AB) Chapter 2: Your Development Environment

Go here if you want the prolog and table of contents to the SYWTLTC series!

The largest difference between what you do in Code Combat and what you’ll be doing in the rest of these chapters is about developing on your local box. To do that, we’ll need to get a slew of tools set up.

For the most part, you can probably just install some off the shelf version of Python and get cracking. But these chapters are about proper engineering. This means, what do you need to learn to code complex systems in large teams. Simple scripts aren’t going to cut it – you’re going to need tooling.

Many of the tools below are how you build high-quality complex systems, and rarely are they taught in school! They’re always learned on the job, and people struggle with the problems that these tools solve – sometimes their entire career. Not you, you’re going to learn how to do things right, right from the beginning.

Shaving The Yak

This also will be an exercise in configuration and probably a little frustration. Every time someone starts a new job, they have to get the code building on their box – get all the right tools, libraries and everything else downloaded and configured in precisely the right way.

Every time you screw up your box, which is probably a few times a year as a coder, you might have to rebuild it from scratch. Which again, means configuration work. Every time you want to try out a new tool or library to see if it solves a problem you have, you’ll have configuration work. This isn’t covered in Code Combat, but it’s something that you’ll hit throughout your career as a coder.

Might as well jump in.

While this isn’t the only time this phenomenon occurs, it may be the first time it occurs in your coding career so you need to get used to this too: Yak Shaving.

Watch the above Gif. Seriously.

Yak shaving is when you set out to do a thing – you want to write a script that does X. And to do that, you need to install a library. To do that, you need to update your dependencies. To do that, you need to update your compiler. Before you know it, you’re shaving a yak and you’re not quite sure how you got that far down the rabbit hole.

In the following instructions, you’re almost sure to screw up something or run into a path I didn’t anticipate. You’ll have to attempt to find out what’s wrong and find a workaround that gets you to the end.

This will probably require some googling, which is good practice to figure out what to search for, as well as some experimentation. You may also want to read help documents on the sites I’ll be sending you.

As a last resort, if you can’t get a certain thing installed, contact your mentor – but don’t do that first. Use it as a challenge to see if you can get your environment working!

In addition to practicing your research skills, we’ll also begin challenging your project management skills. The key to successfully shaving a yak is to – when you’re stuck – remember the following options:

• Use google or other resources to see if others are having your issue
• Experiment to see if you can find a workaround
• Take the smallest steps possible from known working system to known working system
• Be willing to step backward – maybe the problem you’re trying to solve is impossible because you screwed up something earlier. Be willing to start over from scratch. (That means you need to know how to UNDO what you’ve previously DONE)
• Be willing to make compromises that ultimately get you to the end goal but maybe not using the same method or process you originally set out to do, or the method or process you thought you were supposed to follow.

Without further ado, please complete the following:

1. Read this

2. Install Anaconda

Anaconda is a great Python distribution – it comes with the runtime, the IPython replacement REPL, and virtually every library you might want.

Find it here. Keep in mind the differences between Python 2.7 and 3.5 – some textbooks require 3.5, though your mentor may be familiar with another one. In future debugging, remember that material you’re using to debug may be designed for another version.

3. Introduction to IPython, the super Python REPL

Python can run .py files you’ve already written, but also works as a read-evaluate-print-loop interpreter if you don’t give it a file. This is what makes it look like an interactive calculator.

IPython wraps Python’s REPL with all sorts of nice bells and whistles and is the main REPL I use when doing Python. IPython comes with Anaconda. While I can’t supervise and make sure you always use IPython rather than the built in Python REPL, I’d highly advise you make the switch. If your mentor sees you using the old REPL when IPython is available, she’s given permission to give you a solid knock on the head with a cane.

Since it’s already installed, you’ll want to walk through the tutorial here. In addition, watch this video here – forgive the accent.

IPython has a feature called ‘Notebooks’ that you may find online in your googling. We won’t be using those right now.

4. Introduction to py.test, the awesome testing suite

Py.test is a really super convenient current best-of-breed testing tool we’ll use in our Python code. One thing I really like about it is it will automatically discover our tests – we simply write .py files, put the word ‘test’ in our function definitions, and py.test will find them, run them and report results.

Ignore the installation steps as you should have py.test already installed from Anaconda, but finish out this example.

For all future work, I may either give you a test case you need to pass or alternatively expect you to write tests for your code. Py.test makes it super easy to run these tests.

5. Introduction to pip, the Python Package manager

Programming is half algorithms/code, and half libraries. Code combat has focused a lot on the code side, so some of the library aspects of programming may seem unfamiliar to you. Don’t fret, it’s just a new vocabulary you’ll get in time.

Pip makes it very easy to install python libraries that are publically available. It comes bundled with Anaconda. We’re lucky that virtually every library you might need also comes bundled with Anaconda, so you may not need to install one. Still, you should go through some pip examples (you’ll see some with the py.test install instructions) at least reading them since you don’t need to actually physically do them. Follow along here.

The above also has good coverage of virtualenv. Read this too to be familiar with some of the hard parts of library based code (conflicts, versioning, etc). But again, you don’t actually have to do do this tutorial in your own console. Just read over it so you’re familiar with the lingo and problems, and moreover, so you’re confident enough in pip that you can install something in the future if you needed to.

The tutorial uses bash, the Linux, and Mac OSX shell, but windows shell is very similar at least in the use of pip.

6. Introduction to pdb/ipdb, the python debuggers

In addition to testing, debuggers are another fantastic tool to help speed you along in figuring out why your code won’t work.

One of the best patterns of work with a debugger, especially compatible with testing, is to use a trace or breakpoint in your code. Finish out this tutorial on how to place breakpoints.

Testing can tell you ‘hey this test doesn’t pass!’, verbose testing can even tell you what exactly failed. But often you’ll have to put breakpoints either in your code or tests so that you can interactively explore the state of the program and see what’s wrong.

No debug print statements! Learn to use the debugger! Every breakpoint is worth a thousand print statements 🙂

7. Git and Github

Git is how you’ll be sharing code with your mentor from here on out.  Some future tests will still involve pairing with your mentor. But we’re going to get more and more to the point of just communicating via code.

Sign up on Github for an account.

You already have a GitHub username, so now it’s time to start using it to create code repositories, add files, and the rest. Finish out the appropriate tutorial below:

• Windows Instructions on Git
• Mac Instructions on Git

That will show you how to use the GUI (on Windows) and set up your SSH keys. SSH keys are similar to passwords in that they provide authentication between two computers talking to each other – but they’re far more secure.

Since git primarily command line based, you’ll want to finish out with this to know how to set things up, commit, push, etc…, from the command line.

Challenge!

We’ll have two parts to the challenge for this chapter, a code part and a pairing part.

Code Challenge

You’ll create a new repository and put a single .py file in there. That .py file will be a test py.test can run, and it should check that 1 equals 0. This test should fail and I should be able to clone this repository and immediately run the tests and see that it fails. I want you to have the following two lines in the test:

variable_1 = 1

variable_2 = 0

Then check that the two variables equal each other – they should not.

Pairing Challenge

When you’re finished with the code test, pair with your mentor to demonstrate you can do the following tasks. Open that .py file from above, set a breakpoint below the setting of your variables but above the test. Interactively explore the value of the variables and show that they aren’t actually equal.

Then you’ll fix your test – set both variables equal to 1 – and run py.test and show that the tests now all pass.

Next, you’ll add this change to the repo and push it up so that your mentor can see it on Github.

Finally, I’ll want to see you use IPython to do the following:

1. Navigate and list directories
2. Tab completion
3. Historical completion
4. Use the ? and ?? commands, as well as the help and dir functions.

SYWTLTC: Advanced Beginner (AB) Chapter 1: The Command Line

Go here if you want the prolog and table of contents to the SYWTLTC series!

This is the start of the Advanced Beginner series, which is arranged as a series of chapters that will take your skills you’ve learned from the Novice portion and start to apply them to real-world problems – including tools and approaches coders must apply that are not simply code.

Please continue to intermix further Code Combat levels as you tackle these chapters, pushing at the pace of a few levels per chapter. If you are at least on the Desert stage and have found about 10 levels or so to be lacking challenge/easy, you can move on from Code Combat.

For reference, you should be about half-way through Python Programming – having read the bolded chapters and done the exercises.

1. Programming Basics (ch 1, ch 2)
2. Beginner Data Structures (ch 5, ch 11)
3. Structured Programming (ch 7, 8)
4. Procedural Programming (ch 6)
5. Algorithms and Recursion (ch 13)
6. Object Oriented Programming and Design (ch 4, ch 10, ch 9, ch 12)
7. Numerical computing (ch 3)

You should find that as you tackle other online methods as part of this curriculum, as well as these chapters, that going back to Code Combat will be easier and easier – levels should begin to seem almost trivial as you get more experience.

This first chapter will be about the basics of the command line of the computer you are on, and will build skills we’ll need to draw upon to get other toolsets installed for you to practice with. The only requirement from here on out beyond the usual computer and mentor is that the computer you are on may need administrator access – you’ll need to be able to install things. Whether or not you need it will probably rear its ugly head as we move forward, as your operating system – either OSX or Windows – is going to start complaining.

These chapters are structured usually as brief explanations from me on what we’re talking about and why it’s important to you, interspersed with text, video and other exercises around the subject I’ve found online.

At the end, there will always be a challenge – tasks you need to perform to move on to the next chapter. For some of these tasks, you’ll need to set up some sort of screen share with your mentor – or get together for a live “pairing” session – while others will be questions you’ll have to answer for your mentor or code you’ll need them to review.

When you’re ready for this chapter’s challenge, contact your mentor and set up a time. Below, chose either the Windows Command line or Mac OSX Command Line instructions to go through, depending on what kind of computer you have.

The Command Line

Computers have two main interfaces, one of which you’re probably very used to, and one of which you may have used very little. The GUI, or graphical user interface, is what you drive with your mouse. You may have a start button at the bottom left, or an icon strip, or what have you. You click on your internet browser to start it, click around on the web, and so forth.

The command line was the original interface with the computer, and it still remains the most powerful of the two. GUI applications tend to be less powerful though have a lower learning curve than command line applications. The main benefit to command line applications is that they are designed to be interacted with programmatically – sometimes called ‘scripting’ – so that you can write programs that run a bunch of command line applications to get a job done.

We need to get you used to some basics in the command line so that you can install Python and other tools, as well as learn how to navigate your computer only from the command line.

The command line is also sometimes called the console or the terminal, although technically these things are all different things. This series will use the terms interchangeably.

Command Line Basics

Instead of being mouse driven, the command line is keyboard driven. There won’t be much clicking to do, although depending on your terminal (Mac and Windows differ here) it may be easier or harder to do things like copy and paste to and from the command line.

You’ll be typing commands into the command line, which will then print out feedback of what happened in the same window. The same abstractions apply at the command line level as at the GUI level, though. For instance, you’ve probably navigated nested folders on your desktop GUI to find a file. In the command line, the same folder structure exists, although the tend to be called ‘directories’ when you’re using the command line.

We’ll need to get used to the command line ultimately to install Python later. Moreover, nearly all your programming work is going to be command line heavy.

Windows Command Line

Do the following:

• Watch This Video
• Read This – Do at least chapters 1, 2 and 3. Can skip Windows 10 stuff unless you have Windows 10.

Mac OSX Command Line

Do the following:

• Watch This Video
• Do the free version of this Code Academy Lesson
• Read This – Do chapters 1 and 2 only for now.

Text Editing

Once you’re comfortable navigating the command line, you need to be able to open files new and old with a text editor – you’ll be using this editor to do that. The text editor is similar to the window you typed your code in for Code Combat.

I’m going to recommend you download and install the atom editor to do this, primarily because it’s cross platform and has a shallow learning curve compared to others.

Do the following:

• Download and install Atom

Challenge

Do a screen share or live session with your mentor, and show them that you can do the following:

• List, create and remove a directory
• Interactively navigate your file system based on what your mentor asks you to look at
• Open a new file in Atom, write some text, save the file and close Atom, then reopen the file – all from the command line.

Feedback?

Are there resources you’ve found you found particularly useful? Are some of the listed resources redundant? Please let me know so we can keep this clean and up to date!

SYWTLTC: Novice Chapter 1 : Building Intuition

I’m creating a curriculum to organize and guide you through the plethora of online resources available that will teach you to code.

This is the first in that series, for the absolute beginner and novice. No requirements are necessary at this point other than a computer (with a web browser) and a mentor.

If you haven’t managed to find a mentor by this point, take heart. You can still make your way through the novice portion, however, you’ll most likely go a bit slower and miss some big picture items that your mentor would bring up. You won’t be able to move on to the Advanced Beginner portion, though.

Code Combat

Code combat is where you are going to spend the bulk of your time during the Novice stage. Out of all the different resources available to you, why Code Combat?

It’s Fun

Code Combat is a video game – it draws from role-playing game and real-time strategy roots. It creates a bunch of compelling problems to solve from this game, and is addictive in the same way that Starcraft or Farmville are addictive – there are levels to beat, enemies to battle and treasure to loot.

You will be more able to stick to this than many other resources.

It’s At Your Level

Code Combat excels, more than other resources I’ve seen, at starting you off very simply. It assumes absolutely no knowledge and builds you from there. There are a plethora of interesting resources out there that tend to have a steeper learning curve.

It’s Live, and Builds Intuition

Being able to actively watch a program run – in Code Combat, this is done by watching your character interact with other allies and enemies – is called ‘visual debugging’ when done on real world programs. It is one of the best ways to understand something unfamiliar.

The largest handicap for a traditional computer science program is that you have to write a program from scratch, find out at the end it doesn’t work, then slowly hack at it until it does. You’re never taught how to debug, so actually looking at the state of your running program is usually left as an exercise to you.

Code Combat starts you off early seeing the exact state of what’s going on. The more practice you get translating your code to the game’s actions, the more you build up your ability to think intuitively about code. I’ve never seen a resource better at building coding intuition than Code Combat.

It’s Free!

There are free and paid levels, and you should be comfortable working with your mentor to decide if you’d like to take them up on their paid services. Certainly, they’re a great company and deserve your support. But part of the assumption of this curriculum is that people will only need a computer and a mentor.

(Update: Code Combat has since changed how it charges. Previously, entire worlds were cordoned off as paid. Now, there are paid sections of each world. It is entirely possible to get the intuition you need from the free levels. But it’s also very useful to take advantage of the paid levels, especially when you get stuck on some concept and need more practice.)

It’s a Lot of Hours

To learn something, you have to do that thing. And to learn it well, you need to do it a lot. Often, traditional computer science programs may have one homework assignment a week, or multiple if you’re taking multiple classes. The bulk of learning coding in computer science degree programs is through this homework – not in the lecture hall or textbook reading.

Code Combat provides a lot of exercises. By the time you’re done, you’ll have completed as many exercises as someone half way through a computer science degree program. But it won’t feel like that since you’re assignments will have been fun.

Drawbacks

The exercises tend to grow at a slower pace than a traditional degree program, so don’t feel bad if a friend of yours throws out complex terms like polymorphism or lambda calculus and you’re still working with while loops. This is, in my opinion, a good thing.

Building an intuition for the basics is far more important than name dropping on advanced concepts. Coding is not like mathematics, or traditional engineering where having been exposed to a bunch of very different toy problems and their toy solutions will make you a more productive programmer. Coding is much more like playing a musical instrument, and lots and lots of steady, progressive practice will give you a leg up in actually doing your job over someone from school.

The Assignment

Get an account on Code Combat, and get hacking. They’re always expanding to new levels and new worlds. Generally, we want you to work on Code Combat until you start to get a bit bored… and then some.

This happens after about a 100 or so levels in. At that point, you may want to add some variety in terms of a textbook we’ll recommend later. Around 120 levels plus a few chapters out of that book, and you’ll add in some additional variety with exercises from this blog posts “Advanced Beginner” series.

Whether free or paid, take advantage of the optional Web and Gaming mini worlds for additional exposure – even if you never intend on entering either of those industries. They’ll give you your first exposure to what is called ‘architecture’ in coding – largely assumed patterns in code that different industries use to solve reoccurring problems.

Python

This Novice Portion, as well as the rest of the series, is going to be written with the Python programming language in mind unless specified otherwise. Python was designed in the late 1980’s as a teaching language – it has an intuitive syntax that’s easy to learn and is not filled with a lot of ‘gotchas’ or ‘magic’. It’s a dynamic language, which means you won’t have to figure out how to compile anything, and is multi-paradigm, which means you won’t have to jump through hoops to make your program do something as simple as say “hello world”.

For Mentors

It’s advisable to try and get your mentee to coalesce a list of questions for you on a weekly basis for either a face to face meeting or email. Code Combat gives some introductory explanations for computer science ideas like variables, arguments, parameters, functions and the like, but it’s taught from a highly pragmatic point of view. For this first phase, you are your mentee’s traditional computer science education.

Let them come to you so that you can plug in answers to their questions from the theory, but don’t add anything on top. Theory needs to wait for skill to catch up, and overwhelming someone with technicalities before they need them to solve their problem is just going to turn them off. They won’t remember it anyway.

Work with your mentee around boredom points – encourage them to stick with Code Combat past a handful of boring levels to truly see if they’re bored, or just have mastered a concept early and Code Combat isn’t really ready to move on yet. Eventually, they’ll get bored enough that it’s time to give them something more challenging to mix in from the Advanced Beginner portion, and this is largely your job as the mentor to decide.

Finally, the large focus on online exercises during the Novice phase also serves as a wash out period. It takes quite a bit of time, and despite the fun, can be challenging. It conserves your own effort to have them complete the Novice phase first, to truly see who’s interested and who’s merely dabbling. We want to generate more coders to enter the workforce, build open source projects, and the like. We don’t necessarily want to spend mentor hours on folks who want to write a “hello world”

 

So You Want To Learn to Code: Prologue

This series of posts is derived and will continue to be evolved, from my experience mentoring others in learning how to code.

Coding is something that many people are interested in doing – and it’s certainly sexy right now to claim to be learning to code. But out of the plethora of resources out there, which ones are the best? And what does best even mean?

Expert Review of Available Resources

I’ve reviewed many available resources online for you, from the perspective of someone who already knows how to code. I’ve considered them both in terms of “I wish I had this when I was learning!” factor, as well as what I know about education – keeping people interested, engaged, even addicted to learning good habits and skills.

Emphasis on Engineering Skills

In addition to reviewing resources online, I’ve reflected on things I wish I had learned in school and compiled a set of more traditional curricula to teach these things. Often, these skills, which I will generally refer to as ‘software engineering’ skills, revolve around design and quality. Exercises we do online, or even in computer science classes, are often so small that they don’t run afoul of many problems with complex software. They’re often done alone, so they don’t run afoul of the many problems with software written by teams.

Engineering principles are there to help us move from people coding up toy problems, to people who can work together to iteratively build large projects and solve big problems.

A Designed Curriculum

Finally, I’ve coalesced all the above into one linear curriculum – step one, step two, step three – that will give you what you need to learn not only how to code, but also how to code well.

What Do You Need?

First, you’ll need a computer, obviously. The original curriculum was written for someone who came from a Windows background, however, I’ll be attempting to add hints for Mac users as well. That’s the only piece of technology you need to be comfortable with from the start – I’ll start at the very beginning.

The other thing you’ll be required to have is a mentor. While research skills are something to be learned along the way, having someone you can call upon to ask technical questions is invaluable. Moreover, during the later stages of this curriculum, a mentor is required to check and grade your work.

Finding a mentor may be hard. However, if you already know how to code and would like to help others, I encourage you to use this curriculum and be their mentor! Furthermore, if you’ve used this curriculum all the way through, I implore you to become a mentor for someone else. To become a truly expert coder, you need to teach others!

On Python

For all of the beginning portion of the curriculum, I’d highly advise you to do the exercises using the Python programming language.

Python is a very easy language to learn and was designed as a teaching language. It’s got a simple syntax that is easy to not get mixed up in the gotchas and magic of other languages. The Zen of Python says “Explicit is Better than Implicit”, and the language was evolved with that in mind.

To get the most out of Python, find a mentor who’s willing to teach Python – she doesn’t have to be an expert in it, any “dynamic” language (like Ruby, Perl or Lisp) experience would probably make them valuable.

You can ultimately stick with Python your entire career as it’s used in games, devices, mobile apps, the web, and backend supporting programs. It’s particularly popular in ‘big data’ and ‘machine learning’ circles. I wouldn’t advise this, though, as the best Python programmers got that way by learning other languages as well, though we’re not going to do that anytime soon.

A Note on Pedagogy

I think many CS degree programs can be faulted by focusing too much on theory and not enough on practice.

The practice of programming, of building complex things in teams, is what coders do day in and day out. We don’t talk about finite state machines or discrete algebra, and you don’t need to know how those things work to be an accomplished coder.

Often theory can take away time that a student needs to practice! You can often tell productive programmers from unproductive ones based solely on the number of hours they’ve spent coding before reaching you – especially coding problems that are new to them or require them to push themselves. Understanding how to encode binary, quaternions or regular grammars has never made anyone a more productive programmer.

The worst aspect of the focus on theory, though, is that it turns people off of theory! Theory is beautiful and elegant, and – assuming you already have a solid handle on skills – it can lead you to designs you would never have built on your own that are both orders of magnitude more performant and maintainable. But only if you attempt to apply the theory! Unfortunately, so much theory is pushed on students too early that they memorize it to pass a test and promptly forget it. They don’t see how useful it is because they’re still struggling to get an intuitive grasp of programming in the first place.

Unfortunately, so much theory is pushed on students too early that they memorize it to pass a test and promptly forget it. They don’t see how useful it is because they’re still struggling to get an intuitive grasp of programming in the first place.

My advice – both to students of this curriculum and to mentors – is focus on the practice of programming from the outset. Learn how to code, then learn how to code well, and then you’ll find yourself with dozens if not hundreds of questions that will be answered in your discrete algebra textbook. Until then, just do the fun part – because theory can be fun too, but only when you have practice in mind.

Without Further Ado…

I’ll borrow from the Dreyfus Model of Skill Acquisition to break apart the larger linear curriculum into stages – Novice, Advanced Beginner, and Competency. If this is successful, I’ll attempt to provide guidance for the Proficient and Expert levels.

Enjoy!

The Table of Contents of the Curriculum will be updated below, so keep this page bookmarked!

SYWTLTC: Novice Chapter 1: Building Intuition

SYWTLTC: Novice Chapter 2: Effective Hacking

SYWTLTC: Advanced Beginner (AB) Chapter 1: The Command Line

SYWTLTC: (AB) Chapter 2: Your Development Environment

SYWTLTC: (AB) Chapter 3.1 Quality: Test-Driven Design

SYWTLTC: (AB) Chapter 3.2 Quality: Static Analysis

SYWTLTC: (AB) Chapter 3.3 Quality: Assertions

SYWTLTC: (AB) Chapter 3.4 Quality: Collaboration

SYWTLTC: (AB) Chapter 3.5 Quality: Type Checking

SYWTLTC: Appendix A: Object-Oriented Primer