As a former avid Scala developer, I started down the path of watching every Rich Hickey presentation I could find one week. Every video tweaked my thinking just a tad (as I almost always agree with his line of thinking), and I came out of it a better functional programmer and a Clojure developer.
Note: I still do/love Scala, I just develop much less of it in favor of Clojure.
I'm also a big fan of the talk on persistent data structures, simply because it was my first introduction to them.
A performer who has already mastered one or more musical instruments will be better able to rapidly learn a new one, but a novice is going to need to toil away for years before they reach master-level proficiency. Similarly with programming, I think it is fine for languages to present themselves succinctly for the benefit of experienced developers, but I am highly suspicious of anyone who claims you can learn to program in less than, say, 2 years.
I also think this is something to keep in mind with the recent explosion of "alternative programming schools". You can hand someone a guitar and, in a handful of weeks, teach them all the cords for 10 popular tunes. That person can then find a street corner in the nearest city, set down their open guitar case, and play those ten songs in rotation and make some money...but have we created a new musician?
What I can say that the priority is not so much teaching them X, Y, or Z framework, but teaching them what it means to "think like a programmer." You might not think that is teachable, but, well, empirically falsifiable. :)
I'd definitely call students who went through DBC "programmers." Many of them remark after graduating that they never realized how little they really knew. At the very least, we get them from unconscious incompetence to the bottom rung of conscious competence.
If all I were doing were teaching folks "cords[sic] from 10 popular tunes" I'd have no interest in doing it at all. Real programmers or bust.
I can't speak for anyone else, of course.
A proper education lasts longer than the duration of the actual instruction, so I trust that some of these "short term" programs can still make programmers (and anecdotally, I've heard good things about Dev Bootcamp).
"We should not sell humanity short by trying to solve the problem of beginners in our stuff. We need to make things for people to use, and we need to teach people and trust people to be able to learn how to do that"
"Just as we shouldn't target beginners in our designs... nor should we try to eliminate all effort. It's an anti-pattern. It's not going to yield a good instrument. It's okay for there to be effort."
As a workaday hacker, my own practice has been more sporadic than I want. This talk reminded me that practice needs to be structured and purposeful. And regularly done.
video: http://skillsmatter.com/podcast/home/functional-composition
repo: https://github.com/ctford/goldberg
(edited to add the video link)
I don't think programming languages should be like instruments. I find it awkward working in Haskell or Clojure because I'm a composer and not a performer. I might be writing a rock opera one day and some chamber music the next. As a composer it seems completely wrong that I should contort my expression of my music to fit the characteristics of a single instrument. I can't bring an oboe to a metal show.
The computer itself is the instrument... one capable of becoming any instrument I program it to be. One that can be programmed to generate instruments and arrange them into symphonies.
The notation we use for describing music is, in my opinion, what programming languages should be like. If what I'm trying to do is write a symphony there is a common language and notation that everyone understands. A symphony isn't written alone by a composer in a room (despite what Danny Elfman would have us believe). They're generally written by a team of people doing transpositions, arrangements, and the like. If each part is written in its own notation/language then it becomes very difficult to see the whole piece as a single composition when it's finished. And it's much more difficult to compose such a large work and turn it into something we can execute and perform.
And that's where we are today in a number of domains such as web development and other distributed systems. We have these monstrous systems that are supposed to work in harmony but the notations used to describe them are so specialized and disparate that no one person can understand the whole piece. We have bits of systems written in C, others written in a handful of scripting languages, and run-times all over the place performing redundant work and wasting resources. It's a time-consuming and expensive process developing these systems because few of our "instruments," work together.
(and the problem, I believe, is deepening as we continue to develop systems-level programming languages whose ABI's come with the baggage of run-time processes)
I don't think programming languages, environments, and tools need be reduced to single-purpose instruments. I think we need languages more like Lisp and the symbolic model of computation where we can describe our processes using a notation and form more akin to rhetoric and logic that is much closer to our intent and purpose. We need the implementation of those languages to take those programs and turn our general-purpose computers, the real instruments, into virtual machines capable of executing those processes just as we describe them.
Nice link! :)
But programming languages go well beyond this: a programming language is a combination of syntax with semantics. And semantics, by far, is the most important part!
In your musical analogy, syntax would be the notation and semantics would be music theory or composition--the music itself. Semantics pervades everything: it controls what you can express, how you can express it and even how you think about it. All this is very much a function of the programming language more than any other tool or component in a software system.
The computer is the instrument, but the instrument is just an implementation detail. It's what we use to produce the music, but it's the music itself that we create.
As you said, you are a composer not a musician: so which part, then, is important?
I've got it on in the background now while I do some rather mindless tasks. Unfortunately in this version, Rich seems a little tired / low energy in the beginning, but it really picks up in the middle. The bits about instruments and players is especially both illuminating and entertaining.
Overall a great talk, well worth watching.
I can't count the number of months I lost trying to research things at levels of the stack that I'm not interested in but were forced to look into to get to the point where I wanted to be.
It's mostly the reason I started to use rails to build document-like web apps/sites because if I have to answer 35 questions and build a platform on top of node/express just to get to the point where I can start solving the problems I want to solve then I'm clearly at the wrong level of the design stack.
