
Design, Composition and Performance [video] - skardan
http://www.infoq.com/presentations/Design-Composition-Performance
======
hashtree
Truly a great speaker/thinker, able to communicate his thoughts well.

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.

~~~
jonahx
Would you mind sharing links to your other favorites?

~~~
sandyarmstrong
Just look down [http://www.infoq.com/author/Rich-
Hickey](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.

~~~
cgag
Yes, "Simple Made Easy" is a must watch imo.
[http://www.infoq.com/presentations/Simple-Made-
Easy](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...](http://www.infoq.com/presentations/Are-We-There-Yet-
Rich-Hickey)

I also love "Hammock Driven Development":
[http://www.youtube.com/watch?v=f84n5oFoZBc](http://www.youtube.com/watch?v=f84n5oFoZBc)

------
jballanc
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?

~~~
jfarmer
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.

~~~
jballanc
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).

------
bchjam
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](http://skillsmatter.com/podcast/home/functional-composition)

repo: [https://github.com/ctford/goldberg](https://github.com/ctford/goldberg)

(edited to add the video link)

~~~
paperwork
Also at infoq: [http://www.infoq.com/presentations/music-functional-
language](http://www.infoq.com/presentations/music-functional-language)

------
agentultra
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.

~~~
saraid216
Amusingly, this may be the best response I have to your comment:
[http://www.infoq.com/presentations/music-functional-
language](http://www.infoq.com/presentations/music-functional-language)

~~~
agentultra
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! :)

------
brandonbloom
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.

------
rartichoke
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.

------
wes-exp
Is there a way to see this without compulsory registration?

~~~
agumonkey
AFAIK registration isn't required on infoq, and I'm watching it right now.

~~~
wes-exp
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.

~~~
frou_dh
Whenever you're denied video for not having Flash, try making your browser
spoof an iPad User Agent. That works here on InfoQ and on many other sites.

