omg, I found Suzzer's contact at Weapon Company X:

:-D

this is a fair enough warning. also, to clarify, i am not arguing that functional ways of doing things are always the best. my main point, as always, is to emphasize matching concepts in code with those that naturally exist in your head.

so if you are doing something to every element of a list, you shouldn't be a using a loop. you should be using map, because map is the reification in code of that concept.

hmmm... i don't know offhand of a set of problems specifically to drill you on map, reduce, etc (though i'm sure they exist), but if you do the first 5-10 problems on exercism.io, you'll find a number of natural opportunities to use them. another helpful exercise would be to look at your code, and whenever you see a "for" loop, stop and try to rewrite it using a functional method and see if it's more natural. for fixed sized loops, it almost always will be.

I sort of see off-handed use of map / filter / reduce / etc akin to building a class and calling that object oriented programming. It may *look* like OO, but it isn't.

If people are really looking to see what all of these things mean, you can try out the requisite chapters of SICP, since the book requires you to build these items up. If you can't be bothered to learn enough lisp to do that, I could do a thread on this stuff. It is easy stuff, and I think it is somewhat enlightening as well.

perfect thanks

i'm always behind a rec for SICP, but you're missing my point if you think that intensive learning or textbook perusal is required to understand these concepts in the way i mean. i'm proposing making connections between these scary-sounding "functional programming" constructs and the you ordinarily think about the world.

"i want you to take all my clothes, clean them, and fold them"

we think naturally at this level of abstraction. we don't think of going through each item of clothing one by one, as with an index, and first cleaning, then folding it. we think primarily of the intended result (stacks of clean, folded clothes) and perhaps also of the initial state (jumbled pile of dirty clothes), but usually not at all of the specifics of the transformation. indeed, if you gave someone the instructions above, you wouldn't care at all how they accomplished the task -- if they did the cleaning and folding one item at a time, or in bulk.

A good rule of thumb for map/reduce type problems is if you want to mutate every value in an array, use map. If you want to boil down an array to a filtered array, use reduce or filter. An example might be...

We are just adding 5 to each number so it makes sense here to use map.

Here we are asking if each number is greater than or equal to 10, add it to the array, otherwise return the previous value. It makes sense to use reduce here since we are *reducing* our original array to an array filtered via some criteria.

What if I wanted to boil a 2D array down to a 1D array? Let's say every element in the new 1D array is the sum of a column (or alternatively row) in the original 2D array.

+memo + elem is shorthand for Number(memo) + elem. We need to make sure memo is a number. If we don't, the final array will be ['123', '456'] instead of the sum of each of the 2d arrays ([6, 15]).

I'm assuming colums in this case is the index of the array of array. For example array[0][1]. If we wanted to add rows it would probably be cleaner to rebuild the original array such that the columns and rows have been reversed. Then we just do the same thing as we did to reduce a 2d array down to a 1d array.

The reverse in case you're interested would be the following. If you didn't know how to do it, you can use the unzip underscore function to invert the 2d array.

ruby one liner:

nice!

Thanks Craggo. Cool way of forcing a number. I usually just multiply by 1. But + is cleaner.

I don't have a problem set but you can do any of the JS ones and should see ample of spots to use them (myArray.filter/map/reduce).
Conceptually the "big three" are rather simple:
filter=pass stuff through only if true, toss everything else
map=apply some operation to all elements
reduce=turn the collection into a single value (typical example being adding all values of a collection to get a total)

> var x = [1,2,3,4];
undefined
> x
[ 1, 2, 3, 4 ]
> x.filter(function(e){return e%2==0});
[ 2, 4 ]
> x.map(function(e){return e*2;});
[ 2, 4, 6, 8 ]
> x.reduce(function(e,e2){return e+e2;});
10

So yeah easiest example is map in place of array iteration with a for loop.

Don't aim so high. It's a good first step if you can read your own code after a couple of weeks (no this is not a snide remark or joke). so the first step should be to structure your code in a way that makes perfect sense to yourself.

I'm not sure I agree with this 100% of the time. There's value in perfecting mundane things and striving for that as a general mindset. Maybe I've spent too much time with Japanese coworkers* but when I'm at my best** I won't move on until I see no further improvements for now. Let me keep on dreaming about sushi
Interestingly it's also opposed to the general mantra of avoiding premature optimization if you take that mantra out of the algorithmic context.

*interesting aside: one of them would write a test, write some code, rinse repeat until he had a working version that covered the functional requirements (standard TDD) but then...delete everything and redo it. He used to say "before I send code to my review partner (for the commit) I rewrite it from scratch".
Strange might seem inefficient but he wrote very elegant code imo (often mindblowing yet simple). He told me that's how he always does it and sometimes he starts over a second time (also sometimes at different spots). He also did katas every morning which I hadn't seen before.
Needless to say he did everything tons faster than me despite the rewriting madness.
**rarely obviously

Intro classes here use javafx. Which is already strange to me because...mobile/WWW-world yo.

http://lwn.net/SubscriberLink/641779/474137b50693725a/

From the guy misattributed with creating django

Thoughts? Feels?

Totally. There are all kinds of programmers all over the spectrum imo. However there have been studies, and this goes along with my general feeling - that a rock star programmer is like 40 times more productive than an average programmer. Also a truly terrible programmer is going to create productivity drains on every one around them.

So while the distribution may be more flat than a U-shaped curve, the productivity chart might look something like this:

Oh and:

Fixed.

Lol Larry. Kind of true in my experience. A very talented co-worker spent almost a week writing this module to make something simple even easier. It's been used twice since saving a whopping 8 lines of code

A cite of the studies would be interesting to find out how productivity was measured.

True rock stars know where and when to apply their talents for the best leverage. A super-talented programmer who wastes time on white whale vanity projects isn't a rock star any more than a poker player who can make great reads but does other dumb stuff is a great poker player.

It's in some book I read that actually said "up to 38 times more productive" - because 40 times sounded too much like a number they just pulled out of their ass I'm guessing. Lol at measuring programmer productivity to that level of precision.

But anyway I do feel like just in making good decisions up front and steering away from roads that lead to trouble - a really great programmer saves a **** ton of productivity over the life-cycle of the product vs. an average programmer.

Glad you like it, and surprised you can read it.

I think of map as interleaving. I think the Ruby does this, but I'm not sure why you didn't do this directly.