As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I know C++ windows programming is harder than C#. Because we should Create WNDCLASS and Initalize it and using API Funcs and...
But My Question is here , for windows programming ,Is C# better than C++ ?
If yes , why large programs are created with C++ .
Its not "large programs" when C++ is favored over C# managed code.
There are limits to what can be done with managed code, for instance you cannot write hardware drivers or other programs that interface with hardware. You cannot even access all of the Win32 API from purely managed code. Some programs have high performance requirements and are therefore more suited to C++. Sometimes C++ is used simply because the company developing the software has skilled C++ developers. Sometimes C++ is used because the developers don't want the software to be dependent on the .NET framework (which isn't installed out of the box on XP and earlier Windows versions). Sometimes C++ is chosen so that a cross platform application can be developed.
In broad terms, C# is easier to learn and is a more powerful and productive language & framework than C++/MFC/COM etc. But C++ is a very broad tool, and can produce solutions to many very diverse problems, from writing operating systems, real time systems, embedded applications, databases, business software, desktop software, server software, libraries/frameworks, etc, etc.
C# is better suited to a particular class of problem. It is pretty much limited to running on Windows (with the exception of Silverlight & Mono). C# suits rapid application development, which means it is better suited to one-off custom software, such as many internal applications developed within large organizations. And as I've indicated, its more suited to developing desktop and server application software over drivers and other low level software.
If you're looking at which language to start learning, a smart choice would be: C then C++ then C#. This will give you the foundation you need to become a really good object oriented programmer, with an understanding of how lucky we are to have C#! If you don't have 10 years to spare, then go ahead and start with C#. Whatever you do, don't start with C++ or you are likely to give up your programming career in despair and join the circus where things make more sense.
If I could start from scratch all the c++ projects I have done in the past, 99% of the code would be in .NET. Especially when it comes to UI. WPF, Winforms are much more powerful than MFC.
What type of program will you develop? Please elaborate and then we can make a recomendation.
** EDIT
A good example is Visual Studio itself. VS 2010 is based on WPF now.
Better? Better how? Easier? Faster?
C++ is a monster to learn, huge and complex as it is. C# is considerably "friendlier" and easier to work with. C# often lets you complete tasks faster and easier than C++, because the language and it's framework does a lot of work for you. This is part of what makes C# better than C++, and what makes C++ better than C#.
If you let C# do the work for you, that means that you as a programmer sacrifice some control. This is what sets a high-level language apart from a low-level one. For demanding applications, programmers tend to pick a language that provides the necessary amount of abstraction while still providing the desired control. This is why many demanding applications (such as video games) are written in C++. It has a fairly large array of high-level features, while still packing the horsepower to pull really low-level code for situations where you need absolute control of the hardware. It is also why many business applications and other less demanding applications are written in a high level language such as C#, since these applications have no use for low-level features, and can safely enjoy the gains of high-level ones without worrying about performance penalties.
In C#'s case, all applications created with it run in the .NET runtime environment. This is a disadvantage for programs that need to run fast, since you want to be as close to the hardware as possible. So again, C++ wins for demanding applications where either execution speed or memory usage is crucial. Also C++ can be used on a very large amount of platforms, anything from PCs to coffee machines (okay, cell phones, then), while C# is officially limited to platforms running Microsoft Windows.
As for ease of development on Windows, C# is a clear winner. There are available frameworks for C++ too, but they are not even close to C# when it comes to getting things done fast and easy. That said, it is perfectly possible to write complex GUI applications for Windows in C++ without swearing too much.
Anyway, I hope you see how little sense it makes to compare languages like this. It's much like comparing a hammer to a screwdriver. Choosing a language is about choosing the right tool for the job. Many tools overlap - you can accomplish pretty much the same in C++ and C#, which complicates the choice. If you really want to read into this (going for an "educated choice"), I suggest you read up on the individual languages. If you just wonder which language to learn, I suggest you start with C#, and learn C++ if you ever need to (or want to).
C++ and C# both are really good languages, having said that both have their own specialities.
C++ is ideal for applications which needs to highly optimized memory and cpu usage like verly low level device driver development
C# is far superior for creating business applications like accounting and database driven applications which would take ages if you try building them in C++
In short
C++ is for applications which require highly optimized memory and CPU usage.
C# is far productivity and enterprise applications
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking for general opinion about which language would be best. Best in regards to many considerations.
I have a pretty strong background in c, c++, and objective-c. I feel quite comfortable with those 3. I have used very little c#. I've worked in firmware and middleware for over a decade and have moved into mobile apps lately. Mostly iOS, but now expanding to Windows RT.
I am about to write a version of my company's app for Windows Store (or Metro depending on what you want to call it). I did a proof of concept a couple months back using C++/CX. There were are few hurdles learning it (the syntax for ref classes, and the heavy use of namespaces), but that is in the past and I feel quite comfortable with it at this point.
Some drawbacks that I found were that most of the examples (both MSDN and private) of .net are in c# with fewer in c++. It also seemed to be a little tougher to get questions answered concerning .net frameworks with c++. Most of the time people would post a c# answer and I'd need to port it to c++ equiv. Sometimes this is easy, sometimes more difficult.
My question is: Would it be worth my time and my company's time to start over with c# instead of continuing in c++? I'd need to pick up c#, but I don't consider that a huge burden (actually looking forward to it). Some concerns are:
* Acquiring an more engineers down the road to work on this code. Our company will grow shortly. Will it be easier to find an engineer that knows c# vs MS's specialized c++/cx?
* Ease of getting help though examples, articles, and forums. If c# is much more common, that's useful.
* Compatibility between 3rd party libraries (Seems like WinRT components can be used from any of the main languages)
* Advantages of C# over C++? They both offer everything I need for this app, at least that I can see. What are some pitfalls of C#?
* Does c# use the continution/lambdas for asych programming in the same manner as C++/CX?
Are there any other pros/cons that I'm not thinking of?
What do YOU think? Also, what do YOU have experience with? Why do you back your answer?
C# would have the better online support (code examples, answers to questions), and the stronger base of engineers. I mean that in this specific situation, for this kind of strongly Microsoft APIs reliant software development. Windows Store highly important in Microsoft's overall strategy and C# is more important in their language strategy than C++. Thus, C# is the right fit, IMO.
*EDIT (Filip Skakun) I know reopening the question might be hard, so I can't answer it separately but I typed in all this text that could be useful, so I thought I'd add it below:
It is up to you to decide of course and it might be a very subjective choice depending on what you believe in, like if you think the higher potential productivity and better tooling and documentation support of C# outweighs the benefits of a faster, closer to the metal and (slightly subjectively) more portable C++ that you already know. C++ is still almost twice as popular as a language based on the tiobe index, so getting C++ developers might be easier than C# ones. C++/CX is something you only need to use for cross-assembly communication and talking to the WinRT library, but anything else you code should be done in the standard C++ based on all expert recommendations. Also note that C++/CX is not a managed language and you don't use it with .NET. It is highly similar in syntax though to C++/CLI which is a managed language. The good thing about WinRT is that you can use both languages if you want or need to. I use C# for all the XAML UI, networking, business logic etc. There are tons of samples for using C# with XAML while limited range of ones for C++ since it only became available and recommended for XAML platforms with WinRT. On the other hand for anything lower level like working with DirectX or CPU intensive tasks I use C++, since there is more documentation for straight DirectX than the open-source .NET wrappers for it and it performs better when you want to squeeze out all the potential power of the CPU or use the least energy from the battery.
C# is a bit cleaner language than C++ with less punctuation, the new async/await keywords that make async calls (which you must use in Windows 8 apps) a lot cleaner. It is also a managed language so in most cases you might not need to care about when memory gets released, about buffer overruns etc. Debugging C# code yields more deterministic results than C++ (I just spent 2 days debugging some C++ code and I still don't know how far along I am in finding the bug). It is also easier to maintain legacy code since debugging is so much easier.
C++ is faster, so it also uses less battery, your application will start faster and possibly use less energy. If you already know it well then you might have an advantage over the managed development crowd building apps out there. Because it doesn't use garbage collection - memory management is more deterministic and lightweight, so your animations will be more fluid.
Then there is also the motivation factor. If you really want to learn C# - you might be more happy, motivated and productive learning C# than the language you already know and will happily spend more hours learning it than you would be willing to spend writing another C++ app.
The underlying WinRT libraries are the same regardless of which language you use, but the .NET libraries are only available in .NET code and the standard C++ libraries are only available in native code.
Finally - regardless of what decision you make - you can always mix both languages. That could add to maintenance costs since whoever maintains the code in the future might need to know both languages and also the mixed language platform is very young, slightly less supported by the tools (you can't do mixed managed+native remote debugging for example) and potentially more buggy. It is a very good choice in many cases for the reasons I stated earlier though.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm a teacher(instructor) of CS in the university. The course is based on Cormen and Knuth and students program algorithms in C++. But sometimes it is good to show how an algorithm works or just a result of task through GUI. Also in my opinion it's very imporant to be able to write full programs. They will have courses concerning GUI but a three years, later, in fact, before graduatuion. I think that they should be able to write simple GUI applications earlier. So I want to teach them it.
How do you think, what is more useful for them to learn: programming GUI with QT or writing GUI in C# and calling unmanaged C++ library?
Update.
For developing C++ applications students use MS Visual studio, so C# is already installed. But QT AFAIK also can be integrated into VS.
I have following pros of C# (some were suggested there in answers):
The need to make an additional layer.
It's more work, but it forces you
explicitly specify contract between
GUI and processing data. The border between GUI and algorithms becomes very clear.
It's more popular among employers. At least, in Russia where we live. It's rather common to write performance-critical algorithms in C++ and PInvoke them from well-looking C# application/ASP.Net website. Maybe it is not so widespread in the rest of the world but in Russia Windows is very popular, especially in companies and corporations due to some reasons, so most of b2b applications are Windows applications.
Rapid development. It's much quicker
to code in .Net then in C++ due to
many reasons.
And the con is that it's a new language with own specific for students. And the mess with invoking calls to library.
It is better to familiarize students with Qt, as Qt is actually C++. C# is a completely different beast, and if you use C#, you will very likely get your students confused about what things are Microsoft- or C#-specific vs. what is actually defined in the ISO C++ standard, whereas this will be more obvious with just C++. Moreover, Qt and C++ are portable, so your students who are using Mac OS X or Linux will thank you for choosing a cross-platform framework (Qt also works on Windows); whereas, if you use C#, you will force your students to use Windows (yes, there is Mono, but it doesn't work nearly as well as Qt does across platforms).
You might also be interested in using my C++ Project Template which provides sufficient infrastructure for devleoping a Qt GUI application in C++ using CMake, and has been tested and verified to work under Mac OS X and Ubuntu Linux (and, if I get feedback on Windows, I will ensure it works there too). The template includes code that brings up a "Hello World" GUI in Qt when run with the "--gui" commandline option.
I would recommend Qt simply because it is C++, and not C#.
Interfacing between C++ and C# can be messy, and in my opinion would distract students from the object of the exercise (the algorithms, as you said).
Qt -- P/Invoke to use a C++ library from C# adds a whole 'nother layer of nonsense you don't want to even think about. If you were going to use .NET, it might be worth considering using C++/CLI, which linking managed and native code much easier.
I would use C# for the GUI stuff.
There are way more C# jobs out there than C++ using Qt, so why not prepare them for what they are most likely to encounter after they graduate?
One problem I have seen with academia quite often is not teaching what is used in the real world. Sure, all that other stuff is cool, and I personally like it. Experience of real world use after school would be my priority though.
Also, I don't think asking a bunch of programmers is generally the best source of advice on this subject. I would look at what technologies most companies are hiring for in your location, very likely for most desktop GUI stuff it will be .NET or Java.
writing GUI in C# and calling unmanaged C++ library because VS is a good starting IDE and .NET is the most comprehensive set of libraries available. This assumes your students have access to Windows computers. If they are on linux, QT would be the way to go.
Here's a wild idea, (re)write the algorithm in C# for the GUI app. This serves too purposes, 1) it neatly sidesteps the whole mucking with P/Invoke, C++/CLI or COM just to draw some pretty pictures and 2) unlike using Qt it gives you the opportunity to emphasize the distinctions between an algorithm, a program and a programming language.
I don't think it makes any sense to start creating C++/C# unmanaged/managed hybrid applications here.
For teaching it will certainly be easier if the students don't have to learn a new programming language for the Gui. Also interfacing between managed and unmanaged code and the different types in the different languages will complicate things unnecessarily. Much time and effort will be wasted on these topics, not helping anybody to learn the algorithms that are the topic of the course.
Also for "real life" usefulness I think it's clear that only very few projects will use a C++/C# hybrid. If you do your GUI in C# you will also do the logic behind it in that language. I don't see what would be gained from creating the GUI of a C++ application in C#.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 13 years ago.
I want my code to be as secure as possible.
I do not think that the security of your source code is a good reason to choose between C # and Delphi. if you create an .Net executable you can protect it with a tool like .Net Reactor, on the othe hand the win32 executables are by definition very difficult to disassemble (get the original source code) unless you include debug information in them.
You should compare other features, in my opinion you should use the language with which you feel more comfortable and you have more skills.
In my case it always chooses delphi, because it has an excellent and fast compiler and thousands of third party components and in addition to generating executables without dependencies. ;)
You can check this question
What language or RAD IDE do you recommend for building shareware?
Also you can check this list of applications built with Delphi
Good Quality Applications Built With Delphi
Among them Skype, TOAD, FL Studio.
It depends on your needs. But in the absence of additional information: If it's a shareware program, I'd go for Delphi, mainly because it compiles into relatively small and fast native code executables.
Should you be concerned about modern (Delphi 2010) apps being less secure than older ones because of the new, enhanced RTTI - that can be turned off with a compiler switch.
Delphi is your best choice for shareware software : you can distribute your app in a single exe file , you can embed whatever resource you want to : html pages, images, even your dbserver (look for firebird embedded).
Lots of shareware software was developed with delphi : EMS products (EMS SQL Manager for MySQL, IB, Oracle...), Skype, 7zip...
Have fun with DELPHI
Best Regards
Deleting this because everyone is down arrowing my response simply because their opinion is different than mine. It was an answer to his question, but an unpopular one, so people decided to start taking points away from me.
That's not the purpose of the down arrow, to remove points from people who disagree with you. Your childish and ingnorant actions will subtract from the quality of this site.
In Delphi, you can use pointers (and sometimes they are necessary, for API calls for example) - so you are closer to C than with C#. There is a reason why Java and C# do not have pointers: security.
"Most studies agree that pointers are
one of the primary features that
enable programmers to inject bugs into
their code."
http://java.sun.com/docs/white/langenv/Simple.doc2.html
In the C# programming language,
pointers are supported only under
certain conditions: any block of code
including pointers must be marked with
the unsafe keyword.
http://en.wikipedia.org/wiki/Pointer_%28computing%29#C.23
"Pointers are like jumps, leading
wildly from one part of the data
structure to another. Their
introduction into high-level languages
has been a step backwards from which
we may never recover."
— C.A.R.Hoare "Hints on Programming Language Design", 1973, Prentice-Hall collection of essays and papers by Tony Hoare
Use C# just because it has more mainstream support. Plus it is sure to be backed by Microsoft. Which adds incremental features to the language from time to time.
Also, the main architect of C# in Microsoft is Anders Heilsberg which was the co-creator of Turbo Pascal and Delphi of Borland before he got pirated by Microsoft.
It doesn't really matter in which programming language you create your "secure" application as long as you know what you want keep working until you get the result.
If you build an application in python or any other scripting language for instance you can still have good security.
As a good friend of mine told me few times "it's all you! programming language is just an extension of your mind!"
Both are good. Both are secure. Plenty of people are around who work with either of them.
The support for "enterprise" features like heavy Web services, distributed applications and componentized applications is better using the .NET Framework. Similarly there's no direct equivalent to the vector-based forms possible with WPF.
But if your application will never need them - then go with what you feel most comfortable.
As with most of the posts here, I would agree that security is in how you write the program. Not is what language you use.
I use several different languages, depending on the project.
On top of asking your self which you would be more comfortable with, you should ask your self if you want to support multiple platforms.
My company does a lot of cross-platform development, and as such, we don't use C# on those projects.
There is the mono project that aims to allow .net code to run on mac and Linux, but between the two, Delphi, being pascal is somewhat more portable.
( On our cross platform projects, we use either C or C++ )
Use the language you are most familiar with. That way you can hopefully avoid pitfalls and gotchas of using an unfamiliar language.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is the best language for programming a game project and why?
Why is the game programing world dominated by c++?
This is kind of a difficult question to answer. For the most part, C++ is a "better" language for programming games in that it gives you so much direct control over memory management that you have more options to fine tune your performance. That, along with the fact that C++ has been around ages longer than C#, have lead to its current dominance in the game industry.
However, these days, with the .NET platform and C# becoming so much more mature, its not easy to rule it out as a very strong contender in the game programming arena. I think this is especially true for the near future, as .NET 4.0 and C# 4.0 will bring in a whole new era of multi-threaded and concurrent programming that could bring some massive performance gains to their platform. With multicore CPU's taking the desktop computing world by storm, and massively-cored CPU's only a short step behind .NET/C# 4.0, I think the ease of developing multi-threaded applications with .NET and C# 4.0 will give C++ a run for its money.
In the end, it will entirely depend upon how much control you think you need over memory management, and whether that control is worth the effort in the arena of massively parallel games. If you need that control, and think you can deal with the effort of writing a highly parallel game in C++, then you'll probably gain something from it. Otherwise, I would say C# 4.0 would be the better option.
2011 Update:
It should probably be noted that, now two years on from when I originally wrote this, Silverlight games, particularly Silverlight on Windows Phone 7, have become a large and rapidly growing platform upon which games, often quite advanced games, are being developed. Gaming on WP7 has exploded since the platform first launched in Nov. 2010, and already WP7 has more games developed for it than competing platforms. Given the ubiquity of mobile devices and the popularity of playing games on them, I think that is a strong indication of C#'s power and capability as a game development language. Quite a few WP7 games are fully 3D, graphics intensive games.
For commercial / bigger game projects, C++ is probably the best option. However, if you're thinking of doing smaller, indie type games, there's nothing stopping you going with C# or even Java.
I've done several small games with C++, and one with C# using the XNA Framework, mostly for curiosity. Currently I'm working on a platformer game using Java and LWJGL (Lightweight Java Game Library). And guess what? It's working absolutely fine, plus I get cross-platform compatibility practically for free! The reason I started this project with Java was to see if I could create a nice OpenGL-accelerated game using Java instead of C++ I've normally used. So far it's working very nicely for me, I was really suprised actually. =) To be honest I've become a bit tired with C++, coding in Java feels much more productive for me currently (big thanks goes to Eclipse IDE!).
So, for smaller games you can definitely have success with Java or C#, no need to bother with C++, unless you're doing something that needs 100% of the possible performance. XNA might be the easiest option to get started with, although as for myself I most probably won't be using it again since it's basically Windows only (plus Xbox 360)..
Games are some of the most hardware intensive applications you can run. People program games in C++ for the performance, although there are a few games coming out nowadays written in C#.
This question has been asked before, check the following posts for more details:
Viability of C#/.NET as the new standard game dev platform?
https://stackoverflow.com/questions/19642/suggested-gaming-platform-to-learn-direct-x-c-open-gl-or-xna
It took years to get game developers off assembly onto C, then it took more years to get the industry onto C++. The reason is always the same ... "C will be too slow", "Objects will be to slow". There is enormous investment in code (engines, previous games, etc.) and talent in the industry in C++. It will take a long time for that to shift -- just as it has in the past. Someday, games will be developed in managed code, but it will take some time.
Meanwhile there are engines written for .NET in C#.
I think you'll find that, when you create your own game, that being CPU bottlenecked (the only aspect on which language choice has any effect) is the last thing you need to be worried about. It's much, much easier to be bottlenecked by the GPU. Hell, with today's minimum of 2 cores, I would find it impressive if you even managed to ever reach 100% CPU usage because that would require a perfect workload division to utilize the 2 or 4 cores of the CPU.
Generally, it's much too common for me to run a game (presumably written in C++) to see it use at most 50%-60% of my CPU. And can you then really speak of a bottleneck with the language that you use, or a bottleneck of the algorithms used that don't allow you to scale across more than 1 CPU core? So even in a situation where you run into the limits of a single core, it's still possible to (theoretically) double your performance by optimizing your algorithms before you can truly say you're being limited by the language.
And this is only going to increase in the future with the advent of 8, 16 and 32 cores. You really don't want to have a game that's only capable of using only 1 core out of 32.
The real reason why C# isn't being used in the industry: there's no reason compelling enough for game studios that have invested a lot of money into their C++ code to switch to C#. Not just their code, but their developers are already very good in C++ so it would be odd to switch to C# for "ease of use" when that actually means a lot of new challenges to overcome and a lot of money to rewrite existing code. And after all that, you've got new code that's only supported on the PC (with Mono for Linux support) and Xbox 360. No PS3, no Wii. So you've just limited yourself for little gain.
If you use C++, you have a much larger codebase, although this shouldn't matter for most games (except 3D games or games that'll need libraries like physics engines). C# could be easier to write, depending on how much experience you have with it (or how much less/more experience you have with C++).
Also consider using some sort of game creation tool like XNA Game Studio or similar, they often can give you all sort of help with usual stuff.
'Performance' is a red herring. Yes, games are just about the most demanding application that most consumers will run. However, most of the heavy lifting can be done with dedicated hardware, which will beat a software solution in any language any day of the week. The proliferation of Flash games should be proof enough that in most cases we have performance to burn (and now that we have some decent implementations I think we'll soon see games apearing in Javascript too).
I think it's just that many other languages are billed as business focused, or academic, or statistical, and developers on the whole haven't really felt the need to challenge those assumptions.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm going to advise a company on a project soon, and I'm not too sure about what programming language I should advise.
It's a fairly straightforward (desktop based) application with a central datasource on the network, for storing and editing parts that make up a machine. The machine needs to be configured in the application, and with this configuration production documents (manuals, software, bill of material) are generated. (e.g. if part A and B are added to the configured machine, then variation X on chapter 5 of the manual has to be used, if that makes sense)
There's a few non-standard components like a tree with radio & checkboxes, and it has to have some sort of version control in it. It needs a WYSIWYG editor to edit chapters of manuals. It doesn't necessarily have to run on platforms other than Windows because it will only be used on the company network and everybody runs windows.
I was thinking Java because of it's huge numbers of useful libraries and free IDE's. I'm a Java programmer myself so I'm not very familiar with other programming languages. Any thoughts on what language I should use, and why? I believe there's a bit of VB/VBA and Delphi knowledge present in the company (it's not an IT company and I'm not likely to program it myself).
Thanks heaps!
From what your describe of your application and environment, nothing can beat Delphi!
It's the ideal case for Delphi to shine:
- native desktop application with fastest performances and development combined.
- plethora of excellent (often free) components; you'll probably find your tree
- extremely powerful yet simple for DB applications
- very active and helpful community
See also why I recommended it for another SO user.
I think if you have Delphi knowledge in your company : it is a very good choice for Desktop application and as avar says : you can find a lot's of good components here Torry's Delphi Pages.
I recommend this article
for desktop applications ( plus with database/win32 things) i'd recommend delphi. u can find many good components availabe .
You probably want to choose the language that your team has the most experience with. I personally am into Delphi, and it sounds like this might be a good choice for what you describe. Delphi is highly suited for Desktop apps talking to a database. However if your team (those writing and maintain the app) are more experienced with Java / C# / VB then you should go with that.
Well the scenario you describe is not very language specific, so
here are a few hints:
generally, java is absolutely ok but:
In a windows world, you can live easier with .net languages,
because of direct access to COM/activex for combining documentation snippets
in adobe or Word
since there's some vb knowledge about in the company, maybe the task of
maintaining the software becomes cheaper.
I would suggest c#, because via mono, you can go Linux where and if necessary.
well, that's my 2 cents.
Depends. On many things. What language are you familiar with? What database do you use (MS SQL has some advantages when used with a .NET language, but can also be used with java, or ...)?
The libraries are (at least for me) not a main decision point since there are a lot libraries for other languages too.
If you do not program yourself, ask the developer doing the job. Projects have other marks than technology such as time used and money spent. If you choose a language the developer is familiar with, it's more likely to be in time and in cost.
Your question is somehow far too open to give an exact answer. But maybe this helps you to think about it.
You should use whichever language is:
1) Most appropriate for the project
For example: If your project requires real-time processing, use a language that is conducive to performing that task.
2) You (and your team) is most comfortable with.
You would need to discuss with your team whether any languages that you currently know between you all are appropriate (keeping point 1 in mind). If none are appropriate, which language (with point 1 in mind) will all be most comfortable with in learning, developing and supporting (maintaining) throughout the life-time of your project.
This sounds like very curt advice, but I believe it's crucially important. If your project is to succeed, you need a language that you can "live" with, and will work with you rather than against you. If you were a wood-worker, you could use a hammer to put screws into a piece of wood, but wouldn't you be much more comfortable using a screwdriver?
Of the tagged languages, avoid asp.net as it's a desktop application. Other than that all the other languages would do a good job. It would come down to personal preference (more importantly the personal preference of the developer).
I'm a Java programmer myself so I'm
not very familiar with other
programming languages.
If you're going to write the software you should use Java. You're already familiar with it and your familiarity can help you delight your customer.
If you aren't writing it you need to find out who is and take their experience into consideration. Having them learn a new language just because you don't know what they are familiar with is not exactly a good way to go.
Java would work, C# would work (I would personally pic C#), it really just depends on the experience you have available.
What is this about the "non-standard" components? If there are 3rd party controls they want to use that might dictate the language/platform to work with. There are lots of free controls and examples in Java and C# as well and extending the standard Java / .NET controls might even work better that going with the 3rd party controls.
Sounds like you need to know more about the application and some other things that are out there before you can really be advising somebody else on what to do.
Well, there is a lot of wisdom with using what you know (Java).
However, just to counter the "because of it's huge numbers of useful libraries and free IDE's" - .NET also has a huge library base, and free IDEs (including the Express editions of Visual Studio). For .NET, C# would be a "closer" language to Java than VB.
I reckon you'll end up with Java, though (through familiarity - not always a bad thing).
When we build client side systems we use .Net (C# usually). We do Java on the back end, but it sounds like you may not have a traditional back end. For all the libraries and frameworks that are available for Java the vast majority of high quality UI components are in the .Net space these days.
When you are managing the development and someone else is doing the implementation and maintenance then I'd suggest to negotiate the programming language with them.
When you have to do the maintenance then focus on languages that you know.
If you do all/most of the work, just use what language you are familiar with, when you don't have enough time to learn a new language on the way. Especially if the application is important and needs to be pretty bug free. (although there is never a "last bug" as we all know) ;-)
The amount of 3rd party libraries is not a good criterion because this doesn't reflect their quality (maybe most stuff is crap) and many libraries means also a big chance to select the wrong one.
Don't forget to check if the chosen language is capable of doing the job. (Speed, platform constraints, memory footprint, ...)
I think it doesn't really matter that much in which programming language and environment you program, as long as you get to know it thoroughly. C++, Java and C# all have good libraries and all have their strengths and weaknesses. The important thing is that you know the peculiarities of the language, the development environment, the debugger, a good profiler, the standard libraries, the best third party libraries, etc... Moreover, after a while you can reuse your own code as well. For example, you mention an advanced tree widget. In our company, we have our own tree (in C++) which we can finetune as we like.