mnashadka
asked on
Language For Application
I've been developing for a few years now, and I have to architect a system that will be running on Linux using a PostgreSQL database for my corporation. I would like some feedback on what language I should use. I was thinking about C++, which is fast and comfortable for me. Somebody else mentioned Mono (I'm concerned about the new-ness of the language C# and the lack of support, but I'm open). Java is definitely not a good idea. What do you all think? I'll split the points between the people who respond. Thanks in advance.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
mnashadka - I'm interested in your disagreement. I suppose it rather depends on what you mean by C++. By itself C++ doesn't have a garbage collector, and at least in principle, you have to make sure you de-allocate your memory yourself. As for type safety, well last time I looked, C++ had about as much type safety as assembler.
That doesn't mean you can't choose to restrict yourself to certain libraries and programming practices, so a lot of these issues are less *important* than some people make them out to be. A good example of this would be "managed" C++; in other words, the subset of C++ that is "well-behaved" from the viewpoint of the dotnet runtime. Stick to that and you get GC etc.
In real life, there are lots of issues that require a programmer to understand how to allocate and deallocate resources of various kinds. This is true in any kind of non-trivial application development. People have devised strategies for automating some of the more painful things. Sometimes these strategies are encapsulated in programming languages, and sometimes in libraries, frameworks etc.
The thing is that when I say C++ requires "a lot of effort" for some things, it just really illustrates my point that you can't assess a language in isolation. Whether you like it or not, your choice is not "What language should I use?" but "What languages and libraries should I use?"
In my own job, we're just starting now to find that we can work in a single language that is sufficient for all our needs (C#). The choices are different in the Linux world, but the issues are the same.
As for stability of languages, you probably have to accept some change. The question is what the changes cost you, and how that fits in your overall strategy. I heard somewhere that Java is now bigger than Cobol. Maybe it'll be harder for them to introduce new breaking changes. There are two main influences at work: standards and commercial interests. C++ is kept (moderately) stable by a standards process. Perhaps a good example of the other is that Microsoft maintained backwards compatibility over 6 major releases of Visual Basic. (For the purpose of this discussion let's assume that VB.net isn't really VB!) They had a commercial interest in moving their customer base up through each release (not just tools, but platform) - maybe the Java of today would have been different if Sun's commercial interests were aligned in the same way. I'm not saying I'm for or against anything here - just making an observation.
That doesn't mean you can't choose to restrict yourself to certain libraries and programming practices, so a lot of these issues are less *important* than some people make them out to be. A good example of this would be "managed" C++; in other words, the subset of C++ that is "well-behaved" from the viewpoint of the dotnet runtime. Stick to that and you get GC etc.
In real life, there are lots of issues that require a programmer to understand how to allocate and deallocate resources of various kinds. This is true in any kind of non-trivial application development. People have devised strategies for automating some of the more painful things. Sometimes these strategies are encapsulated in programming languages, and sometimes in libraries, frameworks etc.
The thing is that when I say C++ requires "a lot of effort" for some things, it just really illustrates my point that you can't assess a language in isolation. Whether you like it or not, your choice is not "What language should I use?" but "What languages and libraries should I use?"
In my own job, we're just starting now to find that we can work in a single language that is sufficient for all our needs (C#). The choices are different in the Linux world, but the issues are the same.
As for stability of languages, you probably have to accept some change. The question is what the changes cost you, and how that fits in your overall strategy. I heard somewhere that Java is now bigger than Cobol. Maybe it'll be harder for them to introduce new breaking changes. There are two main influences at work: standards and commercial interests. C++ is kept (moderately) stable by a standards process. Perhaps a good example of the other is that Microsoft maintained backwards compatibility over 6 major releases of Visual Basic. (For the purpose of this discussion let's assume that VB.net isn't really VB!) They had a commercial interest in moving their customer base up through each release (not just tools, but platform) - maybe the Java of today would have been different if Sun's commercial interests were aligned in the same way. I'm not saying I'm for or against anything here - just making an observation.
Regarding larger projects, I seldom rely on an interpreted language. Not because it is much slower (and it is), but just because there is always my code AND the interpreter, written by someone else. Of course, there are libraries, there is an operating system, BIOS and whatever else - all written by somone else. But why to add even more uncertainity?
ASKER
DominicCronin,
The deallocation of objects is very easily handled. 98% of the time (in my experience), pointers are not needed. On the 2% that they are needed, you can use smart pointers (like std::auto_ptr, which is part of the language) to handle the deallocation. This has been true for a long time. A side benefit of not having a garbage collector is that you can much more easily do things like reference counting. Also, C is really weak on type safety, but C++ is fairly strong. If you send a string to a function that requires an int, it tells you. If you send a long to a function that requires an int, it warns you (but it does let you do it). As far as objects go, C++ is just as type safe as Java and C#. What Java developers call "primitives" (char, long, int, short, etc.) are not as type-safe in C++, but there is very little difference in objects. Things like templates actually help make the language more safe. You have to actually cast to put a string and a list box in the same container (std::vector, for instance), as opposed to Java, which requires no casting whatsoever.
I'm not saying that you don't have some valid points, and I'm keeping them in mind, I just don't think that you were correct about the downsides of C++.
My biggest concern with C# is running it on Linux. I know that Novell sort of kind of in a way supports it, since Ximian developed it and Novell bought Ximian, but it's definitely a more or less unsupported language.
Thank you all for your input.
The deallocation of objects is very easily handled. 98% of the time (in my experience), pointers are not needed. On the 2% that they are needed, you can use smart pointers (like std::auto_ptr, which is part of the language) to handle the deallocation. This has been true for a long time. A side benefit of not having a garbage collector is that you can much more easily do things like reference counting. Also, C is really weak on type safety, but C++ is fairly strong. If you send a string to a function that requires an int, it tells you. If you send a long to a function that requires an int, it warns you (but it does let you do it). As far as objects go, C++ is just as type safe as Java and C#. What Java developers call "primitives" (char, long, int, short, etc.) are not as type-safe in C++, but there is very little difference in objects. Things like templates actually help make the language more safe. You have to actually cast to put a string and a list box in the same container (std::vector, for instance), as opposed to Java, which requires no casting whatsoever.
I'm not saying that you don't have some valid points, and I'm keeping them in mind, I just don't think that you were correct about the downsides of C++.
My biggest concern with C# is running it on Linux. I know that Novell sort of kind of in a way supports it, since Ximian developed it and Novell bought Ximian, but it's definitely a more or less unsupported language.
Thank you all for your input.
mnashadka,
It is understandable that your confidence in C++ is certain and up to the highest level. There is no point in arguing that there is any downside to using C++ especially when it is seen through the eyes of a C++ architect/developer. In fact, even with Java and .Net around, I know of C++ developers who would forever be attached to C++ simply because of their love and respect for C++. The only thing that draws people away from using C++ is confidence on C++. If you have a powerhouse of C++ experts and developers available, why not C++?
Microsoft still creates and maitains their products using C++. Of course there's .Net, but .Net's likely written in C++ in the first place. Maybe the same can be said about Sun's Java. And even Perl. In fact, it is not suprising to learn that many programming languages are created using C/C++.
We know of products and systems that use C++. Consider Microsoft Office -- C++. Today, Office is a "system" of sorts and you can actually support an entire SME business using only the Office "system". Of course there are database servers, mail servers, web servers, etc. -- all in C++.
There are things that RAD tools like Java or .Net could allow for those who are "in a hurry" and may have no early investments with C++. RAD tools are not about features that are not existing in C++. RAD tools are about productivity. And if you can enjoy the same productivity with your C++ investments, why not C++?
Have fun.
:-)
etmendz
It is understandable that your confidence in C++ is certain and up to the highest level. There is no point in arguing that there is any downside to using C++ especially when it is seen through the eyes of a C++ architect/developer. In fact, even with Java and .Net around, I know of C++ developers who would forever be attached to C++ simply because of their love and respect for C++. The only thing that draws people away from using C++ is confidence on C++. If you have a powerhouse of C++ experts and developers available, why not C++?
Microsoft still creates and maitains their products using C++. Of course there's .Net, but .Net's likely written in C++ in the first place. Maybe the same can be said about Sun's Java. And even Perl. In fact, it is not suprising to learn that many programming languages are created using C/C++.
We know of products and systems that use C++. Consider Microsoft Office -- C++. Today, Office is a "system" of sorts and you can actually support an entire SME business using only the Office "system". Of course there are database servers, mail servers, web servers, etc. -- all in C++.
There are things that RAD tools like Java or .Net could allow for those who are "in a hurry" and may have no early investments with C++. RAD tools are not about features that are not existing in C++. RAD tools are about productivity. And if you can enjoy the same productivity with your C++ investments, why not C++?
Have fun.
:-)
etmendz
ASKER
My only concern with .NET is the fact that it's going to be written on a Linux box. Otherwise I might be ok with it. Thank you all for your input.
etmendz - I believe large parts of dotnet are written in C#. Most of the people at Ms writing in C# will be accomplished C++ coders; it's a matter of productivity .
ASKER
Thank you all for your input. I'm going to leave this open for the weekend and close it Sunday night or Monday morning.