Photoshop is a tool to create products, and it's a product. AutoCAD is a tool and a product. Frying pan and chef's knife are tools and products. Yet when we talk about programming languages and platforms we avoid acknowledging that they are products, and subject to product lifecycle. Thoughts about  experience and product development of a programming languages were bouncing in my mind for couple of months now but I wanted to wait for Apple and Google to do their talk and see if any of them will announce their languages (Swift, Go, Dart) as products. Apple was close, but not there.

Before we get to article proper I need to clarify few things:

  • Language and platform in this article can be used interchangeably. Language without compiler, standard library, documentation and runtime is just a specification, and while Lambda Calculus is cool, I care about things that run on my devices for the scope of this article.
  • Aspects of a languages that everyone already highlights, such as syntax, code editors etc will be glossed over.
  • Data and information in this article is subjective and anecdotal. Collected by me from my experiences and my memories of conversations with self selected group of people I call my friends. So if you know of actual research, or objective data feel free to ping me at davidsergey.com. I'll owe you cup of coffee, tea, beer or small bag of organic salt!

Onboarding

Onboarding one of the first stages of product interaction with person. Onboarding is ability of a product to turn person into customer.

Back in 2001 I was in Moscow University of Management studying Management in Banking and Marketing, being Russian university we had only couple of hours of actual marketing a week, but we had 4 hours of advanced mathematics and linear algebra, I suspect in Soviet times someone would just try to smuggle nuclear physics into curriculum too but we've covered that in school. But I digress. Since most of us were sold on "Marketing" part of our curriculum we paid a lot of attention to those couple of hours a week and being a huge show off I wanted to make best presentations ever, so I ditched Microsoft Powerpoint in favour of Macromedia Flash 5. It was stupid decision, but life changing nevertheless.

I couldn't code. I didn't know what "function" was, In fact I didn't know about Arrays until summer of 2003, but none of that stopped me from using Flash and ActionScript to make my bulleted lists jump around with simulated physics in my overly engineered presentations. I've spent weeks designing presentations that my peers were doing in hours. Without any knowledge of design principles or interaction I was able to create offensive to usability menus and lists. You see flash allowed people like me to keep doing things. If we didn't know how to do something with code, we could simply animate it by hand on the stage. 

This is how Flash turned me into their "customer", though I couldn't afford to actually pay for it until 2005, but I did earned money to buy Adobe Flex using somehow acquired version of Flash. And while we at this let me reiterate the fact that you should never use HTML or Flash to design presentations, you will spend days or if you happen to work for medical company weeks to make something that should be done in few hours with PowerPoint, Google Slides or Keynote.

Flash was unique, it literally had a stage and timeline, and I'm not advocating for presence of drawing tools in Erlang, what I'm talking about is experience for a beginner to be able to keep doing stuff, without feeling of being stuck. It's like airport design. It takes about the same time in Singapore airport to get luggage, as in any other airport, but airport designed in a way to make people think that stuff happens, and they don't have time to get bored.

Ruby on Rails and jQuery also have great onboarding. I know a lot of e-commerce and visual designers who started to use RoR or jQ and achieved acceptable results by means of evolution – trying various gems and plugins until they got the effect close to specification provided by client. In fact there are quite a few e-shops selling all organic natural salt, hand made jewelry and temporary tattoos written by people who frankensteined web sites from soup of gems and plugins until it worked. I'm talking about presentation layer, database, payment and fulfilment. I'm not going to even attempt to share any links because I suspect that those sites are hackable in one afternoon.

But quality of results is not the point, eventually people learn how to create high quality ones or learn to delegate. In the beginning it's very important for platform to get results done. Great artists Ship said Steve Jobs, maybe any one who wants to be an artist should be able to ship. No one should be required to understand how to configure build system, interact with versioning system and setup deployment to create farting app for their phone or publish a business card website.

Interaction Design

Platforms are very interesting from the point of view of interaction design and information architecture. They are cohesion of multiple things: language specification, language reference and documentation, literature about language and frameworks and of course actual libraries, compilers and code editors. It's almost design of ecosystem instead of single entity, but let's focus on few ones that are my pet peeves.

Documentation

There are two kinds of people. Those who like to read, and those who don't, and then there are a lot of different kinds of people I didn't mention. But I believe that any language reference or api docs for library should try to be like Xcode, .NET or ActionScript. Every single entity (class, property, method, whatever) should have it's own page. And every single page should contain description and compilable source code, that people can literally copy and paste into empty project, compile and fiddle with it.

Yes it's very expensive, I wrote few frameworks and never did it. It takes a lot of time and will power to accomplish this, but I promised myself that if I'm ever going to create yet another JavaScript MV* framework then I must write thorough documentation before releasing it to the public. Feel free to blame me and spike my coffee with milk and watch my lactose intolerant body crumple if I betray the promise.

The lack of clear examples is the reason why every single developer uses Angularjs just slightly differently. And in fact I saw five or six different ways to organise code and use numerous types of Factories on very similar Angular projects. People spend hours or days, explaining or arguing about things that could be covered by documentation. We are programmers, we can argue for hours about whether we should call model of users UsersState, UsersModel, or Users, let's be honest it helps if someone just creates convention. And I love Angular, and Angular is actually one of the least offensive frameworks in this regard. Worst among the popular ones is Backbone, I never saw two remotely similar Backbone projects in my life. Phrase "Backbone Experience" in job specification has zero value.

Playground

Apple's Playground in Xcode is awesome. Yes it won't work on big chunks of code, yes it had security issues and wiped somebodies system, yes yes yes. But nevertheless it's awesome. Person can write a line of code, and play around with it until they understand it. Whether it's language feature, or animation equation. It's especially important because Swift is a paradigm change from Objective C, it's hybrid Functional and Object Oriented language and Objective C gurus will need some time and help to shift their minds and rewire their brains. Not to mention it will help bringing entrepreneurs, designers and other non-programmers into the fold – because they will spend less time being stuck while developing their prototype.

Before modern browsers had developer consoles, Firebug allowed people to play around with their code. It was officially a debugger, but it allowed execution of random JavaScript, and it helped me by allowing me to play with CSS right in place. In ATP podcast Marco Arment (creator of Instapaper, Overcast etc) said that he chose Go programming language because it had "Try Go" feature on their website, it allows people to write som Go code, that will be compiled for them on back-end without need of installing anything on their system. It allowed people to play around with language without committing to it.

One of the most popular languages that compile to JavaScript - CoffeeScript has similar feature. I'm not trying to say that this is must have feature. And I probably will have to create a program that would extract all programming languages from some Wikipedia article, then search their websites, and find if their websites or tools have a playground like feature, and then compare it's metrics with languages that don't have this feature and find if this actually does anything. But not today.

Can I sell it?

If you still reading this article that means you either agree with my notion that languages and platforms are products or I have some dirt on you and blackmailed into reading this far. But apart from being a product it's also a tool to create other products. So it's important for a platform to be sellable, it's important for a platform to be understandable and appealing to design and marketing agencies, hipster and tech startups, corporations and non-for profit organisations.

I have a relatively free reign in choice of platforms I use, as long as I can justify technology to myself, my team and my client. Dart was a bad example of that it's next to impossible to sell, and I'm (used to be) very enthusiastic about it.  Tech people love it because it supported by Google and has testing in mind. Business people love it because it has testing in mind, and while they might not know about importance of unit, ui and integration tests, the fact that it comes with it saves dozens of person-hours. Swift is easy to sell, because it’s soft-monopoly, if development of an iOS app is about to begin in few months, Swift is obvious choice, because Apple said so. 

Conclusion

So in conclusion I would like to present you first draft of 8 things that every language, platform, runtime, library or API needs to have to be.

  1. Product should be properly versioned.
  2. Source code of a product should be 90% covered with integration and unit tests.
  3. API of a product should be fully covered by documentation.
  4. More than 80% of entities in API should provide usable examples.
  5. Unstable and subject to change features should be marked appropriately, to avoid arguments in team whether something is intended for public use or not.
  6. Product should have playground, to allow people to quickly experiment.
  7. Product description should be appealing to direct customers (software engineers) and their clients.
  8. Product needs a killer app. Language needs a comprehensive framework, framework needs a good example of it's product and so on.

So maybe we can use 8 pointed star as our symbol, unless someone comes in and ruins symetry.

Image of the 8 pointed star is taken from Flickr, photo by Francisco Caboblanco