On Oct 21, 2011, at 4:03 PM, Rich Hickey wrote:
> I like nil punning, and find it to be a great source of generalization and
> reduction of edge cases overall, while admitting the introduction of edges in
> specific cases. I am with Tim in preferring CL's approach over Scheme's, and
> will adm
Or:
(if-let [[_ v] (find my-map key)]
v
:something-else)
On Tue, Oct 25, 2011 at 1:19 AM, Sean Corfield wrote:
> On Fri, Oct 21, 2011 at 10:05 AM, Michael Forster
> wrote:
> > Yes: Was that a nil value for the key :foo in my map or did :foo not
> > exist?
>
> If you need to distinguish b
On Fri, Oct 21, 2011 at 10:05 AM, Michael Forster wrote:
> Yes: Was that a nil value for the key :foo in my map or did :foo not
> exist?
If you need to distinguish between ":foo is missing" and ":foo's value
indicates non-existence", what about:
(get my-map :foo ::missing)
--
Sean A Corfield -
On Fri, Oct 21, 2011 at 8:35 AM, Timothy Baldridge wrote:
[...]
> What Rich is advocating is this: throw all the data into a hashmap.
> Suddenly, my SQL driver can just dump data in to the map, I can throw
[...]
I suspect he might have meant even more when he said, "... learn SQL, finally."
SQL
On Fri, Oct 21, 2011 at 11:50 AM, Mark Engelberg
wrote:
> I've always felt that Clojure's treatment of nil was somehow inconsistent
> with the elegance of many other features of Clojure. Now I can finally
> articulate why: nil complects non-existence, false, and empty.
>
> The choice to make nil
On Fri, Oct 21, 2011 at 12:38 PM, daly wrote:
[...]
> Having used lisp in many different forms over the last 40 years
> I think that the "complecting" of nil to represent all three
> concepts is one of the most brilliant aspects of the language.
> In fact it is one of the key flaws of scheme, in m
And one more thing to say about polymorphism.
In functional programing protocols are OO polymorphism inside out.
It is possible because FP doesn't care of state, its operates only on
its input and gives outputs (it is by definition - functional).
We are taught from very beginning how to function in
Having watched Rich's talk yesterday, then Stu's "Simple Ain't Easy"
talk an hour ago, I've been trying to wrap my head around this.
What are the benefits of simplicity in the non-compound sense? Stu
mentioned that often we think of simplicity in terms of counting
things and then sort of brushed
On Oct 21, 2011, at 5:37 PM, daly wrote:
> Rich,
>
> My apologies that what I have said about nil punning came across
> as criticism directed at you.
It certainly didn't come across that way - no worries :-)
Rich
--
You received this message because you are subscribed to the Google
Groups "
Rich,
My apologies that what I have said about nil punning came across
as criticism directed at you. That was not intentional. I have
the highest respect for your design work. You're doing an amazing
job and I continue to learn from you.
I understand the lazy vs empty issue and I think you made a
Bravo, bravo! Great speech, I'm already looking for such esseys. I'm
already learning haskell and erlang for great good, because all things
told about lisp has been already read.
I'm also designing system. Because it has some well defined
functionality, my first tought was, hey man I will use obec
This message is not specifically in reply to Tim, but to the thread in general.
It can be very difficult to enumerate (or even remember :) all of the
contending tradeoffs around something like Clojure's nil handling.
The is no doubt nil punning is a form of complecting. But you don't completely
On Fri, 2011-10-21 at 15:41 -0400, David Nolen wrote:
> Just because we have dynamic types does not give us the freedom to not
> consider them.
If all of these dynamics types and all of the tests "respected nil"
in its many meanings then
(when s ...,
(when (seq s)...,
(when (empty? s)...,
On Fri, Oct 21, 2011 at 4:02 PM, Mark Engelberg wrote:
> On Fri, Oct 21, 2011 at 12:41 PM, David Nolen
> wrote:
> > Just because we have dynamic types does not give us the freedom to not
> > consider them.
>
> Oh, I definitely considered the types when I wrote the function. It's
> just that at t
> (because test cases are written by the coder who has a
> specific intention in mind)
>
Good observation. When I see figures of tests coverage I wonder how
many flow paths aren't being covered simply because they don't exists
but they should.
--
You received this message because you are subscr
On Fri, 2011-10-21 at 12:36 -0700, Mark Engelberg wrote:
> On Fri, Oct 21, 2011 at 11:43 AM, Mark Engelberg
> wrote:
> >> How does nil represent empty? '() does not equal nil.
> >
> > (cons 1 nil) is one obvious example.
> >
> > The pattern of using first/next/nil? as a more efficient/compact
> >
On Fri, Oct 21, 2011 at 12:41 PM, David Nolen wrote:
> Just because we have dynamic types does not give us the freedom to not
> consider them.
Oh, I definitely considered the types when I wrote the function. It's
just that at the time I wrote it, I was confident the input would
already be seq-if
Just because we have dynamic types does not give us the freedom to not
consider them.
(when s
...)
Does not communicate anything about collections - only nil, false or
something else.
(when (seq s)
...)
(when (empty? s)
...)
Clearly express a consideration about the types at play.
Davi
On Fri, Oct 21, 2011 at 11:43 AM, Mark Engelberg
wrote:
>> How does nil represent empty? '() does not equal nil.
>
> (cons 1 nil) is one obvious example.
>
> The pattern of using first/next/nil? as a more efficient/compact
> alternative to first/rest/empty? is arguably another.
>
One more anecdot
On Fri, Oct 21, 2011 at 11:22 AM, David Nolen wrote:
> Collections often include false as a value. You will have to handle it by
> using some other value like ::not-found.
>
> David
True, but the multiple meanings of nil creates additional complexity.
Contrast, for example, (filter identity s) an
On Fri, Oct 21, 2011 at 11:08 AM, Thorsten Wilms wrote:
> On 10/21/2011 06:50 PM, Mark Engelberg wrote:
>>
>> Now I can finally articulate why: nil complects non-existence, false,
>> and empty.
>
> How does nil represent empty? '() does not equal nil.
(cons 1 nil) is one obvious example.
The pa
> nil complects non-existence, false, and empty.
Let's explore that a little further:
* Non-existence
- Accessing a local or var that has never been declared
* False
- (if nil :never-here :but-here)
* Empty
- (seq [])
And maybe there is another?
* Not set
- (def x)
- (:x {:a 1})
But
Collections often include false as a value. You will have to handle it by
using some other value like ::not-found.
David
On Fri, Oct 21, 2011 at 12:50 PM, Mark Engelberg
wrote:
> I've always felt that Clojure's treatment of nil was somehow inconsistent
> with the elegance of many other features
On 10/21/2011 06:50 PM, Mark Engelberg wrote:
Now I can finally articulate why: nil complects non-existence, false,
and empty.
How does nil represent empty? '() does not equal nil.
It is also easy in the sense that it is more similar to what Lisp users (as
opposed to Scheme) are used to fro
On Fri, Oct 21, 2011 at 10:38 AM, daly wrote:
> If I understand your post correctly you feel that nil should
> ONLY represent the concept of a missing value. It should not
> represent false and empty.
Yes, you correctly interpreted my post. That is my opinion.
> The context of the nil value
> c
If I understand your post correctly you feel that nil should
ONLY represent the concept of a missing value. It should not
represent false and empty.
Having used lisp in many different forms over the last 40 years
I think that the "complecting" of nil to represent all three
concepts is one of the m
I've always felt that Clojure's treatment of nil was somehow inconsistent
with the elegance of many other features of Clojure. Now I can finally
articulate why: nil complects non-existence, false, and empty.
The choice to make nil represent so many concepts was an "easy" choice,
because it saves
Hey Timothy,
Thanks for the response, I currently perform some of these steps. My data is
taken out of mongodb and converted into straight clojure maps. I pass these
around in my application, calling validation functions on them etc. Having
said that, this talk will push me to take a good look
Great talk!
I got lost a bit in the Abstraction for Simplicity. Could anybody provide me
some concrete examples for Who When Where Why slides?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups
Wow. Easily the best conference talk I have seen... well, ever.
Executive summary: "Mutability is bad for your complection." :)
- Chris
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
No
> And how would one structure something as stateful as a web app using these
> techniques? Hopefully someone can point to a pre-existing example that
> follows all or many of these ideas.
I currently work on a thick-client system. But our back-end is quite
stateless. One thing that irks me the mos
Ok I watched the talk, and I picked up a few things. But I have questions,
which hopefully some kind member in the community can answer.
There are several instances of libraries Rich mentions that provide simple
constructs so what clojure libraries provide, set functions and rules (is it
core.l
I can understand your situation because I've seen a C# code where most of
the classes in some 5-6 different assemblies had all (or 90%) static methods
:)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@go
As a person currently suffering under the load of a highly entangled
system here at work, I really appreciated this talk. The software I'm
currently working on is so entangled, so strongly typed, that we have
some parts of our app even our Architect doesn't want to touch. It's
almost as if Rich loo
In the Simple-Made-Easy talk Rich raises the question
of long term use. In particular, he mentions the issue
of maintenance and change.
In order to change software you need to understand the
program. Unfortunately most people equate "understanding
the program" as being equivalent to "what the func
The video is up:
http://www.infoq.com/presentations/Simple-Made-Easy
Places to watch for comments (or vote if you like):
- http://news.ycombinator.com/item?id=3135185
-
http://www.reddit.com/r/programming/comments/lirke/simple_made_easy_by_rich_hickey_video/
- http://www.dzone.com/links/simple_
36 matches
Mail list logo
