I believe there are two separate concepts here: quickness and simplicity.
I would agree that simplicity makes the system easier to fully understand,
thus making it easier (and usually quicker!) to change later. However, I
believe that simplicity is hard and is generally not the quickest solution.
My one word of caution here is that it's often hard to fully understand a
problem before you roll up your sleeves and start writing some code. IMO,
the quickest way to come up with a solution is often to come up with a
wrong solution first, then throw it away. Similar to how we build
prototypes to
This is Rich Hickey, the creator of Clojure, which is right up there as one
of the best-thought-through pieces of software I've ever seen.
If you haven't read through Clojure's approach to managing mutable state,
it's worth the time.
http://clojure.org/about/state
and also its particular set of
Hey friends!
Today, I sent Sebastian a talk that's made me rethink my development style
and I realized I should open it up to a wider audience:
https://www.youtube.com/watch?v=f84n5oFoZBc
Note: it's development-centric, but not development-specific.
The presenter provides an explicit problem so
4 matches
Mail list logo
