That's really excellent. It's funny, although not entirely surprising, but we have also been using parts of Khan and Bret Victor. The students seemed to really enjoy the sandbox of Khan as a starter to what is possible with code. Repl.it was a big help as well. The hard/fun part is transitioning between the experimenting and learning with these out-of-the-box tools to experimenting and learning by actually making your own stuff. I - and I'm sure the other ScriptEd folks - would love to hear more about your experience (scriptednyc@gmail.com).
Haha. I'm happy someone saw that. I wish I could say that it had something to do with my theory of Social Catamorphism, folding our disparate talents into a better future, or something. Unfortunately, no such theory exists, and I just picked a piece of code that I enjoy and looks attractive.
Ah, yes. You are absolutely right that I pooched the Android memory example. Laymen might not care and it might not help them. I think a better example might be someone copying information off a website. I've seen this happen a lot. Someone will have to print off name tags for an event but there's only 10 people per page. Copy. Next page. Etc. If they understood, say, the idea of scraping, they'd see a simple batch scrape and save hours if not days.
As you your other point though, about general problem solving, I think I was unclear. When I said you miss the loops and divide-and-conquers of everyday life, I was just trying -- perhaps too lyrically for my own good -- that you are unable to categorize the world into categories you do not know and cannot recognize. You can't see that the operation you do for every page could be abstracted into a loop, exectuable by a computer. You don't see that you don't need to compare all of your friends to arrange them by height, say for a sweet picture, but you can quicksort them. (Ok this is about as contrived as you can get but programmers have a hard time thinking of places most people don't see programming but we do. Because we see it everywhere).
Finally, sure we should focus on illiteracy, debt, oppression etc. We are working, though, on a lot of these problems programmatically.
It sounds to me like you're arguing less for programming and more for a) a basic algorithms class, b) an understanding of technology applicability to real-world problems, and c) the need for better tools to automate daily tasks.
You have to be a pretty good programmer to write a multi-page scraping script fast enough that it beats the tradeoff of just doing it by hand. Or you need to solve the problem another way. I guess that's what I'm getting at... the problems you're highlighting are real, but I don't think the solution is "learning about programming."
I like this point. It is an important distinction and a good comparison to a related area, physics. Two thoughts, though, that I'd like to hear your thoughts on:
1. Don't we all learn physics? At least basically in school we learn about inertia and atoms and velocity. Sure we don't learn the hard stuff and our understanding is woefully incomplete. But the analogy would be "the physics we learn in school" and "things like conditionals, sets, graphs, types".
2. The utility curve of physics is a little different than that of programming. Both contextualize the world and give you richer understandings of it in a similar fashion. However, physics stops solving everyday problems sooner than programming does. I have never whipped out alternative spacetime topologies to solve an everyday problem. I have written tons of bots and things to automate my life.
Fair points. I agree on the first (basic programming courses are now being offered by some schools, but they're not mandatory and far from universal), however I'm a little more hesitant on the second. Knowledge of physics is extremely important to solving basic problems you run into everyday, I just think it's so ingrained that most people don't think about it. Home projects like building a deck or wall mounting a TV for instance are examples of things that require basic understanding of physical laws in order to complete successfully.
I think your first points kind of undercuts your second in that we simply don't think about how physics helps us with our everyday problems since the basics have been ingrained since childhood. I agree that basic computer architecture/programming should be taught in grade school and will go further and say that if it was, it's utility would also fade into the background as we end up applying those childhood lessons unconsciously in our every day life.
Right, and this is a barrier to learning digital domains. There is no physicalization of many digital ideas but, precisely by being digital, they do not map onto physical things. I can't run into a lambda on the street or have to fix a leaky loop in my roof. Sure, everyday things touch code but there's a reason why our instinct is to "blow on the cartridge" and not "fire up the debugger"
I wanted to add this to my original post because I think it sums up my point nicely:
"That which interests us in a given situation, that which we are likely to grasp in it first, is the side by which it can
respond to a tendency or a need. But a need goes straight to the resemblance or quality; it cares little for individual
differences. To this discernment of the useful we may surmise that the perception of animals is, in most cases,
confined."
- Bergson from Matter and Memory
Constraints on what we broadly know and understand are constraints on our contact and perception of the world. We can't live in a digital world and be blind to the recursions and graphs in the furniture.
I'm not sure that this conclusion follows nor am I sure that discussions like this accomplish anything. CoffeeScript makes it easier to write "correct" JS and patches an institutional bug: Javascript's development crawls along. Even if it didn't the browser-as-environment handcuffs developers from taking advantage of new language features. (Have you used JS array comprehensions? No, because browser support is spotty, unreliable). And even in the best of development climates -- a thousand genius hackers ardently updating the code base -- these environmental restrictions would persist, drawn over the frame of IE-Mozilla-Google conflict and competition.
So we have languages that compile to JS that let the language evolve. I use CoffeeScript sometimes and JS sometimes. I'm not going to waste the time in the write-compile CoffeeScript loop for 100 lines of JS that I can write correctly. However, I no longer have to work on a 2k LOC, complex JS app without all the niceties of CoffeeScript. Furthermore, if I'm doing something that benefits from the special expressivity of a Lisp, I'll use clojurescript. If I'm very adventurous (and I need to write, say, an H.264 decoder), I'll use emscripten after any language that compiles to LLVM first.
But these are all for different uses, often things you would never have used POJS for anyway. It's not a discussion of plain ol' JS versions of H.264 encoders vs those made originally with Emscripten. It's a discussion of them not existing at all before, and now having the ability to express them and compile to JS. It's not a question of the old enormous apps we built in JS to the new, simpler ones we express in CoffeeScript. It's a question of not being able to build/maintain 5k LOC in POJS across many developers (whereas this task is less substantial in CoffeeScript). Live and let live and everyone benefits.
I think Jeremy's real point is that Javascript is an entirely different beast than Haskell or Java or Ruby. Why? Javascript depends on a free and open code environment to get around the fact that the actual language's development moves glacially, you have no control of the deploy environment (unless you are a browser developer or are working in node) and it is not easy to manage large projects (inclusion and namespacing features are lacking or limited in JS). In fact, the only feature that allows JS to keep up at all with these other languages is that it tells its developers "Look, I don't have a lot of fancy features and I haven't really changed in about a decade, but I'm entirely open. Hack and abuse me at your pleasure, codify me if you must, I'll take it. I always do."
None of the proposed object-lockdown would prevent anything. You could use decorators, you could use an adapter, hell you could rewrite or fork the useful library and take out the object-locks. But all of those introduce the very overhead that JS benefits from avoiding. I mean compare the size of "Javascript Pattern" to the GOF book. What's more, languages like Java are written with a sensitivity toward design patterning, Haskell has robust types/interfaces. Javascript just has a big empty box, prototypes and closures. (This is an exaggeration but if you declaim it loudly enough you will get a chuckle.)
{-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-}
class Concatable a b where concat' :: a -> b -> a
instance Concatable [a] a where concat' l xs = l ++ [xs]
instance Concatable [a] [a] where concat' l xs = l ++ xs
a :: [Int] a = [1,2,3]
b :: Int b = 4
c :: [Int] c = [4]
-- Main> concat' a b
-- [1,2,3,4]
-- Main> concat' a c
-- [1,2,3,4]