71–80 of 104 posts
At 55:20 he says, if you have A calling B all the time, you should "Stick a queue in there." What is an example of this?
Earlier quoted context omitted.
If you mean just the slides, most of them are in this github repo: https://github.com/strangeloop/2011-slides
For some reason, these slides are only available in a flash widget that's synchronized with the video. Here's a little script to grab the flash and build a PDF for yourself. ImageMagick and swftools required. #!/bin/bash for s in {1..39}; do wget http://www.infoq.com/resource/presentations/Simple-Made-Easy/en/slides/$s.swf; done for swf in *.swf; do swfrender $swf -o $swf.png && rm $swf; done convert `ls *.png -x1 |…
Earlier quoted context omitted.
Why do you consider code generators, monkey patching & DSLs to be "testing tools"?
I don't. I refer here only to their use in that context.
(I don't disagree with your main point, but I don't quite see where those techniques fit in).
Great presentation, but it got me thinking. Am I wasting my time trying to get software just right? Is it worth my time to learn Clojure or Haskell, when I don't even know what I'll use it for? How many programmers do you know that are learning all kinds of languages and technologies and methodologies and other things to improve the quality of the software they write and yet will probably sit at a desk writing code f…
Don't we all want to "get software just right"?
"Is it worth my time to learn Clojure or Haskell, when I don't even know what I'll use it for?"
Reasonable question. Pick a project, choose a language. I introduced Scala where I work and it solved a problem but wasn't optimal for our team. Then I introduced Clojure and that's working better for us. Real world problem solutions will help you validate your choices (there was a great talk at The Strange Loop on real world Haskell usage at a startup, BTW).
"What if he spent his time learning Lisp and Monads instead of writing an app that lots of people use?"
Like Paul Graham? (Viaweb)
For me this was the best talk I've seen in a long while. It reminded me of how I felt when I first read PG's essays, someone articulating your own suspicions whilst going further and deeper and bringing you to a place of enlightenment and clarity. BTW for those of you who haven't watched it, this talk is not Clojure specific.
All of Rich's talks are great: http://www.infoq.com/author/Rich-Hickey
If you liked this talk, then you will definitely like "Are We There Yet?" In it, Hickey argues that most popular object-oriented languages make similar mistakes by bundling identity, time and state into objects. He discusses how we might simplify programming by separating these components and rethinking each.
It has a similar theme but focuses on one concrete issue in depth. It has a similar philosophical style while remaining clear-headed and practical. And, in my opinion, it is similarly enlightening. If you couldn't tell by now, I recommend it :)
Earlier quoted context omitted.
The slide where this comes up (~15:45) is about debugging. I think the point Rich is trying to make on that slide is that a bug in production passed the type checker and all the tests. Therefore, tests are not solving the problem of building high quality systems. Rather, tests (and type safety) are "guardrails" that warn when you when you are doing something wrong (they are reactive). As Rich said on Twitter ( https:…
Okay, follow up, I watched half of the talk. Wow. What an insightful guy. I really enjoyed what I heard so far. The section about testing and guardrails seems to have been blown way out of proportion. I fervently believe in Agile/XP practices, TDD and all such good things. But I'm not naive enough to say that "because I have tests, nothing can go wrong". And that seems to be his main point here. It makes me think...i…
I guess it's just that isn't it. There's a lot of talk here about what Rich might have/probably implied. I suppose it would have been infinitely more helpful if he would have just been explicit about it as opposed to projecting a slightly philosophical [sic] point of view.
Earlier quoted context omitted.
For some reason, these slides are only available in a flash widget that's synchronized with the video. Here's a little script to grab the flash and build a PDF for yourself. ImageMagick and swftools required. #!/bin/bash for s in {1..39}; do wget http://www.infoq.com/resource/presentations/Simple-Made-Easy/en/slides/$s.swf; done for swf in *.swf; do swfrender $swf -o $swf.png && rm $swf; done convert `ls *.png -x1 |…
I agree with "teach a man to fish ...", but you know, some people are far away from the sea (linux) so just providing them with the fish (pdf) is also a good option.
Earlier quoted context omitted.
I kinda regret having chosen Clojure for my project. Its not that I can't express ideas in very little code, its just that my workflow is different from languages like Python. In Clojure, it seems that I can't apply the method of spike solution ( http://c2.com/cgi/wiki?SpikeSolution ) and then refactor it into working code like I do with languages like Python or C.
I'm curious why you feel you can't create spike solutions in Clojure?
A good talk. Leave it to a lisper though to call testing and type-checking "guardrail programming". Hickey says instead you should reason about your programming without acknowledging that testing and type-checking are ways to have executable documentation of your reasoning about your program. Testing does in fact feedback into complexity - if something is hard to test it may be due to complexity that you realize you…
Difficulty of writing a test can certainly be a complexity indicator, but in my experience the evidence is against testing having served this purpose very well to date, at least for the kinds of complexity addressed in this talk. If you look at around 31:27 in the talk, you will see ten complex things, with proposed simple alternatives. If testing helped people feel the pain of complexity and discover simple things,…
http://clojure-libraries.appspot.com/category/137002
my 2 cents