Ask Slashdot: Choosing a Web Language That's Long-Lived, and Not Too Buzzy? 536
adelayde (185757) writes "In my day job, I work on a web based service with a lot of legacy code written in that older (and some may say venerable) web-scripting language, Perl. Although we use Modern Perl extensions such as Moose, the language just seems to be ossifying and we're wanting to move to a more up-to-date and used language for web applications, or even an entire framework, to do new development. We're still planning to support the legacy code for a number of years to come; that's unavoidable. This is a fairly big project and it's mission critical to the business. The thing we're afraid of is jumping onto something that is too new and too buzzy as we'd like to make a technology decision that would be good at least for the next five years, if not more, and today's rising star could quite easily be in tomorrow's dustbin. What language and/or framework would you recommend we adopt?"
Perl (Score:5, Interesting)
Perl 5 pretty much satisfies everything you're looking for. What's the problem with Perl again?
Node.js (Score:2, Interesting)
JavaScript isn't going anywhere, and is nearly required for web development in browsers... so having it on the server side just makes things that much easier. It's not particularly hard to learn... you hire people with JavaScript experience, and they can get spun up on Node.js in a week or so.
C++ and CppCMS (Score:1, Interesting)
Use C++ and CppCMS: http://cppcms.com/ [cppcms.com]
You get the benefits of a real programming language, not just a toy like Ruby, Perl, JS or Go. The code is checked by the compiler, you can compile it to run just about everywhere, and the compiled binaries are FAST. You don't need 10x or 20x the servers just because you're using an interpreted language that's really fucking slow.
And if you aren't a dumbass, you'll use the Modern C++ way [microsoft.com]. You will reduce your risk of security holes to a minimum, while getting a very efficient language to program with. Unlike Go, you'll get real OO if you need it, and real support for templates.
C++ is for those serious programmers who want to get real work done, and who don't have time to waste with overhyped crap.
Remove the ransom note excuse with Deparse (Score:5, Interesting)
Most of the time that removes the crazy from the script. I just got a large legacy code-base and that little trick made my life much better. If the perl code works, then you are just looking for work to do. Newer is not always better.
Java or C# + AngularJS (Score:3, Interesting)
Find yourself a good REST writing API (I'd go Jersey & Guice, but many go Spring for Java) and then HTML AngularJS as your front end framework.
Re:Perl still works, and PHP is fine (Score:3, Interesting)
Most of it applies to old, obsolete versions of PHP.
Which might be the only versions that your hosting provider offers because upgrading PHP would change the language's semantics in ways that break other subscribers' programs.
Random garbage or valid Python? (Score:4, Interesting)
Hiring (Score:5, Interesting)
Most of the people who know Perl well already have jobs, and aren't looking to change.
We tried hiring someone to help me offload some of my work, and one the task I've gotten behind on is updating & maintaining some Perl code.
We had one person who I felt could've jumped in, but that management didn't like (as he had previously worked here, and left). The rest were folks who we'd have to train on OO, closures, and other higher level concepts.
If this hasn't been offered as a 12-month position, maybe we could've found someone. If we had advertised it as a general programming job, and then taught someone Perl, maybe it would've been gone better for us.
With trendy languages, you at least get people willing to apply -- even if it's the case that they don't grok the language, you at least get someone you can train up.
Re:.Net / Typescript (Score:4, Interesting)
There is nothing overkill about MVC. It is far simpler than webforms. Webforms is the one that is overkill. The massive view state object that is serialized with every request, the fact that it tries to emulate windows forms controls with heavy objects and non-HTML tags. You want HTML, use MVC. You want the overkill of webforms controls? MVC is far faster even for simple cases.
I did webforms for even applications ranging from simple to complex for 3 years, and I've been using MVC for almost 3 years now, and I can tell you MVC is far simpler for both cases. Webforms was designed to be familiar to people coming from a Windows Forms background, and that layer that created on top of the simple html/http request/response model of the web is overkill. The viewstate for example is designed to give the programmer the sense that state is continuous through the user's interaction, as if it were a webforms app, to hide the request/response web model from the programmer. But this is overkill and actually makes things more difficult to debug and work around. Having to tweak what goes into viewstate and what doesn't. For those who do it alot it is probably second nature, but it is an unnatural layer of abstraction over how the web works.
Try to do something as simple as a small survey that has a dynamic list of questions. On postback, even though you have no intention of showing the user the form again, in order to capture the user's response you must recreate the entire form, and make sure you do it in just the right event handler in the pipeline. In MVC, all you need is a POCO in the Action method parameter.