Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Introducing The Heron Programming Language

Posted by timothy on Wed Dec 08, 2004 03:22 PM
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."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • 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!
  • 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.
      • 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: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]
          • Re:Willful Ignorance (Score:2, Informative)

            by 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 [inria.fr] is a statically typed, natively compiled language that provides fully first-class functions.

            Here [haskell.org] is another.

            There are many others; those are just the most widely used.
  • 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

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

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

    • 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

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

  • by XO (250276) <<blade.eric> <at> <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.
  • by Tim (686) <.ude.notgnihsaw.u. .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.
      • 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
        • 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).
  • 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.
  • 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?!
      • 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. :)
  • 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.
  • 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.
    • 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.
      • 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
            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
        • 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

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

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