You'll quickly get the coolest functions if you do the problems on 4clojure.com. Checking solutions of the best users after my own was enlightening. The typical compression ratio is a 7 lines nested monster with loops to a one line snippet :)
By the way, after 4clojure 'apply' would be within my top 10. It might not look like much (man, I can call my fns directly!) but the fact it can prepend individual arguments to the sequence makes it a very useful tool: (apply mapv vector m) transposes m (assuming vector of vectors). Cool, huh? My own transpose would not be that terse :)
> Not to be confused with empty?, which returns whether or not a collection is empty, empty returns an empty collection that is the same type as its argument:
No, actually, it returns an empty collection that is the same type as its argument OR NIL.
The 'or nil' is really important, and what makes `empty` really not that useful.
Say, for example, that I wanted to iterate over a generic collection, and modify each element recursively, while preserving the types. One would think this would work:
Alas. You'll find that while maps are in theory lists of vector pair
(empty (first {:a 1})) => nil
So empty really isn't very useful at all. If you know the collection will be one of the types that it supports, you might as well just create the empty collection explicitly - you know what type it is, after all.
user=> (doc vector?)
-------------------------
clojure.core/vector?
([x])
Return true if x implements IPersistentVector
nil
So `MapEntry` implements `IPersistentVector`, but is not a vector. It does not make sense to have an empty `MapEntry`, so IMHO the behavior implemented is valid.
'Hey, if I peek under the abstraction, it all makes sense'. Obviously. The code does what it's written to do. That doesn't make such leaky abstractions okay. `vector?` is, AFAIK, the way to check if something is a vector, and if empty doesn't work on some `vector?`s, then i can't trust it.
empty mapentry returning nil is meh. If it returned an empty vector it'd be what you want 99% of the time.
Keep in mind that read-string, eval, and load-string are all exploit vectors. Read-string exposes you to the #= eval macro, which can execute arbitrary code at read time, as well as various vulnerabilities with object construction.
Eval executes the data it receives without any sandboxing or sanity checking, any data that has ever had any user influence should be suspect. 9 times out of 10, if you're using eval, you should be using a function reference.
Load-string is likewise vulnerable to the eval macro and constructor attack vectors.
clojure.edn offers safe versions of read and read-string that do not use the eval macro. You can get load-string equivalent behavior by wrapping the string in a StringReader and then clojure.edn/reading it until eof. If you're reading data that's had any influence from an end user, always use the clojure.edn facilities, and never eval it.
Take a look at postwalk: "Performs a depth-first, post-order traversal of form. Calls f on each sub-form, uses f's return value in place of the original. Recognizes all Clojure data structures. Consumes seqs as with doall."
Personally I do not understand the utility of "pmap" - seems interesting, but in practice there are really few scenarios in which it is actually useful. And btw, the given example is extremely awful. Yes I understand it's trying to simulate a long running computation, but that's the problem - if you want to parallelize long running computation, then pmap is not what you want.
> "but in practice there are really few scenarios in which it is actually useful"
Not true. Parallel mapping is a useful tool for multi-core systems. Clojure (and other languages) include a `pmap` because it provides a simple, elegant way to do parallel computation.
If you want parallel mapping with more control, check out Claypoole:
> Basically, we just wanted a better pmap. Clojure’s pmap is pretty awesome, but we wanted to be able to control the number of threads we were using, and it was nice to get a few other bonus features.
In my experience with code that does data ingest and manipulation, assoc-in and update-in are probably the most useful functions.
Why? As you get used to functional programming, you look for ways to reach in and 'update'* nested data structures. Since you don't have object dot notation, you need another way.
* By 'update' I mean to return a new persistent data structure with a small change.
Don't understand why you would need seperate functions for those three first. map-keys would basically just be map with (keys coll), map-values would be with (vals coll) and entries would just be a normal map, as hashmaps in Clojure are seqs and mapping over hashmap returns entries as [key val]. A simple destructuring in your map function and you're good to go.
Don't quite understand what group-by-1 and group-by-2 does though. Elaborate?
The need of repeating exactly the same destructuring or transformation (keys, uncurrying tuple) constaints your thought. You need to have an instrument that fits your domain perfectly.
group-by-[12] groups a [[k, v]] list by either k or v, of course you can do this with group-by first, but see above.
Map-reduce enthusiasts were wrong: the two fundamental functions are not map and reduce, rather zip-with and group-by. If you want to do real work done.
I've heard Google learned this lesson and their data processing now rests upon these two.
`zip-with` and `group-by` just represent the most common uses of `map` and `reduce` respectively. Many data processing frameworks (cascading, spark, storm, etc.) build these abstractions right on top of map-reduce, and sometimes the layer is pretty thin.
or something else? Without showing what your zip-with (and all the other 'missing' things) implementation looks like, people need to guess what they are and why these might be useful.
All standard tools. I don't know what your definition of zip-with is, but it certainly differs from the one I'm used to from Haskell, and it seems like other people disagree with you as well (but I suppose you'll just consider me 'constrainer' or whatever as well).
Ah, I see. I'm not sure I'd call it zip-with, but it's definitely familiar and useful. Scalding calls it map-to[1], and Trident's `each` can work this way as well.
You keep repeating this, and I find it ill-thought. Clojure offers lots of hammers, saws, drills and other tools.
But you seem like you want millions of them -- a hardware store all your own.
More is not always better, and you don't need to have a tool for every little specialized case (nor it's good for your coding -- fewer but solid abstractions and a set of tools that can be combined to build the most elaborate structures are better than an explosion of tools for everything).
It seems you had to explain all but the first three in this thread.
That suggests to me that these are potentially nice shortcuts for you personally, but they might be more confusing than the well-defined standard building blocks you try to hide in shared code..
I flagged this story, to point out to the moderators that the title should be changed to “Cool Clojure functions” (it is currently “20 cool Clojure functions”).
By the way, after 4clojure 'apply' would be within my top 10. It might not look like much (man, I can call my fns directly!) but the fact it can prepend individual arguments to the sequence makes it a very useful tool: (apply mapv vector m) transposes m (assuming vector of vectors). Cool, huh? My own transpose would not be that terse :)