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?"
Re:Perl (Score:5, Insightful)
Nobody is forced to program that way in Perl. It can be fun and may or may not look cool on a t-shirt but no one recommends that as a way of doing it. Just because there's more than one way to do it doesn't mean you should choose the worst way.
And to the submitter, I agree with the OP.
Re:Perl (Score:5, Insightful)
Nobody is forced to program that way in Perl.
Mobody is forced to write Perl that way, but many people are forced to read that kind of Perl.
Re:Perl still works, and PHP is fine (Score:2, Insightful)
> PHP is relatively modern, robust
No it isn't
Re:Perl still works, and PHP is fine (Score:5, Insightful)
Sure, on paper it looks like you'll have a large number of viable candidates, but when you start interviewing you learn that the PHP "talent pool" is mostly just a pool.
It's just as quick to hire a real developer and train them in PHP.
Java (Score:3, Insightful)
"Ossifying" vs. "Stabilizing" (Score:5, Insightful)
Re:Java or C# + AngularJS (Score:5, Insightful)
Yesod (Score:4, Insightful)
Re:Perl (Score:3, Insightful)
That's the crux of the issue. A good language shouldn't be one that lets you code cleanly - it should do its very best to make sure you CAN'T code sloppily.
I know why you are asking, you said "Legacy" (Score:4, Insightful)
The key word in the summary is "legacy". This indicates that there is a large code base that the current developers are not too familiar with (deep knowledge, staff turnover causes this). This causes an organization to fear change due to the related complexity of changes and potential regression bugs. I'm going to guess that there aren't large, mature suites of unit and regression tests.
So I believe you have:
1. Complex code base without a lot of deep developer knowledge of the innards.
2. Fear to change things too much due to complexity and the possibility of introducing bugs.
3. Do not have effective, wide coverage testing implemented.
But, you also have good knowledge of Perl and the architectural elements that compose the system (server software, external libraries, etc.). That knowledge is very valuable and shouldn't be dismissed just for the sake of changing the base language of a system. And you have a working system. How many person years of development have been put into it? Are you willing to spend that much time on the replacement (do you think a replacement could be built in less time, and if so, why?)?
As well, rewriting large admin systems is very risky. I've personally seen two such efforts fail, a 100% failure rate from my personal experience (both had budgets over $5 million, one was over $40 million). Here's an article on this topic:
http://hbr.org/2011/09/why-you... [hbr.org]
Consider keeping the existing system, but embarking on a long term (years) modernization/re-design/improvement effort to make the system more modern (ie. easier to work with). Focus on small, non-breaking changes that can go out with regular enhancement promotions (the modernization effort should be able to stop at any point, with any improvements to the system staying in place - this allows for tight budget control and financial risk mitigation). Hire a good application DBA to perform analysis and recommend changes to the data model. Hire a good software architect or bring in architectural consultants that can bring a different perspective to the understanding of the application, its goals, and how it could be improved.
Here's an article on approaching IT projects in a "Small and Simple" manner:
http://w.objectwatch.com/white... [objectwatch.com]
Re:Perl (Score:5, Insightful)
A good language ... should do its very best to make sure you CAN'T code sloppily.
Exactly, just like a good spoken language should make sure you CAN'T use profanity.
...But then, what about when profanity is appropriate? What if you need an emphasis that is so fucking strong that simply changing the tone of voice doesn't suffice? What if your whole damned speech is in reference to something condemned by a deity, or referring to Mohammed the thief, who assumed the name of the prophet?
The point of any language is to express. For programming languages, the idea is to express instructions for two different processing styles simultaneously: the deterministic and predetermined understanding of the parser, and the non-deterministic and subjective understanding of colleagues. Similarly, spoken languages must account for the subjective understandings of every listener, some of which may have very different rules regarding obscenity.
There is much more to coding "cleanly" than mere syntax. Structure is equally important, and it must change as the system design demands. If the rules of a language are too strict, then the whole program starts to look the same, and it's more difficult for future interpreters to understand the intent of the program.
There is an art to writing clean code, just as there's an art to writing eloquent language. Strict rules don't always improve that art.
Re:Perl (Score:4, Insightful)
Regular expression are deterministic. Rob Ford, not so much.
Re: Perl (Score:3, Insightful)
Agreed, which is why I get really annoyed with Python bigots. My main exposures to python have been trash piles like Anaconda and cowboy crap that is seven layers of libraries to implement and process check that has such poor syntax that it can't even fail, no matter how screwed the process.
I've seen incomprehensible junk written in tcl, bash, java, javascript, c, c++, visual basic, fortran, cobol, basic and assembler, most often written by "experienced" coders who think comments and structure are anathema and risky to their job security.
Give me "unsophisticated" and/or heavily commented code, thank you.
Re:Perl still works, and PHP is fine (Score:4, Insightful)
It's not a pretty language but you can be reasonably certain that for the forseeable future it's going to stay. It's nowhere near as nice as Ruby on Rails or Python/Django but it does have a huge market share so there's both relatively many people who speak it and a lot of ready-to-use code, from snippets to frameworks.
The huge amount of available code is a bit of a mixed bag, though - PHP attracts a lot of entry-level coders and in many cases it shows. On the one hand you have things like Twig (a clone of Django's template engine) that are a delight to work with; on the other hand you have things like most WordPress plugins, which consist of barely-working code written by someone who thinks that "model-view-controller" involves Kate Moss staring at a gamepad. The fact that PHP makes it easy to write code that is wrong but still runs doesn't help here.
PHP has flaws. A lot of them. It's a pretty annoying language to work with. But it's not going to fade away anytime soon and that is its strength. If that makes it desirable to you then PHP is a reasonable choice. If it doesn't you might want to stay with Perl or take a look at trendier languages like Ruby, Python or JavaScript.
Re:Perl (Score:2, Insightful)
You can have all the innovation you want, but innovation isn't enhanced by allowing you to confuse meters with feet or by allowing you to divide by zero. Certain thing should always be forbidden if they can be detected by the compiler and the compiler can be helped by language rules amenable to correctness. This doesn't limit innovation it just minimizes obvious (or not) flaws.
Re:Perl still works, and PHP is fine (Score:4, Insightful)
You just have to filter out the people who list HTML as programming.
Re: Perl (Score:4, Insightful)
That you think C aids in expressiveness over Perl, Python, Ruby, awk, Go, Swift, Rust, D, C#, Scala, Clojure, or even C++ shows you're talking out the wrong orifice
I expect we're using the word "expressive" differently.
C is a lot of things, but it is not terribly expressive or high level.
Definitely not high level.
C lacks concise and easy to use language syntax to express ideas, but almost any idea that can be imagined can be expressed (implemented) in C. That is what I meant by expressive.
Higher level languages provide all sorts of direct language support for ideas that are not directly present in lower level languages, but all high level lanagauges ultimately compile down to machine code, which can be represented by assembler. Therefore, nothing that can be expressed in any language can't be expressed in assembler. Therefore assembler is maximally expressive. Anything else is just a subset of what you can do with assembler.
However there is PLENTY you can do in assembler, that you can't do in any other language, and C, is the lowest level language above assembler, and while there are some things that can be done in assembler that can't be done in C, there's not a lot that can be done in a higher level language than C that can't be done in C.
Not easily. Not concisely. And not safely... because if you implement a reference counting garbage collector in C to do your memory management (and you can) there is nothing in C stopping you from directly manipulating the GC state to achieve all kinds of stuff you can't do in the higher level language ...and should probably never do!! -- but this isn't about *should* -- its about *can*.