More than a language

Nearly 300 high-level programming languages have been developed during the last decade.

One can only nod when reading this quote: indeed there's hardly a month without a new language being announced. The fun part is that it's the opening sentence of "A Guide to PL/I", printed in 1969! Clearly the programming community has always been prolific when it comes to spawning languages.

And this trend makes sense: the tension between the need for general programming languages, which can deal with any type of problems, and the desire for specific programming languages, which best accommodate particular issues, is prone to give birth to a wide range of diverse languages.

As a programmer, you therefore have plenty of choice when it comes to picking up a language for your shiny new project. Beyond the intrinsic qualities of the language, I posit that there's more to consider when deciding. Here are a few points that come to mind:

• Platform - What is the runtime environment that this languages runs on? Is it mature? Is it easy to install and upgrade? Can it be well monitored in production? Does it use system resources efficiently?
• Ecosystem - Is there a large body of libraries available? Are these libraries mature? Does the community have a tradition for rolling out breaking changes in libraries?
• Tooling - Are there any tools for crafting code with this language? Any auto-formatters so SCM conflicts are minimal? Any static analysis tools? Any dynamic analysis tools?

I haven't included the "availability of developers" criteria because I think it's a red herring. Indeed, I'm convinced any programmer worth hiring should be able to pick up a new language very quickly.

So if your project can accommodate risk and potential yak shaving, you can disregard these points and select a language only for itself. But for those building systems that should last and evolve gracefully, these extra criteria should be considered as much as the qualities of the language itself.

Are there any other aspects you typically consider when opting for a particular language that you'd like to share?

Meet jerg, a JSON Schema to Erlang Records Generator

I'm happy to announce the very first release of my latest Erlang open source project, jerg, a JSON Schema to Erlang Records Generator.

The objective of this project is to be a build tool that parses a rich domain model defined in JSON Schema (as specified in the IETF Internet Draft) in order to generate record definitions that can be used to Erlang applications to both read and write JSON.

I believe that having a formally defined object model for the data that's exchange over web resources is a major plus for APIs. It doesn't necessary imply that consumers have to generate static clients based on such a definition, but as far as the server is concerned, it raises the bar in term of consistency and opens the door for self-generated documentation.

jerg doesn't deal with the actual mapping between JSON and records: there is already a library named json_rec for that. It doesn't also deal with validation as, again, a library named jesse can take care of it.

This first version of jerg generates records with the appropriate type specification to enable type checking with dialyzer. It supports:

• cross-references for properties and collection items (ie the $ref property),
• default values,
• integer enumerations (other types can not be enumerated per limitation of the Erlang type specification).

It also supports a few extensions to JSON schema:

• extends: to allow a schema to extend another one in order to inherit all the properties of its parent (and any ancestors above it),
• abstract: to mark schemas that actually do not need to be output as records because they are just used through references and extension,
• recordName: to customize the name of the record generated from the concerned schema definition.

jerg has a few limitations, like its lack of support for embedded object schemas: pull-requests are more than welcome!

Enough talking: time to get started! Your next stop is jerg's GitHub project. Enjoy!

CRaSH for Mule, an introduction

This blog is the formal introduction to the CRaSH console for Mule on which I've been working for the past month or so. I've decided to interview myself about it because, hey, if I don't do it, who will?

What is CRaSH for Mule?

It is a shell that is running embedded in Mule and that gives command-line access to a variety of Mule internal moving parts. It's built thanks to the excellent CRaSH project, a toolkit built by Julien Viet and sponsored by eXo Platform, which allows the easy creation of embedded shells.

What can we do with it?

Well, it's easy to find it out. Let's connect to CRaSH for Mule and ask for help:



As you can see the range of actions include gathering information, like statistics and names, but also performing actions, like restarting a connector or even stopping the broker.

Why is it better than JMX?

Behind the scene CRaSH for Mule relies on JMX so anything you can do with it could be done with direct JMX interactions (like with JConsole or jmxterm). This said CRaSH for Mule has many advantages over raw JMX, including:

• Adds Mule semantics to JMX. You do not need to fiddle with lengthy object names do achieve what you want: CRaSH for Mule builds the right object names based on your actions.
• Provides auto-completion, this for application names and commands.
• Supports connectivity over telnet and ssh. No need for baroque JMX RMI connection strings.
• All the other CRaSH commands are available. The default set of commands is very rich: to name a few, it comes complete with commands for dealing with the system, the JVM, JDBC and JNDI.

How does it compare to MMC?

Well, it doesn't! The Mule Management Console is way more capable and feature-laden, and comes bundled with the Enterprise Edition of Mule.

CRaSH for Mule focuses on admin-oriented command-line friendly interactions with Mule. And it is fully open sourced.

How do I install it?

Navigate to CRaSH's homepage and locate the Mule distribution download link. You'll get an archive that contains different files, including crash-mule-app.zip that you need to drop in your Mule broker apps directory. This application contains a readme file that explains how to configure it, should the default configuration not satisfy you. You can also read it online.

CRaSH for Mule 1.2.0-cr6-SNAPSHOT has been tested on Mule CE 3.3.1 and EE 3.3.1.

Got into trouble?

Report issues or open feature requests directly to CRaSH's JIRA.