7 ms·

(Re-)Introducing the Heron Programming Lanugage

11 points by prog 17y ago

jriddycuz 17y ago
You know, I hate to dog on attempts at innovation, but I fail to see what is new or exciting about this language. It looks like it's just solving some of the problems with Java and C++ that were apparent 15 years ago. I suppose baked-in support for parallelization of list operations is nice, but I wonder how that works with mutable state. And really, I thought (hoped?) OOP was starting to die out in the latest generation of languages that we were seeing, especially very formal OOP. I suppose strong support for meta-programming and compile-time reflection is a leap forward, but one glance at the grammar of the language, in all its complexity, made me wonder how feasible manipulating the abstract syntax would be in a real environment. I understand not everyone wants to rethink and update older languages like Lisp (Clojure), Perl (Ruby), or Java (Scala), a but this just seems like the author got tired of waiting for C++0x and decided to make his own.
- michaelcampbell 17y ago
  Why are you hoping OOP is starting to die out? I'll admit my lack of real FP knowledge (and an envy of those who have it), but OOP has done pretty well I think. I'm hoping I'm not succumbing to the Blub paradox here, but I might be, and like I said I'm totally NOT against FP in any fashion - far from it!
sukuriant 17y ago
I read over the article. I don't exactly understand his desires to keep a developer from converting an instance of a superclass into an instance of a sub-class (presumably to implement the specific methods). Maybe I don't understand his paradigm properly, and that situation can never happen (there was mention of no virtual methods, either. Perhaps that has something to do with the above situation never actually existing), but why would this be an advantage. Furthermore, can't that very restriction be circumvented by making it a two-step procedure instead of 1? Eg: Any a = (Any)someObject; DerivedObject b = (a as DerivedObject);

11 points by prog 17y ago

You know, I hate to dog on attempts at innovation, but I fail to see what is new or exciting about this language. It looks like it's just solving some of the problems with Java and C++ that were apparent 15 years ago. I suppose baked-in support for parallelization of list operations is nice, but I wonder how that works with mutable state. And really, I thought (hoped?) OOP was starting to die out in the latest generation of languages that we were seeing, especially very formal OOP. I suppose strong support for meta-programming and compile-time reflection is a leap forward, but one glance at the grammar of the language, in all its complexity, made me wonder how feasible manipulating the abstract syntax would be in a real environment. I understand not everyone wants to rethink and update older languages like Lisp (Clojure), Perl (Ruby), or Java (Scala), a but this just seems like the author got tired of waiting for C++0x and decided to make his own.

michaelcampbell 17y ago
Why are you hoping OOP is starting to die out? I'll admit my lack of real FP knowledge (and an envy of those who have it), but OOP has done pretty well I think. I'm hoping I'm not succumbing to the Blub paradox here, but I might be, and like I said I'm totally NOT against FP in any fashion - far from it!

sukuriant 17y ago

I read over the article. I don't exactly understand his desires to keep a developer from converting an instance of a superclass into an instance of a sub-class (presumably to implement the specific methods). Maybe I don't understand his paradigm properly, and that situation can never happen (there was mention of no virtual methods, either. Perhaps that has something to do with the above situation never actually existing), but why would this be an advantage. Furthermore, can't that very restriction be circumvented by making it a two-step procedure instead of 1? Eg: Any a = (Any)someObject; DerivedObject b = (a as DerivedObject);