Skip to content

Field Notes from Test-Driving Other Languages

August 8, 2011

This month I learned two languages outside of work, mostly for fun and to broaden experience. Using a new language may open one to thinking about programming problems with a different approach.

JavaScript

Last weekend, I spent some time teaching myself enough JavaScript to effectively port a browser application that I wrote in Silverlight to run in HTML5. I used JavaScript a bit once before, to plot graphs using the flot jQuery library, but at the time didn’t need classes or data structures, and so didn’t pick up much of the language.

From this brief experience, my thoughts on JavaScript are:

  1. It’s object-oriented, but not in a way familiar from other OOP languages.
  2. It’s functional, but not in a way familiar from other functional languages.
  3. It’s easy to get started and do simple things.
  4. It’s powerful, but in non-obvious ways, and there are many pitfalls when moving beyond the simple aspects.
  5. It’s a pain to debug (always switching back and forth between browser (w/ Firebug) and editor), and seems difficult to write unit tests.

Keep in mind these comments come from a one-day newbie, particularly point #4 which may be due to inexperience.

Regarding point #1, JavaScript is the only object-oriented language I’ve used that doesn’t have an explicit way to define classes in the language syntax. Objects are really just hash maps of other objects, and functions are also objects. To make a class you actually define a function, and compose the rest of the class by mashing the properties and methods into the function object (the function definition also serves as its constructor). A this reference self-refers to the instance from within functions. But any function can refer to this whether it’s defined inside a “class” or in the global scope. Powerful, but madness.

There’s more to it than this, because you can also create prototype objects, and through prototypes get into inheritances. I’ve only scraped the surface of object prototypes, because my program doesn’t really need it, but would be necessary to learn if writing a reusable library.

I can’t say I enjoy JavaScript so far, but maybe that’s because I misunderstand it. JavaScript is considered a prototype-based programming language, as opposed to the class-based languages derived from Smalltalk (e.g. Java, C++, and C#). I don’t feel it’s helped me view problems differently, because my approach is to coerce the code into a notion of class-based languages… not wanting to let go of the encapsulation and data-hiding I’m used to. JavaScript seems chaotic and free-form: I could easily hack up a lot of code, but don’t feel like it lends itself to coherent designs. I worry that the structure of the code won’t be visible when revisiting it a year later.

F#

The other language I recently took for a spin is F#. A few weeks ago, I decided to pick up a bit of F# to see if it was practical to use at work (which mostly targets .NET platforms).

My exercise for F# was solving a question I use when interviewing candidates. It has a recursive solution, and is therefore well-suited to a functional approach. Since I already knew a solution, I could focus on learning the language and not figuring out the problem at the same time. The main difficulty with F# was getting the syntax correct; when I made mistakes and typos, I didn’t understand some of the unhelpful compiler errors. But syntax issues aside, the program itself was easy to compose (succinctly, I might add, compared to non-functional languages).

As a systems developer, it’s not clear that a functional language is the best tool, where applications handle high volume of data and state in the network and the cloud. I have a hard time picturing how to write some of this system-oriented software in F# when it must deal with state. I would need a much higher comfort level with the language to do so as rapidly as in C#, but that’s more of a fluency issue. In general, it seems better for data analysis tasks, and might have some place in the documents processing sections of our software. I could see our stack containing a mix of modules, some written in C# and others in F#. Given they both compile to managed .NET code, this is certainly a possibility.

Functional languages definitely put me in a different mindset when approaching a programming task. Whereas I was reluctant to allow JavaScript to change the way I think about objects, F# sort of forces the issue when it comes to thinking about program flow.

There is one aspect of F# which has considerably changed my approach to programming even in an imperative context: data immutability. In many cases, redesigning an algorithm to use only immutable objects helps clarify the code, making it easier to understand and maintain. There are times when it adds performance cost, because to change an immutable object means replacing it with a new one (and hence allocating more memory). On the other hand it may provide gains, because there is never thread contention for an immutable object, so there are definitely trade-offs.

The big win is that in a complex system that passes around a lot of objects, knowing an object is immutable simplifies the mental model necessary to understand its interaction with other pieces. It’s much easier to get your head around the purpose of something that isn’t going to change state underneath you. And any simplification of a complicated system makes it less error-prone. Obviously not every object needs to be immutable, but when surveying a program at work, I was surprised to discover how many mutable objects that could be made immutable without much effort, and refactored the code for it.

Outcome

JavaScript is definitely an interesting approach to objects. I don’t see myself becoming an enthusiast, but really there’s not much other choice for browser code so I’ll continue to use it when necessary (and libraries such as jQuery make it more tolerable). As for F# I am still undecided. I like it, but currently not productive at it, so I’d like to find a project where I can dig deeper. In the meantime, what’s more interesting is that imperative languages keep borrowing useful concepts from functional languages (e.g. lambdas) and with effort programmers can apply them too (e.g. immutability). So I’m able to pick and choose these techniques when appropriate, without resorting to a new language.

One Comment leave one →
  1. sbanacho permalink*
    September 1, 2011 5:38 PM

    I just attended a talk where the speaker said “JavaScript is a write-once language”. This echoes my concern that it is hard to maintain.

Leave a Reply

Your email address will not be published. Required fields are marked *