I've never been a big fan of MFC, but that's not really the point. I read that Microsoft is due to release a new version of MFC in 2010 and it really struck me as odd - I thought MFC was dead (no ill intention, I really did).
Is is MFC used for new developments? If so, whats the benefit? I couldn't imagine it having any benefit over something such as C# (or even just c++ using Win32 APIs for that matter).
There is a ton of code out there using MFC. I see these questions all the time is this still used is that still used the answer is yes. I work in a very large organization which still employs hundreds of people who write in cobol. If it has ever been used in the enterprise it will continue to be used until there is no more hardware to support it, then some company will pay someone to write an emulator so that the old code will still work.
The navy still uses ships with computers with magnetic cores for memory and I'm sure they have people to work on them. Technology once created can never not be supported. its a bit of the case of Deus ex machina where large organizations aren't completely sure what their system do and have such an overriding sense of fear of brining the enterprise to its knees they have no desire to try out you new fangled technologies(BTW we pay IBM for best effort support on OS2).
Also mfc is a perfectly acceptable solution for windows development given it is an object model which wraps the System API which is pretty much all that most people get out of .net.
As an addendum and since this question is up for a bounty this is a quote from MS regarding mfc in VS 11
In every release we need to balance our investment across the various areas of the product. However, we still believe that MFC is the most fully-featured library for building native desktop applications. We are fully committed to supporting and maintaining MFC at a high level of quality. Here’s a short list of some of the issues that we fixed in MFC for Visual Studio 11:
Here is the link if you want to read the full post
Coolness does not factor in choosing the technology for a new system. Yes if you are a student or want to play around you choose whatever you want.
But in the real world each technology has advantages and drawbacks. A year ago one of the teams started a new project, it was decided that it will be done in MFC.
The reason is very simple: they have to use windows api a lot for low level operations with the printer, internet explorer and god knows what else.
C# was not even in the game, the decision was made between MFC and QT, both had the needed functionality, both could easily integrate the low level functionality, the only difference was that some team members already had MFC experience, so they didn't have to waste time and money with trainings.
Let's suppose they choose C# and WPF:
-1 You have to wrap all native C++ and ASM code in a DLL (ouch this can be painful, instead of coding you write wrappers).
-1 You probably need two teams now, one for the ui one for the winapi stuff. It is very unlikely that you'll find a lot of people able to write both C# and winapi stuff. Agreed that either way you need someone to make the interface pretty (programmers usually suck at this and they cost more) but at least with C++ only code, there is no more wait time between two teams, need a ui modification, no problem I don't have to wait for the ui designer, he will make it pretty later.
+1 You can write the UI code in C# and WPF, let's say the UI development is faster, but the UI is only 1/4 of the project, so the total gain is probably very small.
-1 Performance degradation: for every small operation you can't do in C# you call a external DLL (this is a minor issue since the program runs on 8GB RAM Quad Cores).
So in conclusion: MFC is still used for new development because the requirements and the costs decide the technology for a project and it just so happens that MFC is the best in some cases.
MFC is still used for some new development, and a lot of maintenance development (including inside of Microsoft).
While it can be minutely slower than using the Win32 API directly, the performance loss really is tiny -- rarely as much as a whole percent. Using .NET, the performance loss is considerably greater (in my testing, rarely less than 10%, with 20-30% being typical, and higher still for heavy computation. Just for example, I have a program that does Eigenvector/Eigenvalue computation on fairly large arrays. My original version using C++ and MFC runs one test case in just under a minute on our standard test machine. Some of my coworkers decided it would be cool to re-implement it in C#. Their version takes almost three minutes on the same machine (quad core, 16-gigs of RAM, so no, not "legacy" hardware). I'll admit I haven't looked at their code too closely, so maybe it could be improved, but they're decent coders so a 3:1 improvement strikes me as unlikely.
With MFC, it's also easy to bypass the framework and use the Win32 API directly when/if you want to. With .NET, you can use P/Invoke for that, but it's quite painful by comparison.
MFC has been updated with every release of Visual Studio. It just isn't the headline feature item.
As for new development, yes. It is still used and will continue to be so (even though I, like you, prefer not to). Many organizations made the technology decision years ago and have no reason to change.
I do think you are talking about well-established shops though, folks with more interest in maintaining / enhancing what has been written rather than stay on the cutting edge.
The release of the MFC Feature Pack (one or two years ago, iirc) was the biggest extension of MFC since around 10 years and it gave quite a new boost to MFC development. I guess a lot of companies decided to maintain their legacy applications, push them forward and delevelop new applications on its basis.
For me (as someone who has to maintain a large MFC application) the bigger problem is the decreasing development and support of (Microsoft and third-party) components rather than MFC itself. For instance is porting to 64bit not easy if a lot of old and unsupported pure 32bit Active-X components are assembled in the application.
I did a project last year based on MFC. I'm not sure why MFC was chosen, but it was adequate for making a virtual 3D graphic user interface—a building management security system—with 10 frame per second refresh rate run efficiently on win32-based PCs dating back to the mid-1990s. The executable (which requires only core win32 system DLLs) is less than 400K—not an easy accomplishment with modern tools.
There are advantages to staying away from managed code (maybe you're writing a driver UI, or doing COM).
That and there's tons of MFC code out there. Maybe you work for Company X, and need to use one of the zillion DLLs they've been writing over the last dozen years.
I can think of one commercial software title that benefits from using MFC over C#: Wwise[1]. C++ is an obvious choice for the sound engine, so it makes sense to write the authoring tool in C++ as well. It's both an authoring tool and a sound engine. They could have built the authoring tool in C#, and the sound engine in C++, but if they're debugging a problem with the sound engine that's reproducible through the wwise authoring tool, it's easier for them to see the whole call stack just like that.
I think there's some ways of doing a mixed call stack nowadays, but maybe that wasn't there when they first made Wwise? In any case, using MFC ensured that they wouldn't need a solution to the problem of mixed call stacks. The call stack just works.
[1]Wwise is built on MFC: https://www.audiokinetic.com/fr/library/edge/?source=SDK&id=plugin_frontend_windows.html
Related
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
in which area is c++ mostly used?
I started off with C in school, went to Java and now I primarily use the P's(Php, Perl, Python) so my exposure to the lower level languages have all but disappeared. I would like to get back into it but I can never justify using C over Perl or Python. What real-world apps are being built with these languages? Any suggestions if I want to dive back in, what can I do with C/C++ that I can't easily do with Perl/Python?
To borrow some text from the answer I had for another related question:
Device drivers in native code.
High performance floating point number crunching (i.e. SIMD).
Easy ability to interface with assembly language routines.
Manage memory manually for extended execution runs.
Most of my work has been C and C++. I studied computer engineering in school and worked with embedded devices. My Master's degree had an emphasis in graphics and visualization. One of our visualization apps was written in Python, but for the most part, graphics demands C/C++ for the speed. I now work with embedded devices running Windows Mobile and Windows CE - all C++, though you can do a lot with C#. I previously worked in simulations, which was all C++ code on the backend. C++ is still king for time-sensitive IO, embedded applications, graphics and simulations.
Basically, if you need tight control of timing, you go lower level. Or if you need light-weight (ie, small program size, small memory footprint)
Somewhat unscientifically I took a look on Sourceforge and the top twenty projects/language break-down is currently thus:
Java(43,199)
C++(34,313)
PHP(28,333)
C(26,711)
C#(12,298)
Python(12,222)
JavaScript(10,307)
Perl(8,931)
Unix Shell(3,618)
Delphi/Kylix(3,353)
Visual Basic(3,044)
Visual Basic .NET(2,513)
Assembly(2,283)
JSP(1,891)
Ruby(1,731)
PL/SQL(1,669)
Objective C(1,424)
ASP.NET(1,344)
Tcl(1,241)
ActionScript(1,164)
Perl + Python together still total less than C alone. I have no idea why Java is so high, I know of no single Java developer and have not seen a single Java project, but I am sure someone is using it! For probably the same reason, you are not seeing much C/C++, you are just not working in a domain where it figures highly. I work in embedded systems where C and C++ are ubiquitous and Python comes nowhere. Different languages are encountered to different extents in different worlds.
You ask what you can do with C/C++ that you cannot do easily with Perl/Python; well the answer is plenty, real-time embedded systems for one; but if that is not what you want/need to do, then there is no reason to. On the other hand I might ask the reverse; I'd use C++ for things you might use Python for, simply because for me it would be easier and quicker (than learning a new language and getting the tools working)
C/C++ can be, and is, used for nearly all "types" of programs.
There are some major advantages to C and C++:
Potentially better performance
Easier to build interoperable libraries, especially if working with libraries usable from multiple languages.
well the interpreters for your "P's" languages are most certainly written in c/c++. Most OS code is written in C/C++. On the application side, if you are into games, they are generally written in c/c++. Anything that needs high performance and or low memory is a good candidate.
I've used Gsoap, a c++ soap client implementation for a web service that got HUGE traffic.
Most desktop/console applications with a bias toward graphics rely heavily on C++. This includes CAD software and AAA video games, among other things.
Can anyone give me an example of successful non-programmer, 5GL (not that I am sure what they are!), visual, 0 source code or similar tools that business users or analysts can use to create applications?
I don’t believe there are and I would like to be proven wrong.
At the company that I work at, we have developed in-house MVC that we use to develop web applications. It is basically a reduced state-machine written in XML (à la Spring WebFlow) for controller and a simple template based engine for presentation. Some of the benefits:
dynamic nature: no need to recompile to see the changes
reduced “semantic load”: basically, actions in controller know only “If”. Therefore, it is easy to train someone to develop apps.
The current trend in the company (or at least at management level) is to try to produce tools for the platform that require 0 source code, are visual etc. It has a good effect on clients (or at least at management level) since:
they can be convinced that this way they will need no programmers or at least will be able to hire end-of-the-lather programmers that cost much less than typical programmers.
It appears that there is a reduced risk involved, since the tool limits the implementer or user (just don’t use the word programmer!) in what he can do, so there is a less chance that he can introduce error
It appears to simplify the whole problem since there seems to be no programming involved (notoriously complex). Since applications load dynamically, there is less complexity then typically associated with J2EE lifecycle: compile, package, deploy etc.
I am personally skeptic that something like this can be achieved. Solution we have today has a number of problems:
Implementers write JavaScript code to enrich pages (could be solved by developing widgets). Albeit client-side, still a code that can become very complex and result in some difficult bugs.
There is already a visual tool, but implementers prefer editing XML since it is quicker and easier. For comparison, I guess not many use Eclipse Spring WebFlow plug-in to edit flow XML.
There is a very poor reuse in the solution (based on copy-paste of XML). This hampers productivity and some other aspects, like fostering business knowledge.
There have been numerous performance and other issues based on incorrect use of the tools. No matter how reduced the playfield, there is always space for error.
While the platform is probably more productive than Struts, I doubt it is more productive than today’s RAD web frameworks like RoR or Grails.
Verbosity
Historically, there have been numerous failures in this direction. The idea of programs written by non-programmers is old but AFAIK never successful. At certain level, anything but the power of source code becomes irreplaceable.
Today, there is a lot of talk about DSLs, but not as something that non-programmers should write, more like something they could read.
It seems to me that the direction company is taking in this respect is a dead-end. What do you think?
EDIT: It is worth noting (and that's where some of insipiration is coming from) that many big players are experimenting in that direction. See Microsoft Popfly, Google Sites, iRise, many Mashup solutions etc.
Yes, it's a dead end. The problem is simple: no matter how simple you make the expression of a solution, you still have to analyze and understand the problem to be solved. That's about 80-90% of how (most good) programmers spend their time, and it's the part that takes the real skill and thinking. Yes, once you've decided what to do, there's some skill involved in figuring out how to do that (in a programming language of your choice). In most cases, that's a small part of the problem, and the least open to things like schedule slippage, cost overrun or outright failure.
Most serious problems in software projects occur at a much earlier stage, in the part where you're simply trying to figure out what the system should do, what users must/should/may do which things, what problems the system will (and won't) attempt to solve, and so on. Those are the hard problems, and changing the environment to expressing the solution in some way other that source code will do precisely nothing to help any of those difficult problems.
For a more complete treatise on the subject, you might want to read No Silver Bullet - Essence and Accident in Software Engineering, by Frederick Brooks (Included in the 20th Anniversary Edition of The Mythical Man-Month). The entire paper is about essentially this question: how much of the effort involved in software engineering is essential, and how much is an accidental result of the tools, environments, programming languages, etc., that we use. His conclusion was that no technology was available that gave any reasonable hope of improving productivity by as much as one order of magnitude.
Not to question the decision to use 5GLs, etc, but programming is hard.
John Skeet - Programming is Hard
Coding Horror - Programming is Hard
5GLs have been considered a dead-end for a while now.
I'm thinking of the family of products that include Ms Access, Excel, Clarion for DOS, etc. Where you can make applications with 0 source code and no programmers. Not that they are capable of AI quality operations, but they can make very usable applications.
There will always be "real" languages to do the work, but we can drag and drop the workflow.
I'm using Apple's Automator which allows users to chain together "Actions" exposed by the various applications on their systems.
Actions have inputs and/or outputs, some have UI elements and basic logic can be applied to the chain.
The key difference between automator
and other visual environments is that
the actions use existing application
code and don't require any special
installation.
More Info > http://www.macosxautomation.com/automator/
I've used it to "automate" many batch processes and had really great results (surprises me every time). I've got it running builds and backups and whenever i need to process a mess of text files it comes through.
I would love to know whether iHook or Platypus (osx wrapper builders for shell scripts) could let me develop plugins in python ....
There is definitely room for more applications like this and for more support from OSX application developers but the idea is sound.
Until there's major support there aren't many "actions" available, but a quick check on my system just showed me an extra 30 that i didn't know i had.
PS. There was another app for OS-preX called "Filter Tops" which had a much more limited set of plugins.
How about Dabble DB?
Of course, just like MS Access and other non-programmer programming platforms, it has some necessary limitations in order that the user won't get him or herself stuck... as John pointed out programming is hard. But it does give the user a lot of power, and it seems that most applications that non-programmers want to build are database-type applications anyway.
Just a question that came up from time to time at my old job when we were considering fleshing out our development staff with additional bodies. Does it really matter, if you are a .NET development house, if your developers all code in one language vs another.
I probably started out like alot of the 4million other folks there with Visual Basic way back when, and then migrated to VB.NET. Another developer we had at the time came from a C background and migrated over to C#.NET. Basically he was able to code very quickly in his native language and I was able to do so in mine and since our projects did not really overlap there was no issue until our boss basically said we need to switch to C#... for no other reason than standardization.
So I guess the 'subjective' part of the question is, is it better to sacrifice productivity for consistency? Now I should quantify this in saying we were a SMALL shop, less than 5 developers and given how most of our project plans were done on cocktail napkins its not like we were going for 6-Sigma anytime soon so it was not like 'standards' were a hard and fast rule.
Thanks.
C# is definitely becoming the preferred avenue for Microsoft and it would make sense to choose a language that all developers to use simply based on the fact that if developers move between tasks, having the projects in a uniform language (not to mention coding conventions) will make the maintenance on those projects much easier for everyone involved.
If it helps, I recently wrote an article on my blog looking back at my decision to standardize our development shop on VB.NET over C# and how well my various assumptions have held up and things hindsight has shown me.
Here's a link: "A Manager’s Retrospective on the C# versus VB.NET decision"
As to whether you should standardize the whole shop on one language. I'd say there are definite benefits. The most obvious one is that switching back and forth when you work on different projects is going to incur some mental overhead to re-acclimate yourself each time. Granted, it is going to be less if you have to do it frequently, but to justify the extra complexity there would have to be some offsetting benefit.
Ultimately my advice is to standardize on one or the other based on the following criteria:
(1) If you have a large VB code-base there is a good argument for standardizing on VB.NET.
(2) If everything else is equal, I'd lean towards C# for a number of reasons mentioned in the above article.
(3) Carefully take into account your current team's preferences and the general consensus among developers in your market that you would try to recruit. Language choice is a big deal for morale and hiring.
I think it makes sense to pick one and get everyone on it. The sacrifice in productivity will be brief, competent developers will migrate quickly.
Some advantages:
your last VB developer and the team get downsized...uh oh.
one of the developers quits and you have to take over their code
etc.
I'd say go for whatever works. VB.NET and C# use all the same underlying framework so you should be able to read each others code and with a little googling you should be able to modify it too.
I'd say go for productivity.. ultimately is the customer going to care if it's written in VB.NET or C#?? But saying that you have to think about maintanability.
So I guess the 'subjective' part of
the question is, is it better to
sacrifice productivity for
consistency?
Of course not. What good is consistency, by itself? Ultimately the goal of consistency is productivity. With that in mind, I would suggest that, long term, having everyone code in one language would be the best way to go...in general over the long haul, a lot more time is spent modifying and maintaining code than in writing it, and I would think that having people spend the ramp up time once would be better than having to switch back and forth all the time.
our boss basically said we need to
switch to C#... for no other reason
than standardization. (...) So I guess
the 'subjective' part of the question
is, is it better to sacrifice
productivity for consistency?
Of course not. The only question is what value this 'consistency' has in terms of future productivity, because productivity is all that matters. 'Consistency' by itself is not a business value. It may only help you to achieve more productivity in the future.
Several factors must be balanced:
(+) Tomorrow people will have to maintain only one language, the most popular .Net language: C#. (See Note 1)
(-) Today you must learn C#, which is a cost for your company, unless you do it for free in your weekends. Of course this is a (-) in terms of cost. Learning C# is good by itself, it just has a cost.
(-) Today after learning C#, you or someone else must switch one project from Visual Basic .Net to C#. That has a cost, depending on the LOC count of the project. Also, errors might be introduced, so you need to rerun your unit tests, go over all the failures and work them out. Also, you need to repeat some integration testing, to guarantee that everything works well.
You can't tell what the outcome of the balance is with this information. But you don't have to tell, anyway, since your boss presumably has better information and has already taken the decision. All that you need to do is to actually do it.
Note 1: However, this reasoning is dangerously close to "the world would be a better place if VB.NET didn't exist", which may be too strong a statement. VB.NET, or a mix of both languages, might be a good option in some scenarios.
We're still a mixed language group where I work; however, mixed with a purpose. Nearly all hardware related projects are done in C++ (not assembly, I know :() and all nearly all windows applications are done in C#.
Considering C# popularity and ease, I'd say it's in a company's interest to move to it for when they get new, greener employees.
How do you see yourself as shop?
VB.NET is strong in markets that directly lean on Office, maybe client apps too, while C# is particularly strong in serverside and larger applications.
Maybe it is not about following your or his choice, but make a choice to align with the nature of the shop.
It is important to stick to a singular language choice, if possible. Obviously, if you are writing unmanaged C++, or have some other similar scenario, there would be notable exceptions. Many people have hit on the efficiency of homogeneous language choices, once you have ramped up. Most of the developers I know will run into an efficiency issue when switching languages, even if they know it inside and out. After coding in C# for a couple of months, if I have to go back to VB.NET to maintain something, there is a good day where I have to consciously think about things that are normally automatic. They are simple things, like using vs. Imports, type conversion, etc. It isn't that you forget how it works, but that your mind wants to do something the way you have been doing it for an extended period. A lot like the old parlor trick of pushing your arms out against a door frame for a minute and then resting them at your side. They want to go back up, because that is the signal that your brain is used to sending.
Another very important takeaway, is that this efficiency factor is important in code reviews, as well. If you are working in VB.NET and have to review C#, you are going to have the same stumbling blocks. Sure, you understand the code, but your rate or accuracy in analyzing the code will not be the same as it would be if it was in the same language you are currently using.
There are some additional minor points. Some tooling is geared towards one language over another. For example, Resharper works for both VB.NET and C#, but it provides a larger set of refactorings if you are using C#. Also, if someone in your organization maintains a company coding standard, it makes changes to those standards half as complex, if only a single language needs to be addressed.
I think this also goes a long with coding style standards. Is there really a reason why a development team chooses to go with 3 spaces for tabs rather than 4? Not really there is no technical or business advantage to this decision other than uniformity and making everyone's code look the same so when I switch between files my brain doesn't have to adjust to the new formatting.
Same thing applies here with the uniformity for C# and VB.net. There is no technical or business advantage for taking one over the other (NOTE: I'm sure if you looked hard enough you could find something really obscure). But having everyone's code uniform helps when moving from project to project so people don't have to switch gears from thinking in C# to thinking in VB.net.
One of the advantages of using the .Net platform for development is the fact that you have the ability to develop in the language that is best able to express you solution to the problem at hand.
An arbitrary rule IMO should not prevent you from using F# or a DLR language when those languages would be a more natural fit than an imperative language like C# or VB.Net.
It's a harder decision to make with VB.Net vs. C# because the languages are so similar but If you need to do a lot of work with XML then VB.Net's XML literals may help make the code clearer, conversely C#s terse syntax and support for anonymous methods may make your intent clearer.
I'm writing a app which integrates with windows shell and adds an additional context menu.
And am considering a couple of languages to write it in:
MS .NET - I'd rather not use managed code for this type of app
win32asm - This is my first choice
VC++/C++ - Not sure
So basically its a toss up between assembly and C++ anyone have any thoughts or considerations that might make my choice easier?
You want shell context applications to have small footprints. This rules out managed code at least for now. This may speak somewhat in favour of win32asm, although the C++ libraries aren't really all that large compared to the .NET runtime (less than a MB, all told, isn't that big these days)!
You want shell context applications to be stable, since otherwise people will kick them out to save their explorer.exe processes. This speaks heavily against win32asm. If you know only you will ever maintain the app, and you have great assembler skills, win32asm may work, though I myself wouldn't go that way. You still have to implement COM interfaces, which is a big enough headache without adding the complexities of assembly coding.
I'd go for VC++ with ATL support, without further thought, but with serious unit testing and safeguards against resource leakage. But if you aren't comfortable with C++ and templates, this may present a rocky road for you. On the plus side, you'll have a much smaller set of source code to maintain, and have a much easier time finding others to help or take over. You may also have improved a still relevant valuable skill set.
A renowned PHP user once said: There will be a relaunch in 2 years, anyway.
Those times are gone. Web applications that are older than 5 years are common. With the original developer(s) gone.
The release cycles of the operation system, programming language, and framework are getting in the way of doing real work, if you don't have a big staff.
Is there any way to develop something that doesn't need constant porting to the next level, without the fear of losing support and backing in a community? For people who want to stay in programming instead of climbing the corporate ladder and leaving the problems to the next "generation"?
My company codes almost exclusively in C#, however we have ColdFusion 5 apps still humming along written back in 2001 or so. Theres no need to port them.
If it ain't broke, dont fix it.
Other than security flaws (which are usually handled by an OS/Server Patch, so they dont need code changes), theres no need to change an app just because a new version of the language has come out.
If I'm not mistaken, ColdFusion has had at least 2 new releases since we stopped using it for new code. but that hasn't affected our ColdFusion sites one bit.
Write CGI programs in FORTRAN 77. Should be pretty stable.
Firstly, it is possible to overstate the difficulty in maintaining web applications. In many cases, the changes to a language or platform are expansionary in nature rather than destructive. .NET, python, etc code from several years ago will still run, but new options are being added to make these these tools more powerful for future applications. The case where massive changes occur tends to be on the first or second iteration of a language, e.g. Rails 1 to Rails 2.
Secondly, the still active development of web programming is something to be thankful for.It means that this is a part of the industry that will remain productive and exciting for years to come.
Traditional CGI is stable. It's not sexy, but if your OS continues to be able to run the same binaries or scripts, it's still going to work.
The only programming frameworks that stay stable are those that have been abandoned. A framework that stood still long enough would have no support for, say, AJAX or JSON or even XML.
You're not going to find what you're asking for. The best you can hope for is a mature framework with good support like ASP.net or JSP. And, as #Neil N said, don't keep upgrading unless there's a compelling business need.
The first web programming I ever did was writing Apache modules in C which communicated with a dBase database. I'm fairly sure that code would still run today (if the company I wrote it for still existed).
I do most of my current web-related programming in Perl, which is very stable and has an excellent track record for backwards compatibility. Most, if not all, code written for Perl 4 (released 21 March, 1991) should still run on the latest stable Perl (5.10) - although you might want to update it anyhow to take advantage of the last 18 years of improvements in both software development techniques and language features.
Consider the shearing layers. I've previously worked in large aerospace companies where the same Fortran back-end code and databases have had their front-ends evolve from the paper tape era through mainframe, client server and onto Intranet web sites.
On the outside, you have will typically have CSS and XHTML templates which can be changed to re-skin an application. These change quite rapidly, in large organisations as upper management seems to decide the bike shed should be a different colour every few weeks.
Typically you then have some logic to combine the templates with data from the back-end, and forward user actions to the back-end. This shouldn't change that rapidly, but translate the presentation to calls into the back-end. Expect to refresh this every few years, and rewrite it once a decade. We used Java for this, starting in the late 1990s. Some parts get changed faster than others, but it's not a big issue.
The back-end is usually stable ( some of the aerodynamics code dated from the 1970s; the laws of physics don't change that often ), and will outlast the web UI, as it has all the other UI paradigms. Fortran is forever.
Write your own web server in C then you don't have to worry about a web programming language.
(No, that's not a serious answer)
Have you seriously looked at what TDD, CI, pair-programming, and a solid, rapid development framework (basicaly Django or Rails) can offer to you as a developer vis-a-vis the way you write and design code? There are some really massive benefits that all of those pieces offer to the development process that make it almost a joy to be a programmer again. There are downsides, of course, but the upsides are all in support of the happiness and ease of development for the engineer, which leads to more productivity. In my book, that's a slam dunk win. And the result of my productivity and happiness, has been solid products and great engineering.
YMMV, but if you are having the serious thoughts that you are (and I take them very seriously), I think it's worth you investigating what those tools can offer. By taking the good and leaving the bad from the agile religion plus some of the things I listed above, I've returned to find the joy in programming again this last year, after a good 5 years of a downhill slide of my happiness with this career. It's about finding what works for you. I can only help and lead the way by showing you what worked for me. I'd be more than happy to discuss at length if you want to talk offline, I think this is a really important topic...it lead me to consider a career change many times.
Java Servlets and JSPs have been in use for a decade or so, and they still work the same way like they did in '99. But honestly, can you imagine something uglier than a '90s web application without any rework done since?
The Python web framework web2py promises backward compatibility:
Always backward compatible. We have
not broken backward compatibility
since version 1.0 in 2007, and we
pledge not to break it in the future.
And supports Python versions from 2.4 to 2.7
EDIT: Updated an important project 2 times and every time there was a problem. Well, …
EDIT 2: Needs Python 2.6 to 2.7 now. No support for Python 3.