5 ms·
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 coupl
by ghotli 14y ago
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.
http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
- emil0r 14y agoI second Simple Made Easy. It put into words what I thought was wrong but never could formulate.
- deleted 14y ago[deleted]
- jacobolus 14y agoAlso 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 http://www.youtube.com/watch?v=cidchWg74Y4 And also his talk Radical Simplicity: http://skillsmatter.com/podcast/java-jee/radical-simplicity/js-2051 http://skillsmatter.com/podcast/java-jee/radical-simplicity/...
- coldtea 14y agoDon't know, I like Clojure and Hickey, but I've never got much out of his talks. Seem more like a series of really obvious ideas and some platitudes thrown in for good measure.
- marshray 14y agoSo what's your favorite talk then?
- zerr 14y agoExactly. Except, ironically, I happen to like only Hickey, not Clojure. Rich has some great mood in his talks, and also makes good articulations.
- lifeisstillgood 14y agoReally, I nose-snorted coffee over this one: - 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!
- toufique 14y agoI third Simple Made Easy. Totally changed the way I think about complexity.
- toufique 14y agoI third Simple Made Easy. Totally changed the way I think about complexity.
- dougk16 14y agoJust 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?
- ghotli 14y agoView 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.
- dougk16 14y agoI 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.
- ghotli 14y agoAt 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.
- bsaul 14y agoJust 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.
- freijus 14y agoKind of off-topic: I can't manage to see any video, is it slides and mp3 only ?