Slashdot Mirror
Introducing The Heron Programming Language
Christopher Diggins writes "The Heron programming language, is a new general-purpose multi-paradigm programming language in the style of C++ which is starting to make waves. The popular Polish software development magazine Software 2.0 is featuring an article on Heron, in its first English version of the magazine slated to appear in February 2005. A preview of the Heron article is available."
Yet another statically typed language?
A statically typed language provides a little bit of value: The compiler does a small bit of the testing you should be doing anyhow. In return, static typing extract a huge cost in language complexity (templates, anyone?). Many of the patterns in the GOF book are only there to let you get the job done when the type checking system is trying to stop you.
This language may appeal to those who don't like C++ but think that the particulars of the language is the problem. It's not the particulars that are the problem. It's the static typing, the separate compile step, and all the complexity that supports these basic language decisions.
Heron seems to be aiming at the same market as the D programming language, but IMHO Heron is too much C++-like with all its ugliness.
:)
D is a lot more like Java/C#, but compiled to native code and is low-level enough for it to be used for things like where only C and C++ are feasable now (low-level libraries, toolkits, even kernel drivers).. And besides, there is already a (beta) D Frontend for GCC.
With all the positive attention that D has had recently I find it unlikely that Heron will be chosen over D by anyone, but only time will tell... And the competition is good for both languages.
My other account has a 3-digit UID.
The wikipedia article on heron was almost deleted. Many wikipedians apparently felt that the language (which only had one user) was not important enough to be "encyclopedic." The vote ended up being against deletion. There's a discussion of it on the article's talk page.
Find free books.
They arise from logic, which is the basis of functional programming (some might also say category theory, but they arise there, too. ;)) They are very simple and useful for regular everyday programs, and it's odd that they don't exist ALL in mainstream languages.
... e1 ... ... e2 ...
Product comes from the logical proposition "A and B". It consists of a value of type A, and a value of type B together, ie, a pair. Languages often call the elements of product types "tuples," and usually they are generalized to length-n tuples. This is really convenient when you just want a function to return two or more values.
Sums are more conspicuously missing from popular languages, even though they are a direct dualization of products. They come from the proposition "A or B", so a value of type "A + B" is *either* a value of type A, *or* a value of type B. This is very useful as well. To construct a value of sum type, you say whether you have an A or B:
if x has type A
Left x has type A + (anything)
Right x has type (anything) + A
and if y has type A + B
then
case y of
Left l =>
| Right r =>
Within e1, we know that l has type A, and within e2, we know that r has type B (although only one branch will be run). This is superior to "if (y.tag == T_LEFT)" because there we don't automatically learn anything about the type of the body of y (supposing it is a C union, or something). Well, C and C++ and Java don't have very good type systems...
Of course you can do these things with classes in an OO language, but in general having to use a heavyweight item to do a simple thing is just a pain. (Especially sums -- it seems the standard way to do this is by a series of 'instanceof' tests followed by casts, ugh.)