So, as some people may know, I have a tendency to bite off more than I can chew. I invested a fair amount of work into building a C++ library called the OOTL. I decided that this project is simply too much work for someone trying to at the same time build a programming language. Especially when it comes to supporting all of the nasty C++ compilers out there, and providing proper support to users etc. It is still available in the public domain at ootl.org, and contains some rather unique code. I simply don't have the time or energy to maintain it, not if I want to try and make something of Heron.
Well CUJ closed it's doors, and as one reader said to me, "where are you going to publish your C++ erotica now?". Well at the current moment, I don't plan on publishing anymore C++ erotica. C++ was a bit of a phase for me, I feel like I now know about as much about the language as I care to. At one point, you stop caring whether technique X conforms to the standard, or not. I just want to write software, and frankly I don't care if some MIPS architecture running older versions of GCC bombs or not. To be honest, C++ was a just a means to an end.
I spent the last couple of years trying to get to know C++ as well as I could in order to learn from Stroustrup's expertise and experiences. Despite its shortcomings C++ is a very carefully designed language which elegantly satisfies all of it design goals. I chose C++ as the language to master because the guiding principles are very closely aligned with my own, and the language does things in a way which makes sense to me. I only have minor philosophical differences with Stroustrup's original design, and the fact that I think design by committee, is just a fundamentally bad idea. I think 10 year release cycles, says it all.
On a personal note, I have been applying for work lately. Some people ask me, "how do you make money?". Well to be blunt, I don't. In the past I started up some successful online businesses, and I was living on my savings and residual revenue (and my patient and loving wife). Let me tell you, writing about programming does not pay very well. The whole poor independent researcher thing was fun for a while, but it eventually wears thin.
People keep asking me, "so where is Heron at?". Over the last couple of years I keep learning new things, so it has the unfortunate effect of bringing me one step forward and two steps back. I have been programming computers for 20 years, and I think I learned as much over the last two years as I did in the first 18. Thankfully, I am starting to get a grip on things, and a certain confidence in my vision. The other challenge is that I have had a hard time deciding who my audience should be (it's still vague, but at least I know what I want to do next). This voice in my head keeps saying "build it and they will come".
Heron now has a prototype Heron to C++ translator which currently translates the behavioral traits to C++, as I described in my excruiatingly long last post. I am currently adding support for classes, and I am close to being finished. The next release will probably come bundled with a GCC binary for windows, and a tool which coordinates the two tools. I am working hard on trying to get this out the door, but I can't promise anything.
I know the following request is not a "cool" thing to do on a blog, but I don't have the luxury of not utilizing all my resources, and it is still *my* blog, not a newsgroup or moderated discussion forum. Here goes: if anyone has some interesting and challenging work for a programming language designer / C++ expert willing to relocate, please check out my C.V. and give me a shout at cdiggins at gmail dot you know what.
I don't see anything uncool about looking for work. The fact that you started your own language would seem to indicate some disatisfaction with what's out there as well as commitment to your goals. This is a rhetorical question, but do you feel that sometimes it'd be better if you were a brainwashed programmer who's fanatical about some particular popular language? I say that in jest. But doesn't the expression go "ingnorance is bliss"?
I've been looking into programming languages for several months and although I did learn a lot, I learned that teh issues surrounding programming languages design isn't easy. If it was, we'd be much more advanced. And that's why we do it. Not because they are easy, but because they are hard. Wait, wasn't that JFK?
Good luck in the job hunt. And thanks for putting in all that effort and sharing with us your thoughts. I know of nowhere else where you can gain this kind of inside knowledge (first hand) into language design and the issues surrounding it. Are you gonna keep supporting Heron after you start working?
> I learned that teh > issues surrounding programming languages design isn't > easy. If it was, we'd be much more advanced. That's only part of the problem. I think the real challenge lies in upgrading your users, i.e. the everyday programmers.
For example, consider generic programming. While C++ offers a very powerful implementation of generic programming (templates), I think it failed in a sense that it didn't bring it to the masses. I hope Java and C# do better at that.
In this light, I'm not conviced (yet) that duck typing/implicit (behavioral) subtyping are the right thing to do (sorry, belongs to the last blog actually). Do the use cases justify the developers time to learn it?
> That's only part of the problem. > I think the real challenge lies in upgrading your users, > i.e. the everyday programmers.
Yes! This is a very significant consideration which affects all aspects of language design. This is what a lot of people don't realize about C++ (and all successful languages), it was bounded in large part by how programmers are used to thinking. There are so many things we take for granted.
> For example, consider generic programming. > While C++ offers a very powerful implementation of generic > programming (templates), I think it failed in a sense that > it didn't bring it to the masses. I hope Java and C# do > better at that.
I believe GP in Java and C# has some serious problems, and it will take another language to really bring GP to the mainstream.
> In this light, I'm not conviced (yet) that duck > typing/implicit (behavioral) subtyping are the right thing > to do (sorry, belongs to the last blog actually).
Behavioral subtyping, be it implicit or nominal, I believe has extremely clear benefits. Any system of expressing preconditions and postconditions independantly of implementation is bound to be an improvement, IMHO.
Implicit subtyping, is more contentious.
> Do the > use cases justify the developers time to learn it?
There really isn't much to learn in the case of implicit subtyping, you simply drop "implements" clauses from your classes.
> Behavioral subtyping, be it implicit or nominal, I believe > has extremely clear benefits. Any system of expressing > preconditions and postconditions independantly of > implementation is bound to be an improvement, IMHO. I didn't argue the behavioral part. I think Contract Programming/assertions are great and I hope Spec# will bring that to the masses (and maybe Java follows). I'm undecided about the implicit part.
> There really isn't much to learn in the case of implicit > subtyping, you simply drop "implements" clauses from your > classes. On the surface, I agree. The implements clause, apart from hindering duck typing, has a couple of adavantages: 1) it is great for documentation. If you read ArrayList implements List you immediately know the contract of the class. 2) It is cruitial for agile development/refactoring. When you rename a method in the interface, the IDE will rename all implementations and all method callers as well. I don't see (yet) how this can be possible with implicit subtyping. Maybe a-posteriori subtyping is better in this regard.
To sum it up, I am currently of the impression that adapter classes are a smaller pain than implicit subtyping would be. Or, this is just taking away too much static typing for me ;-)
Heron, OOTL, the cdiggins::any ! and all your high-level, always imaginative but very pragmatical way of though is so valuable for all of us.
It's a shame that people like you don't succeed in making money without working for a company. If I were a company, I really would like to engage you to keep doing what you do. Anyway, good luck for the job. I hope you'll find a well-payed one with enough free time so that you can keep working on Heron and keep sharing your though with us.
Is there really no company nor research group interested in paying you to develop the Heron language ?
> > There really isn't much to learn in the case of > implicit > > subtyping, you simply drop "implements" clauses from > your > > classes. > On the surface, I agree. > The implements clause, apart from hindering duck typing, > has a couple of adavantages: > 1) it is great for documentation. If you read ArrayList > implements List you immediately know the contract of the > class.
Good point.
> 2) It is cruitial for agile development/refactoring. When > you rename a method in the interface, the IDE will rename > all implementations and all method callers as well. I > don't see (yet) how this can be possible with implicit > subtyping. Maybe a-posteriori subtyping is better in this > regard.
This is another good point (though I think slightly over-stated).
I am virtually completely convinced of the need for an "implements x" clause as part of class definitions. This will solve both problems you point out, and I can still have my implicit subtyping when I want it. However, for those who need a strict control over their subtyping mechanism I can provide an optional "nominal" modifier for traits, which means it can only be used by those classes who explicitly implement an interface.
> To sum it up, I am currently of the impression that > adapter classes are a smaller pain than implicit subtyping > would be. > Or, this is just taking away too much static typing for me > ;-)
To be precise the proposed implicit subtyping mechanism is still static typing since it is performed at compile-time. Not many programmers are used to static typed languages with implicit subtyping, so it will be interesting to see what the responses are of people using such a mechanism in the field.
> Heron, OOTL, the cdiggins::any ! and all your high-level, > always imaginative but very pragmatical way of though is > so valuable for all of us.
That is extremely nice of you to say, thank you very much.
> It's a shame that people like you don't succeed in making > money without working for a company.> If I were a company, I really would like to engage you to > keep doing what you do. > Anyway, good luck for the job. I hope you'll find a > well-payed one with enough free time so that you can keep > working on Heron and keep sharing your though with us.
I am actually quite confident that there will be even more developments on Heron over the next while. I have scaled back my vision a bit, and I believe my plans are feasable even as a part-time endeavor. I started making a lot of compromises in my original language design, simply so that I can develop a compiler more quickly.
> Is there really no company nor research group interested > in paying you to develop the Heron language ?
I don't think so, but I am looking. I think this is in part because I have yet to make a strong case for Heron for any particular field of application, and it doesn't offer much in the way of innovation. I am hoping that when I develop some more tools, I might be able to address the niche of people looking for high-performance programming languages, and rapid application development. I think gaming, and scientific programming are niches which I might be able to address with Heron.
> > I learned that teh > > issues surrounding programming languages design isn't > > easy. If it was, we'd be much more advanced. > That's only part of the problem. > I think the real challenge lies in upgrading your users, > i.e. the everyday programmers. > > For example, consider generic programming. > While C++ offers a very powerful implementation of generic > programming (templates), I think it failed in a sense that > it didn't bring it to the masses. I hope Java and C# do > better at that. >
There's a host of problems with templates. First, they're ugly as sin. Second, they make it dificult to have references to the actual implementation rather than the template definition. This is a major pain not only for templates, but OO in general. Third, every compiler has their own way to instantiate a template which can lead to much duplication if you're not careful. And in the special case of STL, you can only really use it as is. They're not very conducive to reuse and expansion, much to the dismay of proponents of generic programming. This is all about language design. You can't put this on the public.
No, language design is difficult because what is language design other than a better and easier way for regular programmers to write software. C was better and people used it. For programmers, by programmers. And then look at most research languages.
When you design a language, you have to first decide who your target audience is. C was very clear. Then you have to decide what problems it will fix or do better. Again, C was very clear. So was C++ and Java in this respect. And we haven't even got into the syntax or language yet.
While I do think that there are too many beginners, we were all there at one point. So your comment about upgrading users just doesn't fly.
> There's a host of problems with templates. First, they're > ugly as sin.
I think this (syntax) is one and only reson why templates didn't catch up. Just look at:
vector< vector<int> > a;
What a stupid way to write a definition of two dimensional matrix.
... and then if program fails somewhere around the line a[3][4]=8; you are going to have a problem if your debugger doesn't understand overloaded operators or templates well.
> > Is there really no company nor research group > interested > > in paying you to develop the Heron language ? > > I don't think so, but I am looking. I think this is in > part because I have yet to make a strong case for Heron > for any particular field of application, and it doesn't > offer much in the way of innovation. I am hoping that when > I develop some more tools, I might be able to address the > niche of people looking for high-performance programming > languages, and rapid application development. I think > gaming, and scientific programming are niches which I > might be able to address with Heron.
I think much of the problem with introducing _any_ new language (no matter how well designed) is the lack of users (and perhaps to a lesser extent, lack of compilers/tools). It's a chicken-and-egg situation: You don't get get much/any users, because you don't have much/any users. There's a reason C++ built on C... This way, hundrds of thousands or millions of C-programmers could start using it, and gradually build their C++ competence, while being able to compile all the code they already have. They could also use existing C libraries.
Perhaps if Heron could be made to be a superset of C++, could it have a better chance of growing. However, that might not fit well with the design of the language.
I don't want to bust anyone's bubbles, but... honestly, how many language designers have been able to make a living of working on the language - at least _before_ it has become popular? Ok, so Java/Oak was developed at Sun, but it was a corporate project from the start. Ditto with C#.
Also, how many languages have really taken off? By all means, even languages that haven't become that widely used, may still contribute ideas and concepts to the field, such as functional programming languages, that, although quite rarely used in real-world projects, many of their ideas have been incorporated into more mainstream languages. Learning about some functional programming language can bring some "a-ha"-experiences. For example, when learning about Haskell, I realised that C++ partial template specialisation is similar to Haskell's pattern matching. And so on.
Bjarne Stroustrup has expressed that, despite starting from C, he wasn't at all certain about that C++ would take off, and certainly not to the extent it has.
The above is some of what I find exciting about working with improving C++ (if I only had got time for it...): You get a chance to contribute to improving the lives for millions of people, who are already using the language.
> Perhaps if Heron could be made to be a superset of C++, > could it have a better chance of growing.
Heron won't ever be a superset of C++, but it will be two-way compatible. Heron libraries can be called from C++, and C++ libraries can be used from Heron. I think the ability to leverage existing code bases, and be integrated into C++ projects, will be an important part of helping Heron catch on in the future.
> 2) It is cruitial for agile development/refactoring. When > you rename a method in the interface, the IDE will rename > all implementations and all method callers as well. I > don't see (yet) how this can be possible with implicit > subtyping.
Consider how Java implements anonymous inner classes. They compile to 'normal' classes with generated names. If you refactor an interface, the IDE is able to refactor these anonymous classes.
If an implicit typing mechanism were to generate (adapter) classes in much the same way as above, then the IDE can easily refactor these implicit classes in much the same way it does now.
More generally, if a compiler can determine a that an implicit subtyping is valid or not, I can't see why the IDE would not be able to recognize changes to that relationship.
> I believe GP in Java and C# has some serious problems, and > it will take another language to really bring GP to the > mainstream.
If you have moment, can you elaborate on what those problems are? I too feel there are major issues with Generics but I when I try to make my case, it's not all that convincing.
Flat View: This topic has 36 replies
on 3 pages
[
123
|
»
]
Previous Topic
