Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Perl Programming

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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Choosing a Web Language That's Long-Lived, and Not Too Buzzy?

Comments Filter:
  • Perl (Score:5, Interesting)

    by XanC ( 644172 ) on Tuesday July 01, 2014 @01:43PM (#47361753)

    Perl 5 pretty much satisfies everything you're looking for. What's the problem with Perl again?

  • Node.js (Score:2, Interesting)

    by Anonymous Coward on Tuesday July 01, 2014 @01:48PM (#47361801)

    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)

    by Anonymous Coward on Tuesday July 01, 2014 @01:52PM (#47361845)

    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.

  • by ksbraunsdorf ( 1600073 ) on Tuesday July 01, 2014 @02:03PM (#47361963) Homepage
    If you don't like ransom notes (which perl programs may become over time) use this trick: get perl to reformat the code with a this command:

    $ perl -MO=Deparse ransom.pl >better.pl

    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.

  • by mlk ( 18543 ) <.michael.lloyd.l ... .at. .gmail.com.> on Tuesday July 01, 2014 @02:29PM (#47362249) Homepage Journal

    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.

  • by tepples ( 727027 ) <tepples@gm a i l . c om> on Tuesday July 01, 2014 @02:39PM (#47362387) Homepage Journal

    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.

  • Hiring (Score:5, Interesting)

    by oneiros27 ( 46144 ) on Tuesday July 01, 2014 @03:10PM (#47362677) Homepage

    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)

    by AaronLS ( 1804210 ) on Tuesday July 01, 2014 @04:45PM (#47363513)

    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.

"It takes all sorts of in & out-door schooling to get adapted to my kind of fooling" - R. Frost