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

Perl by XanC · 2014-07-01 05:43 · Score: 5, Interesting

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

Re:Perl by Anonymous Coward · 2014-07-01 05:51 · Score: 5, Funny

/&%#%^&*)^ADVkjR$%^$E)!HJLGAZ^&R%\jkghlk/^
Random garbage or valid perl?
Re:Perl by trudslev · 2014-07-01 05:52 · Score: 5, Funny

Valid garbage or random perl?
Re:Perl by Anonymous Coward · 2014-07-01 05:53 · Score: 2, Funny

It's too old. As far I can tell, there are exactly zero specific requirements mentioned besides it being something new but that'll stick around, and that the project is "fairly big."

My solution would be to talk to the smart friend of yours with the largest hands. The slap upside the head should solve the problem.
Re:Perl by just_another_sean · 2014-07-01 05:54 · 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.

--
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
Re:Perl by NotInHere · 2014-07-01 05:58 · Score: 2

Using cable1:
$./cable1 "/&%#%^&*)^ADVkjR$%^$E)\!HJLGAZ^&R%\jkghlk/^" "random garbage" "valid perl"
valid perl
Re:Perl by MouseTheLuckyDog · 2014-07-01 06:00 · 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 by azav · 2014-07-01 06:13 · Score: 2

And that regular expressions are as easy to understand and predict as Rob Ford is sober.

--
- Zav - Imagine a Beowulf cluster of insensitive clods...
Re:Perl by Mordok-DestroyerOfWo · 2014-07-01 06:14 · Score: 4, Funny

/&%#%^&*)^ADVkjR$%^$E)!HJLGAZ^&R%\jkghlk/^
Random garbage or valid perl?
Why can't it be both?

--
"Never let your sense of morals prevent you from doing what is right" - Salvor Hardin
Re:Perl by MBGMorden · 2014-07-01 07:03 · Score: 2, 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.

--
"People who think they know everything are very annoying to those of us who do."-Mark Twain
Re:Perl by rmmeyer · 2014-07-01 07:15 · Score: 2

Yeah, that was the theory behind ADA... We know where that went
Re: Perl by jd2112 · 2014-07-01 07:45 · Score: 2

You can write illegible programs in any language, perl must makes it easier.

--
Any insufficiently advanced magic is indistinguishable from technology.
Re:Perl by Sarten-X · 2014-07-01 07:53 · 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.

--
You do not have a moral or legal right to do absolutely anything you want.
Re:Perl by HornWumpus · 2014-07-01 07:56 · Score: 3, Insightful

Regular expression are deterministic. Rob Ford, not so much.

--
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Re: Perl by GeekBird · 2014-07-01 08:13 · 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.

--
use Sig::Witty;
Re:Perl by Cro+Magnon · 2014-07-01 08:48 · Score: 4, Funny

/&%#%^&*)^ADVkjR$%^$E)!HJLGAZ^&R%\jkghlk/^
Random garbage or valid perl?
Yes.

--
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
Re:Perl by Xyrus · 2014-07-01 08:59 · Score: 2

/&%#%^&*)^ADVkjR$%^$E)!HJLGAZ^&R%\jkghlk/^
Random garbage or valid perl?
Spoiler: "DRINK MORE OVALTINE!"

--
~X~
Re:Perl by darkwing_bmf · 2014-07-01 09:42 · 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 by vux984 · 2014-07-01 14:09 · Score: 3, 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*.

Better yet... by OpenSourced · 2014-07-01 05:45 · Score: 3, Funny

Which editor should we use?

--
Rome taught me patience and assiduous application to detail. Virtues which temper the boldness of great, general views.

Re:Better yet... by Anonymous Coward · 2014-07-01 05:47 · Score: 5, Funny

Anyone but Timothy.
Re:Better yet... by tbuddy · 2014-07-01 05:50 · Score: 5, Funny

+9001 Funny.
Re:Better yet... by ArcadeMan · 2014-07-01 06:46 · Score: 2

But... but... it's over 9000!

--
Get free satoshi (Bitcoin) and Dogecoins

Perl still works, and PHP is fine by ShaunC · 2014-07-01 05:47 · Score: 5, Informative

Perl may be legacy to an extent, but it's a Swiss army knife that will get any job done. I don't see it going away anytime soon.

I know it's in vogue to hate on PHP, but PHP is relatively modern, robust, and fully capable of handling enterprise tasks. It's widely adopted and there's support everywhere. Probably half of the websites and services you use every day are built on PHP, it's certainly not the worst language you could choose.

--
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!

Re:Perl still works, and PHP is fine by xmousex · 2014-07-01 06:00 · Score: 2, Informative

If you are concerned about getting in employees who know the language from school or have experience at several prior jobs, and come in at affordable rates, or have a concern about available contractors, PHP is going to give you a larger available talent pool that you can swap people in and out faster then continuing with perl or going down just about any other path where the knowledge pool will be fairly limited. There are a lot of platforms in PHP that can aid with this, providing frameworks that everyone can follow regardless of how stable or unstable your development team may be.
Re:Perl still works, and PHP is fine by tigersha · 2014-07-01 06:00 · Score: 2, Insightful

> PHP is relatively modern, robust
No it isn't

--
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Re:Perl still works, and PHP is fine by Vellmont · 2014-07-01 06:04 · Score: 3, Informative

Anyone cosidering PHP should read this the now infamouns "PHP is a fractal of bad design".
http://eev.ee/blog/2012/04/09/...

--
AccountKiller
Re:Perl still works, and PHP is fine by Anonymous Coward · 2014-07-01 06:12 · 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.
Re:Perl still works, and PHP is fine by TheRaven64 · 2014-07-01 06:14 · Score: 2

That's the same logic people used for choosing C, and just past the 25th anniversary of the first remote exploit of a buffer overflow vulnerability, it's still top of the list of causes of CVEs.

--
I am TheRaven on Soylent News
Re:Perl still works, and PHP is fine by Mordok-DestroyerOfWo · 2014-07-01 06:15 · Score: 5, Funny

> PHP is relatively modern, robust
No it isn't
Skillfully refuted!

--
"Never let your sense of morals prevent you from doing what is right" - Salvor Hardin
Re:Perl still works, and PHP is fine by alex67500 · 2014-07-01 06:16 · Score: 2

PHP is relatively modern, robust
No it isn't
Thanks for your valuable contribution.
Judging by the fact that most of Facebook is based on PHP, it sounds to me like it's pretty robust... It's also object oriented. The only drawback that I would find as a code-geek is weak typing, but that's a personal opinion, not a lacking feature.
Re:Perl still works, and PHP is fine by tepples · 2014-07-01 06:39 · Score: 2, 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.
Re:Perl still works, and PHP is fine by itzly · 2014-07-01 06:47 · Score: 4, Funny

That's not an argument. An argument is a connected series of statements intended to establish a proposition.
Re:Perl still works, and PHP is fine by danudwary · 2014-07-01 07:05 · Score: 5, Funny

No it isn't.
Re:Perl still works, and PHP is fine by ttucker · 2014-07-01 07:44 · Score: 2

PHP is relatively modern, robust
No it isn't
Thanks for your valuable contribution.
Judging by the fact that most of Facebook is based on PHP, it sounds to me like it's pretty robust... It's also object oriented. The only drawback that I would find as a code-geek is weak typing, but that's a personal opinion, not a lacking feature.
Besides that Facebook isn't. They use a proprietary solution that started with PHP, but is really something else now.
Re:Perl still works, and PHP is fine by meustrus · 2014-07-01 07:50 · Score: 2

Don't piss on Javascript. Sure, the standard library is terrible and poor cross compatibility makes it impossible to do anything interesting in a browser without shims, but purely as a language the whole "class = function = object" idea is truly magnificent in its own way, especially with the implementation of anonymous functions and closures. The ability to override "this" as well provides many useful metaprogramming tools; just recently I used it to load an external library into its own independent global scope (since it is not well behaved and I don't want it messing with the existing global scope). I always find pleasure writing Javascript when the task is narrow enough and I've got everything I need. And just so you know I have used C, C++, C#, Java, Ruby, Lisp (Scheme), PHP, and Javascript.
(more on-topic, I can't speak towards Perl, but PHP can be done right and when it is it can be maintained by anyone, although most of "anyone" will probably write you a horrible kludgy mess instead)

--
I sometimes ask revealing, often ignorant-seeming questions. Maybe they're harder to answer than you think.
Re:Perl still works, and PHP is fine by ArhcAngel · 2014-07-01 08:11 · Score: 2

Well it made for one hell of a funny 5 minutes on Monty Python

--
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
Re:Perl still works, and PHP is fine by Jesus_666 · 2014-07-01 09:01 · Score: 3, Insightful

PHP is the boring, reliable choice. It's popular enough that it's probably still going to be mainstream in twenty years. The ease of entry means a steady stream of neophytes who end up checking out PHP at their first web language.

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.

--
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Re:Perl still works, and PHP is fine by UnderCoverPenguin · 2014-07-01 10:55 · Score: 2

I know it's in vogue to hate on PHP,

I don't hate PHP. I just don't use it unless I have to.

but PHP is relatively modern, robust, and fully capable of handling enterprise tasks.

I'm not sure what you mean by "relatively modern". If you mean it is younger then Perl, that is true. 20 years old vs Perl's 26 years.
Both languages have evolved, adopting new ideas and adapting to new needs. They both borrow from other languages and from each other. Indeed PHP started out as a set of Perl scripts. A side effect of this was that PHP 1.0 (released in 1995) "syntax resembled that of Perl" (http://en.wikipedia.org/wiki/PHP).
Both are "fully capable of handling enterprise tasks".
The original posting claimed Perl "just seems to be ossifying". I think this is a perception problem unwittingly caused by the Perl 6 project. I think what we call Perl 5.20 might have been Perl 7.x (or even 8.x or higher) if the developers were free to increment the 5. As a similar example, look at FireFox and Chrome. Google's use of a single version number created a perception that FireFox 3.x was ancient. After Mozilla switched to using single number version for FireFox, the perception of FireFox began to improve. Another example: When Intel added "MMX extensions" to Pentium, people asked when will PowerPC get MMX extensions. The fact that the PowerPC already had equivalent features was ignored and the PowerPC was painted as falling behind the Pentium.
Perl, PHP and many other "old" languages are still used. If anything, their continued use is better evidence to expect they will be actively supported 5 (or more) years from now then whatever the current "rising star" happens to be..

--
Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
Re:Perl still works, and PHP is fine by budgenator · 2014-07-01 11:00 · Score: 3, Insightful

You just have to filter out the people who list HTML as programming.

--
Apocalypse Cancelled, Sorry, No Ticket Refunds
Re:Perl still works, and PHP is fine by Pseudonym · 2014-07-01 13:50 · Score: 2

Don't piss on Javascript.
There's nothing wrong with pissing on Javascript, but it's unfair to mention it in the same breath as PHP. PHP sucks across the board, but Javascript has very specific and identifiable flaws. You can think of Javascript as the living embodiment of Sturgeon's Revelation.
So, for example, Javascript has quite clean variable semantics (borrowed from Scheme, no less!), making it almost a functional language, but then drapes it in an unwieldy function syntax which discourages you from using it as such. Somewhere inside Javascript you can tell that there's a pretty nice scripting language trying desperately to get out. (Hell, membranes are almost elegant.)
I wish that PHP had redeeming features like that. The only thing it ever had going for it was that 15 years ago it had a better Apache binding than any other language, making it the superior choice to CGI.

--
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Re:Perl still works, and PHP is fine by Pseudonym · 2014-07-01 13:53 · Score: 2

Yet C is still in wide use, and is still useful for endless applications. Its bastard offspring C++ is another "fractal of bad design," but it's everywhere.
I used to make the same complaint about C++ until I seriously used it for something.

--
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Re:Perl still works, and PHP is fine by Alioth · 2014-07-01 22:50 · Score: 2

I thought PHP meant "Pretty Hopeless Privacy" due to its track record of security flaws...

--
Oolite: Elite-like game. For Mac, Linux and Windows

Node.js by Anonymous Coward · 2014-07-01 05:48 · 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.

Re:Node.js by jbolden · 2014-07-01 06:22 · Score: 2, Informative

Javascript executes client side. It is the interpreted language that rendering engines are being built around. You can't have scriptable interactions with low latency without something like it and it is at this point usually the best choice.
Re:Node.js by angel'o'sphere · 2014-07-01 06:54 · Score: 2

Unless it is executed on the server, ofc ;D

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:Node.js by Dynedain · 2014-07-01 08:31 · Score: 2

When building pages to send to the client, there's a lot of value in building DOM structures server-side. Having powerful DOM-manipulation tools is an advantage.
Plus, if you run the same language on both ends, you can start to do some really interesting things, like the Meteor framework, where the same functions exist on both sides of the fence, and work the same way.
Think of the power that exist(ed) in using .NET on both the server and IE. It was proprietary, but made huge advancements in rapid development and deployment.
Node.JS and other JS-on-the-server approaches are making this happen in a OS and browser agnostic way.

--
I'm out of my mind right now, but feel free to leave a message.....

Why not... by realilskater · 2014-07-01 05:49 · Score: 2

PHP or Java?

PHP has a number of CMS frameworks built in it.
Java has the JavaEE stack.

Avoid Frameworks. by TechyImmigrant · 2014-07-01 05:49 · Score: 2

If you're using a high level language with WSGI for efficiency, then you can choose the one that meets your performance/complexity goals.

Friendly, maintainable, not high performance: Python
Higher performing, C, C++
Supports elegant solutions if your brains are wired differently: Haskell

But unless your code is a mess, there's nothing so valuable as a large codebase of working code with institutional knowledge built around it. That would be PERL.

--
I should use this sig to advertise my book ISBN-13 : 978-1501515132.

Re:Avoid Frameworks. by TechyImmigrant · 2014-07-01 06:34 · Score: 2

I've yet to meet a Framework that makes things as clean and usable as they claim.
And worse, once a web site is in Django or Drupal or somesuch, no novice can edit anything. Template languages are great if you understand the inheritance model, but non techies do not understand those things. They give up, load dreamweaver and mess all over your lovely framework, so they can get content up.
If you have a staff online to support a web site, then fine. They can mediate transactions. But Frameworks are like an arse. They only get bigger with time.
There are better ways borne of thinking hard about fitting the right solution to the problem.

--
I should use this sig to advertise my book ISBN-13 : 978-1501515132.

.Net / Typescript by garlicbready · 2014-07-01 05:57 · Score: 2

I work in a medium sized software development company, and we work exclusively with .Net usually Visual Basic
C# is also an option in .Net land, typically with the newer frameworks the differences functionality wise are fairly minor
we started with .Net 2,0 web forms and are now on .Net 4.0, everything is backwards compatible as far as I can tell between frameworks
Another direction would be php, or something more specialised such as Ruby for example

If you want rapid development cycles then having intelisense / auto completion / linq / entity framework is definitely something to look into
these languages are server side, you also may want to consider how much of your website wants to be written in client side languages such as javascript. Personally I'm planning on learning Typescript which is a subscript of javascript, basically easier to write and more class based with intelisense

It all comes down to what kind of functionality you want to put into your web apps, and what your developers feel comfortable with

Re:.Net / Typescript by AaronLS · 2014-07-01 08:45 · Score: 3, 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.

Ruby/Sinatra by Unequivocal · 2014-07-01 05:58 · Score: 2

As a greybeard who used to write dynamic gopher sites, I really like to write in Ruby/Sinatra now. It gives me access to lots of nice features (I can install activerecord when I need it) and I can build APIs super quickly and everything in between. And I can get down to the bottom of the network stack pretty easily when I want to. I do miss the Ruby/Rails built-in testing framework, but otherwise haven't looked back since switching from that environment.

Remove the ransom note excuse with Deparse by ksbraunsdorf · 2014-07-01 06:03 · Score: 5, Interesting

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.

Re:Remove the ransom note excuse with Deparse by bytesex · 2014-07-01 07:34 · Score: 3, Funny

I just did your deparse trick on my worst perl script, and it made it *worse*! I must be doing something right.

--
Religion is what happens when nature strikes and groupthink goes wrong.

Perl with Mojolicious by perplexing.reader · 2014-07-01 06:09 · Score: 2

Very powerful and very flexible, without the heavy lifting of many frameworks. We use on a large ISP as RESTFull Server.

Javascript FTW by MouseTheLuckyDog · 2014-07-01 06:17 · Score: 2

Why because Javascript is proof that you can write a language that is worse then Perl.

Re:obvious by TechyImmigrant · 2014-07-01 06:18 · Score: 2

>Javascript. Code for input validation

Umm... Javascript in a web page can do nothing for input validation. Anyone can send anything they want to a server.

--
I should use this sig to advertise my book ISBN-13 : 978-1501515132.

Java by Neruocomp · 2014-07-01 06:21 · Score: 3, Insightful

Be careful with frameworks, because as soon as you find yourself having to do things outside of its protective little garden, you might as well give up on the framework. But in terms of long lived, go with Java. It has no buzz or the glory the pretty new things have and thats why its still in wide use in the enterprise.

--
Physics is like sex. Sure, it may give some practical results, but that's not why we do it

Perl says your garbage is just that by Anonymous Coward · 2014-07-01 06:22 · Score: 3, Informative

Well, it says it in it's own polite way:

$ perl -e '/&%#%^&*)^ADVkjR$%^$E)!HJLGAZ^&R%\jkghlk/^ && print "Valid? No way!"' syntax error at -e line 1, near "^ &&" Execution of -e aborted due to compilation errors.

Re:Perl says your garbage is just that by lsllll · 2014-07-01 11:13 · Score: 3, Funny

syntax error at -e line 1, near "^ &&"
Hell, at least it made it 2/3 of the way through.

--
Is that a roll of dimes in your pocket or are you happy to see me?

Re:Grails by Kagato · 2014-07-01 06:27 · Score: 2

I'm going to second Groovy on Rails. AKA Grails. It's very mature and is one of the languages that compiles down to Java Opt code. You have a large eco-system of production apps that run in the container. The language is fairly approachable (saying this as someone who came originally from a Perl Web App background in the late 90s). You can also use Java Libraries if there's something you want to get out of box such as one of the many Open Source Apache Libraries or Google Guava Libraries.

Java or C# + AngularJS by mlk · 2014-07-01 06:29 · 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.

--
Wow, I should not post when knackered.

Re:Java or C# + AngularJS by asylumx · 2014-07-01 06:48 · Score: 4, Insightful

Agree. Also .NET MVC is really getting pretty good as a framework.

Fractal rant makes about six good points by tepples · 2014-07-01 06:38 · Score: 5, Informative

Anyone cosidering PHP should read this the now infamouns "PHP is a fractal of bad design".

Which must be balanced with the "hardly" rebuttal. For example, PHP lets a program solve the exception/warning dichotomy cleanly in about six lines of code; see the manual's page about the ErrorException class. This leaves about a half dozen legitimate complaints:

No way to turn off the language's loosely-typed comparisons.
Parse errors and undefined function errors are fatal rather than throwing an exception that the caller can catch.
Inconsistent naming conventions in the standard library.
Associativity for the ternary ?: operator is the less useful side.
PHP allows the server operator to change program semantics in ways that are annoying to work around, such as not allowing a shared hosting subscriber to turn off "magic quotes" or not following HTTP redirects in libcurl.
PHP versions change the semantics of existing programs in ways that encourage shared hosting providers to continue to offer only outdated versions of PHP, making it impossible for web application developers to take advantage of new features.

"Ossifying" vs. "Stabilizing" by DutchUncle · 2014-07-01 06:38 · Score: 4, Insightful

... because people saying that something is "ossifying" and jumping to the next fad is EXACTLY what makes things "buzzy".

Random garbage or valid Python? by John+Bokma · 2014-07-01 06:49 · Score: 3, Interesting

http://preshing.com/20110926/h...

--

Perl Programmer for hire

Yesod by John+Bokma · 2014-07-01 06:52 · Score: 3, Insightful

http://www.yesodweb.com/ Lookie, it's even in the domain name ;)

--

Perl Programmer for hire

Hiring by oneiros27 · 2014-07-01 07:10 · Score: 4, 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.

--
Build it, and they will come^Hplain.

PHP by Mr.+Slippery · 2014-07-01 07:11 · Score: 2

PHP is the language for web programming, just as C/C++ is the language for system programming.

People have been hating on C since at least the 1980s. It's still here. People have been hating on PHP since 2000 or so. It's still here.

--
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood

Regarding the linked article on Perl... by jjn1056 · 2014-07-01 07:13 · Score: 2

I'm not going to take sides on 'what language to learn next.' You've not given us enough information on your codebase, the size and nature of your company, etc. I would say a rewrite is as likely to put you out of business than not, but that's ultimately your choice and unless I know all the factors I can't tell you if its a risk worth doing.

Regarding the link you gave on Perl 'ossifying', there was actually a signification discussion on the Perl Reddit about that article which I want to point out:

http://www.reddit.com/r/perl/c...

I would say the website that generated that article seems to be some sort of SEO play (they just have a bunch of articles on stuff that has some interest and controversy) and they stick ads on it. There's nothing mentioned in it that hasn't been mentioned 100K elsewhere (including here on Slashdot).

Perl has pluses and minuses but I've made a good career at it, and most of the code I've worked with is newer (seldom more for 5 or 6 years old), not legacy stuff from before the first dot com bubble. I'll probably make 200K this year, so I can't say its a bad choice. I work with lots of fun people as well. I also like Javascript. If I was starting today I might choose Scala, its a nice clean, fast language with a lot of forward looking concepts. Best of luck whatever you do.

--
Peace, or Not?

I know why you are asking, you said "Legacy" by turp182 · 2014-07-01 07:15 · Score: 3, 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...

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...

--
BlameBillCosby.com

Re:I know why you are asking, you said "Legacy" by turp182 · 2014-07-01 09:14 · Score: 2

Another approach rather than in-place same-tech modernization is the Strangler Pattern, coined by Martin Fowler.
This involves building a new application (or applications, utilities can be important) "around the edges" of the existing one, rewriting functionality aspects into a new system; chipping away at the old system (give the users a better solution for some things and they will not mind working with two systems).
Here's Mr. Fowler's original article about such:
http://martinfowler.com/bliki/...

--
BlameBillCosby.com

Research by tyggna · 2014-07-01 07:45 · Score: 2

Every web framework and technology has benefits and drawbacks. It's a matter of finding the right fit for your company. It's a good thing they're letting you ask the question, because managers/bean-counters make bad decisions in this area claiming that devs can't "see the big picture." Find one that fits well with your system and needs.

But, I assume that's why you're asking slashdot--you don't know what's out there or what their benefits are.

Well, I've spent the past 7 years benchmarking web frameworks and systems and I'll share a bit of what I've found out. Keep in mind, all information given here is my opinion and subject to debate and correction.

First--if you need near-infinite scalability and the absolute best performance, there is nothing that can beat mongodb for a database backend with fastcgi++ for your "framework." Mongodb is a bit buzzy still, but there are good reasons for that. It scales extremely well, and was designed to scale at speed. Fastcgi is anything but buzzy, but it's the fastest there is and it's built right into most webservers--but you're writing C/C++ code so that's an odd beast to deal with.

Now that I've said something that management will undoubtedly shoot down, here are some other frameworks and what they were originally designed to do, and some highlighted features.

Python - Django : "perfectionists with deadlines." Django was designed to chug out simple, straightforward web applications as quickly and cleanly as possible inside of your overall project. Contains template inheritance that has a small learning curve and is very powerful. Uses any SQL backend you want and provides an abstraction layer for it with caching. Cons: can be pretty heavy for a webapp, and difficult to integrate into a production environment.

Python - Flask : Simple and lightweight. Uses the same templates as django, but no database backend. It's meant to be standalone and simple (5 lines of code will get a website up). It's easy for your code to grow unwieldy inside of flask.

Ruby - Rails : Continuous development and test-first environment. This is kinda the poster boy for buzzwords, in my opinion, but it has some strength beneath it. Ruby is largely on-par with perl, so you have that. Rails provides the data modeling and really streamlines a lot of the annoyances common to web development. They designed the system to be the whole "45 minutes to a production environment" pipeline. You're supposed to write your tests first, then your code, and you write your deploy scripts and settings before you even start your project.

PHP - Drupal : Make a website without knowing crap about making a website. Haven't used it personally, someone else can comment.

PHP5 : "Hey, let's fix all the problems with PHP4!" Seriously, though. PHP was meant to add one-off server side scripts inside of your html, and has grown to be so big in comparison. PHP5 is actually a good language though, but it took a while to get it there. It's best used for image data processing, in my humble opinion, but it's on-par with any other language out there.
So, search them, find out who is using which systems, and which ones seem the most similar to your setup and go from there.

Re:Python by GeekBird · 2014-07-01 08:35 · Score: 2

Try hiring people who are over 30.

--
use Sig::Witty;

REST + pure HTML5/JS frontend by Laz10 · 2014-07-01 08:51 · Score: 2

Generating HTML on the server is more or less outdated.
So a "web language" on the server doesn't make sense, the way it used to do (like perl cgi, ASP, JSP, PHP and decendents)

What you do now is write the frontend in one of the new JS/HTML frameworks that run exclusivly on the client.
AngularJS is popular and will likely stick around in one form or another. But pick any you like.

For the backend you want to expose REST services, that serves the content in a way that is easy to digest for the frontend (so you don't end up with too much logic out there).
For that I'd recommend taking a look at Scala (10 years old, and not going away) and the Play Framework (http://www.playframework.com/)
What is nice about the Play framework is that it not only makes it easy to expose REST services. It also makes it easier to deploy the client side framework.

Also take a look at using microservices. Using that architecture enables you to write the REST services in smaller components, rather than one big server. That way you can more easily replace each service, when you want to migrate to the next backend technology.

JavaScript Sucks, Rant [Re:Node.js] by Tablizer · 2014-07-01 08:54 · Score: 2

Most developers only use JavaScript because it's their only realistic option on the client side for web-based applications. It's kind of like the QWERTY standard: you have to use it because avoiding it is made difficult by entrenchment.

I don't know if better tools (IDE's, interpreters, lint-er's, etc.) could make it more tolerable, but most of us have had a crappy experience with JavaScript in browsers, and this has damaged its reputation such that unless something comes along that repairs its reputation on a wide scale, server-side JavaScript is a tough sell. You can't just make it good, you have to show the world it's good and that their shitty browser experience was the browser's fault and not JavaScript.

The browser only seems to give one of two unhelpful errors: "object not found" or "is not an object'.

As far as the language, I don't like its non-WYSIWYG typing model. It has too many nulls, nils, NaN's, Nuns, or whatnot that drive one crazy. I prefer a typing model where every value is or is treated like a string and is readily displayable. No damned hidden types/modes. (Some say Null is needed for RDBMS compatibility, but I've almost never needed such, and the API can use the string "[null]" or the like if null detection is really needed by an app.)

And it has too many "kinds" of data structures; these may be delimited or enclosed with square brackets, curly braces, parenthesis, and whatnot. Too many similar kinds of collections. Just make everything a dynamic ordered tree rather than have similar but not quite the same species of structures. Lisp at least got that part right.

And don't overload "+" to mean both addition and concatenation. Slap the bastard who put that "cute" feature in.

Oh, and literals starting with "0" are interpreted as octal. Cute Marie, real cute. That feature almost got me fired from a contract once because the customer didn't believe such a design flaw could exist in a common language, thinking it was my fault. There's probably only 7 JavaScript programmers who use lots of octal literals; why the hell did you ignore the other 99.999%? Were you targeting cephalopod coders?

And JS lacks typical string- and date-handling functions. Lots of octal-friendly shit and no fucking strings; must be cephalopods.

--
Table-ized A.I.

Isn't it obvious? by dbIII · 2014-07-01 21:29 · Score: 2

With regexes typically more comments than code just like anything tricky to understand instantly in any language. With the rest just as needed for understanding.
Consider the Carmack transform in C. Can you work out what it's there to approximate instantly based on that line of code without being told? It's things like that and very complex regexes that need the implications listed while the hundreds of lines around them probably don't.

Slashdot Mirror

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

78 of 536 comments (clear)