A friend of mine invited Bret to do this talk. He told me that Bret sent close to 50 emails leading up to the event making sure that every aspect of the talk was perfectly choreographed.
Simple Made Easy changed how I think about constructing software systems of any kind. It provided me with a strong vocabulary and mental model to identify coupling and design with a more clear separation of concerns and focus on the output rather than the ease of development.
Also see Stuart Halloway’s earlier talk, Simplicity Ain’t Easy. There’s a fair amount of overlap with Rich Hickey’s talk, but both are worth watching: http://www.youtube.com/watch?v=cidchWg74Y4
- everyone knows you cannot keep up the pace of a sprint
over a long distance race - so they solved it by running
a long distance race but just firing a starting pistol
every 400 yards - and we're off again!
Just watched it...really great stuff. But can anyone chime in on how you can apply some of the principles in his talk to something like a retain-mode display library, for GUI or 3d for example? Libraries like these pop up in all popular OO languages and usually have long inheritance chains with very state-heavy classes, which further form somewhat rigid hierarchies of class instances at runtime. This violates some of his tenants in a big way, but they seem to be the predominant design pattern for getting stuff on screen. Even HTML5 is essentially like this.
Any thoughts on how his talk could apply here? Is there a better way?
View layers can get complex, but you can at the very least encapsulate complexity and have it interact with other parts of the system in a simple well defined way. Have the separate layers of the application communicate via interfaces that keep the ingress, egress points of data flow well defined. Things like event pub/sub systems can further decouple things, the observer pattern, etc.
I meant that if I were designing a general-purpose retain-mode GUI library or 3d engine from the ground up and wanted to incorporate his principles as much as possible, how could I do that? Maybe a retain-mode approach is just inherently (too?) complex?
Correct me if I'm wrong, but I think your answer is in reference to using such a library, and I can certainly see how my question implied that, so sorry for the confusion if this is the case. Thanks for your answer regardless.
At that level it's similar tradeoffs. Consider what the code would look like if it were purely functional. In fact a good answer to your question would be for a thought exercise take a look at how XMonad is implemented in Haskell. That would be a completely different approach to the large, heavily coupled messes that OOP can sometimes lead to when modeling the state as mutable object members.
This is something I've been experimenting with. My intuition is that the scene graph will look a lot more like an AST made from algebraic data structures than an OOP actors network. Down that road, the system looks like an optimizing compiler with the really tricky added bit of iterating in response to user input.
Just rewatched it, and it is a good talk, but i always think the whole OO dismissal is a bit too extreme. I did code "generic data structure + functionnal language" program and "ORM + objects + states" and i didn't find any problem in both cases, because i used it when they were suited.
A document based user application is basically a gigantic state. If you're using generic data structure such as loosely typed maps and sets, with separate functions in various modules for manipulating parts of that structure, you'll end up with a far bigger mess than if you're having a regular three tier MVC code with objects on the model layer (even with an ORM).
I do think, and i have experienced it, that sometimes, regular OO is the good abstraction.
A talk about expressions (c#), it's very usefull if you use the entity framework a lot (like i do).
To bad the author lost the video files (everyone recorded their screen), other video's of the virtual conference are available: http://www.mvcconf.com/videos )
I don't remember having him any tech talks per se. Although there were a few interesting presentations on the NeXT technology with Jobs being a talker, but no one bring these up usually.
Maybe not the 'best', but there's a great short presentation called "Wat" that I really enjoyed that talks about weird behavior in programming languages when operations are performed on variables of different types.
Real Software Engineering, by Glenn Vandenburg. Not a perfect talk (especially the conclusions IMO), but a very good exploration of how some of the common beliefs in the field of software "engineering" came to be, and how something resembling actual engineering practice might be beneficial and practical.
Abstract: "Software engineering as it's taught in universities simply doesn't work. It doesn't produce software systems of high quality, and it doesn't produce them for low cost. Sometimes, even when practiced rigorously, it doesn't produce systems at all.
That's odd, because in every other field, the term "engineering" is reserved for methods that work.
What then, does real software engineering look like? How can we consistently deliver high-quality systems to our customers and employers in a timely fashion and for a reasonable cost? In this session, we'll discuss where software engineering went wrong, and build the case that disciplined Agile methods, far from being "anti-engineering" (as they are often described), actually represent the best of engineering principles applied to the task of software development."
This is a talk about the practical realities of integrating with APIs over the lifetime of a project. In particular, it presents an insightful list of pitfalls API designers often fall into that hamper integration, and it suggests ways to avoid those pitfalls.
Sadly, a decade or so later, many of us are still making the same basic mistakes. If this talk were better known, perhaps we wouldn’t be, so it gets my vote.
Great talk. One of the best. His talk with Gabriel, 50 in 50, is not as good, but still quite fun. Well worth watching, but it is much better in person than on video (saw it at HOPL):
Steele (and Grabriel) are great at doing this talks, they are almost art. Which is why I wouldn't call them so much technical (even growing a language) as they are entertaining and perhaps a bit influential.
He has a series of lectures that explain physics as understood by the modern theoretical physicist. He starts with classical mechanics, goes on to quantum mechanics, special & general relativity, statistical mechanics, and cosmology. The prerequisites are only high school mathematics, he explains the more advanced mathematics as he goes along. The physics that he teaches is condensed, but not dumbed down. It's really how a working theoretical physicist understands physics, "the real deal" as he says. Beware that it's very much a theoretician's viewpoint.
I seem to remember the famous "Diligence, Patience, and Humility" bit by larry wall as reported in the "Open Sources" book was originally a speech. If so I'd vote for that.
Otherwise, at some time I really enjoyed Guy Steele's talks while he was working on Fortress, e.g.
I'm always impressed by Larry's talks. Every time I see him talk about Perl 6 it really makes me want to work on and use Perl 6. So, I'm trying not to see Larry talk, anymore.
The Computer Revolution hasn't happened yet. Alan Kay.
my summary: new tools are first used to do old things a new way. but the revolution is on doing new things and having new thoughts.
Since everyone's already mentioned Rich Hickey's talks, I loved Bjarne Stroustrup's talk on C++11 style: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012... . He provides a crystal clear view of what he thinks C++ could do better and what steps are being taken to move in that direction. Also, I think he has a cool accent.
201 comments
[ 3.4 ms ] story [ 246 ms ] threadThe Golang "Concurrency is not parallelism, it's better" is good too.
Though related to Clojure, they make you think about development in different ways.
[1]: http://www.infoq.com/presentations/Value-Identity-State-Rich...
[2]: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...
[1]: http://www.infoq.com/presentations/Simple-Made-Easy
http://www.youtube.com/watch?v=PUv66718DII
http://lambda-the-ultimate.org/node/4715
You might like it.
Are We There Yet? - http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...
Simple Made Easy - http://www.infoq.com/presentations/Simple-Made-Easy
this one is so far the best by the Guru himself
https://www.youtube.com/watch?v=0SARbwvhupQ
http://www.infoq.com/presentations/Simple-Made-Easy
And also his talk Radical Simplicity: http://skillsmatter.com/podcast/java-jee/radical-simplicity/...
Seem more like a series of really obvious ideas and some platitudes thrown in for good measure.
One that immediately pops to mind is this:
http://vimeo.com/36579366
Any thoughts on how his talk could apply here? Is there a better way?
Correct me if I'm wrong, but I think your answer is in reference to using such a library, and I can certainly see how my question implied that, so sorry for the confusion if this is the case. Thanks for your answer regardless.
A document based user application is basically a gigantic state. If you're using generic data structure such as loosely typed maps and sets, with separate functions in various modules for manipulating parts of that structure, you'll end up with a far bigger mess than if you're having a regular three tier MVC code with objects on the model layer (even with an ORM). I do think, and i have experienced it, that sometimes, regular OO is the good abstraction.
To bad the author lost the video files (everyone recorded their screen), other video's of the virtual conference are available: http://www.mvcconf.com/videos )
Definitely worth a watch
https://www.destroyallsoftware.com/talks/wat
Dr James Grime / Numberphile - Encryption and HUGE numbers http://www.youtube.com/watch?v=M7kEpw1tn50
Les Hazlewood - Designing a Beautiful REST+JSON API http://www.youtube.com/watch?v=5WXYw4J4QOU
classic: Douglas Crockford - JavaScript: The Good Parts http://www.youtube.com/watch?v=hQVTIJBZook
Link: http://www.youtube.com/watch?v=NP9AIUT9nos
Abstract: "Software engineering as it's taught in universities simply doesn't work. It doesn't produce software systems of high quality, and it doesn't produce them for low cost. Sometimes, even when practiced rigorously, it doesn't produce systems at all.
That's odd, because in every other field, the term "engineering" is reserved for methods that work.
What then, does real software engineering look like? How can we consistently deliver high-quality systems to our customers and employers in a timely fashion and for a reasonable cost? In this session, we'll discuss where software engineering went wrong, and build the case that disciplined Agile methods, far from being "anti-engineering" (as they are often described), actually represent the best of engineering principles applied to the task of software development."
http://www.youtube.com/watch?v=neI_Pj558CY
http://mollyrocket.com/9438
This is a talk about the practical realities of integrating with APIs over the lifetime of a project. In particular, it presents an insightful list of pitfalls API designers often fall into that hamper integration, and it suggests ways to avoid those pitfalls.
Sadly, a decade or so later, many of us are still making the same basic mistakes. If this talk were better known, perhaps we wouldn’t be, so it gets my vote.
https://www.youtube.com/watch?v=RlkCdM_f3p4
[edit] Spoiler alert: Everything's in Redis!
http://www.youtube.com/watch?v=_ahvzDzKdB0
http://www.youtube.com/watch?v=Nii1n8PYLrc
https://www.youtube.com/watch?v=0JXhJyTo5V8
Slides:
http://blog.fogus.me/2011/11/15/the-macronomicon-slides/
http://www.slideshare.net/fogus/the-macronomicon-10171952
By Andrew Tanenbaum =^.~=
https://www.youtube.com/watch?v=bx3KuE7UjGA
He has a series of lectures that explain physics as understood by the modern theoretical physicist. He starts with classical mechanics, goes on to quantum mechanics, special & general relativity, statistical mechanics, and cosmology. The prerequisites are only high school mathematics, he explains the more advanced mathematics as he goes along. The physics that he teaches is condensed, but not dumbed down. It's really how a working theoretical physicist understands physics, "the real deal" as he says. Beware that it's very much a theoretician's viewpoint.
Otherwise, at some time I really enjoyed Guy Steele's talks while he was working on Fortress, e.g.
How to Think about Parallel Programming: Not! http://www.infoq.com/presentations/Thinking-Parallel-Program...
http://www.infoq.com/presentations/We-Really-Dont-Know-How-T...