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.
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..
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!
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
[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.
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..
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..
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.
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.
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.
.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.
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
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
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.
The opposite of progress is congress
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.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.
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.
Give me Classic Slashdot or give me death!
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.
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.
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.
... 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)
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 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.
This is my sig. There are many like it but this one is mine.
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
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.
Yes, I am a smart ass; it's better than the alternative.
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.
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...
such as Java's StringBuffer and .NET's StringBuilder
:p
Bah, I'll use Java's StringBuilder then
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?
http://sola-x.com/sola_features.htm
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.
Oh no you didn't!
>50% of what you learned here will likely be outdated within 2 years of graduation.
That's very optimistic. More that this is obsolete in the time it takes to develop lesson plans, get textbooks approved, etc.
-fb Everything not expressly forbidden is now mandatory.
As part of a senior project that was actually the visualization piece of somebody's thesis, I wrote a data visualization/analysis frontend (for software performance analysis data storied in a database) in perl. Full GUI, Perl/Tk, graphs/charts/etc. This was in the 1999-2000 timeframe.
It ran quite well on the hardware of the day, and had the advantage of actually behaving on just about everything in a very mixed-platform campus (Linux, Windows, Solaris, AIX, etc).
ERROR: Null
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"
I wrote an enormous script that takes two XML files as input, one describing data structures I want to encode and another that describes the binary format I want to encode it as (such as a starting byte, the number of bits to store for the length of the message, the type of CRC/checksum to use, etc.). It then creates all of the necessary C code to encode and decode these records bitwise with options for using simple compression algorithms as well. It also has options for generating C++ code wrappers and another independent Java implementation.
While it took a lot of code to accomplish this (even using the XML::Simple CPAN package) it now is a very handy tool for our purposes where we are encoding dozens of records over a very low bandwidth stream (satellite connection) and can change our record structure at will (with a great deal of flexibility) simply by editing a couple of simple XML files.
I have to disagree with your former Professor's numbers. I remember using C, Java, Scheme, and some assembly as in-class languages, and I don't remember any of them. The basic Java syntax has stuck with me to some degree, so I'd say it's more 10% / 90% in terms of the tangible, moot part of a CS education and the less-tangible always-relevant portion.
I've also recently had to train a new developer who looked good on paper, was good enough in the syntax area, and couldn't think like a programmer at all. He didn't last long, and I'll take someone with no formal CS training yet is able to think abstractly over employees like him anyday.
At least one implementation of Perl6 is being written in Perl. Which should help with the situation you describe. Plus the perl6 grammar capabilities are pretty nifty looking.
ah, mod points
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
I wrote an X11 display manager (in the sense of xdm) with Perl/Tk. What do I win?
Just like Bad English is the most widely spoken (but not understood) language, the most widely spread programming language is Bad Visual Basic (but not ... ugh).
... yet. Don't show me, please.
Bad Visual Basic (BVB) in C is horrible, trust me.
I have only limited exposure to "C++BVB" and no experience in BVB in Perl, Java, Python,
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
What kind of logic assumes that you can install Perl but are unable to execute a shell script? It's far more likely that you will have access to a shell and the basic commands in all cases. Making it a requirement to have root access (or permissions to install CPAN modules) to execute your script is dumb.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
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.
It largely depends on your development environment. A previous employer I worked for refused to acknowledge any code not written in VB/.NET for apps/scripting. Even though these languages are occasionally useful, for my purposes(report generating/parsing) they rarely were. .dll's or modules. On the otherside, I'd never consider using any language other then perl for parsing data.
At my current employer I have free control to use whatever I see fit. My boss asked me to write something to parse and compare transaction logs. I told him I was installing perl, he said thats fine... So I scripted in perl , couple hundred lines of code now saves 10-15 minutes of manual comparison everyday.
Where I would use a Visual language to program interfaces, I'd never use PERL even though it can with the help of outside
and seems to work just fine.
-Clio
Karma: Bad (mostly from not giving a fuck)
Blog: http://clintjcl.wordpress.com
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.
One advantage of Perl not mentioned in the article is that it is probably the easiest programming language to master. The syntax is so simple anyone can program it. In fact, just the other day I left my 1-year old baby girl alone in the room for five minutes only to find on my return that she had written a fully functional email client in Perl.
SIG: TAKE OFF EVERY 'CAPTAIN'!!
And over the time new tools has emerged that makes the use of Perl more limited. One of the drawbacks is that it is possible to be very obscure when writing in Perl. But it may at the same time be very efficient.
To Write web applications I have stuck on Java and build the web pages using ECS. Unfortunately the use of ECS really brings out the BAD section of Java's inability to do explicit object deletion. It may be that ECS also could have been written in a better way - so anyway maybe I'm just whining.
The advantage is that I will get a really good HTML which will pass the W3C validator without too much fuzz. The disadvantage is that it's not that easy to introduce the ordinary HTML hacker into the world of ECS. (but why should the world be easy?)
And ultimately - there is a difference between tools and tools. If you have a tool like Eclipse you may use it to edit more than just Java and somebody else may go in afterwards with Emacs, VI or (horrible thought) Visual Studio to continue the work since the code isn't really aware of which tool I use. On the other hand - a programming language is a tool too. If somebody comes in and say that I need DIBOL for a certain task even though everything else is written in COBOL, then you may want to think twice about the mind of that person...
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
In my opinion, Java is definitely THE language, well, at least for business applications. There are some nice things in .NET (such as the accessors, instead of the tedious instanceOfSomething.setXxx(Object yyy), just instanceOfSomething.xxx=yyy without resorting to a public property), but they're nothing really.
.NET is that it promises more that it can handle. Sure, you can throw an SqlDataSource and a GridView and get a quick-and-dirty Table view -- but I can do that easier with Oracle Application Express... I was more than disappointed when I was asked to make an ASP.NET page and found that it was harder to even throw my own PHP from scratch.
.NET completely out of the game?
.NET looks more interesting: you get the actual native look and all (except when Microsoft releases a new Office version with a new, nicer skin that you can't use for your own app). And free XNA development is a plus.
What I didn't like about
For example, GridView is just that: a view, it doesn't have code to "add" new records, and it's so complicated to make it: you have to add a footer and use it as the empty row, but the footer doesn't appear if the dataset is empty...(AND WHO SAID THAT XML IS SUPPOSED TO BE HUMAN-READABLE?) that one is tempted to inline everything like it's 1997.
And do I need to mention the fact that J2EE is so scalable and does most things for you that it leaves
But in the Windows side of thing,
About the web as an application platform... I'll let it cook for a few years... Yes, I'm too lazy and I grew to love "big" languages so much that I'm not really too tempted to hack javascript on the client side to make my app "AJAX-enabled" just to be more responsive... especially if I have to deal with MSIE on the client. Been there and I didn't like it... and the customers like that little blue "e" it's hard to convince them to click on the Firefox icon. (Yes: I'd rather roll a desktop app to tens or hundreds of desktops than spending weeks to find out why the hell XMLHttpRequest is not behaving).
I can't agree with the author on what Perl isn't good for. Shell scripts, for instance, will fork commands anyway...so I'm not sure why perl is being called bad for doing the same thing and replacing a shell script. Maybe the author doesn't really understand what sh does when it sources a shell script.
And perl is quite good at CGI despite claims otherwise. mod_perl and fastcgi make it an excellent solution for writing web cgi. One could debate modular vs object oriented languages or aspect oriented, but that's not the debate- its whether perl can do the task at hand in a fairly efficient as a CGI language. I mean...the url at the top says "comments.pl", not "comments.php".
You also have to take into consideration what technology your job allows you to use. Sure, I'd love to spin out some RoR apps but when you work for a large corporation they aren't quick to adapt new technology. There are a lot of companies out there that still use Perl to handle backend processing for their websites because it's what's available to them and there are plenty of resources that can work on the codebase. There are faster, more efficient languages out there but sometimes they aren't an option.
The visible Object.
You used JavaScript to write WHAT?
The key to understanding when (and when not) to deploy JavaScript has as much to do with the intent of the target application as it does JavaScript itself. Written by Michael Morrison, author of Head First JavaScript.
http://www.cio.com/article/print/175950
... than well-commented Perl.
..." grotesqueness. Code written like that is just waiting for someone to come along later and hose it up.
That has to say something.
1. Java was strongly typed from the beginning. Perl added typing as an afterthought. Inheritance is implemented in a bizarre fashion by adding to an "@ISA" list and "blessing" things.
With Java many of inheritance errors would be caught at compilation time. With perl, there's no compilation, so those kind of things fail at runtime.
2. One has to put a $ or a % or an @ in front of a variable to make sure it's used properly. That (in my opinion) immediately obfuscates code and decreases maintainability.
Java: int i = 0;
Perl: $i=0;
What would you rather look at?
3. Every application I've seen that's been written in Perl looks like a hack. So, if what you need is a quick and dirty throwaway hack, then Perl or PHP may do. However, in many cases those quick and dirty hacks turn into little permanent monsters that someone needs to care and feed every so often.
4. EPIC, the Eclipse IDE plugin for perl, can't find references to variables. Many times it can't find declarations. With Java there's never a problem. How one can do without this kind of functionality is beyond me. I guess you just grep the codebase looking for things that match.
5. Perl trades second generation maintainability for first generation instant gratification.
6. Perl's idomatic quirkiness encourages bad programming practices and butt-ugly code. For example, most Perl code that I've seen uses the "something if (condition)" idiom. If *after* the thing it's suppose to do? C'mon. Or, the "something || die
pretty easy to install things from CPAN
Then you have never tried to install an Oracle DBD from CPAN. When I did that last time (3 years ago maybe) it took me two days of cursing.
Why does everyone keep comparing PHP to Ruby on Rails? RoR is a framework. Of course a framework will encourage cleaner code...as do most of the better PHP frameworks, Python frameworks, etc.
...to put together a mathematical compression algorythm for text. The algorythm assigns values from a register to each text character in a file, then chop up and recalculate those values into smaller values.
All hail to the spacepope.
Otherwise, I too would prefer a Java world if they could update the language to include things like accessors and such, but I've not not been a fan of anything Microsoft out of prinicple for some time so my viewpoint is bias/skewed.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
Javascript is good for everything! My Javascript DRM system is totally awesome.
n the other hand, sometimes two languages are better than one. Like it or not, the JVM and CLR are not always viable options. Maybe there isn't an implementation for the platform you want to use. Maybe you can't get approval to use anything with them but Java and C#. Maybe they just aren't fast enough; not every application is a long-running process of the sort that really benefits from runtime optimization. Maybe they simply aren't managing to recognise and optimise your inner loops, for whatever reason. In such a case, you are going to see a benefit from dropping down to C, either from your JVM/CLR-based language, or from another high-level language like Perl or Ruby.
I'm waiting for the "You Used Microsoft Access to Write WHAT?!" story...
I register my indignation that Perl should be subject of "WTF?" in regards to application. I can assure you the Tcl is used in everything from telescopes to routers to the ad splicing system for all of the NBC television network.
And in fact, I'm composing this from a browser I wrote in Tcl. It's a ni#$%@#$^H^H^H
***NO CARRIER***
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Nonsense. Technology does not move THAT fast. Even saying 50% is obsolete in 2 years is a bit a of a stretch. Seriously, how much has CS/IT really changed in CS since 2005? Maybe a new major version of Java? Yeah, I'm sure Java developers were just scrambling to catch up there... not. Most just continued targeting old releases. Any big changes in Javascript? Python? PHP? Perl? Ruby? C#? Nope, still the same stuff with perhaps a few API updates here and there. Have basic concepts like sorting, linked lists, and recursion changed? Nope. Has some new major concept in programming replaced OO? Nope. Hell, you coudl probably go back 7 years and not find too many major CS concepts that have changed significantly.
Anyone who says that what they learn in CS is obsolete in the time it takes to develop lesson plans and get textbooks approved either went to a shitty school (and had shitty text books) or simply failed to grasp the larger concepts and patterns.
-mtthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
I ran into a fun problem with a shell script recently. Turned out that it relied on the setting of an environment variable that the "programmer" had in ~/.profile. Not documented, of course. It was hell to debug.
At least when Perl is missing a CPAN module it tells you exactly which module it's missing and refuses even to start the script, instead of getting halfway through what it's doing and then suddenly bailing out with an irrelevant message that doesn't even tell you where in the script the error occurred.
Java and C# are almost exactly the same in syntax. How about maintaining BASH scripts, Perl, Python, and Power Builder? Not quite the same. There are advantages to keeping standardization in technology unless there is a really good reason to change.
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.
I'm not really too tempted to hack javascript on the client side to make my app "AJAX-enabled" just to be more responsive
I'm not a big javascript fan myself. I really appreciate some of the custom tags that've come out of the Struts 2 project. They provide AJax functionality, without having to mess around with the actual Javascript (Javascript generated by the JSP).
AccountKiller
"Not an actor, but he plays one on TV."
Give the monkey a keyboard and in a few years it will come up with an article that CIO will publish.
LADIES AND, well, I guess no ladies, but GENTLEMEN! we have here, a DOUBLE-WOOSH!
...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.
IIRC, you can download it to your console via LAN, what you can't do is "burn a DVD" with your game.
Oh, and in my case, I noticed that they don't get lost... they look everywhere, pushing any buttons, keyboard, mouse, start menu, whatever... trying to find the little "e". Damn, when they want something they learn quickly.
You Used PHP to Write WHAT?!
Despite significant shortcomings, PHP is perhaps the most popular Web scripting language in the world. But despite a large collection of nails, not every tool is a hammer. So when should it be used, and when would another dynamic programming language be a better choice? We identify its strengths and weaknesses.
http://www.cio.com/article/176250
It might have a place doing quick and dirty jobs that won't ever be maintained, but it is not a language to use for some thing that needs to be maintained - I know because I wrote thing in perl.
If you're recognizing that new each new system you write is essentially a new language, you might be ready for lisp or FORTH.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
You sound like you may be in a good position to understand what the authors of the Scheme Reports mean when they write that "programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary."
Lisp does this sort of thing by trying to find the really fundamental things that must be provided in order to allow you to do anything at all you could ever want. This is why R6RS Scheme has record types, libraries with controlled export, hygienic macros and call-with-current-continuation; if you have these four features, you can build nearly every interesting feature of any other language out there on top of them. Dynamic method dispatch, in the style of object-oriented programming? Easy. Lazy evaluation à la Haskell? Can do. Logic programming, like in Prolog? A few (admittedly a bit hairy) lines of code using call-with-current-continuation, but after that, it's easy to use. Pattern matching? Just a few moderately-complex macros. Synchronous message-passing concurrency? Sure, why not.
This isn't to say that the Lisp world is a panacea, but the languages are more flexible, period.
Are you adequate?
Being a Software Architect for over 10 years, with 90% of my time on a winbox. I have yet to find a opensource solution that can do anything better then closed source solution. Flame all you want. Perl, Java, Ruby, PHP? None of those flavors does anything that Javascript, VBscript and ASP/VB/C.net couldn't do. Oh MS software is security open, bloatware, bla bla bla. I don't blame the technologies, I blame the developers.
Dirty Programming is the #1 cause of failed, unsecure software, period.
I wish, instead of everyone and their grandmother turning out some new 'opensource' language, wrapper, script, etc. People would focus on a tried and true language and improve the flaws.
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?
Sorry, but language still makes a difference.
http://www.codinghorror.com/blog/archives/000838.html
C++ Compiled 1:1
Visual Basic Compiled 1:1
C# Compiled 1:1
Java Byte code 1.5:1
PHP Interpreted > 100:1
Python Interpreted > 100:1
Photos.
This article contains huge bits misinformation spread all over.
The author fails to notice completely the recent advances of Perl such as Catalyst which is a Rails-like (but better) framework for web application development.
Also, Perl isn't interpreted. It's compiled to bytecode on the fly and run by its internal virtual machine, much like Java (except Java has an explicit compilation stage, while it's implicit in Perl).
Perl performance is more than adequate and surpasses most other languages except. A proof of that is SixApart's perlbal - a load balancer completely written in Perl which is as fast as most of other solutions currently available (some of them in hardware) while providing much greater flexibility.
I'm honestly disappointed by this article (even the title is full of prejudice), especially because I don't have many hopes for the author to correct his mistakes and this is a somewhat influential site.
The bottom line is: Perl is an evolving language and we're not in 2000 anymore. Recent Perl developments have made the language a full fledged platform for web development. But developers need to code in "2008 Perl" not "last millenium Perl".
PS: I wrote this comment for this original article on cio.com and I thought this wouldn't get past the Firehose here... either way, I only pasted it here because I think my comment can be informative or insightful to some of you. Since I'm a bit late, I'm pretty sure it will probably end up buried unless someone mods it up, oh well.
Perl is a hacker language: powerful, flexible, opaque to beginners. But that's what we have C and assembly for ... to scare off first year CS students. Scripting languages have evolved, and for getting real work done there are better options now.
IMO Perl is a bad choice (for a new project) for anything that involves functions being called. I think even the most ardent Perl fanboi will admit that passing arguments to functions in Perl is completely broken. When you can write a single big flat procedure or a one liner that does a bunch of text processing it puts Python to shame, but beyond that you're doing a lot of unnecessary work.
In the real world, CPAN is a big plus, and the amount of Perl code running huge portions of the internet will not go away anytime soon (nor should it.) Perl hackers should continue to ply their craft; Obviously, what works prevails over my rambling, but I think Perl is going the way of COBOL.
P.S. Yes, I understand the irony of posting this via an impressive array of Perl code.
... also, I can kill you with my brain.
... because it was a one-off scientific visualization, and writing in Perl Data Language minimized coding time. Sure, it took two hours to render a scene of the solar corona as seen from a spacecraft flying through it, while an implementation in C might have taken a few hundred milliseconds -- but it only took me a week to code up and debug, and if I were writing in C it would have taken at least a month.
It was for a one-off scientific render. Run time was long (measured in hours) to render the desired scene, but run + devel was exceedingly short (measured in days).
Oh really? That way of thinking has caused my work to consist of things like FoxPro for DOS 2.6 , Visual FoxPro, VBA, VB6, VB.NET, C#, Ruby, Python, Bash, Java, just off the top of my head, without going into mainframe. Best tool for the job has made my job a maze of concepts.
I went through Computer Science, I know the conceptual level, but guess what? There's a little thing called "reality" that gets in the way. What really happens in the real world, is nothing like what the concepts are supposed to be.
Filtering through syntax, programming styles that span a multitude of generations is tough. Had they just tried to use the K.I.S.S. principal (which by the way, isn't taught in school), I might have an easier time today. Instead, I go through this stuff and scratch my head wondering, "Why the hell am I the one dealing with this?"
Live forever, or die trying.
for any given job is the one the person given the job knows best. Just ask them.
Until they learn something better. Same thing.
"I may be synthetic, but I'm not stupid." -- Bishop 341-B
This has to take the price of the stupidest article on slashdot ever. It's an article, using three pages, to explain in great detail, the prejudices most people have for/against perl, and explaining it like it was something really insightful. No shit, perl is good scripting, but bad for numerical analysis? You must be kidding me? Who the fuck needs to be *told* that?
Ok, I realize this was for cio.com, which I assume is for pointy-haired bosses (not really sure about american nomenclature for boss titles). But come on, why not put up an article explaining that it's good to listen to your technically competent employees when you face decisions of a technical nature? And what the fuck is it doing on slashdot? I thought this was "news for *nerds*", not "news for blatantly incompetent people who decide to replace actual thought with stereotyping".
- C# 2.0 and 3.0 In 2005, C# 2.0 was entering beta. People were maybe going to use it. The idea of being able to rely on having
.NET 1 installed on people's machines at all was really just finally solidifying. It was hard to find web hosting that supported ASP.NET 2.0 in 1995. C# Web code was, by and large, written exclusively in 1.1. Web development in 2.0 is day and night different from 1.1, so that's a major area of technology regarding C# that's moved on the last 2 years. Clearly you're not familiar with the radical new things in C# 3.0, like LINQ. You may think you're not sure if LINQ will be awesome, but you probably didn't like generics either then. Finally, 2 years ago Silverlight was just a "maybe someday they might do something". Today Microsoft is pushing silverlight hard and it's going to happen.
- Mono. Way better system today that it was a couple of years about. They've implemented System.Windows.Forms, it runs fast as JIT native code, and it runs ASP.NET 2.0. It's practical for production now, both for web, for server apps, and for GUI apps under either Linux or Windows. Wasn't nearly as good or practical 2 years ago.
- Ruby. Ok, you really think nothings happened with Ruby since 2005? In 2005 Ruby was really exotic and rarely used, and rarely heard of outside of certain circles. Ruby's popularity and adoption has increased staggeringly since 2005. You think anybody saw advertisements looking for Ruby developers in 2005? Hell no.
- PHP. Ruby's popularity has fueled innovation in other areas, including here. CakePHP is a framework I've used on some projects that's really a terrific way to write things. There's other killer frameworks that have come a long way in the last 2 years, such as Django.
- Python Gaining in popularity really fast. Django, and other apps are very strong. Today if you aren't well versed with a scripting language of some sort, you're dog meat compared to other developers. People weren't as wise to that two years ago as they are today.
- Erlang Those umpteen multi core processors are coming soon, and more and more people are interested in languages that easily support parallel processing and distributed processing. Erlang is gaining steam fast. Have you tried it yet? I can tell you tons more people know Erlang today than did in 2005.
Seriously, if you think things aren't moving fast in the industry, then do be careful. If you've been coding the same thing for a handful of years and not learning much new... well, you can only do that for so long before you're like those old COBOL guys that didn't need to learn any of that that newfangle C crap, or the VMS folks that didn't need Unix.This guy lost me when he started singing the praises of Ruby On Rails by claiming that it "offer more out-of-the-box Web support and a cleaner integration into the webpage experience"
When people start giving verbal fellatio to Ruby on Rails without giving concrete details, I know that they're full of shit.
Once, I was explaining to a friend of mine an application that I wrote in Perl. He asked me why I didn't choose something newer, like Ruby on Rails. I told him that I used Perl because I knew it. I then asked him some questions about Ruby and he didn't know the answers to any of them. Nothing that should have been too difficult. I asked him about things like type conversion and whether it was a compiled or interpreted. He was like "I use a Mac. I don't know."
Perl is so widespread because it's powerful. I won't be writing any device drivers in it, but it's useful for a LOT of other things.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
I used Perl for ten years, but for me is almost dead now. Ruby, Python, even Javascript (Rhino) and other languages have the same pattern matching capabilities (Perl's greatest strength), have a more clean syntax and, which is very important, have been ported to the JVM. Something that make them usable in different environments and embeddable in other applications. Perl is not there yet and it appears that it will never be.
You keep claiming that mod_perl is fragile. That hasn't been mine (and others) experience. Could you give references to support your claims or are you just trolling?
Karma: Excellent (My Karma? I wish...:-( )
With PDL you can do heavy math processing really, really fast. And easy!
Ok, but how much does what you learn in CS depend on language specific features? I'm not saying you don't have to keep up to date on languages and APIs. But there's no real fundamental change in the above. Then again, I'm not intimtely familiar with C# specifically, so maybe its evolution was so radical that it makes everything you knew before obsolete. But I seriously doubt it.
So what about this makes what I might have learned in CS obsolete?
You've gone beyond taking my statement out of context. Now you're confusing a change in popularity of a language with a change in the language itself. Even Ruby 1.9 (soon to be 2.0, hopefully) doesn't change THAT much. It will mostly just make Ruby faster.
As we speak, I'm in the process of writing a nasty letter to my alma mater demanding my money back because my entire CS education was centered around a web framework that has now been obsoleted by CakePHP.... NOT.
There's plenty of jobs of developers who specialize in Java, for example. Now you're just making shit up.
Again, confusing changes in language/framework popularity with fundamental changes in CS. tsk tsk.
You would happen to write for Wired magazine, would you? Because this is exactly the kind of technology infatuated garbage I would expect from taht magazine.
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
BUT in SOVIET RUSSIA Perl uses YOU to deal LSD!
An "obscure" language could well be the stand-out choice, regardless of whether the skills already exist in your organisation. You can outsource them to get a more optimal solution (Erlang consultants, for example) rather than being restricted to the lowest-common-denominator of developers you already have.
Disclaimer: I've dabbled in Erlang.
you had me at #!
ASP.NET 2.0 actually pretty much does in fact obsolete most of what you might know about ASP.NET 1.0, which I expect is nearly nothing. I won't bore you with a point by point response to what yuo wrote, I'm sure neither of us care enough to take it seriously anyway.
But two quick notes. Yeah, I can name the next COBOL. It's called Java and Visual Basic, both. They both are languages with large code bases that people have to support but would really rather be using a newer platform if they could.
Also, you keep talking about your CS curriculum. You must be really young and new here. You need to pick up new skills on your own. Hopefully 15 more years into your career you'll be thinking about what you learned in the last couple of years, rather than still thinking about what you learned in CS school.
You're thinking too narrowly. So what if ASP.NET 2.0 is a lot different than 1.0? CS is about concepts and patterns. Not about the framework du jour. If your education centered on teaching you a specific language and/or framework, you got ripped off.
Well, Visual Basic has always been a bit of a toy. Nobody I know ever really took it seriously. SO yeah, I can see that becoming the next "COBOL" in the sense that it will be obsolete. But Java? Please! Java devs I know kinda like it. It has plenty of third party support. It is fast and mature. And technically speaking it isn't really that much differnt than C#. So how do you figure it is going to be the next COBOL? Certainly not any time soon.
I'm talking about CS because that is what this thread is about. The issue is this: how fast does technology move and how quickly is what you learn in CS obsolete? I was responding to a person who claimed that most of what you learn is CS is obsolete in the time it takes to make up a lesson plan. Which is just plain wrong.
I'm perfectly comfortable with my ability to pick up new languages and frameworks as needed. And that is because I grasp the larger concepts and patterns, rather than focusing on the the syntax and APIs of particular frameworks.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
[signature]
I don't want to be a luddite and sometimes you can get tripped up if you don't know the latest buzzwords but I've always had a slight suspicion they're all really flowcharts with a bag on the side.
I also have a concern that the spiffy diagrams become an end in themselves, and give the illusion that it's simpler than it is; very dangerous when the dominant organisational belief is that anything computer related is "just a bit of typing".
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I used to work (for 14 years) updating a very large system... multiple platforms, multiple languages, multiple designs.
Was born from the integration of many original unrelated systems, that evolved to be a single one... in the process: language translation/platform migration/redesign was normal.
The long term end-user relevance of the system its posible because supports metaprogramming at diferent points (each in a different language) transparently trought (in todays terms) "template driven bytecode generators" (who had guessed at that time!! we believed to be ast producers)
I was one of the embebed compilers integration guys... at the end we were doing Eiffel, scheme, sql and c. And migrated parts from Modula-3, lisp and some old propietary inventions (at different times tested ml, haskell, ocaml for use) No asm allowed: low level stuff was done in modula-2 (for qa reasons)
I can tell you: Imperative programing can fake functional doing data driven designs (ending with an adhoc functional language) Pointer to data structures can fake OO and dynamic (ending whit an adhoc OO and/or dinamic language) and template generation could make the use practical.
Every paradigm in programming languages can express more clearly some problems, but not all... but, c let you do it all using the least hardware. The question allways has been: How you need it? going from easy and clear to explicit and efficient.
Yes i now, lots of languages but no english (but maybe better than your german)
I've lost count of how many times I've seen this rather basic mistake. Perl is compiled before it executes. So there's a compiler overhead with each execution, and that can amount to several seconds if you use loads of libraries, which is why it's best to run non-trivial perl websites using mod_perl. But once it's compiled, it's as compiled as C and rather more compiled than java.
For many text-based tasks, Perl is blindingly fast. The canonical example (from the Camel Book) is implementing grep in perl, which runs faster than some native OS implementations. That's partly because it's optimised for that sort of task, but it's also that it has a ruthlessly efficient implementation of hashes. Sure, you can do better in C if you really try, but if you don't really try a perl nested hash structure will blow C linear search out of the water.
The Camel book acknowledges that perl isn't the fastest option for tight loops, and ray tracing would probably fall into that category. But, more generally, the other thing about perl is that it has an extremely large collection of APIs to C libraries. If I want to parse XML, LibXML/LibXSLT are among the fastest C libraries out there, and those libraries run about as fast when called from perl as they do called from C.
Virtually serving coffee
Then simply bundle the modules with your program. Not always a universal solution, but we use it a lot to distribute perl applications around our site.
... I honestly thought it was going to be WTF-worthy stories about/from people who had written inappropriate applications in Perl. Or JavaScript or whatever.
It seems to be written for managers who don't know much about programming -- when they get stuck talking to programmers at work functions they'll have something to chat about, before they say "excuse me for a second" and run away to talk to someone important instead.
Bravo friend. I couldn't agree with you more. I study all the time and it's all valuable. But what I learned in my CS curriculum is priceless. That can never be replaced by clever frameworks and technologies.
This post is NOT black.
This post is blacknot.
This post is black...
NOT
Arr! The laws of physics be a harsh mistress!