Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Introducing The Heron Programming Language 142

Posted by timothy from the you-must-be-a-loon dept.
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."
This discussion has been archived. No new comments can be posted.

Introducing The Heron Programming Language More

Introducing The Heron Programming Language

Comments Filter:

  • Language link (Score:5, Informative)

    by Matchstick ( 94940 ) on Wednesday December 08, 2004 @03:38PM (#11035784)
    Of course, the first thing I search for in the article is a link that describe the language itself [heron-language.com]. What a thing to leave out!

  • more from cdiggins (Score:1, Informative)

    by Anonymous Coward
    Courtesy of Lambda the Ultimate [lambda-the-ultimate.org].

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

  • Willful Ignorance (Score:3, Insightful)

    by Anonymous Coward on Wednesday December 08, 2004 @04:08PM (#11036078)
    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 [lambda-the-ultimate.org].

    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 [scala.epfl.ch], the well-grounded Nice [sourceforge.net], and the nearly complete Aldor [aldor.org].

    And there's no way I'm downloading and installing Kylix just to try it out.
    • 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 crippl

      • Re:Willful Ignorance (Score:3, Informative)

        by Jerf ( 17166 )
        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 la

        • Re:Willful Ignorance (Score:1, Informative)

          by 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 s

      • Re:Willful Ignorance (Score:2, Informative)

        by cdiggins ( 740775 )
        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/ [heron-language.com]
  • 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..
      • 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 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 (Score:1, Redundant)

    by RAMMS+EIN ( 578166 )
    "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 (Score:3, Insightful)

      by Carewolf ( 581105 )
      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.
      • 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.
      • 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 pro
        • 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.

            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 g
    • 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.

      • > 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 g
        • 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.
      • 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.

  • To Quote Steve Jobs... (Score:5, Insightful)

    by smug_lisp_weenie ( 824771 ) <cbarski.4503440@bloglines.com> on Wednesday December 08, 2004 @04:43PM (#11036402) Homepage
    (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... (Score:3, Informative)

      by p3d0 ( 42270 )
      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++.
    • 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..
      • Well if you like "Nice" then perhaps you should also try "Sweet" and "Fuc in A'" as well.

        Just a thought..


        Cheers!

      • 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 b

    • 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

    • 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>

      • 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 d

  • 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 proble

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

    • 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.
      • 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
        • 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)
      • 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 [c2.com], is exactly my idea of "huge cost".

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

    • Static typing is great!! (Score:3, Insightful)

      by Tom7 ( 102298 )
      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
      • 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.

        • 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 orde
          • 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

            • 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 f

    • Re:Another statically typed language? (Score:1, Informative)

      by 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++:

      #i


      • 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?

  • first things... (Score:3, Funny)

    by XO ( 250276 ) <blade,eric&gmail,com> on Wednesday December 08, 2004 @05:04PM (#11036554) Homepage Journal
    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 (Score:5, Informative)

    by Geoffreyerffoeg ( 729040 ) on Wednesday December 08, 2004 @05:07PM (#11036575)
    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... (Score:5, Insightful)

    by Tim ( 686 ) <`ude.notgnihsaw.inmula' `ta' `rmit'> on Wednesday December 08, 2004 @05:22PM (#11036676) Homepage
    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....
    • The speed of java is the one to be afraid of. Python at least lets you use C for things which you need to.
      • Um, JNI, troll.
      • 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.

        • 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 t
          • 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
            • 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 separatel

              • 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
                • 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, remembe

  • Gosh. (Score:5, Insightful)

    by Kickasso ( 210195 ) on Wednesday December 08, 2004 @05:50PM (#11036913)
    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 [heron-language.com].

    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.

    • Don't they teach Scheme in CS101 courses?

      No. :-)
      Not at the school I went to, anyway.
    • 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.
    • 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.
    • 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 (Score:3, Informative)

    by Tom7 ( 102298 ) on Wednesday December 08, 2004 @06:11PM (#11037083) Homepage Journal
    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?!
    • What are sum/product types? Just curious.

      • Re:No Thank You (Score:1, Informative)

        by 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 (Score:3, Interesting)

        by Tom7 ( 102298 )
        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. Th

  • Benefits over D? (Score:5, Interesting)

    by Per Wigren ( 5315 ) on Wednesday December 08, 2004 @06:17PM (#11037134) Homepage
    Heron seems to be aiming at the same market as the D programming language [digitalmars.com], 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 [earthlink.net].

    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 (Score:4, Funny)

    by OldAndSlow ( 528779 ) on Wednesday December 08, 2004 @06:22PM (#11037173)
    will have no trouble deciding what animal to put on the cover of this book.

  • wikipedia article was almost deleted (Score:5, Interesting)

    by bcrowell ( 177657 ) on Wednesday December 08, 2004 @07:20PM (#11037606) Homepage
    The wikipedia article [wikipedia.org] 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.
  • I could bearly stay awake reading that.
    How is this language not Eiffel with C++ syntax??
  • 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.

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

Slashdot Top Deals

IOT trap -- core dumped

Close