Friday, March 25, 2011

Closure in javascript and monad in python

What is a closure?

A closure is a function that returns a function parametrized by variables from lexical scope of the creator. Returned function encloses variables from outside of it's scope.

Javascript:
function createDestroyer(divId) {
    return function() {
        jQuery(divId).remove()
    }
}

var popupLayer = jQuery(document.createElement("DIV")))
popupLayer.attr("id", "popup5")
// fill popupLayer
// prepare layer closing button
var closeButton = document.createElement("A")
closeButton.addEventListener('click', createDestroyer("popup5"), false)

// other very good example is the anonymous function below:
repeats = 0
animationId = window.setInterval(function() {
    // animate something

    if (repeats++ > 100) {
        window.clearInterval(animationId); // access and capture outer scope variable
    }
}, 250)

What is a monad?

A monad is a wrapper around data type. Each function called on a monad has access to wrapped data and returns the monad.

We have just seen one monad: jQuery. It wraps around any DOM element, each call returns jQuery object (so that we can chain for example ajax().css().show()) and each method has direct access to wrapped DOM node.

Effectively every object composition with methods that return instance (this) is a monad.

Let's build one in python (IDLE session dump):
>>> class MyMonad(object):
 def __init__(self, anArray):
  self.obj = anArray

 def add(self, elem):
  self.obj.append(elem)
  return self

 def butLast(self):
  self.obj = self.obj[:-1]
  return self

 def rest(self):
  self.obj = self.obj[1:]
  return self

 def toString(self):
  print str(self.obj)
  return self

 
>>> MyMonad([1, 2, 3, 5]).butLast().toString()
[1, 2, 3]
<__main__.MyMonad object at 0x90b556c>

>>> MyMonad([1, 2, 3, 5]).add("a").toString()
[1, 2, 3, 5, 'a']
<__main__.MyMonad object at 0x90d862c>

>>> MyMonad([1, 2, 3, 5]).butLast().add("a").rest().add(90).toString()
[2, 3, 'a', 90]
<__main__.MyMonad object at 0x90d83ec>

Always returning self is so useful (especially when creating DSLs), that I came to expect this feature everywhere ;)

Monday, March 14, 2011

LISP love

... or why Porsche Spider is cool

Few days ago I posted some unpleasant truths about LISP. Today is the day to straighten some things up: I love LISP. I won't use it for producing code, but still admire it, and think that it was a very good investment to learn a little of it.

Why you should learn LISP

  • It will make you better programmer to an extend you'd never think it was possible. If you only know one or two programming languages, you'll feel like a hacker.
  • Your code will become clearer and much shorter
  • You will swear when you encounter lack of that cool LISP feature in your production language. If your language lacks map, reduce or filter - you either implement it or change language to one that does have them (like ruby or python). This or that - you'll be better off to know what is possible.
  • If you use javascript, you will understand, that this underestimated language has nothing to be ashamed of, compared to Java. Quite contrary: java is primitive, feature-less, bloated, slow and ugly compared to javascript. You will learn, understand and love important javascript features like function as primary object, objects {created: 'like this'} and closures.
  • You will deeply understand recursion and actually start using it in your code. This means using trees as data structured and S-lists (lists that have both normal objects and nested lists of objects as members). If you take time to check out TCO (tail call optimization), you might however never again program your math algos in anything but LISP.
  • You will become more productive and efficient in all languages you use.

That's right, it pays to learn LISP (think Clojure).

Then why you ranted at lisp?

Because LISP is like a 1956 Porsche 550 Spider [movie1, movie2, history]. It's a miracle of racing car engineering, has great sound and stunning look. But by today's standard it's slow.

It might be bad taste to compare it to racing cars of today but... well.. it's slow.

  • It's classy.
  • James Dean owned it.
  • Racing it would make you better driver you imagine possible. It would make you a mechanic to own it.
  • It's slow by todays' standards. Spending 50x less money on a car would buy you ridiculously faster track car, easier to drive and more reliable.
  • And the worst: It's very hard to drive that little devil. You need talent to be fast with it.

Nothing will ever compare to the Spider. Nothing. But you wouldn't use it to race today.

It's even cheaper to use a purpose-build crouch rocket like Python or Ruby ;)

Thursday, March 10, 2011

LISP rant

I started to learn lisp december '10 with the book Programming Clojure. It was first language I started to learn in many, many years - being tied to Java.

I've been enlighted and astonished. LISP totally 0wned me for few months. I finally understood recursion, functional programming and many other important concepts of software craft.

I started to play with WebServices (AXIS) and twitter client. Then I wrote a very simple templating engine, similar to what can be seen in LIFT Framework. Started to think of building even more, but ...

then it came to me... I work too slow.

Yes, it took me far too much time to write all the above stuff. Was it my fault? Yes, of course. But it made me stop and look closer at the whole LISP thing.

Bad consequences of LISPing

  • At first glance, LISP (even Clojure) is as readable as Perl
  • LISP macros were a inspiration to C preprocessing macros. Anyone who ever tried to read huge code written in C, particularly GNU projects, would probably agree with me: this is unreadable stuff. You need to establish a parser in your head with a huge heap, just to read a few-liner.
  • Writing macros is the only possible reason to use LISP over other languages. But writing them is so damn hard, and you're stuck helpless with very unhelpful
    Var clojure.core/unquote is unbound
    every few minutes.
  • While having hard time with LISP, one might overlook how powerful Python become over last few years.
  • While wasting time on LISP one might not notice how Ruby is powerful enough to beat LISP with one hand, and serve you cold drinks while you enjoy your work. Yes, powerful enough. Can't imagine why would one want more than Ruby provides.
  • Clojure (no LISP actually) is not object-oriented at all. This makes you change the way you think, while the whole world of libraries is in fact fully OO. Hard stuff. Fun, but hard.
  • The whole concurrency-problem stuff that Clojure tries to solve so badly is way overrated. You just don't use global/class variables nor static fields (java) and you're good to go. In no time we'll see NoSQL databases or Memcached being used instead of IPC/SHM. General, simple, fast and handy. And thread-safe.
  • No one gives a damn what language you write your framework in. Customers care if they can easily navigate your website and if PayPal button works. Actually everyone should thing of end user and stop whinning about the whole languages stuff. PHP is better if your site written in PHP beats LISP elite code gardens.

These are bold statements, young man.

Yes sir! Thank you sir!

However I humbly ask you to please read these rants as LISP:
How I lost my faith (very long) - comp.lang.lisp | Google Groups - 2002
What are programming languages for? - by the same author, 6 years later.

Key quotes

What's more, once I got knocked off my high horse (they had to knock me more than once -- if anyone from Google is reading this, I'm sorry) and actually bothered to really study some of these other languges I found *myself* suddenly becoming more productive in other languages than I was in Lisp. For example, my language of choice for doing Web development now is Python.
There's another problem with the shorter-is-better premise, which is that the brevity of a program is much more dependent on the available libraries than on the structure of the language.
What I lost faith in was that Lisp was the best programming language for everyone (and everything), and that the only reason that people didn't use Lisp is that they were basically ignorant.
Unrelated, but too good to miss
In fact, I am in certain circles a notorious critic of UML, which I consider one of the biggest steps backward in the history of software engineering.

Bye LISP

So.. sorry Clojure. Python won my heart by being simple (and not being PHP) when I was young. Now I'm mature and choose it because it's powerful enough for me and yet readable after years.

Wednesday, March 2, 2011

Steve Jobs: flash? No thanks.

Steve Jobs posted (2010) his reasons not to support flash on iPad and iPhone:
http://www.apple.com/hotnews/thoughts-on-flash/

  1. Flash is closed, proprietary product and we (Apple) have own open WebKit standard for browsers that makes flash obsolete
  2. H.264 videos are widely available, so users won't miss any content. Flash games? We have our store full of games instead. No farmville, sorry :P
  3. Bad security record for flash technology. Poor performance.
  4. Without hardware video decodec, flash drains precious battery. <video> is hardware accelerated. This is very importand on mobile platforms.
  5. Mobile interfaces don't use mouse. They use Touch ©. So, ... no onmouseover or any other rollover effect - flash apps needs to be rewritten (so use HTML5 this time).
  6. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features.

Is he right?

Yes, because he has the money :> But also, sadly for flash developers, his is very, very right and insightful on flash technology. While having competing product (WebKit) is not an argument by itself, having open source competing product is. WebKit browsers made it possible to have animated demos in HTML5 on every possible device (Firefox/Chrome made it possible on non-mobile machines before).

Observe how mobile technology drawbacks (battery life, CPU performance) now drive the web industry. Drains battery == Bad idea. But my PC does not have a battery? -> PC is obsolete.

Third party development tools hinder innovation. Bold statement. But, sorry Adobe, this is so true. I made a few Flex apps (video players mainly) and noticed:

  • poor documentation, sometimes missleading - you really need to copy a widget from Adobe sources, you can't extend almost anything.
  • inconsistent, overcomplicated, legacy-based API
  • Simple things (including a image as background) made hard
  • Big Ball of XML. Impossible to enhance some of XML components with ActionScript code.

Bad developer experience, Flex is going in wrong direction. Flex 3 was pretty nice and much more powerful that javascript at the time it war released. But now HTML5-generation browsers are so fast that writting operating systems in javascript seems actually a good idea. Backed with full CSS3 support, the HTML reclaims what flash has taken.

Conslusion

HTML5 already won. Jump in and don't look back.

I've been informed that Apple decided to bring back the flash support for iOS. It's slow and quirky but it works and the doors are not closed. So, no, HTML5 still has a way to go before it prevails.

Tuesday, March 1, 2011

Being project-managed: survival guide

As programmers we are part of projects that are project-managed. Whatever that would mean, our payroll and job security often depend on projects' successes. If not, lucky you to work on badly managed, yet resorceful company. Go get a raise :)

For unlucky rest of us, I present this survival guide.

Duties of project manager

  • Deploying on time, high quality, working software
  • Fitting in budget constrains
  • Communicating clearly expectations and duties
  • Shielding programmers from client 'interference'
  • Establishing 'find the solution' and team working culture in face of trouble
  • Discovering and stopping 'just one more little change' stream - keeping scope under control
  • Taking the blame for failure or being a source of success

Types of project management

  1. Planning success. There is someone assigned to manage and he/she takes responsibility of leading the process from beginning to the great finish. Customers are happy and so is the internal team. Manager is exhausted, but drives home in Porsche.
  2. Planning failure
    • There is someone assigned to manage, but that person is not fully experiencing bad consequences of his/her mismanagement. For example: going over budged or finish date is not only his/hers problem. If manager cannot be fired after series of unsuccessful projects, or gets away with it because of unrelated (or unprofessional) factors, we have a problem..
    • The person assigned to manage has other duties in project. The more important are those duties, the bigger the failure.
    • Person in charge is paid for other things that could make up for project failure lack-of-bonus. Example of this would be never-negative bonus for both selling the project and for project implementation outcome. There is huge moral hazard here.
    • Someone is charged with management but no one is professionally evaluating his/her work.
    • A manager is a Holly Cow and knows that. Run away from project.
    • Your boss (or his boss.. or) is dependant on (family, love, sex, blackmail, friendship, drug dealer) the manager. This is really bad. Quit immediately if you discover such dependency or risk serious consequences.
    • No single person is doing all things described as PM duties. That actually can be played to make you a beneficent of process design failure. Think Wally from Dilbert series.

Why do I care?

Your work is evaluated in relation to the project. If project fails, you are part of failure. No raise, no respect. You should care about project management because projects needs to be managed to succeed, little beasts.

Persistence of management failures

If projects fail, how the company prevails? If you ask this, maybe you know too little of your company? Maybe you assumed wrong business model? What if your company earns 90% on hosting the solutions not on programming them? What if your clients also undergo moral hazard of not depending on project outcome? Example? A corporate manager in charge of huge budget that wants part of it for himself.
What if there are many projects in parallel and internal accounting process makes it impossible to evaluate financial outcome of managers work?
What if company makes so much money, that no one cares about projects you are part of?

Bad management sometimes exists also because of high pressure to use Project Management Methodologies (while forgetting WHY WOULD YOU USE THEM IN THE FIRST PLACE). If you use methodology just for a buzzword or have established a culture of 'I made this by the book, don't blame me' - your company might soon fail.

Bad management survival guide

  1. If bad management is common in your company, you'd probably benefit from quitting it unless you are paid very well. If you feel underpaid, there is no hope for raise unless you change jobs (because your work is judged in context to projects). Think twice however whether what you do, is worth more than you are paid - because that's the reason to have you employed. Do that every day - advice from Chad Fowler's 'Passionate programmer'.
  2. If you are offered some executive job, make sure that bad management won't affect you. If in doubt, assume that it does and refuse the offer. Team management is tedious no-fun, no-hacking job. Unless it would give you a huge raise (>25%), refuse. Why previous team leader quit? Got promoted or fired? Promoted to do what? What kind of person is he?
    Little raise + bad project management == frustrated programming team leader. Been there, done that.
  3. Do not ever try to fix company processes. Not only will you fail, but would seem like undermining your boss' position. That is a great "you're fired" opportunity. If you can't live with that, quit your job.
  4. If there are successful projects in your company, try to join those teams. Escape failure-generating platforms, managers, technologies. Be associated with winning or find solutions outside.
  5. Don't ever say it publicly in company what you think about bad project management. Suck it up, smile and do your job. Read Hackers and Painters by Paul Graham to understand why.
Any comments? :-)

Lectures