Despite the fact that I don't have much time. I managed to get my project going a step further.
And indeed I think it's a big step. Firstly it has an official name now - the Mutable Object Framework. Official because the project is now opensource and it's published under the GPL. The official link is here. So far for the formal things.
The second really cool thing is that it works with the CL compiler under Windows and with GCC under Cygwin.
The third - and for now coolest - thing is that the integration of the new object mutation code, which is a generalization of my former object expansion code, now integrates nicely with the object template in AGE. This means that I have reached a state now where the old object expansion code can be removed from AGE and replaced by the new code. This is great.
The next big step is to provide support from the memory allocation side.
Montag, 4. Dezember 2006
Sonntag, 17. September 2006
Reconsidering C++/CLI
After my last post I have been trying to get a hand on C++/CLI, again. It doesn't work for me....
Since I am interested in getting .NET right for me, I have been trying to do something in C++/CLI.. I can turn it in whichever direction I want, It's not a good feeling to write handles and gcnew. I ask myself again and again "Why, oh why is M$ doing something like this?" The only reason that is useful from my point of view, is that someone needs to do the ugly work to integrate old C++ and .NET. That's what it's for - nothing else.
Lately I was Coding with Visual Studio 2005. I must say I really like the UI. It's great. Unfortunately M$ has to put the functionality of two worlds into one Language Environment - at least for C++. When opening the properties window for a project the coder can either choose to go the standard way: Includes, link directories, dependent libraries and so on ... settings for the linker and whatnot. On the other hand he/she can choose to compile against the CLR, there can references be set to dependent projects, which is a M$-mechanism that has nothing to do with C++ coding at all.
So to make a point the C++ environment is - at least from my point of view - an unfortunate mixture of the .NET-programming world and the native programming world. There is no guidance on how or when to use which setting. Of course there is documentation on which feature acts how but it's not made clear at all how the programmer (I also think about people who start programming) can distinguish between .NET and native programming.
There is a mixture of both platforms in C++ (C++/CLI), in the tools for compiling and linking (they act depending on parameters differently and unless one knows these parameters they act unpredictable) and in the development environment itself. The separation of these two concerns seems to not have happened at all. I can only guess why.
On the other hand if I look at the C# environment (especially the project settings) I find a clean pure .NET environment which even points out the mess in the C++ environment and thus makes it even less attractive to the user. This is a pitty but it is the way M$ seems to work. I just await the day that M$ remove support for native C++ programming with the reason that it is too confusing and to error prone.
Couldn't you just be part of the pure clean fine .NET world?....
Since I am interested in getting .NET right for me, I have been trying to do something in C++/CLI.. I can turn it in whichever direction I want, It's not a good feeling to write handles and gcnew. I ask myself again and again "Why, oh why is M$ doing something like this?" The only reason that is useful from my point of view, is that someone needs to do the ugly work to integrate old C++ and .NET. That's what it's for - nothing else.
Lately I was Coding with Visual Studio 2005. I must say I really like the UI. It's great. Unfortunately M$ has to put the functionality of two worlds into one Language Environment - at least for C++. When opening the properties window for a project the coder can either choose to go the standard way: Includes, link directories, dependent libraries and so on ... settings for the linker and whatnot. On the other hand he/she can choose to compile against the CLR, there can references be set to dependent projects, which is a M$-mechanism that has nothing to do with C++ coding at all.
So to make a point the C++ environment is - at least from my point of view - an unfortunate mixture of the .NET-programming world and the native programming world. There is no guidance on how or when to use which setting. Of course there is documentation on which feature acts how but it's not made clear at all how the programmer (I also think about people who start programming) can distinguish between .NET and native programming.
There is a mixture of both platforms in C++ (C++/CLI), in the tools for compiling and linking (they act depending on parameters differently and unless one knows these parameters they act unpredictable) and in the development environment itself. The separation of these two concerns seems to not have happened at all. I can only guess why.
On the other hand if I look at the C# environment (especially the project settings) I find a clean pure .NET environment which even points out the mess in the C++ environment and thus makes it even less attractive to the user. This is a pitty but it is the way M$ seems to work. I just await the day that M$ remove support for native C++ programming with the reason that it is too confusing and to error prone.
Couldn't you just be part of the pure clean fine .NET world?....
Montag, 7. August 2006
C++ and then...
Its astonishing. More than 2 years ago I started digging deeper into C++. The journey was long and I didn't know where it would lead me. I looked at a number of books and an even greater number of links on the internet and I never came to the point where found myself saying: Done. Well, I'm still not at this point, but there's one thing clear to me now....
And this is the destination of the journey. All the time I thought that it's only about clever coding. Surely this is one aspect but it's only one. And the fundamental thing I found (at least for me) is that source code expresses some higher level construct. This has nothing to do with philosophy though it may read like it had. Source code expresses how requirements for a piece of software are implemented. And there are lots of requirements all of which do not have to do anything with functional requirements that originate in a certain problem domain. When I think of requirements the first thing that hits my mind are questions like: How does the software vary? Under which conditions does it vary? When does it vary? So for me software is nothing fixed. It's not a blobb that's written and never changes? It's not even meant to be this way.
I went on a journey starting at C++ coding techniques and now I find myself at a place where a much more fundamental concept drives my thoughts - variability and how it can be achieved. Efficiently.
One thing I am sure that can adress this issue is a thing called Generative Software Development. There is a lot of research going on in this field and one very important point is to find out which parts of a system vary and which do not. This is then expressed in a so-called feature model (which is another form of modelling software). But it's not the only way of modelling software. For instance in the field of Generative Software Development it is often spoken about Domain specific Languages (a word which I came across right while reading about C++ templates and metaprogramming techniques based on them - isn't that funny?). DSLs can be used to modell certain parts of a software system. The resulting models can then be interpreted by some form of code generator and mapped either to other models or to components written in C++ (well actually written in every other programming language). This is kind of a closed-circle-feeling because my journey started at a point which I was not always sure about. And now I find out that "my favourite programming language" is one of not so many that adresses very up to date software development paradigms. And if you have a look at some proposals for the upcoming C++ standard then you will find out that this seems to be intention and not only an accident -> Concepts in C++.
So to answer the question part that comes along with the title of this posting. After C++ for me there is software development based on models, modelling tools and languages which can be mapped to general purpose programming languages like C++ the next big thing.
And this is the destination of the journey. All the time I thought that it's only about clever coding. Surely this is one aspect but it's only one. And the fundamental thing I found (at least for me) is that source code expresses some higher level construct. This has nothing to do with philosophy though it may read like it had. Source code expresses how requirements for a piece of software are implemented. And there are lots of requirements all of which do not have to do anything with functional requirements that originate in a certain problem domain. When I think of requirements the first thing that hits my mind are questions like: How does the software vary? Under which conditions does it vary? When does it vary? So for me software is nothing fixed. It's not a blobb that's written and never changes? It's not even meant to be this way.
I went on a journey starting at C++ coding techniques and now I find myself at a place where a much more fundamental concept drives my thoughts - variability and how it can be achieved. Efficiently.
One thing I am sure that can adress this issue is a thing called Generative Software Development. There is a lot of research going on in this field and one very important point is to find out which parts of a system vary and which do not. This is then expressed in a so-called feature model (which is another form of modelling software). But it's not the only way of modelling software. For instance in the field of Generative Software Development it is often spoken about Domain specific Languages (a word which I came across right while reading about C++ templates and metaprogramming techniques based on them - isn't that funny?). DSLs can be used to modell certain parts of a software system. The resulting models can then be interpreted by some form of code generator and mapped either to other models or to components written in C++ (well actually written in every other programming language). This is kind of a closed-circle-feeling because my journey started at a point which I was not always sure about. And now I find out that "my favourite programming language" is one of not so many that adresses very up to date software development paradigms. And if you have a look at some proposals for the upcoming C++ standard then you will find out that this seems to be intention and not only an accident -> Concepts in C++.
So to answer the question part that comes along with the title of this posting. After C++ for me there is software development based on models, modelling tools and languages which can be mapped to general purpose programming languages like C++ the next big thing.