Summary
The catch-22 of developing a programming language is that the onus is on the designer to promote the language unless they have some kind of corporate backing. This means that often you have to implement most of the functionality
before people see the value in helping you create an implementation.

Advertisement

Most of my activity with regards to Heron lately is focused on trying to explain the language, and demonstrate its value to as many people
as possible. This endeavour is one that I do not particularly enjoy.
At heart I am a programmer, not a businessman, and I would much rather be writing code in Heron.

The catch-22 of developing a programming language is that the onus is on the designer to promote the language unless they have some kind of corporate backing. This means that often you have to implement most of the functionality before people see the value in helping you create an implementation. I have done quite a lot of work on the Heron2C compiler but it is still not complete and probably won't be for quite some time. I made a very regrettable decision early on to implement the compiler by hand and using Delphi, so getting help on Heron2C is out of the question. My only hope for making the language popular is probably writing a Heron compiler in Heron, which I am currently doing but progress is slow.

Without a full implementation of a language, any claims about the language are viewed with great suspicion. There are several claims that I would like to be making publicly about Heron with regards to languages such as C++ Java and C#:

Heron implementations are easily more efficient

Heron has more advanced support for metaprogramming support

Heron scales better or at least as good to large scale software

Heron is more flexibile

Heron has more encompassing support for modern software techniques, such as AOP, OOP, and Generic programming

Heron promotes and enforces better software development practices

Heron is as easy to learn as Java

My dilemma is that these facts -- and yes, I do believe they are facts -- are not obvious to most people by simply reading through the language specification. The other problem is that proving these facts to people, is challenging because every individual has their own preconceptions.

What I am currently hoping for is that at least some people will recognize the significance of Heron from the specification
alone, or the work that has been invested so far on Heron2C, and will
start work independantly on creating an implementation of the language.

If someone is interested in implementing Heron, by all means please do, you will have my full and enthusiastic support, even if they modify the language. Heron is in the public domain, which means that people are free to implement it how they see fit. If anyone is sitting on the fence with regards to Heron, I would really like to know what it would take to prepare a more convincing argument for the language.

You say: Without a full implementation of a language, any claims about the language are viewed with great suspicion.

That's right. That's how it should be, they simply are suspicious until they have been tested in practice. Your claimed advantages of Heron are not facts, and only time will tell whether they will become facts or not. Especially vague qualifications like "productivity boost", "runtime efficiency boost", "scalability improvement" etc. It's too easy to give such claims if they can't be verified at all, even informally.

Ideas that look great in the mind of their author can meet unexpected difficulties when confronted with the reality and actually trying to be implemented. Half of them is considered naive by the same author a few years later.

It's not the fault of the world that it does not take your claims about Heron for granted, nor infer them itself. Programming language authors are always suspicious, because they are too many ideas about programming which turn out to be not as good as their authors hoped theoretically.

That's why I'm not marketing Kogut yet, but working on it.Since the last release, during the last two months, I implemented threads, a generalization of Unix signals, time calculation including computation on Gregorian calendar dates, dynamically scoped variables, weak references, dynamic linking (not as good as it should be), various optimizations in the generated code, and lots of small details.

Still lot of things needs to be done to consider the language mature: networking, macros, having an interpreter (both available in programs and as an interactive language shell), loading code at runtime, interoperation with more languages, database access, serialization, regexps, interfaces to more libraries (e.g. Unix API, cryptography), and again lots of details here and there (e.g. better conversion between numbers and strings).

I'm not complaining that the world has underestimated its value and is not enthusiastic about it. A potential value doesn't count as much as present value; actually this fraction is tiny in case of authors who haven't already delivered tons of widely known products. I'm not claiming what Kogut is in cases where it only hopefully will, or more appropriately would, or maybe not at all - only time will tell.

Only time will reveal flaws in language design; they were not planned. Only time will validate the skill of the language implementor. Other people should be suspicious.

"Ideas that look great in the mind of their author can meet unexpected difficulties when confronted with the reality and actually trying to be implemented. Half of them is considered naive by the same author a few years later."

That is true at the beginning of the language design process, but I didn't start working on Heron yesterday. Heron has been under development for several years, and its first ideas started 10 years ago. A lot of Heron is also already implemented, and tested.

"Programming language authors are always suspicious, because they are too many ideas about programming which turn out to be not as good as their authors hoped theoretically."

I should point out I am not some naive coder who just doesn't understand computing or its history. I have been working as a software developer for ten years, and programming for a lot longer, I am also a published writer with articles in Doctor Dobbs Journal and C++ Users Journal.

I think the real problem lies in the fact that people don't exert enough mental effort to try and consider the implications of language specifications, nor do they give the benefit of doubt to new ideas. As an example, you are here telling me vague generalizations about programming language designers, which is much easier than actually relating your points to me or the Heron specification itself.

"Your claimed advantages of Heron are not facts, and only time will tell whether they will become facts or not."

This is false reasoning. The world was round. A fact doesn't depend on verification to become a fact.

> This is false reasoning. The world was round. A fact> doesn't depend on verification to become a fact.

But the fact is verifiable/demonstrable.

The proof is in the pudding. And with respect to general purpose programming languages, that proof means many different (kinds of) programmers making a lot of different (kinds of) pudding and eating it.

I made a typo previously, I meant "The world was round [even before anyone verified it]."

Yes I agree with John, what I claim as facts are most indeed unverified, and proving their truth/fallacy will definitely require a lot of pudding eating (several years worth). At least I am participating by eating my own pudding and enjoying the taste. :-)

> I think the real problem lies in the fact that people> don't exert enough mental effort to try and consider the> implications of language specifications, nor do they give> the benefit of doubt to new ideas. As an example, you are> here telling me vague generalizations about programming> language designers, which is much easier than actually> relating your points to me or the Heron specification> itself.

It's as hard for me to convince you that particular implications hold, as for you to convince me that the language has advantages of the "vague" kind. Neither of this can be proven mathematically, and we disagree in beliefs whether they will hold or not. They can at most be verified empirically, and even then it's very hard to measure.

For example I'm telling you since a long time ago that lack of garbage collection is a bad idea. You disagree. How can any of us prove his point?

Programmer productivity in using a language depends on its libraries and implementations available, probably more than on core language features (as long as the core language doesn't get in the way). It's of course the more boring part of designing a language, but it's a part without which the language is useless except as a theoretical exercise. For example Java, considering its core language, is a crap, but it has lots of portable libraries and good company support, and that's why it's practical to use in multiple areas. It also has some rare advantages: it's possible to safely execute an untrusted Java applet. Your specification doesn't address libraries at all. How could I know what taste they will have, and how to imagine their implications?

Advantages of a language include quality of implementations for various platforms, quality of error detection (e.g. is there a stack trace when the program terminates with an unhandled exception? how accurate are compiler error messages in practice, i.e. how often they point the actual cause of the error?), availability of profilers and debuggers, availability of an IDE (or Emacs mode), of tools to package and ship libraries, how often the language changes in an incompatible way, how often its implementation breaks binary compatibility of compiled libraries etc. All these things can't be deduced from language specification, while they can be somehow deduced from a working implementation. The stability of the language can only be deduced across a long period of time.

Let's imagine that I would like to know whether Heron was a good choice for an application which requires to send objects over a network, store them in a database, and load separately compiled plugins. How can I know how easy or hard will be to serialize Heron objects to streams of bytes, or to database records? What about dynamic code loading? What about threads? What about making a GUI in Heron? Specification doesn't talk about this. And even if it did, it would not tell how well the implementation of threads will scale (will it be practical to create one thread per service, or they will be too heavy and will require multiplexing services in a single thread?).

Please don't complain that the world doesn't see advantages which don't exist yet :-)

> Most of my activity with regards to Heron lately is> focused on trying to explain the language, and demonstrate> its value to as many people> as possible. This endeavour is one that I do not> particularly enjoy.> At heart I am a programmer, not a businessman, and I would> much rather be writing code in Heron.

I enjoy language design too. Tell you what, though. When I saw your announcement I was looking for two things:

1) What makes Heron different?2) What problem does it solve?

For (1) it seems that the metaprogramming features fit the bill. (2) didn't really snag me because you were talking about general reliability and programming in the large issues and I didn't see a connection back to your feature set.

Unfortunately, part of putting a language out there is selling it to some degree and it doesn't have to be hard but it comes back to those two questions. I'd love to see a tutorial about the metaprogramming features for instance. More examples. More "why I decided to write a language" discussion.

"Programmer productivity in using a language depends on its libraries and implementations available, probably more than on core language features"

Clearly what kinds of libraries can be writtten, and with what ease depends on the language core features. A language designer should make it easy to write libraries. Which is exactly where the focus has been on Heron.

"For example Java, considering its core language, is a crap,"

But it is easy to write libraries in Java, hence the proliferation of libraries for it.

"Your specification doesn't address libraries at all. How could I know what taste they will have, and how to imagine their implications?"

Heron strives to make it as easy to implement libraries as Java, but with a level of sophistication, ease of use and efficiency that surpasses large well-known libraries in C++ such as STL, Boost etc.

"(2) didn't really snag me because you were talking about general reliability and programming in the large issues and I didn't see a connection back to your feature set."

I see that I could make a better case in that regards.

"Unfortunately, part of putting a language out there is selling it to some degree and it doesn't have to be hard but it comes back to those two questions. I'd love to see a tutorial about the metaprogramming features for instance. More examples. More "why I decided to write a language" discussion."

"Why I decided to write a language" is an excellent topic for my next blog post, I will try to get to it later today. Concerning the facility with selling a language, I hope you are right. Concerning the metaprogramming I do have a tutorial hidden online, which is perhaps a bit dated at http://www.heron-language.com/metaprogramming.html

I would be curious to hear more about your particular interest w.r.t language design, perhaps you would care to email me about it? cdiggins@videotron.ca

You quit your day job so you could work on a programming language that you've placed in the public domain? Now that's conviction!

Just to give you my personal reaction the first time I saw Heron on the front page of Artima, my first thought was "Gee, it's Java with a couple of new features and a couple of features implemented differently." It was these paragraph that I skimmed:

Heron is a new open-specification, multi-paradigm, multi-purpose imperative programming language being developed by Christopher Diggins who also maintains a weblog at www.Artima.com.

Heron resembles many recent programming languages such as Java and C#, as it is also inspired significantly by C++. Heron is intended primarily as a very efficient, high-level compiled language for building large scale libraries for widest possible range of applications.

The first paragraph--"multi-paradigm, multi-purpose"--is pretty much exactly how Stroustrup describes C++. The second paragraph doesn't say Heron is any different than Java/C#/C++; that second sentence could describe any of those languages, for some reasonable values of "efficient", "high-level", "compiled", "large scale", and "widest posible range".

In other words, these two paragraphs say to me, "Heron is a new language that is a lot like three languages you already know." That's all it took for me, on this particular day, to pick up and move on.

(I did skim the features list, but there wasn't anything there that piqued my interest.)

Also, I don't think it's realistic to expect busy and jaded developers to be willing to read a language specification, much less glean from it what makes Heron so good. I bet most programmers coming to your site will be thinking, "So what does Heron do that my language doesn't?" and your reponse is essentially "Here, read some really boring BNF!"

I think your latest weblog post is a definite step in the right direction, though. More articles like that post, especially with code examples, would be great.

lol! Yes I agree bnf is very boring and makes it difficult to reason about the language. It is a neccessary evil at this point. I am now introducing new articles on Heron which are more interesting and in-depth. For instance the latest, which emphasize Heron's differences is about Heron primitives at http://www.heron-language.com/primitives.html.