Programming Language Frustration

I've been writing a lot of Opa recently - for those of you who don't know, Opa is a framework for writing web software without the hassle of worrying about database connections, distribution of code between front and back-end systems, asynchronous vs synchronous calls etc. It also cleverly integrates code, HTML and CSS holistically into the language. It is basically a mix of cool functional programming ideas with Javascript and a compiler that generates Javascript to run on Node.js; along with MongoDB (and soon Postgres) integration.

What Opa is brilliant at is abstracting away from all the awkward stuff that web (and thus distributed and network) programming. To make life simpler and programs more robust it is also strongly typed but does support polymorphism, variant (or sum) records etc. It can be a bit of a pain when settling down on your data schemata BUT you should be thinking hard about this stuff anyway. For you agile people go read about technical debt, for the privacy people who also worry about data, go read about the slow data movement.

It has its fair share issues too; some features are missing, eg: monads, but that's curable, but the main problem with Opa, and this is shared amongst many cool things in the software engineering community, and that is documentation.

Opa has a book and basic tutorials, a twitter feed, API documentation and forums (locally and StackExchange), plus you can actually get hold of the guys developing Opa. All very good but the experts on Opa are the people who developed Opa and not the people developing in Opa.

Opa's programming community is very, very small and this seriously holds back the acceptance of use of the language.

In Pirsig's book Zen and the Art of Motorcycle Maintenance, Pirsig talks about the quality of components - specifically how threading the head of a screw can render the greatest motorbike useless. The quality of the whole is dependent upon even the smallest, singular part.

And so it is sometimes with Opa: the lack of a specific example, a relevant explanation for a particular function in a library, how to compose specific kinds of database query etc, can bring a project to a screeching halt with no way forward. Getting past this is critical to any larger scale acceptance and use of the framework/language.

For Opa to succeed it needs better integration between the Opa developers and the developers of Opa. It needs a constant stream of questions, bad code, good code, homemade tutorials etc to develop that external body of knowledge, a set of patterns, case studies from industrial environments, cool solutions to common problems, etc.

I'm constantly amazed at how quickly I can get things done with Opa (apart from CSS which really is the language of evil and frustration) and would recommend it to anyone who needs to develop quick web applications. But to those who do use it, please give something back to the community in expressing what went right and what went wrong, patterns for common problems (eg: OAuth, social network integration, database usage etc)

OK, enough venting of frustration...back to honest coding now...pity that so little time is spent with Opa, most of it seems to be fiddling with the user interface (html and css)...sigh :-)

Links

• Opa Tutorial pt1, pt2, pt3, pt4 (+ intermission)