Is there a stable Programming Language for Web Programming?

Question

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"?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

Write CGI programs in FORTRAN 77. Should be pretty stable.

Answer 5

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)

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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?

Answer 11

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