About Alexander Tsepkov

Founder and CEO of Pyjeon. He started out with C++, but switched to Python as his main programming language due to its clean syntax and productivity. He often uses other languages for his work as well, such as JavaScript, Perl, and RapydScript. His posts tend to cover user experience, design considerations, languages, web development, Linux environment, as well as challenges of running a start-up.

State of RapydScript

Matrix-agent-Smith-clones Many of you probably noticed that I’ve been slow to contribute to RapydScript lately. It’s hard to summarize all of the reasons, but here are the top few:

  • Despite the occasional bug, the project is in solid state and quite usable in production (I do eat my own dog food by the way).
  • I’ve been working on other projects, most recent one being TileZone.
  • I am one man, and my time doesn’t scale. I wish I could continue improving the language and fix the bugs people report but at the end of the day I don’t get paid for it, and as a result I prioritize my other projects and my job over this. I’m grateful for the contributions from other members, but the community isn’t large enough to encourage others to contribute regularly.
  • With ECMAScript 6 and Babel, the future of RapydScript seems somewhat uncertain. Babel is an awesome library that brings many similar features to RapydScript (although with uglier syntax, in my opinion). I think, however, that RapydScript, if continued, will be more relevant in ES6 world than something like CoffeeScript.
  • As mentioned before, I don’t believe Python is a panacea. It’s one of my favorite languages, but I’ll be the first one to admit that it made quite a few mistakes design-wise. Some issues that come to mind are global-scope collection methods (len, map, filter), lambda functions, inconsistent naming scheme for native objects (why are native classes called int and str when the convention is to use title case for them?), exposing of optimization methods (xrange) to the user when they should really be handled behind the scenes, and so on. As a result, it’s frustrating to see new RapydScript users complain that the language should be more like Python, especially the parts of Python that I hate.

With that said, I love RapydScript, and will continue using it. I prefer it to both, Python and JavaScript. Ironically, I started RapydScript to avoid dealing with JavaScript, but in the process learned to appreciate it more. Some design patterns I use in RapydScript would not be possible in Python. JavaScript is a powerful language, and yet it’s messy. This StackExchange answer to a question about language verbosity does an amazing job explaining what I like about RapydScript. If we were to grade the 4 languages I mentioned on those 2 categories, I would rate them as follows:

Language Signal vs Noise Cryptic vs Clear
JavaScript ⭐⭐⭐⭐⭐
CoffeeScript ⭐⭐⭐⭐⭐
Python ⭐⭐⭐⭐ ⭐⭐⭐⭐
RapydScript ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐

JavaScript is definitely the most verbose of the 4, having to type out all of those prototypes, optional argument checks, array[array.length-1], and brackets gets repetitive very fast. Looking at all that code gets repetitive even faster. As far as CoffeeScript, there is no arguing that it’s terse. Its signal to noise ratio is amazing, every character serves a purpose. The only problem is making sense of all that code later, remembering differences between fat and skinny arrow, and wrapping your head around all those invisible parentheses. CoffeeScript solved JavaScript’s verbosity problem, but introduced a new one. Its cryptic syntax is the reason many JavaScript developers recommend steering clear of it. Python has a good balance of the two, and as a result has gained quite a large following from developers who’re tired of dealing with the visual clutter of other languages. But, to be honest, it’s not as clear as modern JavaScript. Let me show you a few examples:

Python JavaScript Explanation
len(a) a.length Global scope, unnecessary abbreviation, should I say more?
def function Another vague abbreviation, but at least def makes it very clear what type of object we’re defining
lambda function At least they didn’t abbreviate it
*rest ...rest They went out of their way to rename all && and || and then introduced this?
**kw {foo:"bar"} Nothing says dictionary like 2 multiply signs next to each other
','.join(array) array.join(',') Are we joining elements via delimiter or delimiters via elements?
str String Another useless abbreviation that ignores the convention of capitalizing classes
list Array Linked list?
ZeroDivisionError Infinity Sure, it’s mathematically correct, but when I divide by zero, 9 times out of 10 infinity is what I want, I’ll end up assigning 999999 to the number in the catch block anyway

You may argue that Python’s operators are more clear than JavaScript’s ||, &&, but which one do most languages follow? Developers are so used to seeing those operators that it really doesn’t matter. RapydScript does as well as Python on signal, and sometimes a bit better (thanks to closures and ability to inject JS), I gave it an extra point for clarity because it can often leverage the cleaner JS approach, as I usually do in my code (although to be fair JavaScript still inches ahead a bit here).

Going Forward

So where does that leave us? As I said, I love RapydScript, but I don’t have the manpower to continue fixing the bugs or make RapydScript more like Python when I have no need for Python. My backends are all in node.js now. It also seems like Kovid has been more active in enabling Python users to feel at home with his fork, so I’ll let him continue that. At this point the philosophies have diverged somewhat. I disagree with adding extra syntax and special-casing variables for Python, he disagrees with breaking Python rules. At this point, I’m feeling like Python has become a bit of a shackle, there is no reason I should repeat the same mistakes as Guido in the name of backwards compatibility with code that wasn’t even written for the same platform.

My goal is to make RapydScript relevant in ES6 age, and here is how I plan to do that (at my own pace of course, given other projects, but you’re more than welcome to help me out):

  1. Fix low-hanging fruit bugs.
  2. Separate tokenizer from lexer (I’ll explain why in a bit).
  3. Rewrite output module to generate ES6 instead, let Babel handle special cases, not us.
  4. Modify output module to fill in templates rather than handcrafting output code.
  5. Drop pythonisms from core (no more int, str, bool) and embrace native JS types (Number, String, Boolean)
  6. Add optional static typing and ability to infer types, let users leverage this information to create/optimize better templates.
  7. Now that tokenizer is separate from lexer (step 2 accomplished this), add a macro-processing step in-between that can mutate the code as the AST is being formed, this will give RapydScript powers similar to sweet.js, but which can handle whitespace.

After all 7 of those steps are complete, users can enhance the language as they see fit, without having to modify the core. If they want a new operator, or pythonic variable names, it would be as simple as creating a macro. If they want different output/format, it would be as easy as writing an output template. Admittedly, this will probably take me a while. But if anyone wants to help, we can probably get this done much sooner.

Equality Operator

Matrix-agent-Smith-clones One thing that always bothered me, and many others, is how useless the == operator is in JavaScript. It seems to combine the worst of both worlds from equality and identity:

  • When comparing primitive types, it acts as a lax equality operator
  • When comparing objects, it acts as an identity operator

I can’t think of any use case for which such behavior is desired. In fact, reversing this behavior would produce a much more useful operator since the concept of “equals” tends to relax as data gets more complex because some dimensions are simply irrelevant. Do I care that two objects were not created at the same exact time? Do I care that their IDs differ? Do I care if the measured length is 4.00000000001 inches rather than 4? When it comes to equality comparison, JavaScript fails miserably. This is actually one of Douglas Crockford’s pet peeves about the language, which he explains in more detail in his book: JavaScript: The Good Parts.

Fortunately, there is also a more consistent identity operator (===), often erroneously called “strict equality” by people who don’t understand the difference between identity and equality. Unfortunately, as I just mentioned in previous paragraph, there is no concept of equality operator in the language at all. For those unfamiliar with these concepts, identity answers the question of “Does A and B refer to the same object?” while equality answers the question of “Is B a clone of A?“.

Naturally, both of these questions come up in programming a lot, so it’s a shame that only one can be easily answered in JavaScript. You probably already stumbled into this problem if you ever tried something like this:

new Date('1/1/2000') == new Date('1/1/2000')

or this:

{"foo": 1} == {"foo": 1}

The problem is not unique to JavaScript, many other languages lack equality operator as well. Typically, however, those languages have an alternative mechanism for handling this case, such as operator overloading. Indeed, there are cases when operator overloading is actually superior – such as when objects contain meta data that one wishes to omit from comparison (i.e. exact creation time, unique id, etc.). Unfortunately, JavaScript doesn’t allow for operator overloading either, and herein lies the problem. While one can easily roll a proper equality function (and many libraries such as underscore already include one) you would still have to decide whether it’s worth using on a case-by-case basis.

We’re not in FORTRAN age anymore, where developers had to tweak each operation. Today we’re spoiled, we often can get away with simply telling the compiler what to do rather than how, and enjoy optimal performance 90% of the time with negligible overhead. One such example is the sort function. When was the last time you had to wonder if you should use merge or insertion sort? You simply use the built-in sort and assume that unless there is something very special about your data, you’re better off moving on to other things rather than attempting to optimize the last 10% out of the algorithm. In most modern languages equality operator falls in the same category. Sure, you’d be able to shave off a few microseconds by replacing that == (equality) with is (identity) for certain comparison operations in Python, but is it worth the extra brain cycles? Most of the time the answer is “No”.

Why then do we have to be explicitly aware of this in JavaScript? Moreover, why can’t RapydScript compile == into deep equality? First, I should mention that, like some other libraries/languages for JavaScript, RapydScript already has a deep equality comparison via the inbuilt eq function. Yes, eq(a, b) (previously called deep_eq) has been supported for years. The problem is that (up until recently) I wasn’t able to make the decision for you of whether you want eq or ==. The issue boils down to the fact that if I decide to compile == to equality across the board for the developer, I effectively introduce enormous overhead (about 700% according to jsperf) on the user in cases where he/she expected identity comparison instead (which is about 90% of the time, since primitives are a lot more common). There has been a lot of discussion about this, which you can follow in issues 93 and 94 on my github page.

As you probably already guessed from previous paragraph, I’m now able to bridge that gap. Effective last month (that’s right, I snuck a change in without anyone noticing), RapydScript is the first JavaScript-based transcompiler to support high-performance deep equality. How performant is this operation, you may ask? Well, take a look for yourself:

Screen Shot 2015-12-05 at 2.59.38 PM

According to jsperf, the overhead is negligible (that’s right, the measurement noise is greater than any visible difference – as you can see from the deep-equality version outperforming identity). So what changed? Why am I suddenly able to blow the doors off of typical deep equality? Well, nothing new happened in JavaScript world. What changed is my approach. I decided to think about the problem creatively and had a sudden eureka moment (which I’m sure other compilers will copy in the future). Unfortunately you’ve probably already looked at the code from JsPerf above, ruining my surprise. But in case you haven’t, here is the pattern I came up with:

A === B || typeof A === "object" && eq(A, B)

How does it work? As you probably learned in your introductory programming class (assuming it was a legitimate C/Java class rather than an online tutorial about JavaScript), binary operators have short-circuit ability in just about all languages. This means that if left-hand side is truthy for || (or) operator, or falsy for && (and), the rest of the line is ignored (it’s as if it’s not there). That means that if A and B are primitives that are equal, the above will be equivalent to a simple A === B comparison. That handles the positive case, but negative is a bit trickier. I was struggling with it for a while (yes, the above equation makes it seem simpler than it really is – everything seems easy in hindsight), until I found a performant operation that works in both, browser and node (my first attempt was to check if A.constructor exists, which doesn’t work on all platforms). Fortunately, the very same “feature” that makes typeof useless in most cases (the fact that every non-primitive is an object) becomes the saving grace of this operation. As you can see from the JsPerf test, the overhead for this operation is negligible as well.

The best part is that unlike native JavaScript, where the developer would have to type that out by hand (because hiding it in a function call introduces the 700% overhead we’re trying to avoid), RapydScript can unroll == operator into that magic automatically. You’re probably wondering, then, how is it that this change has been in RapydScript for over a month if the == still compiles to ===? Well, for safety I’ve hidden this operator behind an import. If you wish all your == operators to compile to proper equality test shown above, add the following line at the top of your file:

from danger_zone import equality

That’s it. Now all your == will compile to the magic shown above, and != will compile to its inverse (thanks to DeMorgan’s Law). The above import will also tweak implementation of indexOf and lastIndexOf to perform deep equality as well, which in turn makes tests like if a in arr be based on deep equality (delivering a consistent experience across the board). As before, the identity operator is still there as well, via is and is not, which compile to === and !==, respectively. In the future, I also want to add an optimizer to the compiler, which will strip away the remainder of the line at compile time if one of the operands is a constant.

Regret and Opportunity

Psychology of Motivation I apologize for the lack of updates. A lot has happened since my last post, the lawsuit that I was involved with was finally settled. It wasn’t settled favorably, and I ended up losing most of my security deposit anyway – a large chunk of it to attorney fees. The seller (who I assume spent just as much on her attorney) probably ended up close to break-even as well. It’s unfortunate that she didn’t come to her senses until 2 years into this ordeal, after the fees started to outweigh the amount disputed over.

Perhaps I was wrong to fight her. Perhaps I should’ve just walked away. After 2 years of dread and stress, I ended up losing almost as much as if I simply gave up on day one and let her have the entire amount. I was ready to compromise, I was ready to split my hard-earned savings in half with a stranger just to preserve something, she was not. As a kid I was told once “Don’t get into an argument with an idiot, they’ll take you down to their level and beat you with experience”. Now I knew what that meant.

This was the most unpleasant experience of my life, 2 years of dread where you know that you’ll lose money, you just don’t know how much. I’ve never felt such disgust for a person before. Not hate, not anger, but disgust. With several million in assets (according to her own agent) from her husband’s estate, she decided that the best use of her time and resources was to go after me (because it’s my fault that flood laws changed as I was buying the house) for what was effectively pocket change to her. To me on the other hand, this was a 3rd of my savings, hence the panic I went through. The rest I already mentioned before. “You could get your deposit back if we end up in court”, my attorney told me, “but you’ll lose more in legal fees, don’t throw good money after bad”. That was my justification for wanting to settle.

However, after I was done sulking, I realized that something amazing happened. In these 2 years that the lawsuit lasted I learned more about real estate than most people do in a decade (partially from the lawsuit, partially from absorbing all the books I could get my hands on – determined not to get into same situation again), I learned more about investing than most do in a lifetime (including derivatives, various quirks of US financial structure, strategies and their pitfalls), I bought my first property to rent out, made connections with local and remote investors to do deals with in the future, learned Objective-C and Swift (which I wanted to learn for a while but didn’t have the motivation), wrote an iOS app, advanced to a lead developer at work, read 43 books, and met an amazing goal-oriented girl, whom I still date today.

What happened? I got the gift of motivation. I realized that life was short, that a single event could wipe me out unless I build a financial fortress out of my remaining assets, and that I was already a decade behind great men who realized this in early twenties. I had to catch up. All of a sudden fear turned from a blockade into rocket fuel, all because my perception changed. I still hesitate, I’m still indecisive, but I now realize that doing nothing is rarely the safest choice. The best analogy would be the Slime Climb level of Donkey Kong Country. I still have to climb up, but now I realize that there is rising water below me, and things in it that could hurt me. This is true for all of us, but most choose to ignore this fact until well into our fifties.

Using Angular Rapydly

RapydScript with AngularJS I’ve been asked a few times if RapydScript works with Angular. The answer is the same as with any other JavaScript framework/library/etc. – of course! RapydScript takes the same approach to compilation/abstraction as CoffeeScript, so there really isn’t anything JavaScript can do that RapydScript can’t. Salvatore has already proven this with multiple demos using frameworks I haven’t even thought of. I urge any developer with similar questions to just try it out, it’s easier (and more fun) to spend an hour building an app than hesitating about it for weeks.

With that said, I decided to put together this tutorial by cloning the 5 examples shown here via RapydScript. I suggest you read the original article before this post. I should also mention that I myself have not used AngularJS before, and decided to learn it through these examples as well. I was a bit disappointed to see that a big chunk of AngularJS is handled magically from their html templates rather than JavaScript itself. This means that there is very little actual JavaScript (and hence RapydScript) used. As far as html itself, you could either write it directly, or use RapydML or Jade (both will have similar syntax). For the purposes of this post, I will leave css code alone, although you can easily convert it to sass as well. Let’s get started.

Setup (Only Needed for RapydML)

Looking at the first example, we immediately notice Django-like variables in the html code. That’s a sign that we may want to use template engines in RapydML. So let’s slap one together. Glancing through the examples we see that most AngularJS variables follow this format:

{{var}}

Doesn’t look like they’re doing anything fancy, so let’s create a very simple template engine in a new pyml file:

angular = TemplateEngine('{%s}')
angular.js = create('{%s}')

I should also mention that you can use AngularJS from RapydML directly, without creating a template engine, I chose to do so for clarity. But nothing prevents you from writing this:

div:
    'This is an angular var: {{myvar}}'

Example 1 (Navigation Menu)

This one doesn’t require any JavaScript. We’ll just need to slap together a RapydML template, leveraging the 2-line template engine we just wrote:

import angular

div(id="main", ng-app):
    nav(class="angular.js(active)", ng-click="\$event.preventDefault()"):
        for $name in [home, projects, services, contact]:
            a(href='#', class="$name", ng-click="active='$name'"):
                python.str.title('$name')

    p(ng-hide='active'):
        'Please click a menu item'
    p(ng-show='active'):
        'You choose'
        b:
            "angular.js(active)"

That’s it, compile it and plug into AngularJS. You will need the most recent version of RapydML, older versions did not handle template engine calls within strings, the new one handles them in double-quoted strings and ignores them in single-quoted strings.

Example 2 (Inline Editor)

As before, we start with the RapydML code:

import angular

div(id='main', ng-app, ng-controller='InlineEditorController', ng-click='hideTooltip()'):
    div(class='tooltip', ng-click='\$event.stopPropagation()', ng-show='showtooltip'):
        input(type='text', ng-model='value')
    p(ng-click='toggleTooltip(\$event)'):
        "angular.js(value)"

Next, let’s add some RapydScript:

def InlineEditorController($scope):
    $scope.showtooltip = False
    $scope.value = 'Edit me.'

    $scope.hideTooltip = def():
        $scope.showtooltip = False

    $scope.toggleTooltip = def(e):
        e.stopPropagation()
        $scope.showtooltip = not $scope.showtooltip

Once again, after compiling the first block of code via RapydML and second via RapydScript, we’ll have a fully-working example.

Example 3 (Order Form)

In this example, we see a new way of hooking into AngularJS. Note the {active: service.active} class tag. We could either reference is in the code verbatim (since it is quoted), or add a new method to the angular template engine for consistency:

angular.active = create('active: %s')

We can now continue with the 3rd example, first the RapydML code:

import angular

form(ng-app, ng-controller='OrderFormController'):
    h1:
        'Services'
    ul:
        li(ng-repeat='service in services', ng-click='toggleActive(service)', ng-class="angular.active(service.active)")
        "angular.js(service.name)"
        span:
            "angular.js(service.price | currency)"

    div(class='total'):
        'Total: '
        span:
            "angular.js(total() | currency)"

Finally, let’s complement it with RapydScript:

def OrderFormController($scope):
    $scope.services = [
        {
            name: 'Web Development',
            price: 300,
            active: True
        }, {
            name: 'Design',
            price: 400,
            active: False
        }, {
            name: 'Integration',
            price: 250,
            active: False
        }, {
            name: 'Training',
            price: 220,
            active: False
        }
    ]

    $scope.toggleActive = def(s):
        s.active = not s.active

    $scope.total = def():
        total = 0
        angular.forEach($scope,services, def(s):
            nonlocal total
            if s.active:
                total += s.price
        )
        return total

As usual, looks similar to the JavaScript version. RapydScript did prevent us from shooting ourselves in the foot by accidentally declaring total as global, something you’d need to be careful about in native JavaScript version.

Example 4 (Instant Search)

For this example, I’ll actually show alternative RapydML code, that doesn’t use our template engine:

div(ng-app='instantSearch', ng-controller='InstantSearchController'):
    div(class='bar'):
        input(type='text', ng-model='searchString', placeholder='Enter your search terms')

    ul:
        li(ng-repeat='i in items | searchFor:searchString')
            a(href='{{i.url}}'):
                img(ng-src='{{i.image}}')
            p:
                '{{i.title}}'

That was even easier than the template engine version, I think I’ll stick to this for my next example as well. Now the RapydScript portion:

app = angular.module('instantSearch', [])
app.filter('searchFor', def():
    return def(arr, searchString):
        if not searchString:
            return arr

        result = []
        searchString = searchString.toLowerCase()
        angular.forEach(arr, def(item):
            if item.title.toLowerCase().indexOf(searchString) != -1:
                result.push(item)
        )
        return result
)

def InstantSearchController($scope):
    $scope.items = [
        {
            url: 'http://tutorialzine.com/2013/07/50-must-have-plugins-for-extending-twitter-bootstrap/',
            title: '50 Must-have plugins for extending Twitter Bootstrap',
            image: 'http://cdn.tutorialzine.com/wp-content/uploads/2013/07/featured_4-100x100.jpg'
        }, {
            url: 'http://tutorialzine.com/2013/08/simple-registration-system-php-mysql/',
            title: 'Making a Super Simple Registration System With PHP and MySQL',
            image: 'http://cdn.tutorialzine.com/wp-content/uploads/2013/08/simple_registration_system-100x100.jpg'
        }, {
            url: 'http://tutorialzine.com/2013/08/slideout-footer-css/',
            title: 'Create a slide-out footer with this neat z-index trick',
            image: 'http://cdn.tutorialzine.com/wp-content/uploads/2013/08/slide-out-footer-100x100.jpg'
        }, {
            url: 'http://tutorialzine.com/2013/06/digital-clock/',
            title: 'How to Make a Digital Clock with jQuery and CSS3',
            image: 'http://cdn.tutorialzine.com/wp-content/uploads/2013/06/digital_clock-100x100.jpg'
        }, {
            url: 'http://tutorialzine.com/2013/05/diagonal-fade-gallery/',
            title: 'Smooth Diagonal Fade Gallery with CSS3 Transitions',
            image: 'http://cdn.tutorialzine.com/wp-content/uploads/2013/05/featured-100x100.jpg'
        }, {
            url: 'http://tutorialzine.com/2013/05/mini-ajax-file-upload-form/',
            title: 'Mini AJAX File Upload Form',
            image: 'http://cdn.tutorialzine.com/wp-content/uploads/2013/05/ajax-file-upload-form-100x100.jpg'
        }, {
            url: 'http://tutorialzine.com/2013/04/services-chooser-backbone-js/',
            title: 'Your First Backbone.js App – Service Chooser',
            image: 'http://cdn.tutorialzine.com/wp-content/uploads/2013/04/service_chooser_form-100x100.jpg'
        }
    ]

On to the last example.

Example 5 (Switchable Grid)

First the RapydML code, as usual:

def layout($type, $imgtype):
    ul(ng-show="layout == '$type'", class="$type"):
        li(ng-repeat='p in pics'):
            a(href='{{p.link}}', target='_blank'):
                img(ng-src="{{p.images.$imgtype.url}}")

div(ng-app='switchableGrid', ng-controller='SwitchableGridController'):
    div(class='bar'):
        for $icon in [list, grid]:
            a(class='$icon-icon', ng-class="{active: layout == '$icon'}", ng-click="layout = '$icon'")
    layout(list, low_resolution)
    layout(grid, thumbnail)
            p:
                '{{p.caption.text}}'

Notice that I chose to be a little more DRY and create an extra function, you don’t have to do that if you believe it hurts readability. Next, the RapydScript code:

app = angular.module('switchableGrid', ['ngResource'])
app.factory('instagram', def($resource):
    return {
        fetchPopular: def(callback):
            api = $resource('https://api.instagram.com/v1/media/popular?client_id=:client_id&callback=JSON_CALLBACK', {
                client_id: '642176ece1e7445e99244cec26f4de1f'
            }, {
                fetch: { method: 'JSONP' }
            })

            api.fetch(def(response):
                callback(response.data)
            )
    }
)

def SwitchableGridController($scope, instagram):
    $scope.layout = 'grid'
    $scope.pics = []
    instagram.fetchPopular(def(data):
        $scope.pics = data
    )

Conclusion

While the RapydScript code above might be a bit cleaner than the original JavaScript code, it’s hard to argue that significant value was gained from porting it. The main benefit of RapydScript comes into play when building larger-scale applications that leverage classes and use numerous variables. Such code increases the chances of shooting yourself in the foot or getting confused when dealing with native JavaScript. Indeed, if you look at some of the jQuery plugins, you’ll see that the code itself seems unmaintainable. After a few layers of anonymous functions it’s hard to figure out what’s being passed around where. AngularJS keeps the code short by handling a lot of the logic for you on the background, RapydScript allows you to keep your own logic readable as it grows. No matter how awesome a framework is, eventually you’ll be writing a lot of your own logic as well.

Displaced Aggression

Displaced Aggression I’m going through a very tough situation in my life – hence the slower development of Grafpad and RapydScript. I won’t get into the details, but basically I’m being sued over a house purchase that fell through. It’s a very stressful situation to be in, and I don’t believe the other party is enjoying it any more than I do. The question then is, why don’t we just discuss it like human beings?

I tried to reason with the other party repeatedly to minimize damages to both. She is not interested in negotiating, her attorney says “she is angry”. She insists that she wants to recover her damages. I still fail to see what those damages are. The mortgage is paid off, she may have incurred a few hundred dollars of extra utility bills she wouldn’t have paid if she moved earlier. I already offered several thousand to make up for it and avoid headaches, we also suggested that she offer her own “just” amount. She refused, her response was that she is angry and intends to take it to court – a court that will take over a year to get to and is just as likely to rule in my favor as in hers.

As a result of the lawsuit, both parties have already incurred several thousand dollars more in lawsuit fees. What did I do that she is so angry about, you may ask? I simply wasn’t able to complete the transaction due to a perfect storm of unfortunate events (recent change in local laws, problems with the bank due to these laws, as well as misinformation from a third party). Another buyer walked away right before me as well, and the seller was angry with them too. I should have seen that as a red flag.

Why am I sharing this? Because I don’t believe that the seller is trying to make a quick buck off of me. If the goal was to maximize her own good, she would have taken the settlement or offered a counter, minimizing harm to both parties, while still maximizing her gain. That is how rational people think. Unfortunately, it seems like it’s not what the seller is after. She is angry. It’s not her own good or damages she cares about, it’s maximizing harm to me – even if it means incurring the same harm herself in the process. Why? Because she is angry, because she wants to “punish” someone for the pain she feels.

When you think like this, you will eventually find someone to punish. Problem is, you’re punishing another victim, you’re not addressing the real cause of the problem. She was angry at the previous buyer, that same anger was later projected at me, amplified by additional headaches. Why was she angry at me? Because this house was a pain to sell (it was on the market for over a year) and because I happened to be the easiest target in this interaction. When you’re angry, you don’t think rationally. When you’re angry, you’re simply searching for a scapegoat, you’re not searching for a solution. If we asked ourselves “how to solve this problem?” more often and “who caused the problem?” less often, we’d create less stress for everyone and we’d need less lawsuits to settle things.

Business Ping Pong

Ping Pong I used to be notorious at procrastination. I still do it, but I got much better at it. The problem was my thought process. We all think in terms of pain. We avoid new pain or seek to minimize existing pain. Procrastination is simply a mechanism to avoid new pain. What we fail to realize, however, is that same pain dwells in our mind. That mental to do list is eating away our brain capacity, causing distractions from other tasks. It’s a numbing pain that keeps coming back. It’s like storing clutter in your house, where the house is your brain. After thinking about my own procrastination, I realized that the pain of dwelling on a task is bigger than the pain of actually doing the task.

As I started tackling these tasks, it became easier to do them. The hardest part is starting. Indeed I got better at this once I started forcing myself to start. The other trick is that you don’t have to do it all in one go, once you start tackling the problem, it gets smaller. The other side of the coin is addressing tasks that involve other people. We tend to procrastinate our responses until the nagging from the other side becomes severe enough. But what if you were to handle the responses as soon as you can? I recently heard a term for this in a conversation: business ping pong. When a ball comes your way, hit it back as soon as you can. Don’t procrastinate, be the one waiting on others, not the other way around. The sooner you reply, the less time you spend thinking about it, the less clutter you keep in your house.

Modifying Native JavaScript Objects

Random Number Generator There are still debates in JavaScript community about modifying native JavaScript objects (Array, Number, String, Object). Some developers believe it’s evil, while other encourage it. If you’ve looked at RapydScript’s stdlib, you probably already know my stance on it – I’m actually in favor of such modifications when they make sense. I might not have as much experience in JavaScript as the gurus, but I have enough experience in language design to form sane opinions about which practices are evil and which are not.

Most arguments against modifying the native objects hold no water. They give examples where the developer overrides a native method to work differently from original implementation. That is indeed evil, assuming that calling this method with the same arguments as original JavaScript implementation no longer produces the same result. For example, if I decided to rewrite String.prototype.replace such that it worked globally, like in most other languages, instead of on a first occurrence:

String.prototype.replace = function(orig, sub) {
    return this.split(orig).join(sub);
}

I could break (or make them behave differently than they should) other libraries/widgets on the same page that assume that replace() will only replace the first occurrence. I completely agree that one should never override existing methods to do something else. It’s important that the basic subset of the JavaScript language works exactly as others would expect it to. If you can’t guarantee that the foundation of your house stays level, you can’t guarantee that your house will not collapse.

There are some gray area cases, where the developer could extend the functionality of existing method, such that it still works as expected given original arguments, but does something else when more arguments are given:

Array.prototype.pop = function(index) {
    if (!arguments.length) {
        index = this.length - 1;
    }
    return this.splice(index, 1)[0];
}

In this case, myArray.pop() will still work exactly as the user would expect. However, if called with myArray.pop(0), the function will behave like myArray.shift(), or like splice() method if called with an index in the middle. The only real disadvantage here is that by overriding the native method, the developer has made the function slower than the original (native methods tend to work faster). Claiming that this is bad because a function could break another logic that mistakenly called it with an argument (which it ignored before) on the other hand is not a legitimate argument. The bug is in the function making the bad call, not in the overriding logic. This is why I like Python, it will complain about unexpected arguments right away instead of ignoring them so they could become a bigger problem later.

Appending your own methods, on the other hand, is the most benign way to modify a native object. This is when we implement something like this, for example:

Array.prototype.copy = function() {
    return this.slice();
}

When doing, so, however, it’s important to be aware if other libraries are appending a method with the same name but different functionality, then you might want to pick a different name (this is usually not a problem with libraries/APIs since you’re unlikely to need more than one library for native object manipulation). So far, the most popular argument I’ve seen against this type of native object modification is potential name collision if future version of JavaScript decides to add a method by the same name. This argument is moot. You’re not developing your app for a hypothetical language that will exist 10 years from now, and when the time comes you’ll easily be able to rename the offending function, since you know all references to it are your own. The entire EcmaScript specification is easily available, and unless you plan to drop support for all browsers older than 6 months, the JavaScript implementation you’ll be using as basis will probably lag behind that by a few months to a few years, giving you more than enough time to handle naming collisions.

You might notice, however, that if you start appending methods to the native Object object, any jQuery code running on the same page will break. The problem is not with overwriting native methods, but with poor assumptions made by jQuery developers who wrote buggy code. The problem is that jQuery developers are part of the group that believe that appending to native JavaScript objects is evil, and instead of properly testing that they’re iterating through object’s own properties, they make the assumption that no one else will append anything to Object when they scan through it using “for key in Object” type logic. To avoid the same mistake as jQuery made, make sure to iterate only through your own keys:

for (var key in obj) {
    if obj.hasOwnProperty(key) {
        ...
    }
}

Alternatively, if you only care about the latest browsers, you can use Object.getOwnPropertyNames() instead. It was a poor design on JavaScript’s part to default to iterating through every property of the object, but that can’t be changed now. jQuery developers have been confronted about their assumption before, they claim the main reason was performance. Independent tests showed about 5% performance hit from adding this check, so I don’t buy the performance claim, especially since jQuery already makes multiple performance sacrifices in the name of usability (show/hide logic having safety checks to figure out the object’s current state, for example). In my opinion, John Resig’s stance on this is no different than failing to do a “division by zero” check (in Python, because JavaScript will automatically return infinity) and then claiming that it’s for performance reasons and anyone who passes arguments that eventually result in a division by zero is the one at fault.

I haven’t checked if this is fixed in jQuery 2.0. Without support for older browsers there is no reason not to use Object.getOwnPropertyNames(). In the meantime, try not to overwrite Object (other native objects are fine) if you’re using jQuery anywhere at all (if you’re not, it’s not a problem). I should also mention that if you don’t plan to support older browsers (such as IE8), a better practice would be to use defineProperty method rather than appending to the prototype, since it will omit the method from getting picked up when iterating through the object, making the jQuery bug a non-issue.

As far as my own stance, it’s fine to append to the functionality of a native object, but never to remove. Modifying existing property to work differently than before, given the same function signature, counts as removal, and is evil as well. I have removed the dependence on overwriting native methods in RapydScript’s stdlib2, but that was mainly to clean up the standard library and make it compatible with jQuery, not because I’m against modifying native objects.

Productivity vs Performance

Productivity vs Performance When I was writing software in college, there was more emphasis on program execution speed than on time spent implementing it. In startups and most work environments, the reverse tends to be true. It took me a while to figure this out, and for the first few years of programming, I would often introduce optimizations that were not necessary, or make code uglier than it needed to be for the sake of performance. I’m not talking about premature optimization, I’m talking about poor design decisions stemming from assumption that performance trumps legibility.

I’ve spent a lot of time refactoring poorly written code in Grafpad – code that wasn’t necessarily bad to begin with, but quickly outgrew its initial purpose as more special cases were introduced to it. What gave me even more grief, however, were the special cases I imposed on myself, in an attempt to preserve bandwidth, CPU and memory usage. For example, each shape point in Grafpad consists of 3 items: x-coordinate, y-coordinate, and curvature flag. In original version of Grafpad, shapes that I knew couldn’t have curvatures omitted that curvature flag. As a further optimization, I wrote faster versions of multiple algorithms (edge detection, intersection, bounding box computations) which didn’t have to deal with curved lines. I later ended up regretting that, having realized that I did twice as much work to handle a case that may have been fast enough anyway. I wasted time I could have invested elsewhere, I introduced special case logic that didn’t need to be there.

Another example is the logic I created for transmitting data to server and back. I didn’t like that JSON.stringify included a lot of irrelevant information, which I wouldn’t need since I knew exactly what kind of object I’m sending over. My packing method transmitted only the values themselves, and I was unpacking them correctly by following the same order of operations. Once again, I performed a bunch of work that JSON.stringify could have handled for me, and ended up with a more fragile solution that depended on pack/unpack logic on both front-end and back-end to be identical.

I’m not saying the work I did was pointless, it simply wasn’t the kind of work I needed to do at an early-stage startup. By the time these kinds of optimizations become relevant, the product should already have multiple users and a team of developers who have time to do these optimizations. An early-stage startup should concentrate on getting the product out the door and fixing bugs that affect users, performance issues rarely matter at that stage. And with proper use of polymorphism, those optimizations will be easy to add later on in cases where they do matter.

RapydScript is Self-Hosting

While the RapydScript community is small, our members are passionate about the project, and I’m grateful for that. Salvatore, for example, has put together a number of demos showcasing RapydScript integration with WebGL, NodeBox, GlowScript, and a number of other JavaScript projects. Charles made a Chip’s Challenge clone. There are also examples of RapydScript integration with D3, and a Paint app that uses HTML5 canvas and jQuery. When we started a little over a year ago, members would ask us “can RapydScript work with ___?”. Now instead of just saying “yes” we can often point them to a demo.

To take things one step further, I decided to port the compiler itself (originally in JavaScript) to RapydScript as well. This effort took a few weeks, and a lot of tweaking to a Decompiler project that was put together a while ago. The decompilation wasn’t without issues, and I had to manually tweak some code. Along the way, I also discovered a few minor bugs in RapydScript, which I have fixed in the process. Overall, however, I was pleasantly surprised by how easy it was to port the code. The ported version is not written in Pythonic style that RapydScript tries to encourage because the code-generation was mostly automated, yet it already looks more legible than the JavaScript version it was ported from. I’m very proud of this, since it’s an important step for a compiler to achieve the self-hosting status, and I’m not yet aware of any other Python-to-JS compiler that can say the same (they’re all written in Python, but the subset of Python that the languages use isn’t enough to support the compiler itself).

I hope that this will make future enhancements and tweaks to RapydScript easier, both for myself and other members of the community. As a bonus, I’ve also added kwargs implementation to RapydScript. It works similar to Python, but not completely like it (for performance reasons), I suggest you read the manual on it before use to avoid surprises.

What is Pythonic?

Occasionally I get told that RapydScript is not Pythonic enough, because I don’t support a certain feature of Python. For example, because I don’t handle string interpolation out of the box. I don’t do this because there are already JavaScript alternatives that do a very good job (http://www.diveintojavascript.com/projects/javascript-sprintf), and I don’t like reinventing the wheel. The purpose of RapydScript is not to mimic Python functionality exactly, but to make JavaScript development more sane for those who’re used to Python (or can’t stand CoffeeScript’s Perl-like syntax).

RapydScript takes a different approach from other Python-in-a-browser frameworks, I do not try to reproduce Python functionality in a browser, and in fact Guido himself argued against that for the same reason I argued against Pyjamas, see his answer to “Python in the browser?” from this interview: http://developers.slashdot.org/story/13/08/25/2115204/interviews-guido-van-rossum-answers-your-questions

The %-based syntax simply doesn’t make sense to implement, because % operator is already reserved for modulo division both in JavaScript and in Python. Overriding that would require a new function, something along the lines of _$rapyd$_interpolation_or_modulo(), which would need to check at runtime what the user meant to do based on arguments. And this kind of overhead for the logic that’s already achievable via a more explicit sprintf is why Pyjamas apps were a pain to debug. The "{}".format("foo") syntax, on the other hand, I have no problem with, it requires no compiler changes and does not conflict with existing functionality. I don’t need that syntax because sprintf plugin does the job for me, but feel free to submit a library that implements it yourself if you need it. That is after all, how open-source works.

At the end of the day, you should ask yourself: What is “pythonic”? Is it something that reproduces Python’s functionality exactly? No, because Python itself evolves. Is Python 2 more pythonic than Python 3 because it was there first or is Python 3 more pythonic than Python 2 because it simplifies parts that might not have made sense? Is something pythonic because it follows The Zen of Python? If so, then isn’t an explicit sprintf more pythonic than % operator, which can be confused with modulo division based on context? I certainly think so.

Since its inception, Python’s main selling point was how similar it was to pseudocode that you would see in textbooks, not its shortcuts. RapydScript tries to stay true to that philosophy, by cleaning up parts of JavaScript that don’t make sense, and leaving the parts that do alone. That’s the main difference between RapydScript and regular Python-in-a-browser compilers. RapydScript doesn’t try to replicate all of Python syntax, that’s a fool’s errand. RapydScript tries to introduce the clarity of Python into JavaScript.

At the end of the day, you have to realize that JavaScript did not start developing its main feature-set until a few years ago. As a result, it could learn from mistakes of many other languages, including Python. If “pythonic” is something that follows Python’s philosophy and simplicity, then in some ways, the new JavaScript is actually more pythonic than Python. If you don’t believe me, look at CasperJS and compare its simplicity against any of Python’s web-scraping alternatives. Better yet, compare the simplicity of building a GUI with HTML5 and jQuery vs building a GUI in Python.