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."

Comments

Language link

[Matchstick]

Of course, the first thing I search for in the article is a link that describe the language itself. What a thing to leave out!

Re:Language link

[Anonymous Coward]

The link is in the Summary, at the end of the article.

Re:Language link

[ssimontis]

I think that they should put forth some very persuasive reasons why you should learn this language. Using as many buzzwords as you can is not the way to do this. It can be a pain learning new programming languages, especially useless ones.

Re:C++ has a style?

[Anonymous Coward]

elegant and simple C++ is not. Perhaps it is an ugly and error-prone derivate of an ugly error-prone language. Joy!

There is a time for all things under the heavens

[Crimsane]

I can't say i've ever seen or heard of it, but i for one welcome a new language to learn and play with.

The gaps between C/C++/[c#|java] are pretty hefty, perhaps this will be a good language to know when you want something inbetween.

Re:C++ has a style?

[cdiggins]

I meant in the sense that Heron bears many syntactic similarities to C++ ( like Java, C# and D ) as well as is statically typed, general-purpose and multi-paradigm.

more from cdiggins

[Anonymous Coward]

Courtesy of Lambda the Ultimate.

The author of this language seems a bit clueless.

Re:OT, feel free to mod down ;P

[Anonymous Coward]

yeah I get that a lot too. I always thought that it might be the admins taking the service down for updates or something...

I think I'm not the only one

[RAMMS EIN]

I think I'm not the only one who misread that as "Introducing The Heroin Programming Language".

Re:I think I'm not the only one

[DesScorp]

You're not the only one...at least we know what the C stands for in C/C++...that would be the Crack programming language I suppose...

Re:I think I'm not the only one

[Anonymous Coward]

CPL->BCPL->B->C->C++

That's Computer Programming Language -> Basic Computer Programming Language -> Basic (not BASIC) -> Computer -> Take C, Increment It, Then Use the Old Value.

D'oh!

Re:I think I'm not the only one

[WaterBreath]

Hmmm... Freudian slip?

Re:I think I'm not the only one

[shadow303]

I personally read it as the Herring Programming Language. I guess I have been hearing too much about Python and Parrot lately.

Re:C++ has a style?

[Anonymous Coward]

"which is starting to make waves"

Icebergs make waves. This does not mean we need icebergs.

Willful Ignorance

[Anonymous Coward]

Diggins makes absurd statements like:

• "As a programmer for over 20 years, I have never been concerned with what a 'type system' is."
  
• "Every programming language I am familiar with has the same basic concept: values and expressions may or may not have a type."
  
• "The concept of "term" is irrelevant to the implementation, design and use of programming languages."

See Lambda The Ultimate.

I'm not sure how Heron is going to emerge from the mess of C++ish languages that includes Java (and variants like HyperJ and AspectJ), C#, the also new (but much more active) Scala, the well-grounded Nice, and the nearly complete Aldor.

And there's no way I'm downloading and installing Kylix just to try it out.

Re:Willful Ignorance

[mattgreen]

Argh, why does every new language have to compile to Java? Some of us haven't bought into the 'bytecode as the savior of the modern world' ideology quite yet. I want to be able to develop desktop applications quickly, and without relying on massive runtime libraries.

Specifically, I'm looking for a language that is:
* expressive - moreso than C#
* multiple paradigm - supporting features like closures and first class functions
* supports generic programming - this is too useful to leave out. I don't mean crippled generics (ala Java) either.
* encourages good practices, but does not forbid dangerous ones outright
* compiles to native code or bytecode
* imposes minimal runtime overhead - in terms of RAM usage and CPU time

The closest fit to all of these is C++, but I'll be the first to admit that C++ is a trainwreck of syntax.

Re:Willful Ignorance

[Jerf]

You're looking for Python and Ruby. Both are so easy to learn that the correct answer to which one is "both"; try the tutorials for both and you'll probably know pretty quickly. The thing to look for is which philosophy suits you better.

The only thing out of that list you might think is missing is "generic programming", but in general that's because both languages support it so naturally that it isn't even a seperate paradigm. I know Python has libraries for people who insist on the trappings of generic languages, or who really, really need completely seperate functions for the various combinations of args, but I don't know much about them because while I've looked at such things, I've never encountered a situation where the "correct" answer wasn't a slighty more careful API, YMMV.

Unless you're doing intensive numerical calculations that can not be expressed in terms of the various libraries for numerical calculation, or are really focused on embedded programming, both are plenty fast for normal programming.

(I don't know about Ruby but there is a lot of progress towards optimizing Python being made, although I don't know if we'll ever quite get to compilation to pure native code. See PyPy, for instance, which has recently been funded so it ought to stick around and produce something. I expect that within another couple of years, through one avenue or another, the speed penalties of Python will be gone for all practical purposes.)

Granted, neither of these may currently perfect... but holy cow, are they better than C++. Unbelievably better, for the vast majority of uses.

Re:Willful Ignorance

[cdiggins]

Heron2C compiles to C++, where did I give the impression it compiles to Java? Heron attempts to satisfy all of those goals you list. Check it out at http://www.heron-language.com/

Re:Willful Ignorance

[Anonymous Coward]

first class functions in a static language? This is like having mallable steel trusses? What is this trying to do again? If you want first class functions, you'll want a define-on-the-fly language as well. Python or Ruby. Or Perl6 in 5-10 years :)

Re:Willful Ignorance

[Anonymous Coward]

first class functions in a static language? This is like having mallable steel trusses? What is this trying to do again? If you want first class functions, you'll want a define-on-the-fly language as well.

You, sir, are either trolling or criminally ignorant.

Here is a statically typed, natively compiled language that provides fully first-class functions.

Here is another.

There are many others; those are just the most widely used.

Re:Willful Ignorance

[Anonymous Coward]

The languages-compiling-to-Java the post you're responding to was talking about were the ones his parent mentioned - Nice, Scala, and so on. Not Heron. Though I can see how the misunderstanding arose.

Out of interest, have you considered providing comparisons of Heron with languages other than C++? I'd be interested to see what you think are the advantages it provides over other "C++ done better" projects like D and Felix.

Re:Willful Ignorance

[Anonymous Coward]

Haskell or ML. OCaml is the most popular language that does what you want. They are both closer fits to what you want than C++.

Of course, the syntax of the languages I mention is hated by some even more than that of C++...

Re:Willful Ignorance

[cdiggins]

I know and correspond with Walter Bright on occasion, so I would rather refrain from comparing Heron to D. I dislike making language comparisons in general, and only grudgingly do so with C++ for the sole reason to help orient potential users or evaluators. I am unaware of Felix, and will look into it. Thanks.

Re:Willful Ignorance

[Anonymous Coward]

Speaking of wilful ignorance...

The only thing out of that list you might think is missing is "generic programming", but in general that's because both languages support it so naturally that it isn't even a seperate paradigm.

They are both dynamically typed, so they provide no support whatsoever, they just stay out of your way while you support yourself. They don't actively get in your way like C++ and friends, but nor do they know to poke their noses back in when you've introduced a bug like a modern statically-typed language would.

I guess it's only fair that I try to answer the question, since I've ruled your answer out. Hmmmm. I'm not sure anything fits all of those criteria - there is only the tiniest niche for languages that have the safety features useful for complex programs and the desired low level features - but I'll stick my neck out and suggest Cyclone. The only real caveat I can see is that ad hoc polymorphism is only supported in the bare form of existential types (ETs are effectively the assembly language of OO) but that's still vastly better than C and infinitely safer than C++. To be honest, I'd recommend you just write everything you can in Haskell and then invoke little snippets of C or Cyclone when you need the low level access - fortunately there's a lot of common ground in learning the Cyclone and Haskell type systems.

Sorry, i'll have to pass

[QuantumRiff]

This could be the greatest thing since the invention of the transistor, but putting phrases in like :
new general-purpose multi-paradigm
is going to lead me to believe that it was developed by an Executive, a consultant, or, worst of all, a corporate motivational speaker!

No thanks..

Re:Sorry, i'll have to pass

[Anonymous Coward]

yep.

Re:Sorry, i'll have to pass

[Earlybird]

• putting phrases in like : new general-purpose multi-paradigm is going to lead me to believe that it was developed by an Executive, a consultant, or, worst of all, a corporate motivational speaker!

What's the problem? General-purpose isn't a buzzword, and multi-paradigm is a common way to describe languages that aren't restricted to just one style of programming, such as imperative programming, object-oriented programming, functional programming... just because paradigm is a fancy-pancy word does not mean it's meaningless. Whatever its merits/demerits, clearly Heron is a general-purpose, multi-paradigm language.

Re:Sorry, i'll have to pass

[be-fan]

It's not marketing at all, it's entirely descriptive.

"General purpose" -> it's meant to be used for general applications. Unlike a special-purpose language like Postscript, PHP, etc.

"Multi-paradigm" -> It supports multiple styles of programming (eg: object oriented, meta programming, aspect-oriented programming, procedural, etc). As opposed to "single-paradigm" languages like Java, that stress a single programming style.

I bet you just saw the word "paradigm" and jumped on it...

Thoughts

[RAMMS EIN]

"multi-paradigm" - Ah, like Lisp.

"in the style of C++" - Ouch.

Seriously, multi-paradigm is good. Or rather, single paradigm is bad. No paradigm is ideal for every case, so a language that enforces one paradigm (e.g. Java) will be ill-suited to many situations.

What does "in the style of C++" mean, though? Does it mean Heron is another language with a standard too large to fit in a programmer's head, and a hellish syntax that is difficult to parse for both humans and machines?

Re:Thoughts

[Anonymous Coward]

and a hellish syntax that is difficult to parse for both humans and machines?

As opposed to lisp, which is only hard to parse for humans? (In my mind, it makes more sense to make the syntax easy for humans, at the expense of increased difficulty for machines...)

I'm no fan of C++, but its syntax is pretty low on the list of its problems...

Re:Thoughts

[Carewolf]

Lisp is a functional programming language you can bend (usually in the Scheme form though).

C++ is the only major inherently multiparadigm language. For instance try to make Lisp a hardware-close explicit memory managed language. Any new multiparadigm language is going to borrow a lot from C++, because it is the king.

Re:Thoughts

[Anonymous Coward]

The Common Lisp standard is far bigger than the C++ standard.

Re:Thoughts

[David Greene]

I'm no fan of C++, but its syntax is pretty low on the list of its problems...

Not to start a religious war (but this will, anyway), but I'm curious what you consider to be the problems of C++. I am a big fan of C++ and have my own wishlist of things to fix. I'd like to learn more about what others perceive to be its shortcomings.

Re:Thoughts

[Wolfkin]

Lisp started as a "hardware-close" language. I mean, CAR and CDR were assembly language on the PDP-whatever. :)

In some Common Lisp implementations, you can explicitly manage your own memory if you feel like dealing with the pain; just wrap everything in (without-gcing ...) or whatever the equivalent is for your implementation.

Re:Thoughts

[Anonymous Coward]

Off the top of my head?

template <typename T>
T identity(T a) {
return a;
}

What is the type of identity? It doesn't have one! WTF, mate?

The impossibility of defining functions in expressions or as local / "auto" variables makes me write entirely too much code for simple ideas -- and don't give me that std::for_each crap.

Re:Thoughts

[2short]

"What is the type of identity? It doesn't have one! WTF, mate?"

What's the problem? identity doesn't have a type, nor does it need one, since you haven't used it yet. If you use it (though I can't imagine why), it will have a type.

Are you trying to say the problem with C++ is that you don't understand templates?

Re:Thoughts

[Anonymous Coward]

What's the problem? identity doesn't have a type, nor does it need one, since you haven't used it yet. If you use it (though I can't imagine why), it will have a type.

First, you're wrong: identity itself won't have a type, though we can implictly reference an instantiation of identity.

Second, I don't have to justify why things should be first-class or why (in a strongly typed language), values should have types. If you use your imagination a bit, you could see

template<typename T>
T double(T a) {
return a + a;
}

template<typename U, typename V>
std::pair<U,V> apply_both(U a, V b, /* What type goes here ?*/ f) {
return make_pair(f(a), f(b));
}

apply_both(/* something */, /* some other thing */, double);

Are you trying to say the problem with C++ is that you don't understand templates?

Yes, that's it exactly.

Re:Thoughts

[m50d]

wtf? How is lisp a multi-paradigm language? It's functional programming through and through.

Python is a proper multi-paradigm language. Do OO if you want, do functional if you want, do imperative if you want. Lisp is less multi-paradigm than c++, at least there you have the choice of OO or imperative.

Re:Thoughts

[Christopher Cashell]

Erm. . . no?

Have you ever used Lisp? And do you understand what 'multi-paradigm' means?

C++ was designed as an object oriented extension to C. It does imperative programming well, and object oriented programming fairly well.

Lisp was initially designed as a functional langauge, but modern lisps bear little resemblence to the first lisp beyond superficial appearance. Modern lisps fully support functional programming, imperative programming, object oriented programming, and to some extent, declarative programming. Additionally, while Lisp started as a functional language, and quickly added support for imperative programming, it was also the first language with ANSI standardized object oriented support.

In short, Lisp supports programming with multiple paradigms much better than C++, and even if you take lisp out of the mix, there are a dozen or two other programming langauges that multiple paradigms much better than C++.

As for the bit about 'hardware-close explicit memory managed language'. . . that isn't a pardigm. That's a comment on the language's level of abstraction. For example, both C and BASIC support the same programming *paradigm*, that of an imperative programming langauge. One of them is a low level langauge, the other is a much higher level langauge, but they're both imperative.

Re:Thoughts

[Anonymous Coward]

Bah.

Lisp is definitely multiparadigm. Often mini-languages are implemented in lisp on top of lisp; the language wrapped around the problem not the other way around. E.g. CLOS, the common lisp object system (FYI, the oldest standardized object oriented language), was implemented in lisp on top of lisp. The resulting abstractions tend to be much more complete and integrated with the language.

Please think twice before you make such ignorant statements, especially when you've got an agenda to promote python.

Re:Thoughts

[Anonymous Coward]

But much more of it are the standard libraries, and much less is devoted to bizarre overloading and instantiation issues.

Re:Thoughts

[Carewolf]

As for the bit about 'hardware-close explicit memory managed language'. . . that isn't a pardigm.

You have obviously never programmed kernels..

And while you can implement any semantics in Lisp, the syntax always stays the same; that of a _very_ primitive functional language ((((hi hi hi)))). C++ has the sometimes hated ability to put new sematics to old operators, and thereby completely change the paradigm of the language.

Re:Thoughts

[m50d]

Huh? Lisp is multi-paradigm because you can implement other paradigm languages in lisp? By that logic C must be the most multi-paradigm language in existence.

To program in lisp, you have to do functional programming. Yes, you can wrap something else in it, but if you really want to you can wrap any way of programming in any other - lisp people have some line that any program complex enough will include a lisp interpreter.

As far as having an agenda, I'm not being paid or anything. I enjoy python programming but will happily use C, C++, Java to a certain extent or perl, and I am trying to learn lisp. I chose python as an example because it's the most multi-paradigm language I've used - Java is an OOP straightjacket, functional is hard to do in c or c++, and perl's object support is somewhat lacking.

Re:Thoughts

[Anonymous Coward]

Huh? Lisp is multi-paradigm because you can implement other paradigm languages in lisp? By that logic C must be the most multi-paradigm language in existence.

The point here is that when you implement a mini-language in lisp you still have access to lisp itself. This is a natural way of working with lisp, but fairly unnatural in C and most other languages. For example, when I define a binary tree, I could also define a do-preorder control construct to iterate through the tree in preorder and use it like

(do-preorder (item tree)
(print item))

where (print item) could be any piece of code I want. Forget the indentation.... that's just /.

Common Lisp is not a pure functional programming language. In pure functional languages functions are purely mathematical: the result with the same parameters is always the same (state enters a function only through arguments). You should look up setq and setf. I suggest you read some books, see http://www.cliki.net/.

Re:Thoughts

[Anonymous Coward]

And while you can implement any semantics in Lisp, the syntax always stays the same; that of a _very_ primitive functional language ((((hi hi hi)))). C++ has the sometimes hated ability to put new sematics to old operators, and thereby completely change the paradigm of the language.

I sincerely hope that the latter sentence does not imply that you think this isn't possible in Lisp. Also, changing the syntax in lisp is easy: just change the reader to convert from your preferred syntax to lisp S-expressions. The "primitive" syntax is by choice. Code being data (lists of symbols) gives lisp much of its power. Originally a more readable m-expression syntax was designed, but it never caught on probably due to the aforementioned reason.

Re:Thoughts

[jaoswald]

Look, the reason Lisp has the syntax it does is exactly *because* it allows programs to parse it easily.

That's not so exciting for someone who programs in C/C++/Java, because only one program needs to parse your program, namely, the compiler. (OK, also your IDE to do syntax highlighting and name completion.)

But in Lisp, almost everyone writes programs that depend on parsing and rewriting Lisp programs. Informally, we call these program-writing programs "Lisp macros," but that always gives outsiders the wrong idea. They are basically nothing like #define in C. Templates in C++ are closer, but are infinitely less flexible.

Now, if the template definitions let you write explicit code, using the STL, for instance, which let you fully specify the resulting C++ code from the template expansion, you'd be getting somewhere. But, then, you quickly realize that the syntax of C++ is in fact too complicated, non-uniform, and context-dependent to make that at all easy.

So, from a Lisp programmer's point of view, C++'s syntax ranks pretty much number one on its list of problems.

Keep in mind that Lisp programmers way-back-when deliberately chose to keep the S-expression (i.e., parenthesized prefix notation) syntax around even though the language designer intended the S-expressions for meta-discussions about the language, and M-expressions (more like Fortran/Algol) for the actual programming.

Re:Thoughts

[jaoswald]

Would you care to explain how programming with setf, incf, rotatef is functional programming?

Most functional programming languages make you jump through special hoops to do I/O to avoid side-effects.

Lisp has many of the aspects of functional programming fully and properly supported, such as

- functions as first-class objects (can be assigned, passed, and returned, just like objects of other types)
- apply/funcall/map... to allow function application under program control
- closures allowing functions to be constructed at run time

(It lacks good built-in support for higher level functional operations like currying.)

But it also has things like set, nconc, eval, etc., that allow function calls to destructively modify the environment, i.e., have side-effects. That is completely antithetical to modern functional programming.

Hell, Lisp even has GO, so you can write 1950's spaghetti Fortran if you want.

Re:Thoughts

[jacobm]

1. Syntax at the "what character do we use to mean X, what characters do we use to delimit blocks" level is such a trivial thing that choosing your language based on it is pretty ridiculous. Or, to quote a PL researcher of my acquaintance, "Syntax arguments are lame."
2. The notion that there is such a thing as a "functional programming syntax" doesn't make sense to me. The syntax Church and the original researchers gave the lambda calculus didn't have parentheses except for the same purposes C uses them. Same goes for ML and Haskell, two of the three most well-known functional programming languages around. The third, Scheme, is the most debatable of the three as to whether it's functional or not, and the parentheses are there for reasons that have nothing to do with being a functional language -- they were orgininally there because MacCarthy was going to add them later and they were kept because people by and large liked the advantages of macros and were willing to represent parse trees explicitly so they could have them without contortions.
3. Operator overloading is a far cry from what's possible when it comes to building new language semantics. Syntactic abstraction is where it's at, as the C++ people have learned with template metaprogramming. Unfortunately metaprogramming in C++ is the result of an accident, and for that reason it's really really unpleasant in C++; if they'd been paying attention they either would have made templates like ML's functors (and made the types work out with separate compilation) or made them like Scheme or Common Lisp's macros (and made it a million times easier to make metaprograms that do useful things).

Re:Thoughts

[m50d]

Common Lisp is not a pure functional programming language. In pure functional languages functions are purely mathematical: the result with the same parameters is always the same (state enters a function only through arguments). You should look up setq and setf. I suggest you read some books, see http://www.cliki.net/.

While it may not be "pure functional" it's functional enough that you have to be able to do functional programming to use it. I will agree that implementing sublanguages in lisp is easier than in most languages - but you're still forced to program basically functionally to implement it. Lisp is not useable by people who are unable to do functional programming. IMO this means it isn't really multi-paradigm. I've seen people happily do object oriented stuff in pure C - much of GTK is done this way, and it starts to look like a sublanguage when you get far enough into it - but I wouldn't say this makes C multi-paradigm.

Re:Thoughts

[m50d]

OK, maybe lisp is more multi-paradigm than I thought. I was judging on what I read in the lisp tutorials I've tried, and I couldn't see how to do something as simple as a while loop without doing it as a function. (defun foo () ((loop statements) (and (test) foo))). No-one mentioned a goto statement, and everything was very functional-oriented, so the impression I got was of a language in which doing "normal" programming is very difficult.

Re:Thoughts

[snorklewacker]

> wtf? How is lisp a multi-paradigm language? It's functional programming through and through.

Actually, it's kind of weak as a functional language, with most implementations lacking proper tail recursion elimination or any syntax for composition or currying. polymorphism is absent outside CLOS, which isn't quite functional oriented either (a method that's still generic isn't first-class, you have to pass the method belonging to something. usually one gets around that with symbols). It's possible to get all those facilities with macros, but it's still sort of painful to use them.

In fact, most common lisp programmers prefer lisp as an OO language. CLOS has OO facilities superior to C++ or Java because of multiple dispatch -- you don't have object.method(arg, arg, arg) but (method object arg arg arg) instead ... but since you have polymorphism on any of the args, you can specialize even more with objects without needing big inheritance hierarchies and interfaces just to glue extra procedures into a class scope. Doing the same in C++ involves a whole lot of verbiage with templates. If want purely functional code, you probably want Haskell, or you might write up a bunch of syntax macros for scheme to get your composition and currying, but Lisp is unlikely to light your fire if you're looking for the cutting edge of FP.

I'd still agree that no modern lisp is going to let you *efficiently* program to the bare metal, regardless of lisp's roots. Of course, someone did write an operating system in Haskell, so anything's possible.

Re:Thoughts

[jaoswald]

To clarify slightly, multiple dispatch means you have

(method object object object object ...)

Where of course, some of the objects can be of unspecified class, so that the actual implementation of the method need not depend on specifying every possible combination. And, unlike some OO languages, every built-in type has a corresponding class to dispatch on.

Re:Thoughts

[jaoswald]

By the way, most people who talk about Lisp mean Common Lisp. A useful on-line spec is here.

Consider, for instance, the section on iteration.

Re:Thoughts

[brpr]

While it may not be "pure functional" it's functional enough that you have to be able to do functional programming to use it.

No you don't. What makes you think this? You could write a virtually line for line translation of a C program if you wanted to. Lisp has loops, assignment and block structure, so it supports traditional imperative programming perfectly well.

I will agree that implementing sublanguages in lisp is easier than in most languages - but you're still forced to program basically functionally to implement it.

Again, no you are not.

Lisp is not useable by people who are unable to do functional programming.

Says who?

I've seen people happily do object oriented stuff in pure C - much of GTK is done this way, and it starts to look like a sublanguage when you get far enough into it - but I wouldn't say this makes C multi-paradigm.

Common Lisp was the first ANSI-standardized OO language. It really is multi-paradigm.

Re:Thoughts

[rsheridan6]

Lisp has lots of functions that modify their arguments, and lisp programmers are not shy about using them. It supports functional programming, but it's definitely NOT functional programming through and through.

With lisp, you can do functional, imperative, OO (since before C++ was a glimmer in Stoustrop's eye), and there are extensions for declarative programming and probably any other paradigm you could think of.

Re:Thoughts

[rsheridan6]

(loop with x = 0
while (less-than x 5)
do (princ (incf x)))

--> prints "12345"

This illustrates a few things about lisp, related to points you've made:

1) It is not functional. Less functional than C, in fact, because C forces you to define at least a "main" function, whereas this is a valid program by itself. Also, it uses side-effects - incf increments its argument. That's a no-no for strict functional languages

2) Loop is in the lisp standard, but it's not lisp. It's an embedded language for iteration implemented in lisp. The difference between that and something like a compiler implemented in C is that loop is integrated with lisp and you can naturally use it from withing lisp. Most lisps are implemented in C, but you can't throw lisp code in the middle of C code and expect it to work.

Prolog and perl-style regular expressions have been embedded in lisp in the same way, and also several different OO facilities (one of which is in the ANSI standard). Macros make it pretty easy to do stuff like this.

Yes! Yes!

[MC6809]

Yes! This is just what I have been waiting for!

Yet another language that will completely revolutionize software development! Yet another Paradigm Shift! Brothers and Sisters, this is truly a great day!

I can't wait to add it to my resume along with C, C++, PERL, Scheme, LISP, Python, Ruby, Pike, Java, Erlang, C# and Forth. The future is now!

To Quote Steve Jobs...

[smug_lisp_weenie]

(in reference to the Next Cube)

"In order for people to adopt a new computing platform you can't give them something that is 30% better- You really have to give them something that is 200% better and that is what we failed to see at Next."

I commend the designer of the Heron language for trying to simplify some of the complexity of C/C++ (Just like the D language and Eiffel tried) and some persons may benefit from such a tool. But I fail to see how a language with some minor improvements in contract and aspect-oriented programming support is really offering more than 10-20% improvement in terms of design over vanilla C++ - Not that anyone says it has to, but to truly make waves in the programming world I think a larger advance would really be necessary...

Also, I am skeptical of the practicality of new languages that don't support garbage collection- Garbage collection is just such a huge win in terms of productivity in many programmers' eyes, not to mention its ability to prevent viruses/exploits from buffer overflows. I coudn't imagine adopting a new language that doesn't at least have this one critical feature, even if you carry a tiny performance overhead because of it...

Still, it's always nice to see people working on new ideas in language design!

--Conrad Barski

Re:To Quote Steve Jobs...

[Anonymous Coward]

The thing is, this doesn't have any new ideas in language design. It's the same stuff, rehashed yet again.

This Heroin language is essentially just C++ with cosmetic changes (some of which are just awful, like some of the Java-ism's).

As you said, minor changes are not enough for everyone to drop the established standards.

Re:To Quote Steve Jobs...

[p3d0]

I commend the designer of the Heron language for trying to simplify some of the complexity of C/C++ (Just like the D language and Eiffel tried)

Actually, Eiffel predates the first edition of The C++ Programming Language, and was much more influenced by Ada and even Smalltalk than by C++.

Re:To Quote Steve Jobs...

[renoX]

Agreed for the GC part.

Disagree for the 200% better part, currently there is no functionnality which can gives a 200% improvement in language design.

But having a language which integrates many small improvements inside something coherent (unlike C++ which is clearly a mess) would still be valuable IMHO. Some claims that Java/C# are the answer, I'm not so sure, D or Nice seems more interesting..

Re:To Quote Steve Jobs...

[cdiggins]

I commend the designer of the Heron language for trying to simplify some of the complexity of C/C++ (Just like the D language and Eiffel tried) and some persons may benefit from such a tool. But I fail to see how a language with some minor improvements in contract and aspect-oriented programming support is really offering more than 10-20% improvement in terms of design over vanilla C++ - Not that anyone says it has to, but to truly make waves in the programming world I think a larger advance would really be necessary...

Thanks for your encouragement. I agree that a language has to be significantly better, but I do think Heron makes enough improvements over C++. One of the biggest improvement are with the Heron approach to interfaces. This approach is having its validity demonstrated through a C++ macro and template library ( the upcoming Boost Interfaces Library ), but unfortunately there is no support in Heron2C for it at this point. What makes Heron interfaces so significant is that they completely turn upside all of the pre-conception that C++/Java/C#/D make about run-time polymorphism.

I have enumerated *some* of the differences between C++ and Heron. I think that this amounts to significantly more than just 20% change. Just look at Java, and it's success. Java offers very little improvement over C++ besides a garbage collection and several missing features ( not that these are bad things ).

Re:To Quote Steve Jobs...

[Anonymous Brave Guy]

Garbage collection is just such a huge win in terms of productivity in many programmers' eyes, not to mention its ability to prevent viruses/exploits from buffer overflows.

<Obligatory> Garbage collection prevents certain classes of memory leak. It has nothing to do with buffer overflows. </Obligatory>

Re:To Quote Steve Jobs...

[Anonymous Brave Guy]

Disagree for the 200% better part, currently there is no functionnality which can gives a 200% improvement in language design.

I don't quite agree with that. The following are relatively recent additions to the programming world -- at least outside of academia -- that yield productivity benefits way better than that in their respective areas of strength:

• RAD tools (Visual Basic, Delphi, etc.) for GUI development
• functional programming (ML, Haskell, elements of several popular scripting languages) for back-end code.

Re:To Quote Steve Jobs...

[Anonymous Coward]

"In order for people to adopt a new computing platform you can't give them something that is 30% better- You really have to give them something that is 200% better and that is what we failed to see at Next."

And where exactly did Steve Jobs say that?

Can't believe you got moderated 5: Insightful and no one noticed that you misspelled NeXT not once but twice. You should lose your hacker license for that gaffe alone.

Re:To Quote Steve Jobs...

[XNormal]

Garbage collection prevents certain classes of memory leak. It has nothing to do
with buffer overflows.

Your comment is correct from a nitpicking point of view. As a language design choice, garbage collection and range checking are virtually always implemented (or not implemented) together. Having no range checking can easily bring down the entire garbage collection system by corrupting its structures. Range checking by itself doesn't help much if the pointer you are range-checking is a stale reference to deallocated data.

Re:To Quote Steve Jobs...

[jaguarul]

Java offers very little improvement over C++ besides a garbage collection and several missing features ( not that these are bad things ).

You forgot the impressive standard library, which is what standard C++ missed the most at the time Java came up. In your interface description (on your website) you have some mistakes, in my opinion. Like Dog has no "MakeSound" method, although you allow it to implicitly implement IAnimal.

Re:To Quote Steve Jobs...

[cdiggins]

Thanks for pointing out the error on the web site, I have fixed it. I am always surprised at how influential a standard library is. The C++ standard library is still hard to use. You may be interested to know that I am working on a more Java-like open-source library for C++ called the OOTL (Object-Oriented Template Library) at http://www.ootl.org

Re:To Quote Steve Jobs...

[Anonymous Coward]

"Almost always" is overstating it. A conservative collector (such as Boehm's for C++, probably more widely used than any other) is no more vulnerable to overruns than a manual heap. They only appear associated because they're each high on the list of features you don't want to do without unless you have to due to their cost (along with exceptions and checks for dynamic typing and numeric overflow).

Another statically typed language?

[WayneConrad]

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.

Re:Another statically typed language?

[cdiggins]

The problem with dynamic languages, like Python, is that they can't be easily compiled to native code and optimized.

I think that the particulars of C++ are the real problem, with all of the backwards compatibility issues, and incremental addition of new features without apropriate removal or updating of deprecated functionality.

Re:Another statically typed language?

[Artega VH]

I don't know about you but spending my time testing typing issues which can be better examined automatically at compile time is exactly my idea of "huge cost".

Using an appropriate language for the job (statically typed or dynamically typed) is much more appropriate, instead of advocating a one size fits all approach.

Re:Another statically typed language?

[selsine]

Personally I like to code using statically typed languages MUCH (emphasis mine) more then when using dynamically typed languages.

For whatever reason I find statically typed easier to work with, so much so that I am always surprised when people say how much they love dynamically types languages.

Differences of opinions, whatever.

Re:Another statically typed language?

[smug_lisp_weenie]

This is less of an issue with Just In Time compilation (JIT) which theoretically can compile even tighter code than a statically-typed language, since they can use run-time profiling information to analyze and improve the compiled code. Admittedly, many languages, such as Python, do not yet have the types of JIT compilers that allow this. -Conrad Barski

Re:Another statically typed language?

[Anonymous Coward]

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.

When the primitive type system of a primitive statically typed language like C++ or Java is getting in the way, perhaps.

A modern statically-typed language like ML does not have complexities like templates.

For example, suppose you want to create a list of integers. Let's look at the hated C++:

#include <list>
using namespace std;
list<int> foo;
foo.push_back (1);
foo.push_back (2);
foo.push_back (3);
foo.push_back (4);

I agree with you: that is ugly and clunky.

Let's look at that in Python:

foo = [1, 2, 3, 4]

I agree with you: that is much simpler and much more elegant.

Now let's look at it in OCaml, a modern statically-typed language:

let foo = [1; 2; 3; 4]

Can you explain to me how this is more complex than the Python example?

Re:Another statically typed language?

[cakoose]

A JIT for a statically typed language can do even better (theoretically).

Re:Another statically typed language?

[pkhuong]

If you need to catch errors where you added a string and an integer, you have bigger problems than your language's typing system. In any case, your unit tests should catch things like that. Re one size fits all: There are languages with dynamic typing where you can specify the typing, and it will be used for both compile-time checks and optimisations. I'd say the fundamental difference between static and dynamic typing is what happens when the compiler can't determine an expression's type: static languages forbid the programmer from using them, while dynamic ones will use tagging.

Re:Another statically typed language?

[Artega VH]

Once again, my point was that its better to have stuff like that automatically and properly tested by a machine rather than a human. It may be more programming work but you'll spend less time testing. Yes.. unit tests *SHOULD* catch things like that.. but compile time checking *ALWAYS* will (provided you are using a true statically typed language)

Re:Another statically typed language?

[Anonymous Coward]

wtf r u blind u hav 2 typ 4 mor chars

Re:Another statically typed language?

[2short]

But

int foo[4] = {1,2,3,4};

doesn't seem any more complex than your other examples. Of course, that's an array, not a linked list. I don't know Python or OCaml, so I'll assume your examples indeed produce a linked list, not an array. Out of curiosity, how do these languages specify an array? Or any of the other half dozen or so variants C++ can specify?

Re:Another statically typed language?

[Anonymous Coward]

One thing that the complexity of C++ enables is the ability to extend the language with some easier-to-use constructs. How about the above example with the help of Boost's assignment library:

#include <boost/assign/std/vector.hpp>

using namespace std;
using namespace boost::assign;

int main(void)
{
vector<int> v;
v += 1,2,3,4;

return 0;
}

Type-safe and pretty.

Re:Another statically typed language?

[Anonymous Coward]

The problem with dynamic languages, like Python, is that they can't be easily compiled to native code and optimized.

Ok, so all the highly- optimizing Common Lisp compilers are fakes?

Or maybe you have no idea what you're talking about? I'm guessing the latter.

Re:Another statically typed language?

[Anonymous Coward]

Arrays are a special case where you can avoid the ugliness of templates in C++ (as long as you don't want to write code that works for an array of unknown type). A modern language with static type inference will let you create an array, list, tree or any user-defined container type comprising elements of concrete or variable type with that single line of code and no type specification. You never have to do it the ugly way with a modern language, and most modern languages give you a lot more guarantees about type safety to boot.

Re:Another statically typed language?

[2short]

"A modern language with static type inference will let you create an array, list, tree or any user-defined container type comprising elements of concrete or variable type with that single line of code and no type specification."

I'm not trying to be argumentative, I just really don't understand: How can you specify (for example) that you want (in C++ terms) a list vs. a vector without a type specification? The two are different; if I want one and not the other, it seems to me I'd need to specfify.

I'd agree being able to use an initializer list for C++ containers would be nice; but it's never struck me as a deal-killer.

Re:Another statically typed language?

[jfx32]

Actually,there is a JIT compiler for Python called psyco.

Re:Another statically typed language?

[sketerpot]

Type inference can help with native compilation a lot (just look at some Lisp compilers like CMUCL for an example---they can get dandy speed), but you're basically right that it isn't easy.

Re:Another statically typed language?

[cdiggins]

In order to optimize code in dynamically typed languages, the types have to be statically determined where appropriate. Determining types at compile-time without static type information declared by the programmer, is hard, and sometimes not even possible for a compiler, even if the programmer knows in advance that a static type is desired. This is why I consider it "not easy".

Re:Another statically typed language?

[JamesOfTheDesert]

I don't know about you but spending my time testing typing issues which can be better examined automatically at compile time is exactly my idea of "huge cost".

Hm, interesting. I don't know about you, but spending my time coding around typing issues, which can be better handled automatically using duck typing, is exactly my idea of "huge cost".

Re:Another statically typed language?

[Anonymous Coward]

Hm. How do those compilers handle "eval"? By embedding a LISP interpreter right in the executable?

Yep. Real efficient.

first things...

[XO]

When I saw this, I read it as "Heroin"... then I thought...

"Heroin. It combines the power of assembly language, with the ease of use of assembly language."

(an old quote, usually applied to "C")

Disclaimer

[Geoffreyerffoeg]

Note that Christopher Diggins is both the author of the language and the article submitter. This may affect your perception on whether a new C++like language is really newsworthy.

As a C++ programmer...

[Tim]

Let me just say that the last thing you want is to emulate is the style of C++!

Perhaps next you'll tell me it has the speed of Python and the type-safety of perl....

Re:As a C++ programmer...

[m50d]

The speed of java is the one to be afraid of. Python at least lets you use C for things which you need to.

Re:As a C++ programmer...

[Anonymous Coward]

Python at least lets you use C for things which you need to.

Uh, so does Java. Ever heard of JNI? I guess not.

Re:As a C++ programmer...

[Anonymous Coward]

err... JNI? Ever heard of it? Let me guess, you don't even know Java.

Re:As a C++ programmer...

[rburt3]

Um, JNI, troll.

Re:As a C++ programmer...

[m50d]

No, I know java. Third language I ever learnt in fact. And I haven't heard of JNI, because the tutorials I saw never mentioned it, wheras the python ones have a big section on "extending and embedding". My apologies for this, but if the docs don't mention it I have no way of knowing it's there. (And I'm aware I probably wasn't following the official sun tutorial, I just used the first few results from a google for java tutorial).

Re:As a C++ programmer...

[angel'o'sphere]

The speed of java is the one to be afraid of. Python at least lets you use C for things which you need to.

The speed of Python is the one to be afraid of. Java at least lets you use C for things which you need to.

Wow, am I insightfull ... yeah that was as lame as the parent, at least *I* know that both languages have a C binding.

Re:As a C++ programmer...

[Anonymous Coward]

Python's works much better though, IMHO.

Re:As a C++ programmer...

[m50d]

OK, but the reason I didn't notice is because java doesn't make use of it. Python uses native libraries for its gui and many other modules which are distributed with it, allowing python guis to have some semblance of responsiveness on sub-ghz machines. Java is AIUI implemented largely in java (which is why the beos people are finding it a bit difficult to port), with the included gui module drawing every pixel in java. Result: java guis are unresponsive, which results in at the very least an appearance to the user that java is incredibly slow.

Re:As a C++ programmer...

[Anonymous Coward]

Swig works great with Java and generates all the JNI boilerplate for you. Tutorials don't mention JNI it because native interfaces aren't tutorial topics. The python tutorial doesn't mention it either, another whole section of the manual does.

Re:As a C++ programmer...

[angel'o'sphere]

Hm, this perception is not right.

Basically a lot of java.lang is written in C. The same for java.io, java.net and java.awt (the abstract windowing toolkit) and java.nio.

Swing, OTOH is pure Java but based on 3 AWT classes.

I think people should try a modern java appliation ... its not less responsive than a python application.

You still fail into the 1995 historical "Java is slow" trap.

angel'o'sphere

Re:As a C++ programmer...

[m50d]

Hm, this perception is not right.

Basically a lot of java.lang is written in C. The same for java.io, java.net and java.awt (the abstract windowing toolkit) and java.nio.

Hmm, it's just the impression I've got from the beos people and the fact it's so slow. My impression was that the java approach was to wrap the basic OS api for, say, tcp sockets and then implement any other java libraries (e.g. http server) in java on top of this, wheras python wraps the os tcp sockets and http server libraries separately. Again, it's just a impression.

Swing, OTOH is pure Java but based on 3 AWT classes.

I think people should try a modern java appliation ... its not less responsive than a python application.

You still fail into the 1995 historical "Java is slow" trap.

I'm sorry but I still find "Java is slow" to be the case. I'm using an 800mhz duron with 256mb ram. Using any java application I find that there is a noticeable delay from clicking a menu to it appearing - examples would be azureus, jedit, and yaggui. This is the case even when nothing else is occuring, and when emerging in the background it becomes really noticeable, quite often a 2 second delay. For a direct comparison try opening the official bittorrent client alongside azureus. OK this is not really a fair comparison since azureus has more features, but gui responsiveness should be top priority, so just try opening the menus in both. Or, try comparing eric3 - a whole ide - with jedit, it starts up faster and is more responsive in use. On a "modern" system it may be irrelevant but on systems within my budget java is very much slow for gui apps, much slower than python.

Re:As a C++ programmer...

[angel'o'sphere]

Hm ... when I started using java I had a far slower system than you :D

My fastest was a 250 MHz Pentium ... and Visual C++ IDE was *not* more responsive than jEdit or Codeguide.

Today I mainly use Java apps ... I *NEVER* saw a response time which was noticeable long on a menu click.

However your system is low on memory (IMHO). And the perception of the perceptee is allways the truth in the eye of the perceptee, anyway. So if you feel a noticeable delay, there likely is one. And while I dont feel any, there might objectively indeed be one nevertheless.

Bottom line there might be GUI issues ... as I never had the luck to have a state of the art high speed machine, I allways foound the gui not very fast and I cope with it. OTOH, a Java application with about 3000 classes compiles in a minute on my system. A C++ application of similar size takes 20 minutes.

The Java compiler is written in Java, the C++ compiler written in C .... So while the GUI might be an issue (and a matter of taste), over all performance is not.

I'm reallys surprised that you brought up jEdit, wich I always found to be a VERY fast application.

angel'o'sphere

Re:As a C++ programmer...

[m50d]

It may well be only gui that's the trouble, and java's fine for number crunching, but for what I've tried programming gui responsiveness is important. But just concerning the compiler, it's not really a fair comparison. Compiling a java application to classes is a lot easier than compiling C++ to executables as the jit compiler will be doing the linking and a lot of what you might think of as compiling. Furthermore, have you ever tried comparing a non-optimizing C++ compiler? They can get very fast, remember the kernel in <10s story a few weeks back. So it might be just that your C++ compiler is doing more optimizing.

First class functions

[cdiggins]

Well actually I missed that requirement. The closest thing to first class functions Heron has are interfaces with one function.

Gosh.

[Kickasso]

Who, in this day an age, deliberately designs a non-hygienic macro system? Don't they teach Scheme in CS101 courses?

Note: call it a macro system, or call it a type safe generic metaprogramming facility, or whatever. I don't care, it's still not hygienic. The relevant wording is here.

Gentle Slashdotter, if you are ever to design a programming language, please make sure its scope rules (whether run-time or compile-time) are sane. Thank you.

Re:Gosh.

[BigZaphod]

Don't they teach Scheme in CS101 courses?

No. :-)
Not at the school I went to, anyway.

Re:Gosh.

[pkhuong]

As a CLer, I'd say capture (which, i believe, is usually the #1 reason given for hygienic macro systems) is less of a problem when functions aren't used as first order objects as much. *Looks at the description* Ouch, that seems sort of painful to use.

Re:Gosh.

[Christopher Cashell]

Well said, Sir!

After learning how powerful and amazingly useful a hygienic macro system really is, it frustrates me to no end when I see new languages being created without some equivalent facility.

Hopefully someday the average programmer will realize what he's missing.

Re:Gosh.

[billster0808]

Why did you have to bring up painful memories of scheme? I almost had those memories repressed! Oh well, back to the therapist...

No Thank You

[Tom7]

The world does not need more C-alike languages, especially if they don't even add in higher order functions and sum/product types. What are they thinking?!

Re:No Thank You

[mwfunk]

What are sum/product types? Just curious.

Re:No Thank You

[Anonymous Coward]

A sum type is a type that can be either one thing or another -- a bool is either True or False, a integer is either positive or negative.

Product types have a value from each composing type -- a point has an x and a y coordinate.

As an example, a list can be viewed as a sum of products - it is either empty or (a first item and another list).

Re:No Thank You

[Tom7]

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.

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 => ... e1 ...
| Right r => ... e2 ...

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.)

Re:OT, feel free to mod down ;P

[El_Servas]

There's three of us...

Happens to me all the time...
Also... sometimes FireFox fails to render the /. homepage correctly... it seem a issues with the tables (or the "page styles" feature of FF...)

Anyone else with this rendering glyph in FF?

Benefits over D?

[Per Wigren]

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. :)

Tim O'Reilly

[OldAndSlow]

will have no trouble deciding what animal to put on the cover of this book.

Static typing is great!!

[Tom7]

I think you're way off base. Static typing helps you catch a large fraction of bugs (these fraction of these bugs being proportional to the quality of your type system) before you ever run your program, which is a very real win. Testing is particularly bad at catching problems in unanticipated inputs or situations, so I don't believe testing can replace static typing as a bug-finding mechanism. (Although testing is of course still important, since it provides another avenue to find bugs.) Tracking down the cause of a type error is always easier than tracking down the cause of a runtime error.

Static typing doesn't come at a huge cost in language complexity. C++ is complex and broken, yes, but there are many much simpler languages (like SML, O'Caml, Haskell) that are statically typed and very elegant. Being a user of SML, I can attest to the fact that its static typing helps catch loads of bugs early--to the point where if your program compiles, it is probably right (indeed, many of the undergraduates at our school, even if they hate typed functional programming, believe this by the end of their first semester with it--I have TA'd these classes and watched programmers learn many times!)

The future (and indeed, where most language design research is done today) is in more powerful type systems that let us express our ideas even more cleanly, reducing run-time bugs even more.

(Again, C++ and Java are definitely not exemplars of this ideal.)

Re:Static typing is great!!

[sketerpot]

The thing that really annoyed me about the type system in O'Caml (I haven't used those other languages you mentioned) is that it seems unnecessarily painful to write things like binary search trees for arbitrary ordered types. The language itself had some exceptions to its rules so that things would be less painful, and to me, that looks like a big weakness.

Type inference is great, and I think that it should be part of every language, but O'Caml's type system has some nasty corners.

Re:Static typing is great!!

[Tom7]

Well, I don't see why this is painful. The two solutions would be to (a) pass in a function that determines the sort order or (b) generate a new binary tree module by parameterizing it on a "contents" module, using functors. There is a certain knowing-what-you're-doing aspect of doing it the second way, but it's certainly no worse than C++ templates. I don't know how you'd do it in lisp since, as far as I know, lisp doesn't have parameterized modules.

If it bothers you that you need to specify the sort order explicitly, Haskell's type classes allow you to overload the > operator (etc.) to have these sort functions be passed implicitly.

Re:Static typing is great!!

[sketerpot]

Does A (pass in a function) work in O'Caml? Back when I know much more about O'Caml than I do now, I could have sworn that you had to use the B approach. Otherwise, why would anybody do it with parameterized modules? Yet there are Map.OrderedType and Set.OrderedType, which are just wrappers around the concept of passing a function, so there must be some reason.

Setting the sort order explicitly doesn't bother me at all; what bothers me is needing to use parameterized modules, which looks like bloating your code just to get around the type system. What I would like is to simply pass a function that can be applied to the element type in the tree---but I don't know how.

The way you would do this in Lisp is to either pass in a comparison function or to use a generic function for comparison, which is close to what you're talking about doing in Haskell. I believe there's something similar in G'Caml, but I haven't seriously looked into it yet.

Re:Static typing is great!!

[Tom7]

Yes, you can definitely pass in a function. This is really straightforward to do; it works just like lisp.

One reason to use parameter modules is to leverage the module system to create different types for your binary trees. For instance, if you had a union function (type 'a tree * 'a tree -> 'a tree), you might want to prevent the union of two trees that had different sorting functions (even if they worked on the same basic types; ie case-sensitive and case-insensitive sorts of strings). This is a win for simpler specifications (which of the two sort functions should union use, otherwise?) and performance (the union function can safely assume that both trees are already sorted).

Re:Static typing is great!!

[sketerpot]

Hooray! O'Caml looks good again! Thank you!

wikipedia article was almost deleted

[bcrowell]

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.

Re:wikipedia article was almost deleted

[fuzzy12345]

Yeah, bit Christopher Diggins is "best known for developing the Heron programming language." [cdiggins.com]

If Wiki deleted the article, and we were left with Chris pointing only to Heron and the language pointing only to him, the garbage collector would discard them both!

Re:wikipedia article was almost deleted

[stevens]

If Wiki deleted the article, and we were left with Chris pointing only to Heron and the language pointing only to him, the garbage collector would discard them both!

Not if the GC is a ref-counter. In that case he's a memory leak.

Re:wikipedia article was almost deleted

[angel'o'sphere]

If Wiki deleted the article, and we were left with Chris pointing only to Heron and the language pointing only to him, the garbage collector would discard them both!

Not as long as one or both are still on your stack.

Re:wikipedia article was almost deleted

[varjag]

If Wiki deleted the article, and we were left with Chris pointing only to Heron and the language pointing only to him, the garbage collector would discard them both!

Remember, in his world there's no garbage collection.

ZzZzZzZz.....

[freewilli]

I could bearly stay awake reading that.
How is this language not Eiffel with C++ syntax??

This is D language

[Anonymous Coward]

this s not a new language , it is really implemented long ago by digitalmars.com as D language and even they have GCC front end

Re:OT, feel free to mod down ;P

[m50d]

It's an incremental rendering thing. You can sort it by changing the text size after the page has rendered. It's fixed in mozilla trunk, so it should be fixed in the next majorish firefox version. (1.1 I think)

I've already converted all my software to Heron

[Anonymous Coward]

I've already converted all my software to Heron - as I do with every new computer language - and BOY are my arms tired!

hmmm...

[digital.prion]

Well if you like "Nice" then perhaps you should also try "Sweet" and "Fuc in A'" as well.

Just a thought..


Cheers!

bad typesetting!

[fortunatus]

This is for the producers of the magazine:

In English you are NOT allowed to stick a hyphen wherever you want to in a word! When you want to split a word between the end of one line and the beginning of the next, you must only do it between syllables! Any worthwhile English dictionary shows where the syllables split in the words.

If you print the article as it is typeset in the preview, not only will it be hard to read, but you're gonna look pretty mediocre.

Re: I think they call that language...

[djeddiej]

english? lol. I am just trying to be funny, so if not, my apologies.

monty python

[exodist-Admin-Ra]

with this language and computerised cutting machines it will now be possible to cut down the largest tree in the forrest with a heron.

Heron today, gone tomorrow

[toby]

Chortle. Waiting the statutory 20 seconds...