Week 2 exercises

[Michael Douglass]

POTENTIAL EXERCISE SPOILER: If you've not done week 2 yet, you may not want to read ahead.

Week two exercises -- easy.  One question, is everybody's map method done similar to forall() and exists()?  Unless there's some way of obtaining an inverse of a function I'm not sure how else to have approached it.

[Norman Richards]

It it is similar to forall or exists, it can probably be written in
terms of one of those functions.

[Michael Douglass]

Continuing EXERCISE SPOILERS...

Yes, I originally wrote it in the exact same form as forall and exists -- and then after I laid down in bed it dawned on me to write it using one of them.

I realized that he says to do exists in terms of forall -- I honestly had to refresh ("cheat") to remind myself how to transform between forall and exists in first-order logic equations: http://en.wikipedia.org/wiki/First-order_logic

It was then trivial to take my long form of map and rewrite it in terms of the other one -- because I could see the similarities in the two long forms.  HOWEVER, I don't know if I would necessarily take this level of pedantic reuse outside of the academic -- It was trivial to author the original, more full form version of all three of them and took more work to figure out how to degrade them into their "simpler" forms reusing the others.  In practice, correctness of code and speed of authorship often outweigh the academic wholeness.

[Michael Douglass]

Woowoo.  10 out of 10 on the first submission.

[Dan Luu]

This reminds me of a question I've had in the back of my head for a while: what's the point of the exercises? The first set is trivial (probably limited by typing speed) if you've taken a combinatorics class before and still remember the material; the second is similar, but for first-order logic. I could understand it if they covered the material in the class, but it seems like the lectures talk about some concepts and describe some syntax, and then the exercises are supposed to be solved using the same syntax coupled with completely different concepts. 

The first exercise at least illustrated the simplicity of applying inductive reasoning, but I don't get the point of the abstraction employed in the second exercise at all. As Michael points out, in this case, it seems simpler to not use their abstractions. If the exercise is supposed to illustrate that their abstraction, or something similar, can be useful, I'd appreciate it if someone could explain why, because I must be completely missing the point.

I can see why you might want to implement sets that way if you wanted to be able to represent arbitrarily large sets (e.g., x % 2 == 0, or x > 100), but they explicitly remove that case by providing a bound. In that case, it seems like it would be a lot simpler to represent the sets directly. And, even given that we want to use their representation for sets, why not just write the "obvious" implementation for map?

On Saturday, September 29, 2012 3:44:12 PM UTC-5, Michael Douglass wrote:

[Cody Koeninger]

The point of the second group of exercises is to get you comfortable with first class functions - taking them as arguments, returning them as results, using them to construct other functions.  I think it actually did a pretty good job of that.  A set is a function; union is a function that takes two sets (functions) and gives you back another set (function), etc.

I think defining filter, exists, and map using the previously defined functions is a lot simpler than rewriting those concepts each time.  For me, they were all faster to implement that way too.  If you havent seen a for loop before, writing out 10 instructions in a row long-hand probably seems simpler and faster to implement than learning a new abstraction as well (don't laugh, Jon has some funny stories along these lines...)

[Dan Luu]

That's fair; I like your analogy.

[Michael Douglass]

Good points Cody.  That is the whole reason I'm here, after all, to challenge my ways of thinking in programming so that, for better or worse, I might come out with some other techniques under my belt.

That said, I'm not sure a 7 week course is going to be enough.

On Tuesday, October 2, 2012 9:41:42 PM UTC-5, Cody Koeninger wrote:

[Brad Peterson]

MD, I don't know if anybody has done the standard book recommendations yet, but the Little Schemer did more to change my thought patterns than any class.  I think with this class it'll be too easy to get caught up in the specifics of Scala.  The book starts with just lists and builds everything out of that.

[Norman Richards]

On Fri, Oct 5, 2012 at 9:57 AM, Brad Peterson <des...@gmail.com> wrote:
> MD, I don't know if anybody has done the standard book recommendations yet,
> but the Little Schemer did more to change my thought patterns than any
> class. I think with this class it'll be too easy to get caught up in the
> specifics of Scala. The book starts with just lists and builds everything
> out of that.

If anyone is interested in getting as primordial as possible, I'm
going to be giving a Lambda calculus talk at the next Austin
Javascript meetup. I'll show how you can build everything out of
functions with no primitive types or complex structures like lists.
It's purely academic, but spending the time learning lambda calculus
fundamentals has functional programming clear in a whole new way.

Side note - if there's sufficient interest, I'd be glad to do a deeper
dive into lambda calculus for the group than I will do for the
Javascript group.

[Michael Douglass]

When is the next meetup -- is there a website for that group?

[Michael Douglass]

For lazy people like me who like to just click links: http://www.amazon.com/The-Little-Schemer-4th-Edition/dp/0262560992/ref=sr_1_1?ie=UTF8&qid=1349923331&sr=8-1&keywords=Little+Schemer