Simple Made Easy
Recorded at:
- Share
-
- |
Read later
My Reading List
Bio
Rich Hickey, the author of Clojure, is an independent software designer, consultant and application architect with over 20 years of experience in all facets of software development. Rich has worked on scheduling systems, broadcast automation, audio analysis and fingerprinting, database design, yield management, exit poll systems, and machine listening.
Strange Loop is a multi-disciplinary conference that aims to bring together the developers and thinkers building tomorrow's technology in fields such as emerging languages, alternative databases, concurrency, distributed systems, mobile development, and the web.
Video release schedule
by
Alex Miller
BTW, the category theory and monad references in the talk were in relation to Erik Meijer's talk earlier in the conference which unfortunately was not approved for release.
Re: Download Slides
by
mikhail franco
github.com/strangeloop/2011-slides/blob/master/...
Mik
Re: Download Slides
by
Alex Miller
complects
by
Vic Ripa
www.carlopescio.com/2010/11/notes-on-software-d...
www.carlopescio.com/2011/01/notes-on-software-d...
they can be easy followed even without reading the previous chapters :-)
Re: Download Slides
by
Andrew Gwozdziewycz
Nice, funny but without examples - useless
by
Sławomir Sobótka
What is missing, are facts. Maybe examples of non-trivial and non-hello-world problems and code/diagrams with some sort of measurement of complexity.
Personal opinions can be considered but only in the context of some kind of psychological personality types that determines "feeling" of complexity.
That could also help preaching Clojure:)
Re: Nice, funny but without examples - useless
by
Rafal Babinicz
If you want more then his words, you can SIMPLY study some real word examples here: github.com/search?langOverride=&language=Cl... and watch maybe: blip.tv/clojure/clojure-for-java-programmers-1-....
Rich Hickey keynote at Clojure/West
by
Alex Miller
Thanks
by
Machiel Groeneveld
When trying to split things up, some developers are actually uncomfortable of having many components because that feels like it will be hard to find out what is happening where. When working with queues, it's are harder to debug a program.
Jugler
by
Erik van Oosten
Hello
by
Tuomas Hietanen
Also, I'm a fan of Clojure and other multi-paradigm languages (like F# where "active patterns" is kind of "multi-methods").
Some comments:
1)
"Clojure and Haskell refs compose value and time"... So is this like reactive programming?
Like programming set-operations against a set of events (event storage/event loop/audit trail/transaction log/history/whatever you call it)?
2)
Pattern matching is very close to multi-methods ("polyphormism ala carte").
Multi-methods can be used to separate the reasoning from the method. So, yes, you can think it makes this one method simpler. But there is still this reasoning somewhere.
"Polyphormism ala carte" has its places, but replacing matching everywhere as best practice would just hide information (a bit like IoC).
Great, but ...
by
Chris Partridge
However, there is one aspect of complexity that I felt was not really explicitly addressed. This is that a braid like structure is the hallmark of high levels of functionality in nature (see e.g. Figure 9.1 in Reengineering Philosophy, which compares the decomposition of a lump of granite and a fruit fly, illustrating what the book calls descriptive simplicity and complexity). If we want to build highly functional systems, then the challenge is to find some way of capturing descriptive complexity with lego-like components (sometimes called deep simplicity).
Chris
notes from this talk
by
Suraj Gupta
obeautifulcode.com/Craftsmanship/Simple-Softwar...
Citations
by
keynan pratt
Is there any scientific basis for this inference? Can you point me to the literature?
Thanks
How to watch this?
by
Owls Rutherford
Pseudointellectualism
by
It's Me Yo
That crap about the starting pistol, about rebuilding stuff that has been done already may well be applicable to the author's projects, to the author's experiences. But I would posit this: how about you've just been working in bad company, and in a bad company. Because I do t experience the same stuff you do. The key difference is that just because I have experienced it one way, it doesbt mean I am going to pretend that my personal experience is the norm, or should be a basis for a new religion. I can look at it objectively and think to myself: well it looks like this stuff works and this stuff probably doesn't work... in this particular situation.
The thing that irks me with a lot of Medium posts and talks like this is that it's usually a relatively young protagonist who has a limited amount of experience to draw on but insists (not thinks, not hypothesises) but insists they have the answers. These kind of arrogant statements produce a revolution one in every hundred. That's not to say discussion isn't valuable, but of there were less arrogance and more objectivity we would spend less time chasing false idols and more time making progress.
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think