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
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".
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 ).
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.
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.
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/
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.
That is exactly how the Silicon Valley bubble burst. A close friend of mine still makes his living in the Washington DC area jumping from failing start-up to failing start-up, where he gets paid to manage computers for technologically handicapped entrepreneurs wasting some venture capitalist's money.
Slashdot Mirror
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
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".
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 ).
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.
Well actually I missed that requirement. The closest thing to first class functions Heron has are interfaces with one function.
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.
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/
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.
That is exactly how the Silicon Valley bubble burst. A close friend of mine still makes his living in the Washington DC area jumping from failing start-up to failing start-up, where he gets paid to manage computers for technologically handicapped entrepreneurs wasting some venture capitalist's money.
I disagree! Systems administration is one of the most commonly outsourced IT jobs around, you seem to be overlooking web hosting.