Design, Composition and Performance [video](infoq.com)
infoq.com
Design, Composition and Performance [video]
http://www.infoq.com/presentations/Design-Composition-Performance
7 comments
I was sold the first time I saw "Clojure for lisp programmers". I consider "The language of the system" and the simple/easy talk two modern classics.
Both Hickey and Odersky are awesome, having to choose between Clojure and Scala is just an embarrassment of riches. The JVM ecosystem is fortunate to have both building on it.
Would you mind sharing links to your other favorites?
Just look down http://www.infoq.com/author/Rich-Hickey . Probably the most famous talks are "Simple Made Easy" and "The Value of Values".
I'm also a big fan of the talk on persistent data structures, simply because it was my first introduction to them.
I'm also a big fan of the talk on persistent data structures, simply because it was my first introduction to them.
Yes, "Simple Made Easy" is a must watch imo. http://www.infoq.com/presentations/Simple-Made-Easy
"Are we there yet" is also great: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...
I also love "Hammock Driven Development": http://www.youtube.com/watch?v=f84n5oFoZBc
"Are we there yet" is also great: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...
I also love "Hammock Driven Development": http://www.youtube.com/watch?v=f84n5oFoZBc
For me, the most poignant message in this talk is when Rich draws the contrast between learning an instrument, which no one pretends is an easy task, and learning a new programming language, which seems to be increasingly accompanied by "learn X in 5 days" type tutorials.
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?
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?
I'm one of the co-founders of Dev Bootcamp, although I'm no longer involved day-to-day. What it means to "learn to program" is nebulous. As you pointed out, a person regurgitating things they've seen is able to "program" in some sense.
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.
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.
I have always been a huge proponent of the concept of teaching the art of learning, as opposed to teaching a specific skill. My concern is that, as Rich discusses, truly learning to program is a slower process, at the outset, than learning how to piece together a handful of frameworks and code snippets from Stackoverflow.
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).
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).
Favorite quotes on this:
"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."
"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."
I'm particularly interested in the idea of programming practice. Hickey specifically mentions Coltrane, who apparently was famous for marathon practice.
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.
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.
[deleted]
I love it when musical and computational composition get paralleled. I just saw a different talk focused on this theme recently, focusing on Goldberg variations using the Overtone library in Clojure. You actually get to hear things build up as you see the code do the same in this one, really cool.
video: http://skillsmatter.com/podcast/home/functional-composition
repo: https://github.com/ctford/goldberg
(edited to add the video link)
video: http://skillsmatter.com/podcast/home/functional-composition
repo: https://github.com/ctford/goldberg
(edited to add the video link)
Another very interesting talk. He always gets me thinking even if I don't always agree with everything he says.
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.
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.
Amusingly, this may be the best response I have to your comment: http://www.infoq.com/presentations/music-functional-language
I've used and jammed on several live-programming environments for sound in Common Lisp and scheme over the years. I like the style of language particularly for those reasons because you can reach a point where you're not programming functions that operate on primitive data structures anymore (although that is what is ultimately executed); you begin to develop a language that makes sense for describing musical processes. And that's just easier to reason about.
Nice link! :)
Nice link! :)
Programming languages are far more than notation. Notation is just syntax, and syntax is not that important. The syntax has to be readable and pleasant and unambiguous but that is it--nothing more, nothing less.
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?
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 saw this talk at Clojure/West and it was excellent!
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'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.
He's definitely right about how most people want a lot of choice but in the end it's going to paralyze you for most use cases. I made this realization a few months ago.
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.
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.
Is there a way to see this without compulsory registration?
AFAIK registration isn't required on infoq, and I'm watching it right now.
I see. It seems that if you don't have flash enabled, nothing appears but links for the MP3 and slides, which do require registration.
If you change your UserAgent to iPhone, you can watch (and download) it without Flash. Not sure if it is OK to download it, but it can be done.
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.