Teachers!

For last few weeks I have been studying online with Andrew Ng on coursera.org  and Salman Khan on khanacademy.org. Both them are superb teachers and I observed these similarities:

• They have a very warm and straight forward approach while discussing matters.
• A good sense of humor.
• They know what to hide and what to share on a topic. When you have teachers like that even an average learner like me won't get intimidated with the vastness and complexities of subjects.
• They strongly encourage learning attitude against the attitude of outshining others. 
• They are very modest and always discuss their shares of failures very constructively.

This is going great! May they continue to succeed in their endeavors!

Lost in Scala's support for partial function and currying

scala> def x(s:Int, t:Int) =  s+t
x: (s: Int, t: Int)Int

scala> def x2(s:Int)(t:Int) = s+t
x2: (s: Int)(t: Int)Int

scala> def x3(s:Int) = (t:Int) => s+t
x3: (s: Int)Int => Int

scala> (x(_,_)).curried
res0: Int => Int => Int = <function1>

scala> (x2(_:Int)(_:Int)).curried
res4: Int => Int => Int = <function1>

scala> x2(_)

res13: Int => Int => Int = <function1>

scala> x3(_)

res19: Int => Int => Int = <function1>

scala> x2(1)(2)

res11: Int = 3

scala> x3(1)(2)

res10: Int = 3

scala> res0(1)(2)

res8: Int = 3

scala> res4(1)(2)

res9: Int = 3

scala> res13(1)(2)

res16: Int = 3

scala> res19(1)(2)

res20: Int = 3

Although by the classical functional programming concepts of currying and partial functions x2, x3, res0, res4, res13 and res19 all of them are same, but they are still so different in Scala.

What could be the reason behind this approach which could be very intimidating to the newbies?
Could it be the burden of supporting object-oriented concepts like method overriding via inheritance where method signature plays an important role?
One thing is sure that Scala's syntax design is very poor and full of gotchas.

Common Problem solving with fp and oop ways

The fundamental basis of common problem solving is to split a problem into smaller problems, smaller problems with one angle/factor/context at a time.

Then try to solve each one of them in seclusion, avoid mixing contexts as much as possible while solving them.

Now once they are solved individually compose them back to get the grand final solution. It will work if the contexts and the solutions both are composable.

Even with my limited knowledge of functional programming concepts I can see the above scheme fitting it nearly well. While solving it FP way I am focussing exactly on the behavior and the solution. Composition of smaller solution units as functions are deeply engrained in the paradigm. I have just one entity to worry about while composing: function/behavior. Things tend to be precise. Although the learning curve is sharp it tends to fall in place sooner or later.

Now that I have been exposed to little of FP, I have started to realise where object-oriented is not working. With that of mainstream object-oriented concepts, I start with the classes. The splitting of the problem and appearance of classes look cool and encouraging. Things look great and beautiful during the splitting phase. But when the time comes to compose the solutions back to the big picture, it tends to start getting ugly. I think the main reason behind this hurdle is that now we are trying to compose the solution at two levels: class and behavior. If I focus on class composition then the behavior tends to either underfit or overfit the desired solution. If I focus on the behavior composition then the classes start to look mixed and weird. Statefulness of the classes add another level of complexity. So now we have to deal with three types of complexities at a time.

Scala is trying to bridge the gap with its hybrid approach, but have you looked at the trio of class/trait/object? They are so hairy, full of details, so much detail! As expected the functional part is hard anyway.

The contemporary programmers like me are going through so much of flux, confusion, trial and errors and brain bending phases. But it is fun of course. Let the wheels keep rolling. :)

Scala implicit: confusing

scala> implicit val x=23
x: Int = 23
scala> def dos(implicit d:Int)(s:Int) = println(d+s)
:1: error: '=' expected but '(' found.
       def dos(implicit d:Int)(s:Int) = println(d+s)
                              ^
scala> def dos(s:Int)(implicit d:Int) = println(d+s)
dos: (s: Int)(implicit d: Int)Unit

So the implicit argument can't be the first one on a curried function.

scala> def dos(d: Int, implicit s: Int) = println(d+s)
:1: error: identifier expected but 'implicit' found.
       def dos(d: Int, implicit s: Int) = println(d+s)
                       ^

Can't declare an argument as implicit if it is not the first one on a non-curried function.

scala> def dos(implicit d:Int, s: Int) = println(d+s)
dos: (implicit d: Int, implicit s: Int)Unit

First argument of a non-curried function can be implicit but the rest of the arguments automatically become implicit!

Those parentheses in inline anonymous function application in Scala

scala> (x:Int,y:Int)=>x+y
res26: (Int, Int) => Int =

scala> res26(_:Int,10)
res27: Int => Int =

scala> res27(1)
res28: Int = 11

scala> res26(_:Int,10)(1)
:9: error: Int does not take parameters
              res26(_:Int,10)(1)
                             ^

scala> (res26(_:Int,10))(1)
res30: Int = 11

Programming language not based on boolean algebra

Programming languages are designed to be executed by a machine which understands Boolean Algebra. Naturally to express an idea in these programming languages one will have to totally unambiguous. Encapsulation and Abstraction concepts of prgramming languages try hard to hide or abstract the context in which the programmer tries to express something. But sooner or later it gets very complex.
Although I have very limited understanding of Fuzzy logic and similar mathematical/statistical concepts, but can we develop some programming language which is based on these foundations rather on Boolean Algebra? Or is it already there?
What I am vaguely imagining is a platform:
1. Is a composition of context bound expressions.
2. Would start with very contextual expressions and assume that they are correct and totally discrete and unambiguous.
3. Working towards the common goal of the program, when these expressions interact with others then there respective contexts should be corrected so that they make sense to each other.
4. The expressions remain the same and aren't corrected. The contexts are corrected.
5. It has to be iterative and evolving.
6. Not sure if the contexts should be aware of the bigger goal of the program. How will the contexts and their corrections align towards the main objective of the program?

Nursery Rhymes!

A number of nursery rhymes are really well thought and designed. I watched a few with my daughter and was delighted to appreciate their intentions. Trying to elaborate a couple of them:

• Hickory Dickory Dock:  Obviously it introduces clocks to the audience. But then it also teaches the counting. And at a subtle level it introduces progression as the animals grow in size. And then this progression can be associated with the numbers on the clock.
• Old MacDonald: This one is a memory jogger. You start with moo-moo and move to baa-baa and then next. But each time you move to the next level you have got to recall the previous one all the way back to the first one. moo-moo. baa-baa, moo-moo. cluck-cluck, baa-baa, moo-moo. The audience can be introduced to the trick of association to recall the order of animals. Kool!

Now the tough part is to encourage them to appreciate these points. Just memorizing them up would be useless and should be sung by deriving the next step with these tricks.

Let me see how I can explain these to my daughter when the time comes. Right now she is too young for them I feel.