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."
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!
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.
Christopher Diggins
The author of this language seems a bit clueless.
I think I'm not the only one who misread that as "Introducing The Heroin Programming Language".
Please correct me if I got my facts wrong.
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.
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..
What are we going to do tonight Brain?
(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
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.
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")
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
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.
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....
Let's try not to let fact interfere with our speculation here, OK?
Well actually I missed that requirement. The closest thing to first class functions Heron has are interfaces with one function.
Christopher Diggins
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.
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?!
There's three of us...
/. homepage correctly... it seem a issues with the tables (or the "page styles" feature of FF...)
Happens to me all the time...
Also... sometimes FireFox fails to render the
Anyone else with this rendering glyph in FF?
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.
will have no trouble deciding what animal to put on the cover of this book.
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.)
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.
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.
I could bearly stay awake reading that.
How is this language not Eiffel with C++ syntax??
Lisp started as a "hardware-close" language. I mean, CAR and CDR were assembly language on the PDP-whatever. :)
...) or whatever the equivalent is for your implementation.
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
Property law should use #'EQ, not #'EQUAL.
"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?
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 am trolling
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.
Topher
Well if you like "Nice" then perhaps you should also try "Sweet" and "Fuc in A'" as well.
Just a thought..
Cheers!
Smile.
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.
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.
I am trolling
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.
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.
-jacob
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.
I am trolling
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.
I am trolling
with this language and computerised cutting machines it will now be possible to cut down the largest tree in the forrest with a heron.
> wtf? How is lisp a multi-paradigm language? It's functional programming through and through.
... 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.
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
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.
I am no longer wasting my time with slashdot
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.
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.
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.
Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
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.
Don't drop the soap, Tommy!
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.
Don't drop the soap, Tommy!
Chortle. Waiting the statutory 20 seconds...
you had me at #!