|
Hehe, C# ahead with one vote !!
|
|
|
|
|
And here I was thinking I was being outrageously funny...
cheers,
Chris Maunder
|
|
|
|
|
Yes, Perl can be ugly, it is not as glamarous as many other languages... but for a general purpose scripting language (for Windows or any other OS), it is the way to go.
We don't distribute any Perl apps, but we do use them in-house quite frequently.
It sure beats programming with batch files.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
|
I know its not cool but SQL is at the top of the employers most wanted list
|
|
|
|
|
More generally spoken, they want profound Database knowledge.
And no one seems to care for .NET here. But maybe that is because I am into scientific computing, not 'lifestyle'-computing.
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
It's just a file format with a lot of hype;)
|
|
|
|
|
Anonymous wrote:
It's just a file format with a lot of hype
Just like C#!
The magic to 'sharp'en C++ is in the CLR - not in the language.
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
You're right, although it is a format that is quite flexible and useful, so I marked it anyway.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
That would make XML very interesting.
|
|
|
|
|
That is not completely correct. Since they lumped pretty much anything that uses XML under that umbrella, that includes WSH, which is a scripting language (well, actually a set of scripting languages).
If you want to get down to it, what is the difference between an XML file and a C++ source file? They are both text files that follow a certain syntax.
"If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week"
|
|
|
|
|
The overall technology is pretty interesting though, even if some of the implementation borders on the silly.
|
|
|
|
|
It may be a file format alright...but hype? I think there is solid use in XML.
|
|
|
|
|
In Microsoft's opinion the future is in managed code, in whatever flavor your prefer. Here's a quote from the Longhorn FAQ at WinSuperSite[^]:
Q: So what's changing from a developer's standpoint?
A: In the technology generations leading up to Longhorn, Microsoft has been moving to a .NET-based managed code environment, and the Longhorn generation will finally mark a clean split with the Win32 APIs of the past. That is, Win32 will be in maintenance mode, and all new development will occur with managed .NET APIs.
|
|
|
|
|
If you look at the free text comments you will see many people have a different opinion than MS about "managed code"
|
|
|
|
|
I guess it all comes down to what platform(s) you want to write code for.
If you're part of the crowd that likes to make your money from developing for Windows, the writing certainly seems to be on the proverbial wall, and the decision seems to have been made for you already.
Time will tell of course, and if the direction were to change it wouldn't be the first backflip we've seen
|
|
|
|
|
Furty wrote:
If you're part of the crowd that likes to make your money from developing for Windows, the writing certainly seems to be on the proverbial wall, and the decision seems to have been made for you already.
Assuming Longhorn ever ships...
Yes, it does seem like managed code will be essential for Longhorn and future OSes... but right now, 100% of the customer base is *not* running Longhorn, since it isn't out yet.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
Are you saying that only c# and c++ with "managed code" will work on Longhorn? Surely you must be joking?
|
|
|
|
|
"...c++ with "managed code" will work on Longhorn.."
Native C/C++ application of course will still execute on Longhorn, BUT there will be no more improvement on native C/C++ (MFC/ATL/WTL/SDK) a foreseen fact. Future VC++ become a 100% .net dependent language... , shame on MS!!
I wonder how qt or cyg gonna handle this one?
|
|
|
|
|
Well, it seems like if you want access to the OS API at all, you'll need to use managed code.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
so a company with a 1 million line application has to rewrite it in a new language just so it can run on the next version of windows?
|
|
|
|
|
Of course not! But you can put the hard earn C/C++ knowledge aside and start "manage" by .nut, native C/C++ become something "exclusive" to Microsoft...that's right, they do whatever they want, but you do EXACTLY who they ask you to!
Who knows one day .nut application must have "MS-INTEL superior security chip" to run?
Dam! Lucky I have Linux with me...;P
|
|
|
|
|
Sorry, I didn't read the post by TW before I posted:
"Native C/C++ application of course will still execute on Longhorn, BUT there will be no more improvement on native C/C++ (MFC/ATL/WTL/SDK) a foreseen fact. Future VC++ become a 100% .net dependent language..., shame on MS!!"
...of course there has been no real improvement of MFC since VC 4.0, so that doesn't make any difference. Also, most companies have to support all versions of Windows, not just the latest, therefore they won't be able to take advantage of the latest SDK features anyway. What will happen is if a company wants some of the latest features in Longhorn they will just find a way of implementing them in c++
|
|
|
|
|
Sorry, I should have read the post by TW before I posted:
"Native C/C++ application of course will still execute on Longhorn, BUT there will be no more improvement on native C/C++ (MFC/ATL/WTL/SDK) a foreseen fact. Future VC++ become a 100% .net dependent language..., shame on MS!!"
...of course there has been no real improvement of MFC since VC 4.0, so that doesn't make any difference. Also, most companies have to support all versions of Windows, not just the latest, therefore they won't be able to take advantage of the latest SDK features anyway. What will happen is if a company wants some of the latest features in Longhorn they will just find a way of implementing them in c++
|
|
|
|
|
If they want to take advantage of new features in Longhorn, then yes. Although it is possible to mix managed and unmanaged code, so I bet that in most cases, code will be mostly C++, with some hooks into managed C++ whenever necessary.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|