The Mono team should be working hand-in-hand with the Wine team if they truly want to make cross platform apps a reality, anything less is just a half-hearted attempt to benefit Microsoft's technology.
Agreed. And you have to remember that WinForms (the Windows-look-alike GUI part of
Maybe the
The Mono team has no plans to support launching any type of binaries other than Mono and
I am on the side that finds Mono a waste of effort based upon the way it has gone.
1. Algorithmic improvements will always trump optimizing execution speed.
And what are these magical algorithms that only work in Java and C# but don't work in C/C++?
2. Unless there is a hard requirement, development time is more important than raw performance.
I fail to see how Java and C# reduce development time.
3. Hardware is cheaper than developers.
You have clearly never done any embedded work. You think a customer is going to want to pay the extra money for a device that runs Java instead of one that does the same thing and runs on a $1 micro running C/C++? Furthermore if you seel 100,000 pieces, every $1 of hardware is $100,000.
4. A rich and flexible library is more useful and stable than custom coding for performance.
Depends on the application. Write a CAD tool in Java and see if customers don't mind it when their compilations take an extra hour to finish
My point exactly. And another thing, as expressed in your last point, time is expensive! What is more important? Getting software out the door faster that sucks? Or getting your designs ready (on time, on schedule) with a native app that will not rely upon the (buggy) Java VM or
So it is a money issue. That is the saddest part. We are going to have lesser performing applications all because software companies want to pay less to developers.
I would rather pay $100 more for a sleek native program vs a Java one.
I used Mono pretty recently and was completely disappointed by lack of features in comparison to
At the same time, Wine needs
Okay, so you can code less with C# and possibly Java. So what! Your code is still going to run slower than C code. I know about Paint.NET; seems to be just an example application supporting the usage of
I'll agree with you that C++ sucks. OpenMP is looking good though. Right now I use pthreads-w32 for Windows and POSIX threads elsewhere (Linux, BSD, OS X).
It is true that programming for platforms is sort of an issue with a bunch of #idefs but I find #ifdefs to be a lot better than starting from scratch.
With something like Qt (speaking of the GUI toolkit and ONLY that), you will have very few #ifdefs in my opinion because MOST of the code is completely cross-platform.
Agreed. The Qt API is RIDICULOUSLY easy to use, especially in comparison to Win32 API and even GTK+ and wxWidgets.
Death to Mono!
Next question?
de Icaza can go to Hell along with his bosses at Microsoft.
Agree. de Icaza is a Microsoft-paid Microsoft technology-supporting money man.
But you go work for Microsoft today as a 'Linux enthusiast' and you will be lying to death tomorrow with all that money you got.
Where do you want to go today?
s/using Java or Qt/using Java over Qt/g
Lucky for Windows users, Windows will always search the current directory first for DLLs that an app needs. So just include them. QtCore4.dll and a few others. Many apps ship their own version of Microsoft's DLLs just to make sure the app will call the correct version without worrying about a newer version being in system32 or the wrong version being called from WinSxS.
No, there is no case for using Java or Qt now. Qt looks sleek on every OS and is SO incredibly easy to program. It is native and is very fast.
GTK+ is in a NSIS package and runs with
Yeah, because you can compile standard C and standard C++ on just about EVERY platform. Unfortunately the phone OS makers do not want us to make native code and instead want us to program Java apps. With that we will never be able to trash the idea that phone apps are slow and pseudo-3D.
Learn and master C, as above is saying! Seriously, I try hard as possible to stay away from
The worse argument I have seen is that when we have computers that are faster in the future, the speed will not be a problem.
I will always prefer to program in C (or C++) and have the program be native. I am very supportive of the GCJ project, which turns Java source into native. Soon Swing will be implemented, making the case for using bytecode INCREDIBLY impossible to justify. Mono should do this with C# and the like. I do not even see why Microsoft did not do this anyway. All it involves is making new libraries. What is the difference in making C# native as making MFC API native back in 96? Instead we get more bloat. How does this make any sense?
I have much better things to do than wait for Java AND your app to initialise. Furthermore, I have better things to do than wait for Java AND your app to de-initialise at exit. Same goes for
Or you could just do what we do here. We have some old software and hardware that worked on Windows 95. So we keep a couple boxes running with Windows 95. Problem solved. It's ONLY used for that using a piece of hardware, so it's really not an issue as far as management goes. They aren't even hooked up to the network.
The only slight issue I have with maintaining old hardware is power usage. Old hardware almost always means inefficient power usage in comparison to today's machines. Beyond that, you have the problem of 'imminent' death. The machine could die any moment and you know it is far closer than your newer machines.
First of all, why would you go Freenode asking to download non-free software? Second, there is something called Google. Even Google has a torrent indexer.
Beware of Programmers who carry screwdrivers. -- Leonard Brandwein
