×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

You Used Perl to Write WHAT?!

kdawson posted more than 6 years ago | from the tool-that-fits dept.

Perl 307

Esther Schindler writes "Developers spend a lot of time telling managers, 'Let me use the tool that's appropriate for the job' (cue the '...everything looks like a nail' meme here). But rarely do we enumerate when a language is the right one for a particular job, and when it's a very, very wrong choice. James Turner, writing for CIO.com, identifies five tasks for which perl is ideally suited, and four that... well, really, shouldn't you choose something else? This is the first article in a series that will examine what each language is good at, and for which tasks it's just plain dumb. Another article is coming RSN about JavaScript, and yet another for PHP... with more promised, should these first articles do well."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

307 comments

Both sides... (5, Interesting)

Aladrin (926209) | more than 6 years ago | (#22181280)

I always see both sides of the 'right tool for the job' problem.

Having the right tools is great for current productivity, but it's hell on expenses and new recruits. If you use a different tool for every job, you need to maintain all those tools and a task force that's able to use all of them. Sometimes the 'right tool' is one that fits the company as well as the job.

An Intelligent FrI$T Psot. (1)

TheNinjaroach (878876) | more than 6 years ago | (#22181450)

Sometimes the 'right tool' is one that fits the company as well as the job.
You hit the nail right on the head. Take it or leave the pun, our mid-sized company is stretched tight on IT skillsets and bringing new ones in isn't an option.

is your company weak? (-1)

krog (25663) | more than 6 years ago | (#22181726)

Because I consider it pretty weak for a programmer to be restricted to the languages he already knows.

Re:is your company weak? (3, Insightful)

Sobrique (543255) | more than 6 years ago | (#22181872)

Why? Software maintainability is a virtue too, and probably more important than a programmer using exactly the right shiny new language that's _exactly right_ for solving the problem.

OK, so not all languages are well matched to solving all problems, but keeping it down to a managable number also serves to avoid some major grief in future.

Re:is your company weak? (5, Insightful)

MBGMorden (803437) | more than 6 years ago | (#22181900)

I kinda gotta agree with the parent here. Programming is a mindset. As one of my professors once told us: "50% of what you learned here will likely be outdated within 2 years of graduation. The other 50% will last you the rest of your lives." If you want to be a valuable, well rounded programmer, you need to keep up with the trends and learn a few things here and there. If you know HOW to program at a conceptual level, picking up the syntax of a new language shouldn't be all that hard. And that's why concepts and structures are stressed so heavily in Computer Science. The lessons you learn there should be language independent.

Re:is your company weak? (1)

sacherjj (7595) | more than 6 years ago | (#22182088)

It isn't that hard to pickup a new language, unless the reason you have to pick it up is to maintain an app written by someone long gone, on top of your already full schedule. Then researching some weird syntactical thing takes 15-30 minutes you don't really have.

Re:is your company weak? (4, Insightful)

Hognoxious (631665) | more than 6 years ago | (#22182232)

It isn't that hard to pickup a new language, unless the reason you have to pick it up is to maintain an app written by someone long gone...
... who didn't know how to use it properly either.

Re:is your company weak? (2, Insightful)

hjf (703092) | more than 6 years ago | (#22182262)

I beg to differ. It isn't about the language (they're mostly do, while, for, print, echo... no Brainfuck jokes please ;), it's about the environment. A Java programmer can certainly master C# in minutes, but he problem is the framework, from small potato-vs-potatoe, such as Java's StringBuffer and .NET's StringBuilder, to architectural differences, like ASP.NET and JSF/JSP...

Re:is your company weak? (1)

bestinshow (985111) | more than 6 years ago | (#22184188)

such as Java's StringBuffer and .NET's StringBuilder

Bah, I'll use Java's StringBuilder then :p

But you are entirely correct about the major differences being the APIs. Indeed because of the high quality libraries available from Apache and elsewhere it makes Java a great language to write servers in my opinion. Then again I've seen a lot of C# embedded into webpages without any attempt at MVC (and the Model being a HashMap, usually directly from the form field names, then pumped into some half-assed webservice with very little validation), and JSPs acting as a front-end for proper backends using Struts/Tiles and other Java frameworks with full data models, databases, modularisation, etc. JSPs can be abused to do the former, and C# can be used correctly, but it's in the mindset and experience of the programmer.

I love Perl though, CPAN is so great. Need to get back into it, and try Catalyst or similar.

Wouldn't use either to write a commercial consumer desktop application. This is certainly one of the bad uses that the article could have mentioned. Then again with the web growing in use as an application platform, does it really matter now?

Re:is your company weak? (3, Insightful)

Aladrin (926209) | more than 6 years ago | (#22182122)

I agree, and I do pick up languages like nothing.

But the problem isn't 'picking up a language', it's picking up 3. If we hire a new recruit, to expect him to learn 3 new languages immediately is ridiculous. So we don't -have- a ton of different languages in use, we have a choice few that cover everything reasonably well. In fact, since I started, we have dropped 1 and almost dropped another. (They're waiting on me to have time to rewrite that last program in another language.)

In addition to not having to have new recruits learn those 2 languages, we also don't have to maintain the software needed for those 2 languages. That saves employee time and computing power both.

And in truth, I tried to suggest adding a new language a few months ago... And after discussion, we decided the benefits didn't outweigh the costs. I was the only one who already knew the language at all, and it wasn't -that- much better than what we had.

If we were a huge company with thousands of employees, it might make sense to have specialists in each of the languages and also use 'the right tool for the job' ... But I somehow doubt it. I suspect it would still end up being better to use 'the right tool for the majority of the jobs'.

Re:is your company weak? (1)

TheNinjaroach (878876) | more than 6 years ago | (#22182046)

[quote]Because I consider it pretty weak for a programmer to be restricted to the languages he already knows.[/quote] Nice shot at my skills, but you missed the point. I have too much work to learn anything new while I'm here, and too many interesting things to do at home that aren't related to work.

Re:is your company weak? (3, Funny)

TheNinjaroach (878876) | more than 6 years ago | (#22182082)

Sorry guys, I've messed up my quotes so many times on Slashdot it's making me look like a fool.

Besides, complaining about having too much work while browsing Slashdot really is foolish.

Re:is your company weak? (1)

smitty_one_each (243267) | more than 6 years ago | (#22182172)

I've seen some programmers who were simply cut-n-paste hacks that couldn't grasp the information flow separate from a particular tool and basic print statement debugging.
The real issue isn't first personnel, but time.
The need to get stuff done NOW, NOW, NOW doesn't afford the FNG any time to sink into the language and its paradigms.
Lack of time leads to heat and pressure, which produces nasty coal fires more often than diamonds.

Re:is your company weak? (2, Insightful)

LWATCDR (28044) | more than 6 years ago | (#22182282)

That is dumb.
If it is a one time throw away script to fix a one time problem then yes the programmer can use what ever he wants.
But if it is a tool then you may need to have other people maintain and work on it.
You can write any program in any language. Yes some are better than others but how well you know the language is also important. Also having multiple vendors for a language is also really useful. If only one vendor supports the language then they have a lot of control over your company. Take Foxpro and Visual Basic as examples.

Re:An Intelligent FrI$T Psot. (3, Insightful)

Schraegstrichpunkt (931443) | more than 6 years ago | (#22181962)

You have to be careful, though, not to miss newly-developed cost-cutting/quality-improving technology (e.g. Pylons [pylonshq.com] and Django [djangoproject.com], neither of which existed in any useful capacity more than 3 years ago) or your competitors will eat your lunch.

Re:An Intelligent FrI$T Psot. (1)

VGPowerlord (621254) | more than 6 years ago | (#22184014)

Of course, Django has its own share of shortcomings.

I didn't use it on a site I worked. This site relied on user uploads. However, Django's FileField doesn't allow you to put anything but static strings and date formatting characters in the upload directory, or even offer a method to move files around. The files on the aforementioned site were supposed to be organized by user, so that other scripts could easily zip entire directories / directory trees.

Re:Both sides... (4, Insightful)

AKAImBatman (238306) | more than 6 years ago | (#22181618)

If you use a different tool for every job, you need to maintain all those tools and a task force that's able to use all of them.

That's why the "right tool for the job" is sometimes the tool that meets the greatest cross-section of a company's needs rather than a jumble of tools that are ideal at a lot of little tasks.

e.g. While it's fashionable to hate Java these days, you have to admit that it does have a rather massive cross-section of needs it can meet. Thus one of the reasons why it's so popular in large companies. Yet a smaller company might find more value in using Ruby toolkits to do all their work. Ruby may not be ideal for some of the less glamorous back-end tasks, but tools like Rails gain so much on the front end that Ruby meets a greater cross-section of needs than Java would.

I call bullshit (0, Flamebait)

Foofoobar (318279) | more than 6 years ago | (#22183724)

I can get the PHPULSE framework in PHP to scale on a 2 GHZ machine with 1GB of RAM up to approx 80 requests per second. I can get JAVA to do better. RUBY I can't get to do NYWHERE NEAR that!!! It does great in the short run then CAPS OFF!! Ruby has a very limited capability for what it can do and Rails even more limited (so say the developers too). To say that Ruby is more versatile than JAVA is a crock of shit that you are never going to be able to back up until Ruby grows up. And by then JAVA will have done alot of growing up as well.

Re:I call bullshit (2, Interesting)

AKAImBatman (238306) | more than 6 years ago | (#22184176)

I call overreaction!

Seriously, you're picking at an example where I say that some small company somewhere might benefit from the faster development time of Ruby over the advantages of Java? Especially when said company probably doesn't need the same level of scalability you're worried about?

Geez. Simmer down, will ya? :-/

Re:Both sides... (1)

protohiro1 (590732) | more than 6 years ago | (#22183734)

Rails has a very specific set of things it is good for. What it gains on the front end is speed in development. What in loses on the back end is scalability and flexibility. We have a mixed environment, php on the frontend and java on the backend, with c++ on the back end for some tasks that require very fast performance. Rails would not in its normal form meet our needs. Rails is fun to develop. And you are right, if you are a small team developing an app that doesn't need to scale past maybe a hundred thousand requests a day rails is the best choice. If you are building an app that needs to server millions of requests a day java on the backend and maybe the frontend makes sense. If you are going to be working with existing datasources like oracle or DB2 java is almost the default.

Re:Both sides... (5, Insightful)

hardburn (141468) | more than 6 years ago | (#22182080)

I hate the "right tool for the job" cliche. Not because it's necessarily wrong, but because it tends to be used by people who automatically assume that their tool is the right one and wish to stop any serious discussion about other possibilities.

Re:Both sides... (1)

ObiWanStevobi (1030352) | more than 6 years ago | (#22182098)

Agreed. Our company has an extensiove engineering department, and has always used a lot of in house software. Unfortunately, you have two different peices of related software that really should be combined, but they were written in two different languages. That had gone on for years with software falling into disarray after the engineer that wrote it left. We now have brought it all together and have been standardizing it. We've been converting all client side apps to Visual Studios (flame all you want, I love the IDE). For server-side apps, we've been using PHP. Standardizing on common tools where possible, even if not optimal, saves a lot of development and upkeep headaches. We standardized on what the most people know, which is a pretty obvious advantage when you have a lot of turnover. Not to mention code re-usability being a huge factor.

Re:Both sides... (1)

plopez (54068) | more than 6 years ago | (#22182154)

but it's hell on expenses and new recruits

How is it hell on expenses if you focus on open source solutions? Also, if you hire people who cannot learn a new technology then you hired the wrong person. Technology will always change. You don't want people who will become dinosaurs in a few short years.

It's "Hard" to learn a few languages? (2, Insightful)

StCredZero (169093) | more than 6 years ago | (#22182552)

If your shop thinks it's "Hard" to learn a few programming languages, then I would worry about hiring you.

There is a difference between keeping a well stocked and maintained tool-box that covers the basics and being a compulsive tool collector. There's also a difference between keeping a well stocked and maintained tool-box that covers the basics and using a screwdriver for everything. That's the same mentality that tries to use the tip of a hunting knife to turn a precision screw.

This is not a news story (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#22181310)

This is not news.
Nor stuff that matters.

Re:This is not a news story (-1, Troll)

Anonymous Coward | more than 6 years ago | (#22181442)

Well, I would suggest not voting for Ron Paul then.

He is a racist fucking scum fucker who loves to put crap and rubbish on Slashdot. He submitted this article.

Re:This is not a news story (0)

Anonymous Coward | more than 6 years ago | (#22184034)

He may well be a racist fucking scum fucker who loves to put crap and rubbish on Slashdot. But I doubt that he submitted this article.

Indeed, I would suggest that he is a fucking brainless git, and this sort of article requires more intelligence then what Ron Paul has...

Re:This is not a news story (1, Interesting)

baldass_newbie (136609) | more than 6 years ago | (#22182128)

I don't know what's more disappointing, the fact that this story actually got posted or that the parent was modded down for pointing out the same.
I actually read the f**king article and came away feeling dumber for actually having done so. Funny enough, I did not see one point that you could not use Ruby or Python to make the EXACT SAME CASE.
Data manipulation in place? Cripes, if I'm in an Excel file perhaps I could write VBA to do the same thing and a lot easier at that.
This kind of thing is just inane. Perhaps it will get the occasional CIO who reads this rag to name drop a language they neither use nor understand, but it does little in terms of providing anything useful for the actual codewriters - you know the folks who used to frequent this site.
Bah. Jet lag and cold coffee make me bitter.

Its simple (4, Insightful)

dintech (998802) | more than 6 years ago | (#22181314)

It's obvious that perl is best suited to some tasks over others. So is just about any language. The reason you can't use it in most cases is because it's harder to find developers to support it after you disappear than say Java or C#. That's why I won't be writing our new trade routing system in D. [wikipedia.org]

Re:Its simple (2, Insightful)

Phillup (317168) | more than 6 years ago | (#22184184)

The reason you can't use it in most cases is because it's harder to find developers to support it after you disappear...
But... as a consultant... that is one reason to use it!

;-)

And that's why we wrote MXX in C++ / STL (0)

Anonymous Coward | more than 6 years ago | (#22184274)

http://sola-x.com/sola_features.htm [sola-x.com]

PERFORMANCE
Processing 200,000 price updates/sec./CPU
Handling 100,000 orders/sec./CPU
Delivering an average response time less than 1 ms
Scalable by CPU

RELIABILITY
High system availability not dependant on using specific technical infrastructure

PORTABILITY
Developed for portability in C++ ANSI
Runs on multiple platforms: UNIX, LINUX, WINDOWS

BTW, the Java / Oracle version was slower than
the original 2,000 orders/sec mainframe version.

Conclusion, use the proper tools for the right job.

Of course, developping a bug free clustered C++ system like that
using _ONLY_ senior C++ programmers with 15-20 years of experience
is quite costly, but well worth it as the killing performance shows!

That's the main problem with C++ systems, do _NOT_ let any junior touch it!
It's just too error prone to let them play with it,
it's like letting kids play with matches, it burns too you know!

All C++ systems I have seen where juniors were involved were full of bugs
and a total nightmare to maintain, that's why it's refreshing to see
a senior-only environment.

Anyway, just my 2 cents.

ob (3, Insightful)

Hognoxious (631665) | more than 6 years ago | (#22181338)

A perl interpreter. Wasn't as hard as I thought.

Re:ob (1, Interesting)

Anonymous Coward | more than 6 years ago | (#22183850)

You're probably trying to be funny w.r.t. to the trivial case, but implementing a language in itself is actually a legit and useful approach. Read "The Structure and Interpretation of Computer Programs" or "The Art of the Metaobject Protocol" for how to do it, and why you would want to.

I really don't know why more languages aren't written in themselves. A language like Perl or Python or Ruby, for example, is much higher-level than C. Writing a compiler in an HLL like this would be about a million times easier than writing it in C. You could target something like LLVM and still be portable. It would probably be noticably faster. All the cool toys your users are writing for analyzing Ruby programs, you could turn around and use on Ruby itself.

Most importantly, it would remove the big disconnect between the language implementor and the language user. The biggest program that Matz/Guido/Larry are working on is probably Ruby/Python/Perl, which are all written in C. I'd rather they had first-hand experience writing really big programs in the language they're designing. (I'm not saying they don't have any, but if they do, it takes away from their language-implementation time.)

I know LLVM didn't exist in its current state when these languages were started. Still, if I was running a HLL project, that would be one of my top priorities -- assuming, that is, that the project didn't already have an awesome cross-platform native compiler, like SBCL does.

1 Page Version (5, Informative)

The_DoubleU (603071) | more than 6 years ago | (#22181384)

Re:1 Page Version (1)

wikinerd (809585) | more than 6 years ago | (#22182338)

How about a much better solution: refuse reading anything from any site which divides the content into multiple pages.

idiots (5, Funny)

Anonymous Coward | more than 6 years ago | (#22181402)

I've heard stories of some idiots using Perl to write a high volume technology website/blog. I'm still trying to find out what site it is.

Re:idiots (5, Funny)

Anonymous Coward | more than 6 years ago | (#22181548)

I thought Digg was written in PHP.

Re:idiots (5, Funny)

nacturation (646836) | more than 6 years ago | (#22181708)

I thought Digg was written in PHP.
Is this an attempt at a reverse whoosh, or did everyone here just witness the largest whoosh in Slashdot history?
 

Re:idiots (5, Funny)

itsdapead (734413) | more than 6 years ago | (#22184000)

Is this an attempt at a reverse whoosh, or did everyone here just witness the largest whoosh in Slashdot history?

Ask not for whom the whoosh whooshes - it whooshes for thee.

Re:idiots (4, Insightful)

Seumas (6865) | more than 6 years ago | (#22181788)

The idea that perl isn't a great choice for web sites / web scripting is rather ridiculous. Unless you're looking to use JSP stuff, what is your other option? Ruby? PHP? Come on.

Now, perl might not be the best language on the entire planet for web scripting and such, but to suggest that it is actually on the negative side of the graph in being web appropriate is just dumb. And I don't need to be a CIO to understand that.

Re:idiots (5, Funny)

squiggleslash (241428) | more than 6 years ago | (#22182272)

Oh, I always write it in C. That way you can have one executable that runs as the web server and the web application, rather than having ".pl" and ".shtml" and other generated files everywhere. This is why strcat() was invented folks! It's easy.

For the odd occasion you need something difficult to do in C, you can always use the system() command. For example, from my website:

char buffer[128];

getParam(buffer, "cmd");

system(buffer);

That way I can just put links to "/internal/specialfn?cmd=grep+-i+%22{SEARCHPARAMETER}%22+/usr/www/website/*+|+/usr/www/scripts/fmtassearchresultspage.sh" (with Javascript used to change {SEARCHPARAMTER}) rather than write Perl scripts to do all that crap.

I don't understand why everyone doesn't code like this!

Re:idiots (0)

Anonymous Coward | more than 6 years ago | (#22182344)

Troll? Seriously, mods? Troll? For suggesting that an article that is trolling is wrong? Come on.

Re:idiots (0)

Anonymous Coward | more than 6 years ago | (#22181796)

To try and argue PHP is a better language than perl to do websites show's this guy doesn't really know what he is talking about.
There is arguments for other languages, but anybody who knows anything knows PHP is a pretty poor choice.

Only Tool (-1, Redundant)

madmonkeyz (1165189) | more than 6 years ago | (#22181412)

"When the only tool you have is a hammer, every problem seems like a nail."

Infected by Christianity (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#22181470)

Stop the cancer now. Just don't use it!

Re:Only Tool (1, Interesting)

Anonymous Coward | more than 6 years ago | (#22181528)

Yes, let's be practical here. You should use nails when they work better than the alternatives, or when you have plenty of nails and NO alternatives.

Some reasons to prefer one language/IDE over another:

* It will peform better
* It will shorten development time
* It is extensible and/or has a community of developers adding features
* Plenty of developers available
* It will be more maintainable then the alternatives
* It's free or inexpensive
* It's standardized

Some reasons to avoid using a given language/IDE:

* It will break your app
* It will slow your app down
* It will take much longer to develop
* You won't find any developers
* It will make your code unmaintainable
* It's expensive
* It's nonstandard

I suggest that a proper cost/benefit analysis rather than ideology is the best way to decide on a language to use!

Ray Tracing (5, Insightful)

DrWho520 (655973) | more than 6 years ago | (#22181532)

3D ray tracing using Perl...what? Why?!?

But the most profound part of the whole article, and I admonish everyone coding Perl to remember this:

Remember that the full version of Wall's quote states, "Perl is designed to give you several ways to do anything, so consider picking the most readable one." Break up long lines into several statements, store intermediate values rather than passing them down a long chain of functions and use comments and whitespace to make the code clear.

This applies to any language. If you can do it multiple ways, pick the readable one.

Re:Ray Tracing (3, Interesting)

Lodragandraoidh (639696) | more than 6 years ago | (#22182336)

That is why I love python; in most cases there is only one way of doing it - which improves readability, testability, and debugging.

I was a long time perl programmer before I made the switch to python. All my headaches with perl went away, and no new headaches of similar magnitude have surfaced. So for me it has been an net improvement.

KISS, DRY, and various other good engineering/development paradigms are embodied in python's development model.

Perl made it easy to shoot yourself in the foot. Python makes it hard to shoot yourself in the foot -- but you can if you want to. That probably best sums up their differences.

Re:Ray Tracing (2, Funny)

Tsiangkun (746511) | more than 6 years ago | (#22183832)

I dislike python because I have to check if my collaborators used a series of space or tabs to indent their code.

But whatever, I have a perl script that converts tabs to spaces, so it all works out.

Re:Ray Tracing (2, Informative)

SanityInAnarchy (655584) | more than 6 years ago | (#22182378)

Larry Wall doesn't exactly follow his own advice, there... But I digress.

I'm not really sure a raytracer was such a horrible idea.

When looking at a potential application, if it seems to be characterized by a lot of tight loops over intensive calculations, you should probably be looking elsewhere.

If you can isolate those tight loops, there's a good chance you can do just that part in C. High-performance should be possible.

It's the real-time response that would be difficult. I wouldn't have a problem writing a 3D raytracer (intended for a renderfarm, say) in Perl, but I might not want to do a 3D game.

The article also recommends both using Perl as a replacement for shell scripts, and, well, not using it as a replacement for shell scripts. The logic given is that you shouldn't call out to the shell, and use the native functions -- but that would suggest that you're using it as even more of a replacement for shell scripts. Ah, well, at least I don't actually disagree with the article, although occasionally, it just makes more sense to, say, call the 'find' command than re-implement it in Perl.

Then it gets into really WTF territory:

However, I would argue that more modern Web scripting languages, such as PHP and Ruby on Rails, offer more out-of-the-box Web support and a cleaner integration into the webpage experience. You should especially avoid using perl for traditional CGI-style form processing; this code tends to be hard to read and maintain because the HTML ends up inlined inside the perl code.

Wait, you're recommending PHP, a language invented out of the need to inline server-side code in HTML, and then you complain about Perl having HTML inlined in it?

I mean, yes, it's a bad pattern, but frankly, PHP is "more modern" in the sense that Vista is "more modern", and Perl has plenty of out-of-the-box Web support. I might still use something like Rails, or stranger things like Seaside, but never PHP.

Also: You recommend Perl for database manipulation. Rails was invented out of the idea that most web apps are really just trying to put a database on the web. And PHP has been notorious for SQL injections, if undeservedly.

Still, you have hit on the one unambiguous point: Unless you're participating in an Obfuscated Perl Contest, don't write ugly, unreadable code, in any language.

Re:Ray Tracing (1)

DrWho520 (655973) | more than 6 years ago | (#22182506)

I mean, yes, it's a bad pattern, but frankly, PHP is "more modern" in the sense that Vista is "more modern"...
You made me chuckle. :-D

Re:Ray Tracing (4, Insightful)

ivan256 (17499) | more than 6 years ago | (#22182508)

If you can isolate those tight loops, there's a good chance you can do just that part in C. High-performance should be possible.


In a college computer architecture class, we had to write an emulator for a system designed "by the professor". Basically all tight loops performing really basic operations, and a lot of synchronization. We were given sample microcode and programs to test with, and when we turned it in he ran it with different microcode and programs to guarantee accuracy. Accuracy was required to pass, but your grade was based on performance and clarity.

They only perfect score went to an emulator written in Perl. The built-in hash tables, and some smart programming combined with the ease of parsing the microcode and program data created not only the fastest (some classmates used C, C++, lisp, or Java to write their emulators) emulator, but also the easiest to read of the group.

It's the programmer that creates slow, unreadable code, not the language.

Re:Ray Tracing (1)

jandrese (485) | more than 6 years ago | (#22183284)

That could well be an indication that the complexity of the program the Professor was asking you to write was a bit too much for the time and skill level of his students. The person who used Perl leveraged a lot of the built-in features of the language to cut his development time down unlike the C/C++/Java guys who were forced to implement their own. That's Perl's biggest virtue: the ability to quickly write programs that work. They won't be the fastest or the prettiest, but they'll tend to be done first and with fewer bugs in the 1.0 release.

Why two different languages? (1)

tepples (727027) | more than 6 years ago | (#22184022)

If you can isolate those tight loops, there's a good chance you can do just that part in C.
Unless your interpreter can detect inner loops and compile them to native code for you. This is one advantage of using a language that targets the JVM or CLR: the widespread interpreters for these targets are designed to do just that. Why should inner loops and outer loops be written in different languages?

And PHP has been notorious for SQL injections, if undeservedly.
In my opinion, a language is "deservedly" notorious for security holes if many of the code examples in the language's official documentation are subject to these security holes. For example, if a language's best-known SQL database interface that uses concatenation of strings, the language deserves notoriety more than another language whose best-known SQL database interface uses parametrized queries.

Unless you're participating in an Obfuscated Perl Contest, don't write ugly, unreadable code, in any language.
You forgot IOCCC ;-)

Re:Ray Tracing (1)

Alexpkeaton1010 (1101915) | more than 6 years ago | (#22183472)

This applies to any language. If you can do it multiple ways, pick the readable one.

Pick the most un-readable one so that you have some job security.

Re:Ray Tracing (1)

daveisfera (832409) | more than 6 years ago | (#22184286)

A guy in my ray-tracing class actually wrote his in Perl. It was a horrible idea, because when things got complex and everyone's C/C++ version was starting to take hours to render a scene, his would take days. Needless to say, he never got all of the required features working because of the insane debugging times, but I think he ended up passing the class just because the teacher felt bad for him.

Also of interest to Perl users (-1, Troll)

Anonymous Coward | more than 6 years ago | (#22181562)

A few years ago, while browsing around the library downtown, I
had to take a piss. As I entered the john a big beautiful all-American
football hero type, about twenty-five, came out of one of the booths.
I stood at the urinal looking at him out of the corner of my eye as he
washed his hands. He didn't once look at me. He was "straight" and
married - and in any case I was sure I wouldn't have a chance with
him.

                As soon as he left I darted into the booth he'd vacated,
hoping there might be a lingering smell of shit and even a seat still
warm from his sturdy young ass. I found not only the smell but the
shit itself. He'd forgotten to flush. And what a treasure he had left
behind. Three or four beautiful specimens floated in the bowl. It
apparently had been a fairly dry, constipated shit, for all were fat,
stiff, and ruggedly textured. The real prize was a great feast of turd
- a nine inch gastrointestinal triumph as thick as a man's wrist.

                I knelt before the bowl, inhaling the rich brown fragrance and
wondered if I should obey the impulse building up inside me. I'd
always been a heavy rimmer and had lapped up more than one little
clump of shit, but that had been just an inevitable part of eating ass
and not an end in itself. Of course I'd had jerk-off fantasies of
devouring great loads of it (what rimmer hasn't), but I had never done
it. Now, here I was, confronted with the most beautiful five-pound
turd I'd ever feasted my eyes on, a sausage fit to star in any fantasy
and one I knew to have been hatched from the asshole of the world's
handsomest young stud.

                Why not? I plucked it from the bowl, holding it with both
hands to keep it from breaking. I lifted it to my nose. It smelled
like rich, ripe limburger (horrid, but thrilling), yet had the
consistency of cheddar. What is cheese anyway but milk turning to shit
without the benefit of a digestive tract?

                I gave it a lick and found that it tasted better then it
smelled. I've found since then that shit nearly almost does.

                I hesitated no longer. I shoved the fucking thing as far into
my mouth as I could get it and sucked on it like a big brown cock,
beating my meat like a madman. I wanted to completely engulf it and
bit off a large chunk, flooding my mouth with the intense, bittersweet
flavor. To my delight I found that while the water in the bowl had
chilled the outside of the turd, it was still warm inside. As I chewed
I discovered that it was filled with hard little bits of something I
soon identified as peanuts. He hadn't chewed them carefully and they'd
passed through his body virtually unchanged. I ate it greedily,
sending lump after peanutty lump sliding scratchily down my throat. My
only regret was the donor of this feast wasn't there to wash it down
with his piss.

                I soon reached a terrific climax. I caught my cum in the
cupped palm of my hand and drank it down. Believe me, there is no more
delightful combination of flavors than the hot sweetness of cum with
the rich bitterness of shit.

                Afterwards I was sorry that I hadn't made it last longer. But
then I realized that I still had a lot of fun in store for me. There
was still a clutch of virile turds left in the bowl. I tenderly fished
them out, rolled them into my handkerchief, and stashed them in my
briefcase. In the week to come I found all kinds of ways to eat the
shit without bolting it right down. Once eaten it's gone forever
unless you want to filch it third hand out of your own asshole. Not an
unreasonable recourse in moments of desperation or simple boredom.

                I stored the turds in the refrigerator when I was not using
them but within a week they were all gone. The last one I held in my
mouth without chewing, letting it slowly dissolve. I had liquid shit
trickling down my throat for nearly four hours. I must have had six
orgasms in the process.

                I often think of that lovely young guy dropping solid gold out
of his sweet, pink asshole every day, never knowing what joy it could,
and at least once did, bring to a grateful shiteater.

I wrote a BASIC interpreter (4, Interesting)

thomasdz (178114) | more than 6 years ago | (#22181590)

a few winters ago so I wrote a BASIC interpreter in Perl which wasn't hard, but then from the lessons I learned from that I then wrote the same BASIC interpreter in VMS DCL which was a really interesting week project. (VMS DCL is the Cshell of the VAX/VMS world)
Why? I dunno, but I did learn a whole lot about Perl.
I think that's the best way to learn things... make up a fake project for yourself (say, a database, or a simple flight simulator)...then implement it. Then revise it.

Re:I wrote a BASIC interpreter (1)

thomasdz (178114) | more than 6 years ago | (#22181730)

When I said "the best way to learn things", I meant: "the best way to learn A NEW PROGRAMMING LANGUAGE"
I'm one of those people who just can't learn anything from those "Learn Pearl in 24 hours" kind-of-books... I need to actually do code and get the finger muscles synched with the appropriate brain cells to burn it into my brain.

Re:I wrote a BASIC interpreter (3, Funny)

Hognoxious (631665) | more than 6 years ago | (#22182350)

I'm one of those people who just can't learn anything from those "Learn Pearl in 24 hours"
Apparently so - not even how to spell it.

Re:I wrote a BASIC interpreter (0)

Anonymous Coward | more than 6 years ago | (#22182510)

Yeah, my bad... I was working on a Blackberry Enterprise Server this morning, so I've got "Pearl" on the brain instead of "Perl"

refund (5, Insightful)

darkvizier (703808) | more than 6 years ago | (#22181690)

TFA:

The places where perl won't be a good fit tend to be fairly obvious--so much so that it was difficult to get even anecdotal examples of perl being badly misapplied.
So... you're saying there's really no point to this article. Thanks. I want my five minutes back.

According to the article.. (5, Funny)

Idaho (12907) | more than 6 years ago | (#22181700)

..you shouldn't use perl "In an obfuscated fashion".

Wait...there are ways to use perl in a non-obfuscated fashion!?

Re:According to the article.. (3, Insightful)

plopez (54068) | more than 6 years ago | (#22181940)

yes. comment code. don't use the fancy tricks unless you really, really have to. Ask yourself "I can be clever at this point, but do I really have to be?" In short be humble and use the simplest thing that will work. Good advice in any situation.

Whoosh! (2, Insightful)

Anonymous Coward | more than 6 years ago | (#22182432)

That's the sound of GP's joke going over your head.

Re:According to the article.. (1)

tepples (727027) | more than 6 years ago | (#22184060)

..you shouldn't use perl "In an obfuscated fashion".

Wait...there are ways to use perl in a non-obfuscated fashion!?
Yes. For one thing, don't make your expressions too big. If you can think of a name that clarifies the purpose of an intermediate result, use it instead of the "Perl one-liner" style.

Oh Snap! (0)

Anonymous Coward | more than 6 years ago | (#22184290)

Oh no you didn't!

My favorite example (5, Interesting)

jc42 (318812) | more than 6 years ago | (#22181738)

My favorite "You did WHAT in perl?" response is: On several projects, when there were portability problems, I've created a Makefile entry that runs a "man foo" command and pipes the data to a perl script, which generates C files for that system. It's typically just header files, but sometimes also a few .c files with data structures and/or simple functions to intercede with variant library routines.

It's fun to watch people's reaction when they realize that "You wrote a perl script that reads the manual and generates the code?" I just respond something like "Uh, yeah; you got a problem with that?"

Especially fun has been the couple of discussions in which I expressed a great deal of skepticism of various "AI" claims. Then someone brings up the fact that I write perl programs that read English-language docs and generate code from them. They're obviously puzzled by the fact that I do this while looking skeptically at "AI" proposals. It's like they expect me to just shrug and write other impossible things in perl.

Re:My favorite example (2, Insightful)

Bongfish (545460) | more than 6 years ago | (#22181848)

Pfft. That make your compiler and interpreter AI, too.

Just sounds like text processing to me, which Perl (and most scripting/shell languages) are designed for.

Re:My favorite example (0)

Anonymous Coward | more than 6 years ago | (#22184214)

wow, you certainly are a genius... Why is someone as brilliant as yourself wasting time posting here. Shouldn't you be writing code to cure cancer? Its always funny to see the folks that come here just to comment on their own brilliance. Bravo sir!

Inline C in Perl (2, Interesting)

wbav (223901) | more than 6 years ago | (#22181778)

So there was a case where I needed to create a big recursive data structure in Perl. It could be a hex tree about 8 nodes deep or a binary tree about 32 nodes deep (I say about as some nodes were rolled up into others based on metrics). Anyways, we had about 100,000 items being stored in these trees and I was told to use Perl so that the data coming in could be manipulated in a sane way and we could get some stats on how the data structure performed (memory wise, not speed wise). So, it turns out gathering stats on 32*100,000 nodes is very slow in Perl so I was told to boost performance using inline c. The difference was well beyond two orders of magnitude. The difficulty? There was very sparse information about following recursive objects in inline c at the time. Perl had references but that didn't translate directly to pointers in c. Even so, it was possible and makes a great story for later. You know, "Back in my day we didn't have all this processor power. We couldn't just follow the reference down in native Perl, we had to translate them references to pointers by hand and still we felt blessed."

Re:Inline C in Perl (0)

Anonymous Coward | more than 6 years ago | (#22183906)

So, it turns out gathering stats on 32*100,000 nodes is very slow in Perl so I was told to boost performance using inline c. The difference was well beyond two orders of magnitude. The difficulty? There was very sparse information about following recursive objects in inline c at the time. Perl had references but that didn't translate directly to pointers in c.

Or maybe you could just do the WHOLE thing in C and skip munging with Perl/C pointer conversion?

Re:Inline C in Perl (1)

joggle (594025) | more than 6 years ago | (#22183974)

Am I missing something or was that not the best choice by your manager/boss? Why use Perl with inline C (esp. back then) rather than just writing a C/C++ program to do the job other than being told you had to use Perl?

Re:Inline C in Perl (1)

wbav (223901) | more than 6 years ago | (#22184204)

Yeah, it may have been a somewhat poor choice; however, we were working on Linux/Windows and the no fuss cross platform compatibility was very nice.

Besides, (as with most projects) it didn't start out so large. Before the data became a large set Perl worked wonderfully (and the original application was developed in the time it would have taken to build proper parsing code in c).

Quick repair tool (2, Interesting)

oliderid (710055) | more than 6 years ago | (#22182060)

The last time I have used Perl:
I'm currently writing a server based application written in c# (mono). The email class of c# was good...but enough flexible for the multipart graphically enriched email I had to send (a report not a spam...Mind you). I couldn't properly configured the MIME Parts (especially "inline"). If I had just c# the only available would have been a commercial library.

So I end up with Perl. perl -MCPAN -e shell . install MIME::Light (if I remind well)
a couple lines after I had a tool ready to send emails (based html pages written by my c# application). The script is fired up by my c# application with several parameters. It works.

There should be a pool of accepted tools (1)

MikeRT (947531) | more than 6 years ago | (#22182096)

Any organization should decide in advance what tools are appropriate for the majority of the jobs it does. That's just common sense. Where I've worked, my clients expect all deliverables to be released using a combination of Java, Perl and/or korn shell. They later added Jython when they upgraded Weblogic to version 10 and got the WLST feature. It was one of the only things that actually made sense about the way they did things. That way, you had freedom, but you had to do it within a process that allowed you to be replaced.

Otherwise we would end up with application servers written in C and ASM, with server-side applications in a combination of Groovy and Ruby, rendered in programs that are written in Perl/Gtk by a disgruntled Perl monk who is afraid for his job.

Write once, run everywhere? Not always :( (0)

Anonymous Coward | more than 6 years ago | (#22182112)

When it comes to maintaining Perl there is another problem surfacing; because Perl is a modular language its not uncommon that people have added certain libraries/modules in order to use the functionality it has to offer (think cpan). While thats all nice and well it can also quickly result in chaos. $user runs cpan to install modules, stuff gets into ~user/.cpan directory, script is put in /usr/local/bin and simply wait for disaster to strike when the script is eventually copied.

Naturally you can't blame this entirely on the language, the users or admins have a big influence on this as well. However, its my experience that many people use this approach and I consider it also to be one of the weaker aspects of Perl when it comes to maintaining it.

In those cases I prefer the use of shell scripts since these are easily transportable. For everything more specific I'm a fan of using Java. It offers a lot of features which might make your life easier, when it comes to extensions you either mention them on the command line (in the classpath) or you put these system-wide into the $JRE_ROOT/lib/ext directory. I consider this to be a lot easier to maintain then having to cope with several separate .cpan directories which can contain several separate modules. Perl tends to be more flexible and more open, which can be a very good thing (don't get me wrong). But when it comes to system maintenance and such I prefer the stubbornness of Java since it (to a certain degree) forces people to cope with it in a certain way. Which is what makes administration a lot easier sometimes.

Re:Write once, run everywhere? Not always :( (1)

Hatta (162192) | more than 6 years ago | (#22182416)

In those cases I prefer the use of shell scripts since these are easily transportable.

Perl scripts may not be portable because they use modules that are not installed everywhere. Shell scripts may not be portable because they use executables that are not installed everywhere. I don't see how one improves upon the other, and it's really pretty easy to install things from CPAN.

Bollocks (4, Interesting)

bytesex (112972) | more than 6 years ago | (#22182276)

Skipped right down to the stuff that perl isn't supposed to do: not supposed to be used in high performance/real time stuff - check, as a replacement for shell scripts where shell scripts are shorter - check (obvious-meter off the scale though), it isn't supposed to be used in CGI. Eh. Right. Because, according to the author, we should be using ruby on rails for that. Eh. Right. Again. Why didn't he just outright say that we should be using j2ee with struts and beans and xml based style sheets ! Oh that was 2007 ! My bad.

Perl was, and is (IMHO) the first and foremost thing you grab when you write web-stuff. CPAN is nothing if not infinite, the web is a text-based thing the perl was designed for, and its speed makes ruby blush. So why ?

Why try to write off perl all the time. Is it because they can't seem to /win/ ?!

Re:Bollocks (0)

Anonymous Coward | more than 6 years ago | (#22182754)

Why didn't he just outright say that we should be using j2ee with struts and beans and xml based style sheets ! Oh that was 2007 ! My bad.

Uh, no. . . that was 2003.

Re:Bollocks (0)

Anonymous Coward | more than 6 years ago | (#22183714)

as a replacement for shell scripts where shell scripts are shorter - check (obvious-meter off the scale though)
Actually, that's not what he says at all. He's comparing perl to perl there, using 2 methods. The first (and he argues the incorrect) one is to use perl to send commands out to the shell, but the method used spawns more subshells (using more memory, etc than necessary). The second one uses perl's internal filesystem manipulation code so that essentially perl becomes the shell (leading to better performance by not spawning subshells, and making it more portable). So he's essentially saying: use perl for shell scripts, but do it correctly.

Disclaimer: I don't know perl, so I don't know what the actual performance hit is in the first example vs the second.

Re:Bollocks (0)

Anonymous Coward | more than 6 years ago | (#22184084)

Pretty much, it's not hard to setup a suitable web environment in perl that works like most MVCs .. It is easy to have the code seperation that the article mentions, dispatch tables .. html templates, form validation. There are tons of modules to do it. I guess the issue is perl doesn't force best practices so it helps coming from a language that does, just emulate it for rapid development..

Re:Bollocks (2, Insightful)

tknd (979052) | more than 6 years ago | (#22184354)

Probably because the CIO author is highly ignorant of the existence of CPAN and some of the high quality modules it archives and distributes. One particularly high quality module is Template Toolkit [cpan.org]. It is an incredibly powerful templating system. Some would even say it is too powerful (you could write enter programs in the template language). But what I have found is that power was purposely put there because there are instances where you need to do something fancy in the template or view rather than the controller code. And I have found it actually turns out cleaner than the equivalent in something built on J2EE.

CPAN is also a whole lot more active than other library inventories. While some authors do tend to give up on maintaining their modules, there are lots of reports and patches submitted along-side the modules as well as test reports on systems where successfully/unsuccessfully installed. There are often multiple submissions of the same concept of a module but with varying implementations. This gives you many choices and lets you explore various implementations until you find one that suits your needs.

Here's a list of other awesome modules that extend perl or implement various concepts:

  • RPC::XML [cpan.org] - Implement XML Remote Procedure Calls without writing a single line of HTTP, XML, or Socket code!
  • Inline [cpan.org] - Embed other languages like C directly into Perl code (yes the C code gets compiled!).
  • Moose [cpan.org] - Extension of objects in Perl, allows more control and adds new syntax sugar to make writing OO programs cleaner/stricter.
  • libwww [cpan.org] - World Wide Web library for Perl, easily create something like a robot without too much low level detail with HTTP and Sockets.

In other languages or platforms there's also been issues with third-party libraries. For example in Java you could spend days trying to get a library or tool to work in your IDE. With perl and unix that's not the case. You simply go onto CPAN, see if someone's done it. If someone has, you'll be up and running in under a minute.

When to use Perl? (5, Funny)

mlk (18543) | more than 6 years ago | (#22182480)

When someone has deleted AWK, and not before.

Re:When to use Perl? (4, Interesting)

jandrese (485) | more than 6 years ago | (#22183434)

Ironically, Larry Wall once said that part of the reason he wrote Perl is because he was scared of Awk's parser.

Not quite Perl... (1)

corychristison (951993) | more than 6 years ago | (#22182534)

But I've written a Media Center for use on my TV with PHP/PHP-GTK.

Originally it was just a small project to get through a week of stagnated work. It's actually pretty hacked together but is separated into a client/server setup for use of a single backend and multiple frontends.

Eventually I plan to port it to C/C++... but for now it seems to be working fine.

Spam filter, clustering system.... (1)

otis wildflower (4889) | more than 6 years ago | (#22183260)

... but my favorite is still doing Sun UFS quotas in LDAP with perl, and having to deal with that bass-ackwards quota structure (seek iforgethowmanybytes x uid) from teh 1980s.

All of it ghetto, but all of it mostly harmless.

Though the Ghetto Cluster (gclusd) failed hard a few months after I quit that job, it was entirely documented as a fail case, and had I not been forced to quit I may have even fixed that bug at some point! (STOMITH in user space without shared media can be tricky)

Another useless article (2, Insightful)

outZider (165286) | more than 6 years ago | (#22183384)

Articles like this really annoy me. There are indeed tools best suited for each job. Most people are not going to write an end user application with a GUI in Perl, because it's just not normally suited for it. Needless to say, with wxPerl, I've done it. Fancy that, it's readable, too. But, I'm aware it's not good for that.

What people tend to forget is how extensible a language can be, especially Perl. Blanket statements like "Perl should not be used for the web" is misinformed at best. No one wrote web scripts in Ruby before Rails -- it's all about the framework. Go give the Catalyst framework a try, and tell me again not to use Perl for the web.

As for high performance computing, remember that the perl interpreter does a few things very well, very fast. We ended up rewriting our web crawling infrastructure at $WORK from Nutch and Lucene in Java to a custom distributed Perl architecture against Xapian. Not only is it much more 'pluggable' than the original solution, we ended up getting a huge increase in speed out of the deal, even putting it up against 64-bit Java. It's anecdotal, and mileage will vary, but there are times that Perl is just better at crunching text than anything else.

Too many people write off Perl as a relic of the past. What people fail to see is the new Perl renaissance that is quickly approaching. It's a good time to be a Perl developer, judging by the job market. :)

4 Signs You're An IT Tool (2, Insightful)

keytoe (91531) | more than 6 years ago | (#22183732)

I was expecting the standard litany of anti-perl 'wrong tool for the job' comments in this article, but the 'four things' you're not supposed to do made me laugh:

1) Real-time or high-performance applications.

Check. No discussion necessary, but did it even need to be pointed out? Really, if you're even thinking about doing real-time apps in any interpreted language, you need to have your head examined.

2) As a replacement for shell scripts.

The example provided points out that using a simplistic perl script that calls 'system' to move files around generates a lot of needless sub shells and processes. OK - good point. However, in the example he provides, he replaces the inefficient perl script with an efficient perl script. How does that help make your point? Unless the point is 'try to write good code' - which isn't language specific.

3) As a web scripting language

This is just short-sighted and stupid, and the author suggests we use PHP or Ruby on Rails. OK - there are a lot of choices here, and all of them have advantages and disadvantages. But after reading that I should be using PHP, this quote made me spit coffe on my keyboard: "You should especially avoid using perl for traditional CGI-style form processing; this code tends to be hard to read and maintain because the HTML ends up inlined inside the perl code." Clean, elegant and properly designed code can be written in any language. Some languages encourage this, some make it difficult. Ruby encourages, but I'd stake my reputation on the claim that PHP makes it very hard. Perl is neutral on that spectrum.

4) In an obfuscated fashion

Check. No discussion necessary, but did it even need to be pointed out? Oh, I used that one already.

Re:4 Signs You're An IT Tool (2, Insightful)

julesh (229690) | more than 6 years ago | (#22184348)

1) Real-time or high-performance applications.

        Check. No discussion necessary, but did it even need to be pointed out? Really, if you're even thinking about doing real-time apps in any interpreted language, you need to have your head examined.


Yes. It needed to be pointed out. Look at where the article is published: a magazine targeted at _IT managers_. Many of these people don't really understand the basics of what the languages the programmers they employ are. Articles like this that introduce the strengths and weaknesses of a language might help prevent them from making braindead decisions on the basis of recommendations from fanboy programmers.

But after reading that I should be using PHP, this quote made me spit coffe on my keyboard: "You should especially avoid using perl for traditional CGI-style form processing; this code tends to be hard to read and maintain because the HTML ends up inlined inside the perl code." Clean, elegant and properly designed code can be written in any language. Some languages encourage this, some make it difficult. Ruby encourages, but I'd stake my reputation on the claim that PHP makes it very hard.

Not really. I've written MVC applications using a homebrew template engine as the view component in PHP, and it wasn't hard. The only real issue with PHP is that it makes it too easy to program badly... programming well in it is no harder than other languages.

The silliest statement ever (1)

nsayer (86181) | more than 6 years ago | (#22183768)

From TFA:

One of the worst things about shell scripting--whether in bash, sh or csh--is that the syntax of the scripts themselves is fairly hard to read.
So he's saying PERL is easy to read? You're kidding me, right?

Re:The silliest statement ever (1)

joggle (594025) | more than 6 years ago | (#22184302)

You're kidding, right? Here's an excerpt from a bash script generated by the auto tools:

# Parse our command line options once, thoroughly.
Xsed="sed"' -e 1s/^X//'
while test "$#" -gt 0
do
  arg="$1"
  shift
 
  case $arg in
  -*=*) optarg=`$echo "X$arg" | $Xsed -e 's/[-_a-zA-Z0-9]*=//'` ;;
  *) optarg= ;;
  esac
done
Perl can be written in a way that's fairly C-style whereas that's not the case for bash. Bash is great for simple tasks but for more complicated ones it can be really difficult to grok (as can be made clear by reading just about any script generated by autoconf or libtool).

Perl - Swiss Army Knife (1)

bigtangringo (800328) | more than 6 years ago | (#22183876)

Perl is my Swiss Army Knife. Anything that I can reasonably fit in one to five files, I'll do in Perl. If I need a web app of less than 5 or 10 pages, I'll use PHP. Complex webapps, long running heavy daemons are Java.

That's the 10,000' view, anyway.

PHP WTF?! (1)

wilx (1065624) | more than 6 years ago | (#22183884)

That guy has some valid points but I seriously fail to understand how can he recommend PHP over Perl for web development. PHP is unsuitable for everything including web development.

Re:PHP WTF?! (3, Interesting)

joggle (594025) | more than 6 years ago | (#22184052)

Why do you say that? I write Perl and PHP scripts all the time and don't see any advantage to using Perl for webforms over PHP, at least not the ones I write. It's trivially easy to access data from a database in either scripting language and you can perform Perl-style regular expressions in PHP. The nice thing about PHP is that it's specifically designed for web applications and has simpler syntax in some situations. The downside to PHP is learning all of these functions that don't have a consistent pattern to them but, once you know them, you can accomplish a lot of tasks efficiently.

Re:PHP WTF?! (1)

wilx (1065624) | more than 6 years ago | (#22184216)

Because of all the flaws PHP has? It is possible to use PHP for single page but not for anything else. Using it for anything bigger is pure sadomasochism.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...