My New Favorite Language

Lately, I’ve been working in Java, Lisp, and JavaScript.  It’s been interesting to see the similarities and differences in the three.



First, Java - I don’t like it.  I really don’t.  It’s syntax is overly verbose.  The type and packaging systems are arcane, even for their age.  Directly using primitives and object wrappers seems silly and breaks the object-oriented paradigm.  The rigid class system forces you into creating complex hierarchies to create programs.  One public class per file, really?  And, to top it off, it’s controlled by Oracle.



Yes, Java has a huge standard library, which is nice.  However, the language isn’t the library.



Which leads me to Lisp.  It’s syntax is very expressive, save for the obnoxious plague of parentheses.   Using Emacs and elisp together provides an excellent environment for programming; it’s got built in documentation lookup, syntax highlighting, scratch buffer, etc.  However, the library support is pretty bad.



The one caught in the middle is JavaScript, with the syntax of Java and the concepts of Lisp.  Douglas Crockford points out the power of JavaScript’s anonymous functions, which were inherited from Scheme.  This is not a construct that is present in Java, but I’ve found that it’s tremendously beneficial for JavaScript’s event-driven model in the browser.  It, linked with the object literals and prototypal inheritance, allow for a lot of flexibility and expressiveness.  Honestly, I’m finding that JavaScript is becoming my favorite language.  Yes, I’d have to use it no matter what in web development, but I actually catch myself wishing I could be using Node.js at work.



Server side JavaScript is definitely appealing, but there aren’t that many libraries out there.  On the one hand, that’s not a problem - there are tons of redundant libraries like jQuery, Prototype, Dojo, and so on.  People are happy to write their own libraries in JavaScript, it seems.  But, there is the movement for creating common APIs at the CommonJS site.  I think this is a good idea, but not everyone’s on board: Node, for example, is selective in what it takes.



It will be an interesting road forward - JavaScript is all over, but with lots of people figuring out that it can do more than simple web page gadgetry, I think it will become a contender to Python and Ruby in server side languages in the next few years.

New App Store Policies and Guidelines

Last Thursday, Apple announced that they were relieving some of the heavier restrictions on iOS development, as well as publishing guidelines so developers know what kind of criteria their apps are measured against for approval.  While it’s not a complete abolishment of the App Store like some people want, it’s a huge step in the right direction.



The fact that they’re not restricting tools is a big one.  From what I understand, Adobe’s Flash cross-compiler is now completely legal, as are MonoTouch and similar platforms.  Flash still can’t run in the browser like it can on Android, but that’s really not what Adobe was after with the CS5 cross-compiler.



The runtime is addressed by the new, clarified 3.3.2 rules, which states that an application cannot download or install executable code, but interpreters and their scripts can be bundled into the application.  This was big for game companies, and I think we’ll see more people exploring the use of scripting languages as app platforms now that the wording is clearer.



3.3.9, the section which apparently banned the use of 3rd party ad networks, has been relaxed.  The main sticking point, one that Jobs called out in his D8 talk was that the analytics packages were gathering hardware data and leaking information about Apple development hardware.  Now, with time to calm down, Apple’s reverse their strong arming, allowing other people back in, but still explicitly blocking hardware analytics tracking.



Finally, the App store guidelines.  While I don’t have an iOS developer account, I did catch some of the details at Daring Fireball .  It really sounds to me like Steve Jobs was directly involved in this document, either in writing it or dictating it.  The language is casual, has his tone to it (“We have over 250,000 apps in the App Store.  We don’t need any more Fart apps.”  Gee, wonder if that meme finally got under his skin?) and is delightfully absent of legalese.  Several rules that had never been explicitly stated yet were used to reject apps were finally stated, like apps that simulate a ‘desktop/multi-app widget experience’.  It certainly doesn’t cover everything, but it’s definitely way better than what was available previously.



I did not expect Apple to reverse their decisions so drastically.  They really do like having control over their brand and user experience, so when they played hard ball earlier this year, it wasn’t really a shock.  This set of changes is welcome, but should also demonstrate to potential developers that Apple really will change things drastically under your feet - here’s hoping it won’t be a repeat of the lockdown next time.

The Best Tools

Recently at work, we’ve been discussing NetBeans as our “standard” development platform.  Personally, I had switched off of it several months ago to use TextMate, but I’ll get to that in a little bit.



What prompted the switch from NetBeans was all the little papercuts it had - long start up time, poor support for Python compared to other languages, weird syntax highlighting (that completely breaks when using something like Jinja templates), and a bunch of other things.  So we started looking around for some alternatives.



Our two main criteria were that it must be cross platform, and it must have Subversion support.



Before I had started here, they had tried Eclipse and didn’t like it (I don’t know their reasoning) and moved to NetBeans.  Now, because of the quirks listed above, and the fact that Oracle’s future support for it is questionable, we’re looking around.  So far the only proposal has been Komodo, which I’m trying out before I can say too much about it.


My main issue, though, is that this ignores the point of the tools.



Any tools you use should be used because they allow you to be more productive.  That’s really at the heart of the issue.  If you’re more productive in Windows and Word, then you probably shouldn’t buy a Mac and get Pages.



For myself, the tools that are the best are the ones that don’t get in my way.  TextMate has all the power of the IDE, but it’s not thrown in my face and put in my way.  It’s extensible through bundles, supports tons of languages out of the box, and is just all around nice to work in.  Hell, I’m writing in it right now.



But, it’s not cross platform, which I do admit can suck sometimes, but not enough for me to drop it entirely.  Instead, I’ve made sure I learned enough of VIM to be able to survive on a machine without OS X.  No, it’s not VI, but I had to draw the line somewhere.



Same goes for the command prompt - I like using that with the other tools (Subversion, Mercurial, etc) because it stays out of my way.  Yes, remembering the commands is a little arcane, but it’s faster that the GUI for me and I can usually get exactly what I want done with minimal effort.



Finally, I’ve been playing around with Mercurial at home instead of with Subversion like at work.  Subversion’s branching mechanism are a major headache, and merging from one branch into another is a time consuming and manual process.  While I have yet to do much with branching and merging in Mercurial, I’ve already found instances where it’s better than Subversion - like monitoring for commits, updates, and changes in the entire code branch, not just the directory you happen to be in.



Ultimately, though, this is all a lot of masturbatory talk - if the tools aren’t being used to make something, all those features and comparisons don’t matter.

Ruby vs Python

Alex Martelli, the guy who spearheaded the Python Cookbook has a nice essay on Python vs Ruby.



It hits on a lot of the things I’ve noticed between the the two languages.  They’re very similar, far more similar than you’d think at first glance; both allow a great degree of metaprogramming (though admittedly, Ruby’s is far more prevalent and pervasive) , both allow people to put things into production with pretty straightforward syntax, and both kick the crap out of Perl.



The biggest differences that Martelli highlights are things I’ve noticed, too - there are little syntax nits, but the big issues are the level of metaprogramming allowed, and iterators/codeblocks vs iterators/generators (and I’d throw decorators in there, too).  Ruby allows you to open anything up, and while that can be nice in some scenarios, it could be a nightmare in large scale projects.  Python still lets you clobber builtins, but you can’t, for instance, open up the Python 3 str class and edit it, outside of subclassing.



It’s far more common in Ruby to crack open a class and do stuff with it; Rails is fundamentally built on that.  Python lets you do that, but I just don’t run into it as much in actual code.  There’s some, but it’s closer to the straight-forward C-style stuff.  Perhaps it’s the projects and code I’ve encountered, I dunno.  But, for contrast, Pylons and Django are far more comfortable with requiring the programmer to use them as libraries, rather than the DSL-ness of Rails.



Ultimately, between the two it’s really a matter of taste.  Yes, that applies to all programming languages, but Python and Ruby are close enough to each other that it’s more down to taste than one of those compared to say, Java or C.



All that said, I’ll continue to use and learn what I can about both.    Sometimes, an idea can be more easily expressed in different syntax, and that’s ok.

RDD

I found an excellent piece by one of the founders of GitHub talking about Readme Driven Development.

It's an interesting take on "agile" and "test-driven development" methodologies; as a response to the waterfall methods they were great.  But documentation accompanying them can often leave much to be desired.  That's certainly the case with our "agile" projects at work.  The software's done, the code is commented, and people are ready to move on.

Preston-Werner makes a good case for getting the Readme down.  The file shouldn't be long and doesn't need a lot of detail, but it helps you think about the bigger picture first.  It organizes your thoughts.  Because of it, you have a better idea of what to focus on first, and how pieces of the program fit together.

His other comment about getting other people up and going on the project without having seen your code is valuable, too.  I'm trying to be very diligent on getting any kind of design decisions or discussions into the project's Trac wiki for anything new that we do for this exact reason.  When it's there, in writing, it's far easier to remember what was agreed on, what direction we should take, and offers a springboard for new discussions.

What to learn

A friend sent me an article today entitled 'tactics, tactics, tactics'.  I loved it.

It's about stepping back and really looking at what you're trying to learn.  Are you focusing on the tools, in the case of programming, design patterns, languages, source control, IDEs, so on and so forth, or tactics?  Something transferrable to any programming language, something that isn't a fad and that doesn't get in the way of actually becoming better.

The comparison of a "junior" programmer to a fledging chess player is very astute, I think.  Simply being able to code does give you a rush; hell, I remember looking around at all my coworkers when I began automating tasks at my old job and thinking "What the hell is wrong with these people?  Why do they think this is so hard?"  Admittedly, I sort of enjoyed the attention it got me, at least for a while, but eventually I started interacting with people who were beyond my skill level, and I found that I was only scratching the surface.

I think this was a good thing.  It pushed me to learn more.  However, I haven't always been learning the right things.  Stressing over Ruby or Python, Pylons or Django, CouchDB or PostgreSQL; while important, they're not nearly important as learning how to make loosely-coupled, highly cohesive classes.  Or crafting an appropriate data solution to your application.  Or understanding network communications and HTTP connections between clients and servers.

Ultimately, for me, I think this was a bit of a wake up call to get back to the stuff I get all fired up about when listening to Merlin Mann.

Get back to doing things and learning important things, not stressing over tools.

Oracle

Oracle's not done a whole lot to impress users since buying Sun.  The latest jackass move was that they essentially slammed the door in OpenSolaris without saying a word.  In response, the entire OpenSolaris Governing Board resigned.

I don't think this is good for anyone, even though OpenSolaris was comparatively small next to Linux or the BSDs.  Having some of the Solaris tools, like DTrace and ZFS, out in the open and maintained in the open was great.  FreeBSD especially was pretty gung ho about integrating these and providing support for them.  I'm sure that this kind of behavior is seen as a threat to Solaris by its new keepers now, though.

Oracle seems to have gone on a killing spree since acquiring Sun, either by damaging the image of a product or by attacking former partners and users, either through their internal memos or things like the Google lawsuit.

We've even been hit directly at work; academic pricing on Sun hardware is now gone, and the Sun Grid Engine we used for scheduling the clusters is getting the open source axe, too.

In February, we began migrating any projects we could off of MySQL to PostgreSQL, simply because Oracle's intentions were such an unknown.  Given what they've been doing to the portions of Sun that didn't conflict with their brainchild, I can only imagine that it will be a matter of time before they set about tearing apart MySQL.

Pretty sad that in the past year, Microsoft's gone from being the 'evil empire' to Oracle and Google competing for the crown.

Python 3 and WSGI

I like Python.  I really do.  It's clean, easy to read, quick to write, and is usually fun.  It's been our primary choice when developing for the web at work, and in it's current state it fits that role exceptionally well.

Well, kind of.

You see the WSGI standard that most Python web frameworks and libraries adhere to right now don't work in Python 3.x.  Why?  It has to do with how strings are implemented in 3.x vs 2.x.

In Python 2.x, the str data type was a series of bytes with methods that made it convenient to treat them as, well, strings.  There was also the unicode type that had many of the same methods.  One thing that Python 2.x did that was really annoying, though, was it would implicitly change data back and forth between the two types on you.  This led to all kinds of hard-to-find bugs (I ran in to TONS of them in working on my first project for my current employer, a web crawler).  Especially in web programming, there were times were it was unclear whether a value was str or unicode.

Enter Python 3.x, which was largely motivated by a desire to clean up weird bugs like the above in the language.  To fix the above problem, what they did was this: Python 2.x's unicode became Python 3.x's str, and Python 2.x's str became Python 3.x's byte arrays.  Kind of.  The Python core developers felt that giving the new byte arrays all of the old str methods would result in exactly the same problem; developers would inevitably get strs and byte arrays mixed up.

This obviously affects anything that has to deal with strings, but it especially affects WSGI.  A lot of WSGI implementations seemed to rely on the implicit type changing behavior from before, and Python 3.x breaks that pretty hard.  So some of the people involved with the original WSGI spec got together and tried to propose new solutions.

From what I have been able to ascertain, there are three main camps:

• Make everything native (that is, unicode) strings
• Make everything byte arrays
• Use a combination of them (usually bytes or strings in the header, and the body being the other)

There is also a fourth view, to petition the Python core developers to re-introduce the string methods on byte arrays, or at the very least create a new data type that does so.  This hasn't gotten much traction from either the web community or Python core.

Using native strings across the board sounds nice, except that HTTP isn't implemented in Unicode; it's ASCII.  So, there would have to be a conversion to the byte array at the response/request boundary, when the data is leaving or entering the server.  This could result in data loss, depending on the encoding used by the WSGI application(s).

And speaking of encoding, it seems unclear which would be the default.  There are a lot of Unicode encodings, and without clear definition of which one is the 'default', it becomes hard for an implementation that relies on WSGI middleware-wrapping to keep them straight.

That leads us to the byte array proposal.  This matches up with the HTTP spec quite well, and would put us back where we're at now in Python 2.x, right?  Unfortunately, that's not quite true.  Again, because the byte arrays don't have the old string methods, you can't do string operations on them inside of your application without doing an explicit conversion into Unicode, which again runs into the problem of which encoding to use.

Compounding that, when using WSGI middleware, an implementation with bytes would have to encode-act-decode in every single middleware application, which could certainly add up.

Finally, there's the mixed approaches.  These carry the same problems as the first two approaches, along with the added confusion of working with two different Python types in a single response or request.  And, some proposals have even had mixed data types inside of the WSGI environ dictionary, something I'm sure would be a head ache.

So where does that put us?

Right now, I don't know of any concrete attempts to build any code implementing any of these proposals.  None of the library authors (Paste, BFG, Werkzeug) want to take the time to do a large-scale conversion for fear it would be wasted effort if that particular proposal lost out.  At least, that's my understanding from digging through their blogs and the mailing lists.

Everyone agrees that a new standard is necessary for Python 3.  After all, 2.7 was released last month, and it's the last of the 2.x line.  Sure, it will still work, but it's not going to receive any new features that future 3 versions will, like Unladen Swallow.

It's hard to predict what's going to happen.  My fear is that something will either just get implemented without much input, or a PEP is accepted just to break the deadlock, and we end up with a problematic standard.

Maybe that's everyone else's fear, too.

"Weak Android Player Proves Jobs Right"

This article is great, but the comments are even funnier.  Seriously, someone who claims to be from Adobe saying the author stole the software?  And the people asking about TaskKiller?  Yeah, real people don't work like that.  They expect it the thing to work out of the box, and that's something Flash on mobile just cannot deliver right now.

But of course, like desktop Linux, any day now...

"The worst one in the band."

I recently read The Passionate Programmer by Chad Fowler, and gotta say, I'm a raving fan.  It will probably come up a lot, largely because I think it's good, solid advice, and because I'm fairly confident most people know a lot of it already, they just need the push.

One of the essays in it has a topic that's been pretty central in my mind lately:

"Be the worst one in the band."

Sounds like really bad advice, huh?  I mean, who would want to be the worst in their group?  Not really an enviable position.

But Chad makes a clarification that completely turns this on it's head.  If you're always striving to be the worst person in the band, you're constantly going to be surrounded by great people.

I mean, think about it - would you rather be the most talented person in Nickelback, or the least talented person in The Beatles?  The best person in your local quartet, or the worst violinist in the London Symphony Orchestra?  Best player on a minor league team, or the worst in a major league?

Chad points out that this almost necessitates you change bands; after all, you're not trying to stay the worst.  So, as your skills grow, it makes sense to move on.

To me, this is incredibly inspiring.  I faced pretty much this exact choice around October of last year: I could either stay on at the company I was with and be a 'senior network engineer' (if not in title, definitely in practice) straight out of college or I could start applying to other places and expand my skills.  A big deciding factor for me was that I was already doing the work I would be doing after school; I had gotten as high as I could there.

In reflecting on it, I had realized that in terms of skill set, I was at the point where I had wanted to be upon entering college.  So, I decided to make the leap and look around.

There were a few places I applied, one of them being thesixtyone.  I had loved their mission, and I loved the site itself for a while at that point.  When I had heard they were looking for candidates, I was thrilled.  Not to mention, they were pitching a wanted ad that spoke to me - no resumes, no cover letters, no degrees.  Here's a set of problems, work on them and send us your code.

So I did.

I got turned down, and in looking at my code now, nearly a year later, I can definitely see why.  But, even in that attempt, I enjoyed what I was doing, and there was nowhere to go but up in terms of programming skill.  Thankfully, my current employer recognized that, and things have been going well.  I get to work on interesting problems, and I'm surrounded by incredibly intelligent people.  At this point in time, it's an excellent band for me to explore and learn.

So, the next time an opportunity comes up to join a 'better band', don't be put off because you think you'll be the worst.  In reality, you'll probably surprise yourself and find out you aren't.  And even if you are, so what?  That only means you're at the ideal place to take risks and grow.