Another new language, written specifically for .NET and Mono? Many existing languages, such as Fortran and Cobol, have been ported to .NET, and Microsoft has contributed IronPython, IronRuby and Small Basic, but it is a rare event, so soon after F#, to see the introduction of another new general-purpose language; one  that is of production quality. It is the vision and work of just one independent person over nearly a decade, with help from a small but active community of enthusiastic users. Chuck Esterbrook’s Cobra language has taken the best features from many languages including Python, Objective-C, Eiffel and C#.

“Most of all, one
should be constantly
asking the questions:
How can I write better code?
How can I be more productive?”

Esterbrook, who is not as widely known as perhaps he should be, has Cobra down as his second major compiler in additional to several prototypes. He created Webware for Python, an open source suite of web frameworks and has designed object-relational mappers (ORM) including an open source ORM for Python called MiddleKit and a .NET one, originally created before NHibernate and others were available and mature.

Chuck works as a consultant for application and A.I and anything from algorithms, parsers, business rules, UI, etc. working with object-oriented languages and SQL databases. He lives in California.

RM:

Chuck, how did Cobra come into existence? Was there a particular problem you were trying to solve?

CE:

I was bouncing between various languages depending on their strengths and a given project. On the surface, that sounds alright, but in reality it was silly because many of the strengths of these languages are not mutually exclusive. For example, having clean syntax does not require poor performance. Having static types does not exclude dynamic message passing. And so on.

The last straw for me was a financial analysis program originally written in Python. The coding was very fast, but I had to wait over twenty minutes to get the results. This made the cycle of ‘think-code-run’ very slow. Next I tried C#. Using the same classes, methods and algorithms, execution time dropped to twenty seconds, although coding time increased substantially.

Some of the more interesting projects actually require good performance from the start. Examples include simulation, bio-informatics, games, financial analysis, artificial intelligence and some business applications. Sometimes you’re lucky and you can offload the performance issue to a library, or write your code a little smarter in order to get the performance you need. But that’s not always the case, and getting kicked out of Python (or Ruby or Smalltalk) over performance is a sour experience.

The C-based languages offer sufficient performance for a much wider range of applications, but just because I want my programs to execute reasonably fast doesn’t mean that I don’t want to code like the wind.

Along the way, I also became interested in the quality problems that plague applications. Programs are just too buggy. Consequently, Cobra offers first class support for unit tests, contracts, ‘informative’ asserts and compile-time nil/null tracking. I now consider these features an essential part of Cobra.

RM:

Has there been anything that you’ve found difficult to work into the model?

CE:

Generics (or something similar) is a feature that I consider essential for any language that offers static typing, but implementing them was very challenging. On the surface, they don’t look nearly as bad as they end up being implemented. They yield interesting cases because they combine with many other features of the language (inheritance, methods, initial values etc.

Compile-time nil/null tracking was also demanding. Cobra does this across all types, but Cobra’s first target, or ‘back-end’, .NET only does it for value types. This results in impedance between the language and the virtual machine which is always a source of fun for compiler writers.

RM:

What languages influenced the design?

CE:

The four languages that primarily influence Cobra are Python, C#, Eiffel and Objective-C. With the exception of Eiffel, I have deep experience with these languages which informed my design decisions when creating Cobra.

Python confirmed my suspicion that curly braces, semicolons and parenthesis were wasting my time and cluttering my code. Cobra takes many ideas from Python including clean syntax, collection literals and ‘no hassle’ local variables. Python was influenced by SETL by way of ABC, and Cobra takes this a bit further by offering set literals.

C# is the flagship language for .NET which was the first back-end for Cobra. Its use of static types and generics with fast method dispatch make it feasible for applications where Python and Ruby are too slow. By incorporating high level features such as garbage collection and generators, C# shows that fast execution doesn’t require the developer to use a low level language.

Eiffel was a pleasant discovery while researching languages. I think contracts can be powerful on their own and also complementary to unit tests. Both are built into Cobra.

Objective-C is the first language I know of to provide both static and dynamic typing. I enjoyed the benefits of this capability throughout the 1990’s as a NeXTstep developer.

RM:

And where did you get the functional aspect?

CE:

Both Python and C# offer functional features including lambda expressions, closures, list comprehensions and generators. Cobra offers all four features because I have found them to increase code succinctness. By its very nature, succinct code is faster to read, write and debug. In other words, functional features increase expressiveness.

RM:

Where do you envisage Cobra’s future lying? What would you like to see happen to it?

CE:

Cobra is open source under the MIT license so of course I would like to see a larger community for the benefits that brings. I would like to see even more contributions in areas that are complementary to my core work on the language and compiler; specifically IDE integration and back-ends. Speaking of back-ends, Cobra runs on .NET and Mono with a partially finished JVM back-end. I could use some help there!

RM:

Do you think that openness is beneficial to innovation?

CE:

Certainly. It empowers people to create patches at any point in time to enhance the product. Those enhancements could be direct innovations or even features than enable further innovations by adding a new form of extensibility. There is also the option of forking the project if needed.

RM:

How does Cobra compare to say C++ or Perl? What makes it a better choice?

CE:

My experience with C++ was that it was complicated in the wrong ways. Having learned languages like Objective-C and Smalltalk at approximately the same time, I was not impressed with the productivity level of C++. And while I don’t want my software to run as slow as say, Python or Ruby, I am willing to spend some CPU cycles to save developer cycles.

I realize that C++ was created with certain goals in mind, but my own goal is maximum productivity across a variety of applications. Several languages surpass C++ in that way, including Cobra.

The overall weakness I perceive in many languages is a lopsided design that emphasizes one or two aspects of a language to the extreme detriment of others. For example, Perl emphasizes writeability over everything else.

I feel Cobra has a strong balance between concerns such as readability, writeability, performance and quality.

RM:

What stage is the language at now?

CE:

I describe it as late beta. Cobra already has an extensive feature set, so recent work has centered around refinements and fixes. Any changes to syntax and semantics were emphasized early on, so after four years, the language design is quite stable.

We still find nooks and crannies that need to be clarified and fixed. Like many good open source projects, Cobra is hovering in the 0.8 – 0.9 neighborhood of version numbers while this process continues.

RM:

I’d like to ask you a couple of general questions about programming. How much time do you spend thinking before you code, what are your thoughts in that time?

CE:

The time I spend thinking before coding is inversely proportional to how familiar I am with solving that kind of problem or writing that kind of code. I’ve been writing code for twenty-eight years now and after awhile you develop a feel for when you’re ready to proceed or not.

The specific thoughts vary immensely according to what is going to be done, but some concerns are fairly uniform. Will it work? Will it be maintainable? Is there a tighter solution? Am I solving the correct problem? Should I be solving a larger problem? Or perhaps a smaller one? What will be the ripple effects of these changes?

RM:

Is there anything you’ve done specifically to improve your skill as a programmer?

CE:

There are many things I have done and that anyone can do. These include studying other codebases, reading books, reading blogs, participating in discussion groups, contributing to open source projects, starting open source projects, learning from colleagues at work, earning a degree in computer science and more.

Doing all of these at once is not always feasible, so alternating between them becomes important as they each have pros and cons. Most of all, one should be constantly asking the questions: How can I write better code? How can I be more productive?

RM:

Do you think education is the answer to developing better software and that somehow we will get away from the ‘we must do it first and ship it now no matter how buggy it is’ way of thinking?

CE:

For willing individuals, I think education is great, especially when it’s on-going and mixed with practice. But I think you’re referring to the general landscape and in that sense, I’m sceptical. I’m all for better education but not everyone embraces that, and not every company has a management team that values quality as much as consumers wish they would.

I think the road to better software is multifaceted and includes language features, education, better environments and better project management. I’m also enthusiastic about deeper and more automated code analysis like what we see in Pex and Spec#.

RM:

Several of the people I’ve interviewed recently have recommended learning various programming languages because it has given them a different perspective on how to solve a problem? Have you done the same and would you recommend it to others?

CE:

There are additional reasons for learning multiple programming languages. The strongest, in my opinion, is that you may discover a new language that is fundamentally more productive and/or enjoyable than what you’re currently using. In 1999, when the NeXTstep market was drying up, I switched to Java. Quite frankly, moving from Objective-C to 1999’s Java was depressing. Fortunately, I discovered Python which put new energy into my projects.

From a more theoretical view, if you have an interest in “computing” or “computer science” then you should be naturally curious as to what else is out there. Without a varied background, you will almost certainly be “in the dark”. (Since there is always more to learn, we’re all “in the dark” to some degree.)

And yes, learning other languages will teach you things. The first object-oriented language I used was Turbo Pascal 5.5. The second was C++. The third was Smalltalk. But Smalltalk was the first where things clicked and I ‘got it’

RM:

Picking up on this thread, do you think Smalltalk and Scheme for example are under-appreciated and that in lots of ways they are significantly in advance of some of the technology we’re using now? Is there an argument for saying let’s throw out everything we’re working on now and go back to Smalltalk and Scheme or do we try to factor in as many as these ideas as possible into modern languages?

CE:

Excellent questions. I appreciate these pure, elegant languages like Smalltalk and Scheme. There is something special about their idealistic approach that is instructive. It’s like learning the principles of languages.

On the other hand, I got along better with Objective-C than Smalltalk due to practical issues like performance and executable creation. And when I needed something more productive than Java, people were talking about Python and “batteries included”, instead of Scheme. So for developing applications, the so-called “practical” languages have served me best. Not everyone agrees, of course. Smalltalkers are still out there and people are still scheming.

Regarding what is more “advanced”, that is not so clear. Maybe Smalltalk is more advanced than C# because its design is relatively simple while still providing great power. Or maybe C# is more advanced because it outperforms Smalltalk while providing some of the same conveniences such as garbage collection and closures. Maybe Eiffel is more advanced than either of them because it offers boolean-based contracts and they don’t. Or maybe it’s less advanced because the last time I tried it, I couldn’t understand half the error messages it gave me.

So ranking languages can be difficult because there are multiple issues to consider not to mention that requirements vary between developers and projects. Of course, we tend to form opinions anyway which can lead to interesting discussions and debates on those issues.

Regarding ideas, I think cross pollination is essential to pushing computing forward. And note that there has been at least one variant of Smalltalk that incorporates static typing. So the flow is not just in one direction.

Yes, let’s incorporate great ideas back and forth. Cobra stands on the shoulders of giants and wouldn’t be such a great language if it didn’t.

RM:

Are there other skills that are not directly related to programming that you feel have improved your programming or that are valuable to have as a programmer?

CE:

Perhaps it’s informative that the worst developers I have ever met were insular. They didn’t read about their craft (whether through books, articles, groups or blogs), and when asked ‘Why?’ responded with either ‘I don’t care about that stuff.” or “I’m smart so I can just figure it out myself.’

So let’s go with persistent learning and improvement as the most valuable attribute. In the book ‘Talent Is Overrated’, Geoff Colvin makes a strong case that top experts in a variety of fields are neither endowed with high IQs nor genetically gifted. Instead, top performers intently improve their performance over a number of years, thereby accumulating skill.

That requires a great investment of time of energy, so pick something you love!