Slashdot Mirror
You Used Perl to Write WHAT?!
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."
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.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
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.
A perl interpreter. Wasn't as hard as I thought.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
http://www.cio.com/article/print/175450
What power has law where only money rules.
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.
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.
The cancel button is your friend. Do not hesitate to use it.
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.
Karma: Excellent. 15 moderator points expire sometime.
..you shouldn't use perl "In an obfuscated fashion".
Wait...there are ways to use perl in a non-obfuscated fashion!?
Every expression is true, for a given value of 'true'
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.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
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."
=================
Unix is very user friendly, it's just picky about who its friends are.
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.
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.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
You have to be careful, though, not to miss newly-developed cost-cutting/quality-improving technology (e.g. Pylons and Django, neither of which existed in any useful capacity more than 3 years ago) or your competitors will eat your lunch.
http://outcampaign.org/
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.
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.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
I agree, and I do pick up languages like nothing.
... 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'.
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'
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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...
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.
/win/ ?!
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
Religion is what happens when nature strikes and groupthink goes wrong.
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.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
That's the sound of GP's joke going over your head.
When someone has deleted AWK, and not before.
Wow, I should not post when knackered.
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.
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.
- oZ
// i am here.
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 languageThis 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 fashionCheck. No discussion necessary, but did it even need to be pointed out? Oh, I used that one already.
Culture is more than commerce
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.
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?
Javascript + Nintendo DSi = DSiCade
I wonder if this whole discussion is off the mark. Languages are for the most part trivial. And universal. "It's the libraries, stupid" is sometimes how I feel. If it was easy to link in or call any library function from any language, then half of this discussion would immediately be seen to be irrelevant. So Perl is "the right tool for the job" because it has the ability to apply regular expressions to strings? But, you know, C can do that too thanks to this PCRE library. Hashes? C can do that too via another library. In case anyone has forgotten, Perl itself is written in C. I read that Perl 6 has vastly improved the interface to other languages, especially C libraries.
These day, whenever I write a new program it often feels as if I'm creating yet another language. A simple, superficial, limited language, but nonetheless, a language. Program needs a configuration file? Whip up a suitable format (language) for that. Needs to save data? Barf out this big data structure into a YML file. Want some way to run the interface from a batch process, or otherwise automatically? Start turning the user interface into a language. Want to connect Perl 5 and C? Get acquainted with XS, a "language" the Perl folks felt it necessary to create for that purpose, because Perl 5 wasn't good enough alone. Want to compile a large project written in C? Get familiar with the language of Make, because while C certainly could do it, C isn't so good for that. Is ANT a "language" for building Java projects? Where's the line between language and library?
I suppose where things lead to a new language is when someone wants to implement a new concept and the established ways aren't good enough. Or has a way to eliminate a bad programming practice, but some elements of an existing language must be dropped to do it. For instance, wouldn't be nice to have variable length parameter lists in C, as C's own printf function does? Too bad it's such a pain to do that in C. How about lazy evaluation and currying so we can have infinitely long parameter lists? Oops, guess the C call stack can do recursion, but isn't too well suited to expressing that sort of thing, time to make another language, Haskell. Do we want to pass along a pointer to a structure, or a copy of a structure? Java defaulted to pointers where C did not, but then said Java didn't use pointers. Nice not to have to type in ampersands and asterisks all the time, but still, I find the thinking misleading. Then there's garbage collection. The consensus is that garbage collection is overall a good thing, but that a good programmer can do better than the automatic garbage collector. And so on.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
The list missed the most important part of perl. A glue language. Python and a few other languages claim they can be glue languages but that's pretty much a joke to anyone who knows both fluently. Perl is the ultimate glue language for combining diverse output so different programs from different sources, written decades apart in different languages can all work like a well oiled machine.
The other really odd experience for me was learing object oriented programming. I had been programming in objects since I was first introduced to them when the first NeXT computer came out. I used java. And C++ and such. I thought I understood objects.
Then one day I learned to program object oriented in Perl. An I learned that while I was fluent in object oriented usage, I really had a pathetic understanding of how they worked and what was actually possible with objects.
Perl objects are sort of like owning a copy of grey's anatomy or "the visible" man. You son't just see that arms connect to torso's from outside but you see all the sinews and bones and blood.
It's actually amazing how so many things we think of as different concepts in object oriented programming and data bases are actually different reflections of the same trick. And that's the trick perl use to make objects.
in perl, an object is any variable that has an attribute that can store a list of package names.
Let's see what you can do with that.
Hmmm.... well that list can be your inheritance heirarchy so each package is what you search for methods. But notice that since it's a mutable list a perl object can do something else that most object oriented languages cannot. A variable can change it's "inheritance" list after the fact. it can change it's own class.
Okay Now this is just a single variable so where to we get attributes of the object? Well, if that variable is say a hash (dictionary) then we can just use the key's as the attribute names. so if were to write self.foo in C++, you would write self->{foo} in perl.
More fun: let's say you call a method() or ask for an attribute on a variable that does not exist. Well, a perl object can just add more packages to it's inheritnace list. Or it cold write the method on the spot and add it too it's own inheritnace. "I'm my own grandpa". I've used this trick many times to create tables. I don't write any of the "get" or "set" methods. instead I just intercept the call to the method "setfoo()" which never existed cause I never wrote it, then I have perl create an attribute called foo: Self->{foo} = "something". then I have perl write a subroutine called "setfoo" and add that subroutine into a package namespace and put that in it's inhereticnace list.. ("like adding methods to a C++ package outside the declaration". (programming tip: obviously this is could lead to problems with typos, so I also provide the variabel with a list of all allowed attribute names--- but of course I can always add to that list later).
Now something more exotic. The hottest thing in Data base programming is the realization that sometimes column centric data bases are better than traditional row-centric data bases structures. In perl an object can change which it is, transparently. For example, if I'm a traditional object with a row organization then all my attributes are stored as self->{foo1}, self->{foo2}, self->{foo3}. and so on, just as you might right self.foo3 in python. But I did not have to do it that way. What if instead of making the self variable a hash (dictionary) I had made the self-variable a simple scalar, say an integer. Well at fist this seems stupid, where did all the instance variables go? Well, I just store them in the class. I make the scalar self-variable's integer just an index. The class keeps the instance variables in arrays--that is column based storage--.. SO for example if self = 4, then the attibute foo for this instance now becomes self->class->foo[4].
The beauty of this is that si
Some drink at the fountain of knowledge. Others just gargle.
That's pretty much my point. While I was at college, I worked with Java, C, C++, Fortran, VB, and SPARC Assembly. I have a vague working knowledge of VB and Java syntax. I still remember C and C++ pretty well as I use those still (and I use a lot of PHP as well, but that I picked up after I was out). If you asked me to write something in Fortran or SPARC Asm at this point in time the best I could do without a reference book next to me is a blank stare (The Fortran class I took wasn't even geared towards CS majors. It was just there for Liberal Arts people to get a required computer credit - I took it because for a 3rd year CS student it was like a free A+ to add to your GPA :)). I just haven't used it recently at all and the syntax is lost.
:P. But, regardless of the percentage, the point still stands: syntax is trivial. The important part is knowing how to think like a programmer. If you can do that the rest just falls into place.
HOWEVER, I do remember quite well what threads are, what a semaphore is, what a binary tree is, the difference between a bubble/quick/radix sort, the concept of object oriented design, etc. I wish I could say I remembered UML modeling but honestly, I hated that darned part of CS and never paid attention there anyways
"People who think they know everything are very annoying to those of us who do."-Mark Twain
First, and more than sufficiently, of all: who the $curse is going to be taking coding language advice from CIO Magazine? If it's a real practicing software developer, they need to turn in their geek card and coder license immediately. And if it's a CIO or other PHB-level entity, for the love of $DIETY, don't let him start dictating software tool choices on the basis of stuff like TFA!
Second, the author of the article sounds like he has only ever dabbled with Perl, sysadmin-tool-like. He betrays a disturbing unawareness of the recent development in frameworks and methodologies in the Perl universe that track most of the major software development trends and tools available in other communities. His advice, positive and negative, seems stuck in basic out-of-the-box Perl 5.6 or something. Most of the time, that's plenty good enough for the ol' sysadmin "Swiss Army Scripting Language" approach, but certainly missed out on a lot of good work. (The reader comments after the article call him out on this pretty well, so I won't rehash.)
Third, a lot of the advice is universal, not Perl-specific. I mean, stuff like "Don't use Perl in an obfuscated fashion" is like "Don't drive a 1973 Dodge Ram pickup truck while drunk." Very true, very sage advice, but the problem is not Perl (or the truck), it's the obfuscation (or the drunkenness). Code readability is a timeless, domainless, endless problem. The only reason Perl gets picked on for readability is basically bad PR.
Frankly, a lot of TFA just sounds like an excuse to fill up a few column-inches the editor needed filled in.
Welcome to the Panopticon. Used to be a prison, now it's your home.
#6 - Slashdot
Lindsay Blanton
RadioReference.com
was in using perl to perform an xsl transform converting xml directly into executable perl code. hooray for eval. surprisingly it was one of our most stable jobs and ran for years with no problems. i think this was mostly because everybody was afraid to touch it once it got going... is there anything perl can't do?
"Glory is fleeting, but obscurity is forever." - Napoleon Bonaparte
So it's a virtue to be programming in a half a dozen different languages? Or to force an accomplished programmer to switch to a different language for no good reason? Sure, he should be able to pick it up, but there is a learning curve, and lingering inefficiency issues that will last for a while.
.Net came out, I purged it from my memory banks. I am not going back, not for anything. Does that make me weak, to refuse to dive back into an obsolete language in order to generate a new application?
I recently had a throwdown regarding this because one of my coworkers was working on a project, and I flat refused to help him in his chosen language. That language? VB6.
Now I used to program in that...thing...and when
It's one thing to be flexible and open to new ideas, and dedicated to improving your skillset, but it's entirely different to be running around programming in random different languages for no compelling reason. One of the negatives in TFA was that if you used perl to sub for a shell script, you'd take an efficiency hit...This after he said you should never use it at all where efficiency was an issue because it's interpreted! The reason to use perl instead of a shell script is because perl will work in any shell...If you need performance you shouldn't be using it anyway.
In short, using a different tool for every job is only useful if it's not more efficient in the long run to do the job with the tool at hand. If I need to tighten a bolt, I could go to the hardware store and get a socket set that will fit that bolt, or I could use the crescent wrench that's sitting 5 feet away. The sockets would do the job a hell of a lot faster...But it would take longer to get them than it would to just use the wrench.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Sure, Perl is pretty much on everyone's shit list these days. But as the Director of Development for Zappos.com from 2000 through 2006, I have to take exception with his claim that perl is unacceptable for high-performance applications. Of course it depends what type of high performance applications you're talking about, but for high performance web applications it's actually quite good.
:)
Specifically, the Zappos site, built with Perl, was rated the fastest retail website in the world for broadband customers for much of 2006. It beat out Amazon, Dell, Best Buy, etc, etc, you name it. It was also the most consistent speed and the fewest errors. Search Internet Retailer for the more numbers. It always places in the top 5.
Also, the claim that one might mix HTML in scripts is a sign that this guy hasn't actually used Perl in the past decade. Everyone switched to powerful templating systems sometime in 98. There are several very nice web development frameworks for Perl these days. Just like almost any other language.
The rest of his criticisms are more valid. I wouldn't try writing graphic intensive applications, or anything with heavy math processing in Perl. And the most common complaint, that it doesn't prevent you from writing messy code, is certainly true. Of course, just because your code looks neat doesn't mean it's good code either
Cheers.
Oh, perhaps the kind that provide exclusive or small-reach services? e.g. If I ran a local salon, how many people would reasonably be hitting my site simultaneously? I might not be able to afford to have someone build me a scalable J2EE online-appointment system, but I could probably afford a small Ruby on Rails site. Scalability for my site would be handled by throwing hardware at the problem, as it's a LOT cheaper in this case than trying to pay for a massive development effort.
And if my site is well and truly straining under the load applies to it (for a single-shop salon!) then I've got a lot bigger problem with over-booked schedule than with my technology.
To carry that example one step further, I would probably look at opening new locations to solve my overbooking problem. Each location could get its own scheduling system on a different subdomain, thereby solving my issues for the near future. If I manage to get so popular as to need a unified solution, then it's probably time to rearchitect the technology AND the business to meet the demand. (As good as we programmers like to think of ourselves, we can't possibly predict the issues that will be involved in such a changeover to the extent to where we can deliver the original solution with that sort of adaptability in mind while still doing it inexpensively.)
Javascript + Nintendo DSi = DSiCade
Sadly it is the brain dead of the HR departments and headhunters who do the hiring/selecting... usually. To them, what is on paper trumps experience. Seems that ever more often these wastes of brain pans either submit for interviews or will outright hire a newly graduated Masters student (based entirely on their piece of paper) with fuck all experience and make them managers or 'senior' developers, or architects, etc. And people who you would like to hire will have their resumes dumped in the waste bin because they don't have the requisite piece of paper that the dumb fuck HR person thinks makes you useful. So you know who is going to be your new boss. Must stop now before meltdown. Yes, some bitterness. Life.
-- I ignore anonymous replies to my comments and postings.
Swiss Army Knife? You must be using perl 4. It's known as the Swiss Army Chainsaw nowadays.
...and I tend to think they just aren't doing anything *significant* in just-learned languages.
The problem is not learning the syntax and basic idioms. Agreed, that's pretty quick, particularly if you have a good reference.
The problem (and the time sink) is the *ugly* side of every language. The parts of the standard libraries that sucked, and were reimplemented elsewhere (but you gotta know that...). The functionality where everyone who "lives with" the language grabs X open source library to implement -- not Y! it's a POS! -- but you don't know that yet. The language features that have secret, illogical gotchas for special cases. The bugs in the compiler or interpreter that are easy to avoid -- once you've been burned once. The code that will break cross-platform compatibility for obscure reasons. The code that will make it almost impossible to internationalize later, because you didn't learn how that support worked yet.
Granted, the cost of these things with any reasonable mature language should not be enormous (though it depends how long you go down a wrong path...), and you can allow for it, but it's always a significant risk *especially* if you don't have someone on the team (perhaps the new team who has to maintain your old code) who's already more-or-less expert level.
But either way, you have to allow *something* for that cost, and sometimes it's not worth it just to use the absolute best tool for the job when you have a pretty close fit available.
What you're really talking about here is the difference between the Turing machine model of computation and the Lambda Calculus model, and you're absolutely right. Even though the two are provably equivalent (try expressing one of your Haskell programs as a while loop with a stack; it works but it sucks having to write it!), the very mentality that you use when programming in a language like Haskell is so totally radically different from how you program in C that it's useless comparing the two.
In college I did a lot of work in cryptography and artificial intelligence. These are tasks for which functional programming is particularly well suited. I remember the day that I learned what the functional folding did. It was like that moment you're talking about, when suddenly I realized that summing all the values in a list didn't require its own function and it was just one succinct statement. Suddenly the evaluation of a perceptron network became a functional fold nested in a functional map, and my AI code shrank from hundreds of lines to dozens, but was still perfectly readable.
People can say that languages are universal . . . but that's really not the full story is it? The fibonacci sequence, for instance. I'd express it like this in Haskell:
How do you explain that line of code to someone who's only ever seen C? And yet it'll compute the 1000th fibonacci number almost instantly on my computer. The infinite list idiom can only exist in a lazy-evaluative language, and that's a concept that doesn't even translate well to other functional languages like ML (unless you cheat and use ML's lazy module, which I've never really figured out).
One of the greatest things that I learned in college was that languages are not universal. The people who say they are obviously talking about Java vs. C vs. C# et cetera. Going from imperative to semi-OO like C to C++, you're not really switching entire paradigms. Going from imperative to, say, pure OO (see also: Ruby, Smalltalk), or going from imperative to pure functional (see also: lisp, ML, Haskell, Prolog), is quite a mindfsck.
Anyways I'm glad to hear that it's not just me here who loves the functional languages. Have you decided to do anything cool with it yet?