Modern compiled language? Good GUI toolkit?

I have already learned C and C++ to a workable degree. However, now and then I hear that these languages are "outdated" or "obsolete". I am aware that the worldwide development focus now shifts toward the .NET platform, Java, interpreted languages (PHP, Python) etc. However, these are all interpreted or JIT-compiled languages. This has portability benefits, as well as some interesting but rather nasty reflection functionalities, but IMO isn't best performance-wise. Those platforms are probably good for developing desktop applications, but nobody is going to write a video game or computationally intensive simulation program in these. So my question is: are there any "modern" compiled languages that can be utilized in performance-critical situations beside C/C++? I've heard about D, but this one is far from maturity.

Also, I'm getting a little tried cranking out apps in pure Win32 API and am looking for a good toolkit for C++ to start learning. What would you recommend? wxWindows, GTK, FLTK? There are also Open Foundation Classes, but this project is dead as far as I can tell... Or maybe it's a good idea to write a toolkit for Win32 myself and add to it when needed?

The last question: I assume that anyway I can't get along without learning some portable VM language. Which is the best choice: C#.NET, J#.NET, C++.NET, Java? And is there a less bloated free IDE for .NET languages than Visual Anything Express?

C and C++ aren't going anywhere. There is no language faster than C for most general-purpose algorithms. However, you don't seem to realize that computers are a lot faster than they used to be. The game Psychonauts has a core engine written in C/C++, but ALL of the game logic is handled in Lua, an interpreted scripting language. JIT compiled languages are plenty fast, too.

What, exactly, is your "performance critical situation?"

Also: out of C#, J#, Managed C++, and Java, only Java is "portable." The rest aren't even close. J# is a joke.

As for the performance-critical aplications, I mainly mean real-time physical simulations. Generally kinds of things that run in a while(true) loop and utilize 100% of processor power. An increase in performance permits a decrease in step size, increasing accuracy. So the faster it runs, the more accurate it is.

Aside from Fortran I can't think of any other mature languages with the level of optimization you'll get from a good C/C++ compiler. C is very nearly ideal as a portable assembly language so other languages tend to be aimed at solving different problems.

But if the non-performance critical UI portions of your application constitute a significant part of the project then I don't see why you can't handle those parts in some other language. Mixing C with another language isn't exactly pain free but still very nearly universally supported. The use of scripting languages in games has been standard practice for the last decade, and I've seen a few C# applications with performance critical sections written as external C DLLs as well.

Another thing you may want to keep in mind is that binary compatibility generally isn't nearly as important as source level compatibility. And while there are C compilers available for just about every computer system developed in the last 30 years, .NET can only be executed on a handful of them.And think hard on which system you really want to support and don't waste a lot of effort trying to be flexible enough to handle the more esoteric platforms out there, for instance floating point is a big performance killer on many mobile devices but do you really want to abolish the use of floats in the project 'just in case'?

Here's an interesting suggestion: Start by learning C# 2.0, then move to F# once you're familiar with the platform. If you want a high performance, learn OCaml afterwards, since F# is based on it and it has quite high performance (But only when used correctly, like everything else). F# is not well-known itself, but for an unpopular language, it has been developed quite well by the Microsoft Research team.

The obvious alternatives to C# and Java in the "fast, modern language" category are mostly functional - there are a few (Scala, Nemerle, F#, etc.) for the major VM platforms, and a few major ones - Haskell and OCaml, mainly - that allow native development for each platform.

A distant third option is to learn some scripting language with a cross-platform GUI and close ties to C or C++ (Ruby, Tcl, lua, etc.)

And if you're totally crazy and want to lose your mind, there's also J.

As for the performance-critical aplications, I mainly mean real-time physical simulations. Generally kinds of things that run in a while(true) loop and utilize 100% of processor power. An increase in performance permits a decrease in step size, increasing accuracy. So the faster it runs, the more accurate it is.

For these specs, I would choose C.

btw, If someone tells you C and C++ are obsolete, then they have no idea what they are saying.

Also, I'm getting a little tried cranking out apps in pure Win32 API
and am looking for a good toolkit for C++ to start learning. What would
you recommend? wxWindows, GTK, FLTK? There are also Open Foundation
Classes, but this project is dead as far as I can tell... Or maybe it's
a good idea to write a toolkit for Win32 myself and add to it when
needed?

The last question: I assume that anyway I can't get along without
learning some portable VM language. Which is the best choice: C#.NET,
J#.NET, C++.NET, Java? And is there a less bloated free IDE for .NET
languages than Visual Anything Express?

I would use C#. I don't use C++ .NET because I don't really see any advantages to using it over C#. If I want something that's not native I tend to stick with C#. As for the IDE, there are a lot of free IDE's, and they work well. I like VS2K3. 2K5 is WAY to bloated, but 2K3 still feels decent. I tend to write the gui for most of my apps in C#, and have them call a C DLL for processing intensive parts. It's a combo that seems to work really well.

If you want a high performance, learn OCaml
afterwards, since F# is based on it and it has quite high performance
(But only when used correctly, like everything else). F# is not well-known itself, but for an unpopular language, it has been developed quite well by the Microsoft Research team.

The
obvious alternatives to C# and Java in the "fast, modern language"
category are mostly functional - there are a few (Scala, Nemerle, F#,
etc.) for the major VM platforms, and a few major ones - Haskell and
OCaml, mainly - that allow native development for each platform.

The way to get real performance boosts in computationally intense code
(physics simulations in this case) is to use modern SIMD units (well,
either that or offloading calculations to the GPU). With
good code, carefully crafted datastructures and a vectorizing
compiler (Vector C for instance) you can frequently achieve
improvements of several hundred percents.It's
not a matter of using the language 'correctly', the current generation
of VM jitters just aren't capable of generating such code. Period.

I'm not saying that it necessarily applies to all such applications,
and you should definitely consider multithreading regardless of the
language, but it's often surprisingly effective.

If your wanting to learn the same think a lots of times and be restricted to only running on a M$ system than learn WTL or a .NET based language (i.e C#.NET, J#.NET, C++.NET), but if you looking to learn once use many than use wxWidget (which will work on MAC, Unix and Windows). C/C++ are cross platform languages which means unlike C# will never become outdated.

There is no language faster than C for most general-purpose algorithms.

Actually, due to some obscure expressibility issues with C's array system that limit the possible optimisations, the fastest known (non-assembly) language for most algorithms is Fortran. C takes second place. (In both cases assuming a really good programmer who has hand-optimised the code)

Most people conclude that the pain of using Fortran is not worth the speed advantage. Usually only physics researchers who need horrible multi-dimensional math bother.

Also: out of C#, J#, Managed C++, and Java, only Java is "portable." The rest aren't even close.

Java isn't close either. You can count the number of platforms it is portable to on your fingers - and most java code only runs on Windows and i*86-pc-linux-gnu. (The rest usually only run on Windows - it's not easy to write portable code in any of the .NET languages)

The way to get real performance boosts in computationally intense code
(physics simulations in this case) is to use modern SIMD units (well,
either that or offloading calculations to the GPU).

It would be really nice if this were true, but physics simulations frequently need double precision, which is not currently feasible on GPU chips (it's possible but doesn't work very well) and fairly limited on current SIMD units (you'll get a factor of 2 advantage, maybe). These devices are primarily aimed at single precision work, for games. Very little practical research work can make use of them effectively.

Currently, the way to get real performance boosts in code like physics simulations is to use lots and lots of CPUs, which typically means MPI, targeting C, C++, Fortran, or MATLAB. Threading is a toy when compared to MPI.

The way to get real performance boosts in computationally intense code
(physics simulations in this case) is to use modern SIMD units (well,
either that or offloading calculations to the GPU).

It would be really nice if this were true, but physics simulations frequently need double precision, which is not currently feasible on GPU chips (it's possible but doesn't work very well) and fairly limited on current SIMD units (you'll get a factor of 2 advantage, maybe). These devices are primarily aimed at single precision work, for games. Very little practical research work can make use of them effectively.

Currently, the way to get real performance boosts in code like physics simulations is to use lots and lots of CPUs, which typically means MPI, targeting C, C++, Fortran, or MATLAB. Threading is a toy when compared to MPI.

Heh, I just automatically of assumed physics simulations meant physics engines for games. I guess that shows what my interests are

Also: out of C#, J#, Managed C++, and Java, only Java is "portable." The rest aren't even close.

Java isn't close either. You can count the number of platforms it is portable to on your fingers - and most java code only runs on Windows and i*86-pc-linux-gnu. (The rest usually only run on Windows - it's not easy to write portable code in any of the .NET languages)

That's why "portable" was in quotes. I understand that it's not particularly easy to get Java running on platforms not explicitly supported by Sun, or those without significant JVM projects. You have to admit, however, that Windows, most Linux distros, OS X, Solaris, FreeBSD, and a handfull of others makes for many times the count of systems that .NET CLR languages will run on. Portability is relative. Java is relatively portable compared to C#. Mono is not a viable option either.

As for SIMD: I think that it's a good field to look into, but before that I'll have to get more familiar with assembly programming. My knowledge in this field is pretty basic at the moment. Actually, the physical simulations I'm talking about are more similar to games than research software, as almost all of them include some kind of interactivity. Therefore, single precision computation is not a major drawback.

There were some comments about multithreading. Can it bring substantial benefits on a single processor machine?

I heard the "C is outdated" idea when someone said that it is no more taught as a first "real" programming language (i.e. excluding Logo or primitive dialects of Pascal). Obviously I have misinterpreted this a bit.

obviously threading brings huge advantages to single threaded systems. Say you have a picture editing program and you want to turn the picture sideways with a button. With single threading the entire program will hang (with the button in the down position so it's really obvious) while the single thread manipulates the image. With threading you spawn a worker thread to do the work and then send the parent back to manage the GUI. that way you can look through the menus while your waiting for the picture to turn and not sit there with a non-responsive program.

As for SIMD: I think that it's a good field to look into, but before that I'll have to get more familiar with assembly programming. My knowledge in this field is pretty basic at the moment. Actually, the physical simulations I'm talking about are more similar to games than research software, as almost all of them include some kind of interactivity. Therefore, single precision computation is not a major drawback.

Don't be too sacred of the SIMD instructions. Download Intel's interactive SSE tutorial and play around a bit with compiler intrinsics in MSVC or Intel's own C compiler. They're a lot easier than you might think to work with, not at all like x86 assembly in general.

If you want your program to do 2 things at once, then threads are the best way to go.

I have quite the opposite opinion. Threading should be a last resort when you really need the performance benefits or, for instance, want to guarantee UI responsiveness (keep in mind that threading itself isn't a solution, you have to avoid locks as well). In most situations you can use non-blocking I/O, coroutines or simply restructure your code instead.Thread synchronization is simply to complex and bug-prone to use other than at great need or when the communication between threads is minimal.

With single threading the entire program will hang (with the button in the down position so it's really obvious) while the single thread manipulates the image.

You mean just like most image editors do? Consider that allowing the application's UI to remain responsive during the operation also requires a system of queueing commands and inter-thread communications.

With single threading the entire program will hang (with the button in the down position so it's really obvious) while the single thread manipulates the image.

You mean just like most image editors do? Consider that allowing the application's UI to remain responsive during the operation also requires a system of queueing commands and inter-thread communications.

It's really not that difficult to do. Most GUIs are event driven, and it's "standard procedure" to put intensive work in a second thread, with an event to call when the work is done. They are just being lazy

Also, Qt is another good toolkit to use that is (mostly) platform independent. It has an open source license that you can use if you don't plan on selling your software. If you do, then the cost of a license for it might not be worth it. It is a little bloated, but it depends on how optimized you need the interface to be.

How about Adobe Flash Player? Don't laugh. It's already deployed on most computers and takes only a few minutes to deploy. It is available for most platforms. It's a powerful GUI. Casual web-surfers use it willingly.

Also, Qt is another good toolkit to use that is (mostly) platform independent. It has an open source license that you can use if you don't plan on selling your software. If you do, then the cost of a license for it might not be worth it. It is a little bloated, but it depends on how optimized you need the interface to be.

I agree. Coming from a Visual Studio background, using KDevelop and QT was a VERY easy transition. I found working with Qt to be very easy, and never noticed any bloat. I think that it's really a very good way to introduce windows programmers to a linux (or even *nix) GUI programming environment. I had almost no difficulty figuring out how to do things. It even has a designer, although there is an extra step added between design and coding (For example, when creating a form, the designer doesn't generate skeleton functions for your class that implements the form class, you have to add them yourself, or copy and paste from the build process. Definitely not hard, but something that someone who has never it before would never know). If I was going to produce a cross platform product, I would probably choose to use Qt.

It even has a designer, although there is an extra step added between design and coding (For example, when creating a form, the designer doesn't generate skeleton functions for your class that implements the form class, you have to add them yourself, or copy and paste from the build process. Definitely not hard, but something that someone who has never it before would never know). If I was going to produce a cross platform product, I would probably choose to use Qt.

I attempted to use their designer at first, but I didn't really like it. It can definitely do what you want it to do if you are careful to use proper layouts (which they don't enforce in the designer), which results in many resizing issues. I'm more of the "old school" non-UI programmer, so I like to do it by hand.

Qt also has Visual Studio integration, including their designer, so you can stay in VS completely if you so desire.

obviously threading brings huge advantages to single threaded systems. Say you have a picture editing program and you want to turn the picture sideways with a button. With single threading the entire program will hang (with the button in the down position so it's really obvious) while the single thread manipulates the image. With threading you spawn a worker thread to do the work and then send the parent back to manage the GUI. that way you can look through the menus while your waiting for the picture to turn and not sit there with a non-responsive program.

I was thinking more about performance benefits. In my recent program, the architecture is roughly as follows: the program is divided into two worker threads. One is computing the simulation. The second wakes up every 20 milliseconds and draws the results of the simulation on the screen. The simulation thread has a message queue implemented using the standard Win32 PeekMessage function. The simulation thread looks at the queue every 20 or so simulation cycles and then processes the appropriate messages sent by the window procedures. The drawing thread doesn't have any message queue, as it doesn't need anything more than read access to the simulation data. In such a setup, I think the are several benefits. First, the simulation and presentation code are neatly separated (although they are not completely independent). Second, the refresh rate of the display is not affected by the speed of the computation (and this is important, since many parameters are customizable).

However, there is some context switching overhead and I was primarily concerned about that. However, come to think of it, they happen at about the same intervals regardless of whether I have one or 10 threads in my app, because there are 100's of them running in background.

Thread synchronization is simply to complex and bug-prone to use other than at great need or when the communication between threads is minimal.

Actually, no. Everyone should learn how to do thread synchronization, and all the code you write should be thread-safe (and exception-safe).

You can't write any code for a web server without dealing with threading -- unless your user is willing to wait until all the bits are pumped out through the previous user's dial-up line before the server starts working on the next user's request.

Thread synchronization is simply to complex and bug-prone to use other than at great need or when the communication between threads is minimal.

Actually, no. Everyone should learn how to do thread synchronization, and all the code you write should be thread-safe (and exception-safe).

You can't write any code for a web server without dealing with threading -- unless your user is willing to wait until all the bits are pumped out through the previous user's dial-up line before the server starts working on the next user's request.

Threads on a webserver only have to synchronize when accessing shared resources, e.g. database connections. This is quite easy to do.

What doynax was talking about are multithreaded GUI programs, where the GUI thread and the worker thread(s) have to synchronize. It should be obvious that this is much more sophisticated.

I find GUI - workers synchronization quite easy, esp. in Win32, where you don't have to constantly poll for input, but instead write a window procedure that handles all the input when it is detected by the system. All you have to do is set up thread message queues and invent a simple interface between the threads and the procedure, and put calls to SwitchToThread() in some non-critical places in the workers to make sure they don't lock the GUI. However, the overall complexity would vary depending on what the program would have to do.