Desktop / Web Jobs
-
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[^] -
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
Given the increasing capabilities of hardware these days If you sense a certain amount of cynicism amongst some of the "older" guys, or those of us who have seen all this before, keep in mind that for almost 10 years this has been the mantra of the Java folks for desktop apps! Always just add more hardware, a faster CPU, more memory. Well guess what, I have a 1Ghz CPU(and lets say that with just a tad of appreciation for how incredibly fast that is for most of the kind of processing you typically need to due), over 500MB of RAM and large scale Java GUI apps still suck ass in terms of performance to a regular Win32/MFC/ATL/VCF(hint, hint) app. And the Win32 platform is by and large the best platform they (Java apps) run on (don't even mention Solaris or *nix)! basically makes a native machine code image of the executable tailored to your particular hardware setup Ahh but the key phrase is basically. Sure this may be fine for simple little utility apps, or smaller games, or some little db front end you slap together for a business app. However, I suspect, being the utterly cynical, bitter bastard that I am, that this will not scale up. And if the way GCC optimizes things are any bench mark, then the linux version (if you choose to use mono) will be even slower and more bloated than it's Win32 counterpart. If Christopher is reporting problems like these with a (I'm just guessing here) reasonably simple application like a contact management program, how well is it going to do with stuff like word processors, imaging application's ala Photoshop or Illustrator, or large scale, sophisticated development IDE's? Just like VB, it (.Net) will have it's place. But just like VB (and Java for that matter) there are a lot areas where it falls flat on it's face. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
-
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
What development platform and language to use has always been a per project decision in most cases. I see no reason for that to change anytime soon. .NET just supplies more choices not [the answer]. It really is that simple. As times change the number of criteria and considerations for projects increases. There is much more to consider and having more options for platform and language potentially makes that job easier. Attempting to predict what platform and languages will be used in your future projects with any accuracy is somewhat a waste of time. What to learn to add value to your own career in the future is easy, as much as you can! Sometimes your geographic location can play into that decision. If you have no desire to relocate and you can discover what the primary types of projects are in demand in your location that can help you determine what direction to study. Otherwise if your location has a wide variety or you might relocate then all bets are off. Andrey Del Pozo wrote: Desktop / Web Jobs As far as desktop vs. web apps. I don’t think web development will subside substantially. However it is possible that the use of desktop apps for client side internet (client/server) applications could increase in the next few years due to the desire for richer user interfaces than can be supplied in a browser. But, that's just my opinion... I could be wrong.
-pete
-
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.
Drew Stainton wrote: Probably the best ending of any movie I've seen. Absolutely! The entire thing is one continuously fun romp, and the sound track is good enough to listen to in the car without the movie. In an age when it's hip to be dark and dismal, I found it quite rejuvinating. 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