Leon Gersing

Suzan blogged her thoughts on restraint in the modern era in her usual insightful and thoughtful way. It reminds me of a thought I was having this morning while gathering the new morning’s sunlight through the slit in my blinds.

140 characters can ruin a life. 140 characters can save a life. 140 characters can inspire others. 140 characters can depress others. 140 characters to get it right. 140 characters to get it wrong. 140 characters to find love. 140 characters to destroy love.

Here-in lies the hidden dilemma of our time: We are the engineers of our own fate. The weak want others to make those choices for them. They trade uncertainty, fear, tension and courage for dogma and idiom. They will gladly kill the next herald to cross their newly understood and easily digestible wisdom in the hope that it will silence the fear in their belly; the fear that they are, in fact, every bit the fraud they fear they may be. This fear, armed with dogmatic purpose turns the thinking, feeling, sentient into a mob joining, pitchfork wielding, embarrassment to free/thinking society.

There’s no industry immune. There’s no community unaffected. There is no escaping the universal need to feel above it all. Unfortunately, this freedom does not come from consensus and it does not come without the risk of harm.

The choice, the great and terrible choice, is that you must be true to yourself and what you feel is right at all times. Even when that is inconvenient. Even when it means you may stand to lose all possessions and relationships. It means taking a punch and never throwing one. It means doing that which everyone knows is right but lacks to courage to make. It means being judged harshly today to be vindicated tomorrow… if ever.

I have had my code called “crazy”, “arbitrary”, “whimsical” by those who both knew what I was doing and those who did not. Fortunately, I was strong enough to hear the criticism, decide if they could see what I saw, and if not, simply say thank you for their time and care and move on.

You can choose to be bothered by everyone who doesn’t understand your point of view. You can choose to give away your own point of view for someone else’s. One of these is comfortable, safe and leads to a good life. One of these choices is not. Both are worth making and everyone does. How you choose will determine who you are. You can change your mind at anytime. All it takes is understanding the great and terrible burden of choice.

I don’t know what it is with my generation in America these days but I find myself acting like a broken record. Reminding folks of the same things over and over again. I decided to make it simple and share it with you now.

There is no one to gain permission from. There is no one to impress. There is only you… now.

The common response when I ask what someone is doing is “well, I’m doing x but I really want to do y.” to which is reply: “then do Y. now.”

“well… [enter excuse here]”

Let me make this perfectly clear. You are exactly what you practice. You are only what you’re doing right now. Not what you dream to be doing, not what you think you will become, you’re this… Right now. Every platitude and excuse you give, every lie you tell to me about your hopes, dreams and aspirations is a myth you’ve concocted in order to deal with the fact that you’re no closer to obtaining them today than you were the first time you uttered the words to yourself.

That’s ok. You are not a failure unless you believe that it will happen by magic. Even then you’re not a failure, you’re just in denial of the truth. The truth being that you’re in complete control of your life. You can choose to be whom you want and take steps to ensure that the world sees you. Do not wait for permission, do not validate your life until you’re living it. We are obsessed with our own histories. That is a waste of time. What good is planning how you want your story to be told if you’re not out living enough of a life to merit telling?

Be you now. Whatever that is, whatever that means, stop waiting for someone to let you do anything, go out and do it. Now.

So for those looking for someone to help them start, allow me to be the first person you thank in your novel’s liner notes, the first shout out on your hip-hop mix tape, the first name listed in the thank you page of your new web app. I hereby grant you the permission to start doing whatever you need to do to be the person you claim you want to be. Anyone hating on you, any critics you meet along the way, tell them thanks for stopping by and send them and their negativity packing. You’re walking the path you’ve always intended to walk and they are scared by the sound cracking their ears, the wind brushing their cheeks, the light flashing before them as you pass them by.

For those who requested the slides from my Pecha Kucha talk at CodeMash 2012, here you go. All rights for photos belong to their perspective holders. For those I could not find copyright info, please feel free to get in touch and I’ll provide full credit as required by your licenses. Thanks!

Leon

link: http://public.iwork.com/document/?d=Love_-_CodeMash_2012_Pecha_Kucha.key&a=p79052775

browse here:

CoffeeScript is something that I’ve watched for a very long time and my first attempt at using it in a project was early in its development and while I wanted to commit patches, reading some of the conversation around the purpose and overall goals made me realize that I simply see JavaScript differently than the author (Jeremy Ashkenas, whom I do not know but would LOVE to have a drink with (alcoholic drink or otherwise) and pick his brain, if anyone knows him and would kindly introduce us at a conference or something :). I’m buying, btw!). Different is wonderful and should be celebrated; encourage! Which is why I am loathe to write an article like this but after being mis-represented on twitter for the ump-tenth time, I decided it would be in my best interest to attempt to articulate my perspective first hand.

CoffeeScript makes a wonderful assertion of referential transparency in it’s scoping rules. By eliminating the “var” keyword and wrapping the entire context in a closure, it’s impossible to unwillingly scope variables globally nor can you augment outer scopes in an inner context through assignment which is fantastic. So far I’m loving this! Throw in all the syntactical sugar, iterators, and list comprehensions and hot damn if I didn’t think our brilliant friend was trying to “haskell-ize” JavaScript! Until I saw the class keyword. In this, my heart sunk. Then I saw a differentiation between “->” and “=>” in which the very notion of the scoping rules being encapsulated by the language seemed to be leaking back into the developer’s lap. Finally, the back tick (`) to interpret something as JavaScript inline. These 3 items are significant concessions on the overall vision that give me pause and I begin to ponder “In what context, would I need a back tick?” or “If classes ape their statically typed brethren of Java, then, idiomatically, is the idea that I should augment them by reference? and if so, is it even possible to do so given the implementation of var without the overhead of accessor methods? And if so, doesn’t that just kill all the cool stuff that came before it?”

All of these questions came up in the first project I used Coffee in. It’s not the that Object modeling metaphor used in CoffeeScript is bad, it’s just overly object-oriented and builds on OO style inheritance. JavaScript has a built in mechanism for attaching functions to any instance, like composition aka “mix-ins”, which can lead to high degrees of function reuse outside of any domain logic that may be encapsulated by a class to begin with. JavaScript’s Prototypical inheritance model is so simply in it’s implementation that it actively discourages large object graphs from being constructed through traditional OO methods. Yet CoffeeScript is engineered to dismiss this compositional simplicity in exchange for a more complex albeit more familiar OO style inheritance model. This, in my opinion, makes CoffeeScript less transparent that JavaScript, increases the complexity and introduces an amazing amount of generated JavaScript code into your runtime interpreter that contains little value over JavaScript and no compile time optimizations (closures don’t count, scoping doesn’t count). This means that CoffeeScript is not a language with it’s own identity and purpose but rather a bridge to another one. CoffeeScript classes have attributes and properties that are encouraged to be mutated by reference so a language contrivance was devised (@) to allow OO style encapsulation while still trying to provide Functional referential transparency in anonymous contexts… wrap your head around that. I can’t. {} is an object, any object, in JavaScript. What good does it to force it into an “Animal” type that extends another and another and so on? So that I can know that {name:”Leon”} can be safely mutated in it’s scope but not outside of it? CoffeeScript’s Class system and inheritance model adds un-needed complexity in a way that I’ve yet to comprehend the inspirations for. I’m going to scope the rest of my article to deconstructing it and leave some of the other issues for another article.

Ironically, if the idea was to mix-in existing functionality via functions, Jeremy wrote a much more simple and elegant version of this in 6 lines of code for underscore.js (yes, he’s the author of both!) in the extend method; extend is simple, idiomatic, and encourages the construction of tiny and discrete units of code that can become polymorphic as the need arises. Here’s the extend function in all it’s glory…

_.extend = function(obj) {
  each(slice.call(arguments, 1), function(source) {
    for (var prop in source) {
      if (source[prop] !== void 0) obj[prop] = source[prop];
    }
  });
  return obj;
};

Right?! RIGHT! It’s awesome! that means I can compose my objects (as late as runtime!) from existing objects, objects that don’t exist and objects I don’t even know exist yet. Each composed to be as simple or complex as the domain allows, without the increased overhead of the OO object model of CoffeeScript’s “class” implementation. I can give functions to objects, properties, anything my heart desires, whenever I want.

I would love to juxtapose the implementation of the class based inheritance in Coffee to the simple extend in _.js but the comparison is orthogonal and unfair. Instead, I’ll compose methods onto a tiny object from the class example in the CoffeeScript docs. First, let’s examine the output of the Class results from this CoffeeScript:

class Animal
  constructor: (@name) ->

  move: (meters) ->
    alert @name + " moved #{meters}m."

class Snake extends Animal
  move: ->
    alert "Slithering..."
    super 5

class Horse extends Animal
  move: ->
    alert "Galloping..."
    super 45

sam = new Snake "Sammy the Python"
tom = new Horse "Tommy the Palomino"

sam.move()
tom.move()

The generated JS:

var Animal, Horse, Snake, sam, tom;
var __hasProp = Object.prototype.hasOwnProperty, __extends = function(child, parent) {
  for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; }
  function ctor() { this.constructor = child; }
  ctor.prototype = parent.prototype;
  child.prototype = new ctor;
  child.__super__ = parent.prototype;
  return child;
};
Animal = (function() {
  function Animal(name) {
    this.name = name;
  }
  Animal.prototype.move = function(meters) {
    return alert(this.name + (" moved " + meters + "m."));
  };
  return Animal;
})();
Snake = (function() {
  __extends(Snake, Animal);
  function Snake() {
    Snake.__super__.constructor.apply(this, arguments);
  }
  Snake.prototype.move = function() {
    alert("Slithering...");
    return Snake.__super__.move.call(this, 5);
  };
  return Snake;
})();
Horse = (function() {
  __extends(Horse, Animal);
  function Horse() {
    Horse.__super__.constructor.apply(this, arguments);
  }
  Horse.prototype.move = function() {
    alert("Galloping...");
    return Horse.__super__.move.call(this, 45);
  };
  return Horse;
})();
sam = new Snake("Sammy the Python");
tom = new Horse("Tommy the Palomino");
sam.move();
tom.move();

Now here’s the same re-written in pure JavaScript.

function move(aDistanceOf){
  var it = this.name || "It";
  if(arguments[1]){ alert(arguments[1]); }
  return it + " moved " + aDistanceOf + " meters.";
}

var snake = { name: "Sammy" };
var horse = { name: "Tommy" };

move.call(snake, 5, "Slitering");
move.call(horse, 45, "Galloping");

That’s it. Now, I know what you’re thinking, “Leon, please, the Coffee example is contrived and doesn’t represent real world domains.” You’re right and so is mine as a result. “But you also didn’t create real domain models.” Also right, because I didn’t have do, nor would I ever want to. Therein lies my point. Sometimes a struct is a struct and not an class. The difference that I’m desperately trying to convey in this overly simple context is that by leveraging FP over OO one can provide not only a more dependable abstraction but when combined with JavaScript’s inherent flexibility as a language, we can achieve true referential transparency and polymorphism. As my domain continues to increase in complexity I’m not concerned about constantly redefining my object graph, instead, I pass them through the move function as I would any valid javascript object to achieve my end goal. When I encounter a task that move does not make sense for, I can create a different function, add additional arguments (for say, callbacks) or refactor this one (be sure to run those tests!)

In terms of pragmatic interface design, I’m not impressed by the fact that I have to think of the “move” function as only pertaining to that model’s object graph. It’s an abstraction that is bound (and encouraged) to leak. This is a fundamental difference between OO and FP and the crux of my frustration with CoffeeScript. FP encourages building small functions that do not mutate state and can be bound together as needed to perform a task whereas the OO philosophy is to encapsulate and achieve polymorphism through interface or contract. The more dynamic your context the more OO’s encapsulation paradigm, as seen in the inheritance model, leaks and defies it’s 3rd and most important tenant: Polymorphism. Even these 2 contrived examples above, if I look at the majority of CoffeeScript I’ve seen written at EdgeCase (including my own… guilty.) there has become this Java-esque DTO on the client side that takes a pure, evaluated, ready to go json object that is sent back from the server, xhr style, and translates it into a “Snake or Horse” instance. for what? This is where Jeremy’s claims to “just as fast or faster as the JavaScript you’d write” fall down. The overhead encourages more complexity, more computation and ultimately more indirection.

CoffeeScript sees the world through OO’s eyes. When I see JavaScript, I find beauty in it’s ability to be a dynamically typed Functional programming language. (that’s your TL;DR;, friends.)

This doesn’t mean CoffeeScript is BAD, poorly written, without merit. In fact, I encourage you all to check it out and decide for yourselves. I think you’ll find a clean, well crafted lexer and a sweet tokenizer written in JavaScript. That’s a pretty cool thing in itself; something worth celebrating. I simply find that outside of an academic context I don’t prefer it over JavaScript. JavaScript’s function keyword and curly brackets aren’t “ugly” to me, they are useful indicators of code smells. Do you have too many of them in a row? Time to break down your functions. This is not a problem with JavaScript, this is a problem with developers. CoffeeScript’s encouragement of OO patterns over Functional ones seems, to me, misguided in it’s current form which is not a compile-time machine or VM optimized language alternative to JavaScript but a bridge that seeks to help you write better JavaScript at the expense of gaining the wisdom of what that even means.

If you’re a fan of OO you’re going to love CoffeeScript from day one, guaranteed. If you’ve never tried to see the world through Functional glasses then I assert that you’re going to be missing out on a few beautiful vistas. Even if you go back to OO, give your solution a try in a functional style before turing JavaScript into Ruby or Python just because it feels more comfortable. If you can’t do it on this project, try it at home, or better yet, learn Erlang or Haskel or F# or Clojure and try to see the world that JavaScript sees before you turn it into something it’s not.

I hope you enjoyed this article. It was painful to write because I want to see more wonderful things from authors like Jeremy (seriously, _.js is genius.). While CoffeeScript is not for me, it’s obvious that many others find value in it and that’s really all that matters.

“Don’t try and bend the spoon. That’s impossible. Instead try and realize the truth… There is no spoon. Then you see that it is not the spoon that bends, it’s only yourself.”

Jim has a new blog post that solidified a few of my own thoughts on the age old saying I hear bandied about over and over at software conferences: “You can change where you work or you can change where you work.” A phrase that has only recently revealed its inner wisdom to me.

This statement illuminates a simple paradox. It reveals the person sharing it to be someone who has decided to change the environment around them in spite of direct opposition rather than to walk the path that they’d like to actualize. It’s rarely imparted in the other direction unless to hopefully reveal it’s inner wisdom from an outside perspective one more time. The paradox in this choice is that while it seems to provide an easy answer to a complex problem it’s really indirection. It’s denial. It’s a solution that lacks balance and reveals the individual making it to be in a state of waiting; not ready to embrace the path they wish to travel; highlighting the lack of understanding of themselves and why they are not at peace with the very task that used to provide such joy. This person and the opposite that they’ve created (manager, organization, team, so on) cannot accept the other and therefore balance cannot be achieved. They believe that fighting the opposite will be rewarded. They arm themselves with the texts and teachings of Software Practice Prophets and hold to these teachings with the fervor of a true dogmatist. Thus resulting in devaluing of the individual as they see their life not as it is but how they wish it could be. Manifesting in shame, loss of motivation/hope compounds like bad debt and as they fight a fight that they don’t even understand, knowing that once the others see the world through their eyes everything with be…perfect. Continually perpetuating the notion that there is a single path to enlightenment. That holding stalwartly, doggedly to the dogma will provide the enrichment of life that they so desperately desire. This if, of course, paradox. The 2 opposing sides must find balance and in this situation they cannot.

This is a choice. If there is wisdom to be gained through the teachings of a guide then that wisdom must be gained through experience. The wise man’s role may be to reveal to you a door to your path that you may not be able to see, to leave footprints behind from their own experience. The wise walk the path, with doubt, with questions, with fear, with hope, with joy, with passion. They walk with the full spectrum of human emotion and experience and they find others along the way to balance themselves and share perspective on the journey.

Jay-Z puts this perfectly in Renegade: “No lie, just know I chose my own fate
I drove by the fork in the road and went straight”

Jay recognizes there is a path, by those that walked it or want to control his experience but chose to forge his own path. The artifacts are, of course, new music and new paths for others to recite back as dogma. Which is, of course, entirely their choice. He made his, others must make theirs.

I wrote down a phrase after a terrible conference experience that I had that I never understood until recently.

“Dogmatist believe. Messiahs doubt.”

It’s not a quote from anything, just a thought I had while reading books over the years where I noticed a trend in both religious, spiritual, philosophical texts and from the messages I was hearing at the many conferences I used to attend. This seemingly paradoxical juxtaposition was of great fascination to me at the time and it wasn’t until recently, as I began to inherit the codebases of some of the very people I have come to respect from afar. My dogma had been shattered. You see, I had come to worship the dogma of idioms like TDD, Test-First, Test everything, patterns patterns patterns and more patterns. At first I was angry. “How could this person who lectured me for an hour at that conference about their clean code practices produce such utter contradictory drivel!?” That anger lead, inexorably, the its only conclusion: I missed the point. I was worshiping the messages of wisdom, seeing the footprints on the path as truth but that’s ridiculous. That’s dogma. They were, in truth, simply how someone achieved their goals repeated back. There was no wisdom inherent to the words or the individual who shared them. They were the living representation of perspective from someone walking their own path. I was using it as a buffer to prevent me from doing the very thing that would be the most beneficial: Making up my own mind.

My choices are my own and the wisdom they provide is only for me. When I am faced with the notion of “change where I work or change where I work” I realize that I’ve already made the choice. Understanding why I made it is the challenge and the only way to gain that wisdom is to simply start walking my own path.

“Don’t try and bend the spoon. That’s impossible.” or as I hear it now: “Don’t copy me for what I do. See past this illusion and realize the truth therein.”

“Then you will see that it’s not the spoon that bends. It is only yourself.”

Of course. There is no spoon.

I love how a device that no one has really used has caused such a rift in the geek/nerd/tech/yawn universe. So, I’m going to weigh in….

I remember when Apple came out with the Macbook Air and nerds were up in arms over that because of the price. It was under powered by their stupid, nonsensical standards. You know what happened? People who travel a lot and need a computer that allows them to get things done (email, documents, presentations, etc) while traveling on a plane or a subway or whatever. Guess what happened? They loved it and geeks didn’t buy one. You also forgot about it the next time another machine was added to the Macbook Pro line. Because __that__ machine was for you.

Not every user experience has to be a ubiquitous homogenized one. People are heralding iPad as things like a Kindle killer. Nope, you’re wrong again. If sales go down, they’ll drop the price. If no one buys it they’ll devote more time into building apps for iPad or the subsequent Google Android Tablets that are bound to pop up in the next year or two.

So, if you’re interested in one, buy one. If you’re not, then don’t. If more people like them than don’t then they’ll go the way of the Newton. If not, then get a Macbook and start hacking away at apps for it and fleece the millions of iPhone, iPod and iPad users out there who actually are interested in the device.

Oh yeah, and no one, __NO ONE__ has ever, __EVER__ said that the iPad was the end all be all of the future of computing, because that would be hyperbolic. IF you’re worried about your kid _not_ getting into computing because you only own an iPad, then buy that little hacker a mac mini and give them room to run. But stop with the whiny conjecture and hyperbolic punditry. I’m over it.

DISCLAIMER: I’ve been programming for years. Frankly, a computer that my parents can use without calling me for tech support every week has me pretty excited.

Me? Waiting to play with it but am very intrigued.