Mark Guzdial

Pea & Kurland's basic idea is still correct. They were arguing against the notion that learning Logo programming would exercise some generic intelligence 'muscle' that would benefit students in other areas. Instead, what later research demonstrated was that cognition is contextually bound (see research on situated cognition and situated learning and embodied cognition).

In the case of teaching programming skills - that is the main goal, for students to learn how to program and improve their computational thinking skills. Just like when teaching writing skills, reading skills, speaking skills, time management skills, etc.

One of the biggest problems is we try to teach these skills without context. You learn some procedure or concept and you're supposed to just memorize it and apply it sometime later. Instead, we should start with the context. Making a game, for example, or creating an app or website that serves some relevant purpose or solves some real-world problem. This is the idea behind problem-based learning, service learning, and the like. It also can be more effective to teaching programming in the context of other school topics, like math, science, etc. Here's one example: https://edsource.org/2016/teaching-math-with-computer-programming-can-help-narrow-achievement-gap/563371

And here are a couple of relatively recently summaries of some research in computer science education, but there's a whole field of research on the topic, with conferences and journals…

Alan Kay doesn't consider "remote procedure calls" to be "object oriented programming".

http://mythz.servicestack.net/blog/2013/02/27/the-deep-insights-of-alan-kay/

mythz> On RPC, and how it distorts developers mindsets in architecting and building systems:

Kay> The people who liked objects as non-data were smaller in number, and included myself, Carl Hewitt, Dave Reed and a few others – pretty much all of this group were from the ARPA community and were involved in one way or another with the design of ARPAnet->Internet in which the basic unit of computation was a whole computer. But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with “Remote Procedure Call” instead of thinking about objects and messages. Sic transit gloria mundi.

mythz> Carl Hewitt being the inventor of the Actor Model and Dave Reed who was involved in the early development of TCP/IP and the designer of UDP.

mythz> The last latin phrase translates to “Thus passes the glory of the world” - expressing his dismay on what might have been.

He also doesn't consider accessing a data field called "entire_name" to be "object oriented programming". He calls that "simulated data structure programming".

https://computinged.wordpress.com/2010/09/15/alan-kay-on-motis-objects-ever-cacm-article/

Kay> If you are “setting” values from the outside of an object, you are doing “simulated data structure programming” rather than object…

> Making Software, Oram & Wilson

Going to quote one of the authors (Hakan Erdogmus) from here: https://computinged.wordpress.com/2010/11/01/making-software-tdd-doesnt-work-architecting-is-mixed-scripting-is-great/

"I am one of the authors of the TDD chapter. Ours was a review of existing some 30+ studies of TDD. Yes, Nachi’s experiments (the MSR study mentioned above) were included. BTW, I wouldn’t have concluded that “tdd doesn’t work” based on our data. Rather, I would have conservatively concluded: there is moderate evidence supporting TDD’s external quality and test-support benefits, but there is no consistent evidence in one direction or other regarding its productivity effects."

The only thing inconclusive was the increased productivity effect, not the code quality effect.

> It's especially not clear whether it's worth it to do TDD in comparison with simple automated testing and other testing strategies.

https://www.researchgate.net/publication/3188484_On_the_effectiveness_of_the_test-first_approach_to_programming

I've done every testing strategy. Test-none, BDD, TDD, test-after, integration testing, unit testing, GUI testing, you name it.

If your code will last longer than a couple years, it is worth it to do extensive unit testing via TDD, integration testing of major/important workflows, a visual once-over by a QA person to make sure something didn't break the CSS, and that's it. If you are the founder of a startup and expect to sell within 2 years (and are…

> 'Actor model' but it ended up being very misunderstood when implemented in C++, Java, etc,

Yap here it is right from the horse's mouth, so to speak:

https://computinged.wordpress.com/2010/09/11/moti-asks-objects-never-well-hardly-ever/ (see comments history)

---

If you are doing “simulated data structure programming” rather than object oriented programming. One of my original motivations for trying to invent OOP was to eliminate imperative assignment (at least as a global unprotected action). “Real OOP” is much more about “requests”, and the more the requests invoke goals the object knows how to accomplish, the better. “Abstract Data Types” is not OOP!

...

Many of Carl Hewitt’s Actors ideas which got sparked by the original Smalltalk were more in the spirit of OOP than the subsequent Smalltalks. Significant parts of Erlang are more like a real OOP language the the current Smalltalk, and certainly the C based languages that have been painted with “OOP paint”."

---

There you have it folks, Erlang is more OO than C++/Java and C#. It is kind of a funny tidbit, good for sharing during meetups over beers.

One interesting response to that I heard from a developer was "Well, it doesn't matter what Kay thinks anymore. C++/Java/C# got so popular and that is OO now officially".

I think this is exactly how Apple sees it. Look at the specific language from the SDK agreement:

"Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework."

This doesn't forbid third-party interpreters; what it really does is control distribution of code. All code that is run on an iOS device must be downloaded either through the App Store or through Apple's WebKit.

This means there are no distribution channels on iOS that use their own non-Apple mechanisms to obtain and run software -- no Flash Player, no Chrome Web Store with NaCL, not even MIT's Scratch programming environment for kids (whose runtime was banned from the App Store in 2010 [1]). Web apps on iOS are less controlled than native apps, but Apple still gets to decide which capabilities to expose to them. This is one of the major things that gives Apple such tight control over the user experience, security, and evolution of the platform.

[1]: http://computinged.wordpress.com/2010/04/15/apple-removes-scratch-from-ipadiphoneitouch/

This book should really be called "How to Design Functions" -- not "Programs" -- because it sidesteps the most difficult and interesting topics in making software programs, namely the work of a) separating a task into simpler subtasks and then b) composing smaller functions into a program that performs the task. IIRC the most complicated example in this book pertains to calculating the optimal price of movie tickets. There is merit in some of the book's recommendations. But overall this material could be condensed into the 25-page intro of a much more interesting programming textbook. As it stands, HTDP is a buzzkiller.

Speaking of which, here's a 2010 blog post about how Georgia Tech stopped using HTDP, featuring an argument in the comments between the author of HTDP and Alan Kay.

https://computinged.wordpress.com/2010/05/11/playing-the-cards-youre-dealt-a-story-of-gt-and-htdp/