Desktop / Web Jobs
-
I know there has been a lot of discution about this subject but anyway i’ll ask. Do you think that right now there is the same amount or need of MFC/Desktop based development than before (say 3 years ago?) and that .Net/Web based development just adds for more jobs instead of subtracting the old ones.? Sorry for bring this overly talked subject; it’s the fear of extinction. :~ "I don't want to achieve immortality through my work... I want to achieve it through not dying." Woody Allen
-
I know there has been a lot of discution about this subject but anyway i’ll ask. Do you think that right now there is the same amount or need of MFC/Desktop based development than before (say 3 years ago?) and that .Net/Web based development just adds for more jobs instead of subtracting the old ones.? Sorry for bring this overly talked subject; it’s the fear of extinction. :~ "I don't want to achieve immortality through my work... I want to achieve it through not dying." Woody Allen
While there is still a market for desktop applications (and probably will be for many years), a large number of companies are opening up a new world of "web applications". And there are many reasons. This is causing a large demand for qualified web application developers. I would expect this growth to only continue while desktop applciations as we know, will decline or move to freeware. Rocky <>< www.HintsAndTips.com www.MyQuickPoll.com - 2004 Election poll is #33 www.GotTheAnswerToSpam.com "We plan for the future, we learn from the past, we live life in the present!"
-
I know there has been a lot of discution about this subject but anyway i’ll ask. Do you think that right now there is the same amount or need of MFC/Desktop based development than before (say 3 years ago?) and that .Net/Web based development just adds for more jobs instead of subtracting the old ones.? Sorry for bring this overly talked subject; it’s the fear of extinction. :~ "I don't want to achieve immortality through my work... I want to achieve it through not dying." Woody Allen
Based on my experience (see thread below about Act) with desktop apps that have been moved to .NET "just because", I hope that business soon begin to realize that .NET rocks for the web and sucks for the desktop. Fly your MFC flag high! :-D Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
-
Based on my experience (see thread below about Act) with desktop apps that have been moved to .NET "just because", I hope that business soon begin to realize that .NET rocks for the web and sucks for the desktop. Fly your MFC flag high! :-D Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
Don't you think it's a bit hasty to judge all .NET client apps based on your one experience with Act CMS? Hell I've run into many many sucky bloated MFC apps (maybe the reason why WTL has become so popular despite MS not supporting it) but that doesn't mean MFC is inherently bloated or slow. Granted, we'll probably see more bloated .NET apps than MFC apps in the future simply because the framework allows developers to do so many things without thinking about the consequences (boxing/unboxing, fire and forget callbacks, ...) But that doesn't mean all client .NET apps are slow; developers simply must be careful to write efficient code, just as it has been with MFC. Judah Himango
-
Don't you think it's a bit hasty to judge all .NET client apps based on your one experience with Act CMS? Hell I've run into many many sucky bloated MFC apps (maybe the reason why WTL has become so popular despite MS not supporting it) but that doesn't mean MFC is inherently bloated or slow. Granted, we'll probably see more bloated .NET apps than MFC apps in the future simply because the framework allows developers to do so many things without thinking about the consequences (boxing/unboxing, fire and forget callbacks, ...) But that doesn't mean all client .NET apps are slow; developers simply must be careful to write efficient code, just as it has been with MFC. Judah Himango
Judah Himango wrote: Don't you think it's a bit hasty to judge all .NET client apps based on your one experience with Act CMS? Well, yes and no. Kinda reminds me of the early days of VB. The .NET stuff is interpreted code and geared towards productivity over performance. Programming skills being equal on both sides, I doubt seriously that a .NET app will ever perform as well as a C++ one. True, that doesn't matter to the manager concerned with time to market, but it sure does to the customer using the app. I think .NET is the absolute cat's meow for web stuff, but I'm just not convinced there's any practical real world benefit (other than resume enhancement) for using it in a desktop app. That is, until MS releases Longhorn and declares all C++ programmers to be renegade criminals (er, that's "Unmanaged" in .NET parlance) to be assimilated or wiped out. And when that day comes, in the immortal words of Captain Jack Sparrow, it's, "Drink up, me hearties, yo ho..." :-D Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
-
Judah Himango wrote: Don't you think it's a bit hasty to judge all .NET client apps based on your one experience with Act CMS? Well, yes and no. Kinda reminds me of the early days of VB. The .NET stuff is interpreted code and geared towards productivity over performance. Programming skills being equal on both sides, I doubt seriously that a .NET app will ever perform as well as a C++ one. True, that doesn't matter to the manager concerned with time to market, but it sure does to the customer using the app. I think .NET is the absolute cat's meow for web stuff, but I'm just not convinced there's any practical real world benefit (other than resume enhancement) for using it in a desktop app. That is, until MS releases Longhorn and declares all C++ programmers to be renegade criminals (er, that's "Unmanaged" in .NET parlance) to be assimilated or wiped out. And when that day comes, in the immortal words of Captain Jack Sparrow, it's, "Drink up, me hearties, yo ho..." :-D Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
i agree with christopher, for me .Net is pretty similar tu VB6 in terms of programming productivity. That is, until MS releases Longhorn and declares all C++ programmers to be renegade criminals (er, that's "Unmanaged" in .NET parlance) to be assimilated or wiped out. The thing that scarme the most is the fact that MS may force developer to move to .Net just because they may not keep supporting MFC/C++. Don't get me wrong, i really like .Net but for me is 50% hype/maketing and 50% good technology "I don't want to achieve immortality through my work... I want to achieve it through not dying." Woody Allen
-
I know there has been a lot of discution about this subject but anyway i’ll ask. Do you think that right now there is the same amount or need of MFC/Desktop based development than before (say 3 years ago?) and that .Net/Web based development just adds for more jobs instead of subtracting the old ones.? Sorry for bring this overly talked subject; it’s the fear of extinction. :~ "I don't want to achieve immortality through my work... I want to achieve it through not dying." Woody Allen
I think there will always be a need for desktop applications, for example, I'm working on electronic jukebox software at the moment. What reason is there for that to be a web based app ? Christian I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
-
Judah Himango wrote: Don't you think it's a bit hasty to judge all .NET client apps based on your one experience with Act CMS? Well, yes and no. Kinda reminds me of the early days of VB. The .NET stuff is interpreted code and geared towards productivity over performance. Programming skills being equal on both sides, I doubt seriously that a .NET app will ever perform as well as a C++ one. True, that doesn't matter to the manager concerned with time to market, but it sure does to the customer using the app. I think .NET is the absolute cat's meow for web stuff, but I'm just not convinced there's any practical real world benefit (other than resume enhancement) for using it in a desktop app. That is, until MS releases Longhorn and declares all C++ programmers to be renegade criminals (er, that's "Unmanaged" in .NET parlance) to be assimilated or wiped out. And when that day comes, in the immortal words of Captain Jack Sparrow, it's, "Drink up, me hearties, yo ho..." :-D Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
Forgive the fact that I can't format my messages completely correctly here, Firefox doesn't rend CP all that well... The .NET stuff is interpreted code That's not the case, believe it or not, .NET was built from the beginning to be "just-in-time compiled" to native, it's never interpreted, unlike Java which is often a mix of interpreted code and hot spot just-in-time compilation. .NET apps should be and usually are JIT'ed at install time, which basically makes a native machine code image of the executable tailored to your particular hardware setup. The cross platform open source Mono implementation of the CLI spec also supports ahead-of-time compilation to native as an alternative or a complement of just-in-time to native compiling. That said, you are 100% dead on that .NET is geared for simplicity over performance. Given the increasing capabilities of hardware these days, the mess of VB6 and the complexity of using Win32, direct COM, MFC, ATL, et al, **I** personally prefer love, desire, delve into with wide open arms, refreshed by, can't get enough of, C# and .NET. :-) But... I can understand why the older die hard C guys choose otherwise, don't like the 'neutered' feel of .NET and miss the fine-grained low level control of C++. Judah Himango
-
I think there will always be a need for desktop applications, for example, I'm working on electronic jukebox software at the moment. What reason is there for that to be a web based app ? Christian I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
Christian Graus wrote: What reason is there for that to be a web based app ? Order systems, man, order systems. It works like this. A customer orders a CD from a web site. It then makes a call to the web based electronic jukebox app, which in turn talks to the physical jukebox on the server, instructing it to hurl the CD 4 states over to my exact address. Much, much cheaper than Airmail or FedEx, don't you think? :-D Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
-
Christian Graus wrote: What reason is there for that to be a web based app ? Order systems, man, order systems. It works like this. A customer orders a CD from a web site. It then makes a call to the web based electronic jukebox app, which in turn talks to the physical jukebox on the server, instructing it to hurl the CD 4 states over to my exact address. Much, much cheaper than Airmail or FedEx, don't you think? :-D Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
Well, I think the idea is that you go to a pub and pay a dollar per track every time you want to hear the song. But I'll mention it to the client.... :P Christian I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
-
I know there has been a lot of discution about this subject but anyway i’ll ask. Do you think that right now there is the same amount or need of MFC/Desktop based development than before (say 3 years ago?) and that .Net/Web based development just adds for more jobs instead of subtracting the old ones.? Sorry for bring this overly talked subject; it’s the fear of extinction. :~ "I don't want to achieve immortality through my work... I want to achieve it through not dying." Woody Allen
There will almost certainly be a market for both. However, whether desktop apps remain MFC-based is unknown. It seems that, for better or for worse, MFC doesn't seem to be under active development anymore. So the options for desktop development are... - MFC : although it probably won't get many enhancements in the future, there is still a huge codebase out there, and site like this to help you out. - Java : As much as many people here despise it, it is still an important platform. Take a look at Eclipse, finally Java apps have a GUI toolkit that doesn't suck. - Other renegade libraries, like wxWindows, QT, etc., have their niche as well. At least wxWindows is being actively developed (and there is even talk of wxWindows.net??!) - And of course, .NET on the desktop. Probably will see a lot more of this in the future, after Longhorn, .NET 2.0, etc., are all out and relatively widespread But in short, desktop apps will probably always be big, at least until everyone has 100% reliable, high-speed internet connections (e.g., never. :) ) What platform is used to make those desktop apps may not always be MFC though. Just my two cents. :) An expert is somebody who learns more and more about less and less, until he knows absolutely everything about nothing.
-
Forgive the fact that I can't format my messages completely correctly here, Firefox doesn't rend CP all that well... The .NET stuff is interpreted code That's not the case, believe it or not, .NET was built from the beginning to be "just-in-time compiled" to native, it's never interpreted, unlike Java which is often a mix of interpreted code and hot spot just-in-time compilation. .NET apps should be and usually are JIT'ed at install time, which basically makes a native machine code image of the executable tailored to your particular hardware setup. The cross platform open source Mono implementation of the CLI spec also supports ahead-of-time compilation to native as an alternative or a complement of just-in-time to native compiling. That said, you are 100% dead on that .NET is geared for simplicity over performance. Given the increasing capabilities of hardware these days, the mess of VB6 and the complexity of using Win32, direct COM, MFC, ATL, et al, **I** personally prefer love, desire, delve into with wide open arms, refreshed by, can't get enough of, C# and .NET. :-) But... I can understand why the older die hard C guys choose otherwise, don't like the 'neutered' feel of .NET and miss the fine-grained low level control of C++. Judah Himango
Without a doubt, I'm a control freak and generally try to avoid being neutered whenever possible! :) However, for a moment forget how fun it is to code in .NET and think like a user. If the app is slow and sluggish in response, you're most likely going to look for another app to use. .NET is great on web sites because in comparison to desktop apps, web sites are already slow (due to bandwidth issues). For desktop apps, however, a faster native language is more suitable. The right tool for the right job, so to speak. Judah Himango wrote: That's not the case, believe it or not, .NET was built from the beginning to be "just-in-time compiled" to native, it's never interpreted I'm not a serious .NET guy so I could be a little off the mark here, but my understanding is that C#, VB and other managed languages are all compiled down to MSIL (MISL?), not low level CPU dependant executable code - that's what makes the cross language compatibility and "managing" work. MISL (which is editable, is it not?) is then executed by the .NET runtime. MSIL is, effectively, p-code, hence my statement that .NET stuff is interpreted. If it were truly native code that was generated, your users wouldn't have to install the .NET runtime before they could run the app. I don't think you can "staticly link" a .NET app to the framework. Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
-
Well, I think the idea is that you go to a pub and pay a dollar per track every time you want to hear the song. But I'll mention it to the client.... :P Christian I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
:laugh: Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
-
i agree with christopher, for me .Net is pretty similar tu VB6 in terms of programming productivity. That is, until MS releases Longhorn and declares all C++ programmers to be renegade criminals (er, that's "Unmanaged" in .NET parlance) to be assimilated or wiped out. The thing that scarme the most is the fact that MS may force developer to move to .Net just because they may not keep supporting MFC/C++. Don't get me wrong, i really like .Net but for me is 50% hype/maketing and 50% good technology "I don't want to achieve immortality through my work... I want to achieve it through not dying." Woody Allen
Andrey Del Pozo wrote: The thing that scarme the most is the fact that MS may force developer to move to .Net just because they may not keep supporting MFC/C++. I don't think you really need to worry about that right now. I can't speak specifically for MFC however C++ isn't going to be disappearing; even the plumbing for Indigo interacts with unmanaged code. - Nick Parker
My Blog | My Articles -
Without a doubt, I'm a control freak and generally try to avoid being neutered whenever possible! :) However, for a moment forget how fun it is to code in .NET and think like a user. If the app is slow and sluggish in response, you're most likely going to look for another app to use. .NET is great on web sites because in comparison to desktop apps, web sites are already slow (due to bandwidth issues). For desktop apps, however, a faster native language is more suitable. The right tool for the right job, so to speak. Judah Himango wrote: That's not the case, believe it or not, .NET was built from the beginning to be "just-in-time compiled" to native, it's never interpreted I'm not a serious .NET guy so I could be a little off the mark here, but my understanding is that C#, VB and other managed languages are all compiled down to MSIL (MISL?), not low level CPU dependant executable code - that's what makes the cross language compatibility and "managing" work. MISL (which is editable, is it not?) is then executed by the .NET runtime. MSIL is, effectively, p-code, hence my statement that .NET stuff is interpreted. If it were truly native code that was generated, your users wouldn't have to install the .NET runtime before they could run the app. I don't think you can "staticly link" a .NET app to the framework. Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
The code compiler, Visual Studio for instance, compiles .NET code (C#, VB.NET, etc) down to ECMA Common Intermediate Language, which MS of course slaps their name and calls MSIL. From there, the first time you run a .NET executable, the .NET runtime "just-in-time" compiles the MSIL to machine code, and performs optimizations specific to your hardware and proecessor architecture. So for my 32 bit Windows XP machine, it will just-in-time compile down to good old CPU machine langauge instructions (in this case, x86-specific instructions). Now, the process of JIT'ting an executable is what is slower. MS knows this, that's why instead of JIT'ing the entire MSIL the first time you run the executable, it instead JIT's the MSIL on a per-method basis. That is why it's proven the first time you run a .NET app, it's slower than successive runnings of the app. Any NGEN'd parts are cached on the system by the runtime for later use, meaning once MyMethod is generated to native, the next time you run the app it won't have to just-in-time compile it to native, it will already be in native code. Now, some people don't want this JIT to occur when the user is running it since it does slow things down. MS thought of that too - which is why they included the ngen.exe utility with the .NET SDK. Basically it will (endeavor to) take your app which is in MSIL, and generate a native executable (machine language instructions) and cache the native image on your machine. Whenver you go to execute my .NET MSIL app, the runtime will use the native image provided the versions are the same. So to stress, .NET code never gets interpreted. It may have to be just-in-time compiled to native CPU-specific instructions if the developers didn't NGEN it at install time, but in any case it will be native code when you're actually running it. I agree that bloated, sluggish code is a turn off for users. If that is all .NET could produce, I'd go back to my ATL and MFC. Fortunately, .NET can in fact produce efficient code. You just have to avoid being careless with the power .NET gives to the developer. Judah Himango
-
Without a doubt, I'm a control freak and generally try to avoid being neutered whenever possible! :) However, for a moment forget how fun it is to code in .NET and think like a user. If the app is slow and sluggish in response, you're most likely going to look for another app to use. .NET is great on web sites because in comparison to desktop apps, web sites are already slow (due to bandwidth issues). For desktop apps, however, a faster native language is more suitable. The right tool for the right job, so to speak. Judah Himango wrote: That's not the case, believe it or not, .NET was built from the beginning to be "just-in-time compiled" to native, it's never interpreted I'm not a serious .NET guy so I could be a little off the mark here, but my understanding is that C#, VB and other managed languages are all compiled down to MSIL (MISL?), not low level CPU dependant executable code - that's what makes the cross language compatibility and "managing" work. MISL (which is editable, is it not?) is then executed by the .NET runtime. MSIL is, effectively, p-code, hence my statement that .NET stuff is interpreted. If it were truly native code that was generated, your users wouldn't have to install the .NET runtime before they could run the app. I don't think you can "staticly link" a .NET app to the framework. Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
.NET is not nearly as slow as you try to make it ;) Sure, it's not as fast as native C++ code I'm not arguing with that. I'm a C++ dev myself, but made this[^] application in .NET. It started out as a "I wanna try this C# stuff" but ended up being a full featured photo management application, written 95% in C# and the last 5% in Managed C++. The application, ShotKeeper as it's called, is actually not that slow, and none of my users have called it sluggish. Don't judge .NET on a single bad app, instead judge the devs who have made it ;) - Anders Money talks, but all mine ever says is "Goodbye!" ShotKeeper, my Photo Album / Organizer Application[^]
My Photos[^] -
The code compiler, Visual Studio for instance, compiles .NET code (C#, VB.NET, etc) down to ECMA Common Intermediate Language, which MS of course slaps their name and calls MSIL. From there, the first time you run a .NET executable, the .NET runtime "just-in-time" compiles the MSIL to machine code, and performs optimizations specific to your hardware and proecessor architecture. So for my 32 bit Windows XP machine, it will just-in-time compile down to good old CPU machine langauge instructions (in this case, x86-specific instructions). Now, the process of JIT'ting an executable is what is slower. MS knows this, that's why instead of JIT'ing the entire MSIL the first time you run the executable, it instead JIT's the MSIL on a per-method basis. That is why it's proven the first time you run a .NET app, it's slower than successive runnings of the app. Any NGEN'd parts are cached on the system by the runtime for later use, meaning once MyMethod is generated to native, the next time you run the app it won't have to just-in-time compile it to native, it will already be in native code. Now, some people don't want this JIT to occur when the user is running it since it does slow things down. MS thought of that too - which is why they included the ngen.exe utility with the .NET SDK. Basically it will (endeavor to) take your app which is in MSIL, and generate a native executable (machine language instructions) and cache the native image on your machine. Whenver you go to execute my .NET MSIL app, the runtime will use the native image provided the versions are the same. So to stress, .NET code never gets interpreted. It may have to be just-in-time compiled to native CPU-specific instructions if the developers didn't NGEN it at install time, but in any case it will be native code when you're actually running it. I agree that bloated, sluggish code is a turn off for users. If that is all .NET could produce, I'd go back to my ATL and MFC. Fortunately, .NET can in fact produce efficient code. You just have to avoid being careless with the power .NET gives to the developer. Judah Himango
Interesting stuff, thanks man. I was under a couple of mistaken impressions it appears. Well, it ain't the first time I've been full of it when it comes to programming! :-D Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
-
.NET is not nearly as slow as you try to make it ;) Sure, it's not as fast as native C++ code I'm not arguing with that. I'm a C++ dev myself, but made this[^] application in .NET. It started out as a "I wanna try this C# stuff" but ended up being a full featured photo management application, written 95% in C# and the last 5% in Managed C++. The application, ShotKeeper as it's called, is actually not that slow, and none of my users have called it sluggish. Don't judge .NET on a single bad app, instead judge the devs who have made it ;) - Anders Money talks, but all mine ever says is "Goodbye!" ShotKeeper, my Photo Album / Organizer Application[^]
My Photos[^]Cool looking stuff, man. Hope it makes you rich (or at least enough to keep yourself in the latest versions of everything)! :) Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
-
Judah Himango wrote: Don't you think it's a bit hasty to judge all .NET client apps based on your one experience with Act CMS? Well, yes and no. Kinda reminds me of the early days of VB. The .NET stuff is interpreted code and geared towards productivity over performance. Programming skills being equal on both sides, I doubt seriously that a .NET app will ever perform as well as a C++ one. True, that doesn't matter to the manager concerned with time to market, but it sure does to the customer using the app. I think .NET is the absolute cat's meow for web stuff, but I'm just not convinced there's any practical real world benefit (other than resume enhancement) for using it in a desktop app. That is, until MS releases Longhorn and declares all C++ programmers to be renegade criminals (er, that's "Unmanaged" in .NET parlance) to be assimilated or wiped out. And when that day comes, in the immortal words of Captain Jack Sparrow, it's, "Drink up, me hearties, yo ho..." :-D Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
Christopher Duncan wrote: in the immortal words of Captain Jack Sparrow, it's, "Drink up, me hearties, yo ho..." Probably the best ending of any movie I've seen. My 2-1/2 year old daughter recites that whole ending every night after brushing her teeth. She's too young for the whole movie but we've watched that last part about a million times. Now, bring me that horizon... Drew.
-
Cool looking stuff, man. Hope it makes you rich (or at least enough to keep yourself in the latest versions of everything)! :) Christopher Duncan Today's Corporate Battle Tactic Unite the Tribes: Ending Turf Wars for Career and Business Success The Career Programmer: Guerilla Tactics for an Imperfect World
Christopher Duncan wrote: Cool looking stuff, man. Hope it makes you rich (or at least enough to keep yourself in the latest versions of everything)! Thanks :) Unfortunately it don't make me rich, but my different shareware apps have always paid for my computers and stuff like VS :) - Anders Money talks, but all mine ever says is "Goodbye!" ShotKeeper, my Photo Album / Organizer Application[^]
My Photos[^]