Re: Too over complicated

[Alan Thompson]

Olek - You may find some of the convience functions you are missing in the
Tupelo library.  In particular:

https://github.com/cloojure/tupelo#convenience-in-testing-seqs
https://github.com/cloojure/tupelo#keeping-it-simple-with-not-nil

Keeping It Simple with not-nil?

Clojure has the build-in function some to return the first *truthy value* from
a *sequence* argument. It also has the poorly named function some? which
returns the *value* true if a *scalar* argument satisfies (not (nil? arg)).
It is easy to confuse someand some?, not only in their return type but also
in the argument they accept (sequence or scalar). In keeping with the style
for other basic test functions, we provide the function not-nil? as the
opposite of nil?.

The unit tests show how not-nil? leads to a more natural code syntax:

(let [data [true :a 'my-symbol 1 "hello" \x false nil] ]
  (let [notties   (keep-if not-nil? data)
nillies   (drop-if not-nil? data) ]
(is (and  (= notties [true :a 'my-symbol 1 "hello" \x false] )
  (= nillies [nil] )))
(is (every?   not-nil? notties)); the 'not' can be used
(is (not-any? nil? notties)))   ;   in either first or 2nd positon

  (let [count-if (comp count keep-if) ]
(let [num-valid-1 (count-if some?data); awkward
phrasing, doesn't feel natural
  num-valid-2 (count-if not-nil? data); matches intent
much better
  num-nil (count-if nil? data) ]  ; intent is plain
  (is (and (= 7 num-valid-1 num-valid-2 )
   (= 1 num-nil))


Enjoy!
Alan



On Sat, Jun 18, 2016 at 5:56 PM, James Reeves  wrote:

> On 19 June 2016 at 00:07, Olek  wrote:
>>
>> Now lets talk about "difficulties" which I have found.
>> For example when we talk about removing element from collection.
>>
>> Why there is no one operation which could behave the same for set,
>> vector, list, string, and map? Let the community talk by themselves:
>> http://stackoverflow.com/questions/28844647/why-are-disj-and-dissoc-distinct-functions-in-clojure
>>
>
> I guess the difference is intent, but you'd have to ask Rich.
>
>
>> Why there is no one operation for checking if an element is in a
>> collection/keys of map/string?
>>
>> http://stackoverflow.com/questions/3249334/test-whether-a-list-contains-a-specific-value-in-clojure
>>
>
> You can use "some" to achieve this effect for most collections. Maps are a
> little tricky, because you could be checking for the existence of a key, a
> value, or a key-value pair.
>
> It might be nice to have an "includes?" function, though, particularly one
> that was more efficient.
>
>
>> There is no even simple method for saying that element is not a nil. This
>> requires from me the (not (nil? %)) combo.
>>
>
> There is. "clojure.core/some?" is the same as #(not (nil? #)).
>
> - James
>
> --
> 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
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Too over complicated

[James Reeves]

On 19 June 2016 at 00:07, Olek  wrote:
>
> Now lets talk about "difficulties" which I have found.
> For example when we talk about removing element from collection.
>
> Why there is no one operation which could behave the same for set, vector,
> list, string, and map? Let the community talk by themselves:
> http://stackoverflow.com/questions/28844647/why-are-disj-and-dissoc-distinct-functions-in-clojure
>

I guess the difference is intent, but you'd have to ask Rich.


> Why there is no one operation for checking if an element is in a
> collection/keys of map/string?
>
> http://stackoverflow.com/questions/3249334/test-whether-a-list-contains-a-specific-value-in-clojure
>

You can use "some" to achieve this effect for most collections. Maps are a
little tricky, because you could be checking for the existence of a key, a
value, or a key-value pair.

It might be nice to have an "includes?" function, though, particularly one
that was more efficient.


> There is no even simple method for saying that element is not a nil. This
> requires from me the (not (nil? %)) combo.
>

There is. "clojure.core/some?" is the same as #(not (nil? #)).

- James

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Too over complicated

[Matching Socks]

The Clojure Cheatsheet can be very helpful if you are experiencing a shock 
of re-entry to clojure.core after a few years of relatively finite Javadoc 
pages of 10 methods per class.  It is fun to chuckle at Alan Perlis' 
aphorism about 100 functions vs 10 each for 10 classes, but when you swing 
open clojure.core and see what 100 functions looks like, it is a bit 
sobering at first.  Emerick, Carper & Grand's "Clojure Programming" does a 
particularly good job of making it all make sense.

I sure wouldn't mind if "contains?" threw.  Perhaps the coming clojure.spec 
instrumentation of clojure.core will address that.

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Too over complicated

[Olek]

Hi!

I've back to Clojure env. after 3 years of absence.

I have started to code in my best language ever and was hit by some 
difficulties with the simplest things on earth
I remember when I first dived into language and started coding in it. After 
4 months of heavy doc/forum/irc usage I was able to quickly express myself 
in the Clojure. All for then was for me clear, natural and easy.

Now after some long brake I'm back and now I can make some critics on the 
language sine I know what Clojure can offer me and I know what from concise 
dynamic language with abstraction in mind I should expect.

Now lets talk about "difficulties" which I have found.
For example when we talk about removing element from collection.

Why there is no one operation which could behave the same for set, vector, 
list, string, and map? Let the community talk by 
themselves: 
http://stackoverflow.com/questions/28844647/why-are-disj-and-dissoc-distinct-functions-in-clojure

Why there is no one operation for checking if an element is in a 
collection/keys of map/string?
http://stackoverflow.com/questions/3249334/test-whether-a-list-contains-a-specific-value-in-clojure

There is no even simple method for saying that element is not a nil. This 
requires from me the (not (nil? %)) combo.

Now how suppose the world should pray to Clojure when they are unable to 
accomplish these simplest ops?

Just add these simple functions to the core lib so the new comers won't 
whine on Clojure and when they get mature and more comfortable with Clojure 
they will just use the "core & idiomatic" set of functions.

-- 
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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.