However, when I just need to do some basic config file editing I use Jove which is a scaled down version of Emacs that has the same keys as Emacs but loads as quickly as vi.
Look into using emacsclient or gnuclient so you can load Emacs as quickly as vi without removing the features that make it Emacs.
Yeah, I noticed that after I posted. I was hoping nobody else would.
Rails has gotten the most press, so it's naturally taken away some of the thunder. I haven't compared them extensively to claim one is better, because I don't care that much.
If we're talking languages, though, comparing Perl to Rails like comparing apples to apple pie. Perl vs. Ruby is a discussion (that I've had before).
What big-name projects is Perl being used for today? While it was once very big for web scripting, that arena now seems to be dominated by PHP, Ruby-on-Rails, ASP, JSP, and so forth.
The trends have moved towards frameworks. Perl now has Catalyst, which is "heavily inspired by such frameworks as Ruby On Rails, Maypole, and Spring," but it's coming a little late(r) to the party.
Even Pugs, a Perl 6 compiler, is written in Haskell rather than Perl.
I once had to write an interpreter for a subset of the OCaml language in OCaml for a class.
Yeah, I did some more looking into ties, and the example I gave before is probably not the best one. However, learning about the feature has been a good experience.
As I understand it, ties are essentially ways of intercepting messages to make more complex structures look like standard types. This has a lot of application in databases, but could be used anywhere. It's a lot (if not exactly) like a Proxy Pattern, which I will return to.
However, I think the Ruby language itself removes the need for the need for this, because of the uniformity of objects - there's nothing special about a hash, array, etc. If I wanted to do the same thing, I would just write a simple interception class, and handle this kind of thing with the method_missing functionality.
This is an implementation of distributed system calls, but you can imagine (and I have done on several occasions) caching calls to a database abstracted through the same idea, making a database look like an Array. Heck, Ruby is so dynamic, you can even redefine the class method so that your interceptor class appears to have the right type!
I don't see how consistency in behavior and interface actually preclude anything, especially to those more familiar with the language. It is a Good Thing(tm) to be consistent, even if it means the language is still accessable to "the uninitiated." In fact, it makes someone already familiar with the paradigms more productive, because they have to look less stuff up, and have a clear idea of what to expect.
Just about every language out there has little nuances for which understanding will only come when one has a great deal of experience with the language involved. Things like Duff's Device that will catch you completely off guard if you are not expecting them.
Yes, but I prefer languages that minimize these nuances and unexpected behavior.
One of the reasons I love Ruby (standing in for Perl) is the sheer consistency of the libraries. Since all objects inherit from the same base class (with a good set of features), if I come across something new, chances are pretty good I know how to deal with it. There's no second guessing, no special types with extra functions you need to learn (yes, new classes have new member functions, but the basics don't change). Messages are handled uniformly to objects - it doesn't matter if it's actually data or a function, so they can be interchanged if the design warrants it. The list goes on...
These kinds of features allow you to fight less with the language and more with the problem.
Let's say you're in a typical Visual Basic shop. You estimate that a project is going to take the team 12 month to complete in VB. Now, let's say that it would take 3 months for the team to learn a more efficient language well enough to complete the project. Because the new language is so much more efficient, you'll be able to finish the project in 8 months instead of 12. So by learning a new language, not only do you have the project complete a month early, but you'll be able to do future projects that much more efficiently.
What makes this decision hard is not knowing those numbers before hand. Projects that jump on new(er) technology at the drop of a hat tend not to fare so well, even if the developers have lots of fun playing with the newest toys. It's rare that a new language/framework holds up to its initial hype.
Some languages are better designed than others, and allow you to do things easily that are difficult (if not impossible) in other languages.
Indeed. But the best drill press in the hands of a baker is just going to send someone to the hospital.
I'd suggest that anyone who's serious about developing software read this essay. It's highly enlightening.
Thank you for pointing to this - It's a great read. I have bookmarked it for later in-depth consumption.
In re-reading my post, I don't think I really said in this last bit what I intended (ironic, in a discussion about language). The language is important, but no language will handle design for you, despite any claims of the vendor. Even with a good language, you can write bad things. Also, many languages cater to particular programming styles.
Sometimes, it's also acceptable to use an inferior tool if:
It's all you've got.
Other parts of the system alreay use it.
Your people already know it. (the cost of learning something new is never small)
It's already proven to be good enough (to inspire confidence in those funding you).
Language choice is always a tradeoff. Most projects don't have the freedom to explore this, but those that do should.
As to the "too much to remember" I'd answer, "No. Not really.". It's neat that a lot of the one-off stuff is there but you don't really need to commit it to memory.
The problem is, a good portion of people who loudly support Perl cite these kinds shortcuts as reasons they can write code quickly (and with as few characters as possible). If that's the case, then they probably use them. If I have to deal with their code, then I'm going to have to remember this stuff, or go look it up. Not every programmer has the luxury of not working with others.
And that was just correcting a newbish misunderstanding about the language -- if you know of a language where new programmers don't make any mistakes or misunderstand anything I'd love to learn it.
I'm starting to sound like a bit of an evangelist, but of any language I've seen, Ruby is the closest to what you've asked for. The behavior is very consistent. After a few chapters of the "Pickaxe" book (available online here - http://www.ruby-doc.org/docs/ProgrammingRuby/), you should be up and running.
I'll admit - I'm no Perl guru. I could make better arguments if I were. Because of my interest in languages, I'll get to it one of these days. I'm definately subject to some of the newbish misunderstandings. However, if I'm really going to learn a language, it's either needed (I learned Java for a course in distributed systems), or I'm excited about the features and design of the language.
For sharp contrast look at how C++ handles OO behaviors.
C++ is not the pinacle of OO design, it's just the one everyone knows. Like Perl (although, as you state, with a different approach) it has been added to a language which was not inherently object based.
Contrast this with Smalltalk, Eiffel, or Ruby, and you might understand why I don't like it.
Well, if you were trying to piss someone off I think you failed miserably. You made well reasoned arguments and presented them without being inflammatory. I happen to disagree with you but that's not enough to piss me off.
No, I wasn't trying. I actually enjoy having serious, non-inflamatory discussion about programming languages (hence the reason I've posted here quite a few times). I'm glad you're here backing up your side maturely.
I rarely go into a situation looking to piss people off, I just do anyways. Glad to hear I'm ineffective.
I'll close by saying that the important thing to me about Perl isn't if it's the perfect programming language or not. No, the important thing is that it let's me do the work I need to do quickly and easily while I get paid a handsome sum to do something I enjoy.
That's a good sentiment. I feel exactly the same way about Ruby (which I use at home and at work, whenever I'm not writing production code that has to be in C). But if we're talking about which language to use for a task, then these kinds of things should be the focus.
The particular project I was talking about simply put performance evaluation too late in the plan (in an embedded environment). Some people seem to think Java is a magic button you can push that does everything for you.
This thread is really starting to make my point for me. Perl is just too idiosyncratic. There's too much to remember, and I'd quite frankly rather spend my time thinking about design problems and algorithms than niche features.
Yes, there are some nice features for writing shell utilities (which is where Perl should be). But if we're talking large scale apps, my thoughts always go to object orientation, when things get more complex than processing text and command line options. Don't go telling me that Perl has superb OO features.
As much as webtrash gets a bad beat, developing a good application is a really complex problem, simply because of the limitations of the web.
I swear I'm done. I'll go piss off some Java people now, unless any Python junkies want to step up (I haven't yet seen much of that yet, and I'm surprised)...
If your main concern is programmer time, find a framework. You will take a performance hit, but you'll have most of the tedious work out of the way, letting your programmers focus on the stuff that matters.
OCaml (notice the spelling, for people who are interested in learning more) is awesome. I'm too lazy to look up specifics, but I know it's been the tool of choice for several competitions where speed was a major factor. We had to use it for a programming languages class (a while ago), and I couldn't be happier about it.
The problem is, many people just can't wrap their minds around functional programming...
I think Perl gets put down a lot for being unmaintainable because it has allowed people to complete projects they otherwise could never have completed. I've been witness to several Java rewrites of to replace Perl projects and not one as been successful. This is despite the fact that the original Perl programmers "didn't know what they were doing" according to the java "software engineers".
I have seen Java projects fail because of the language, but for performance issues, and not because the language is inadequite (unless the project was written in Brainfuck). These projects probably had other reasons for failing.
I think my point is, if we're going back to the original question, is that, although Perl has its place (I don't like it, so I use Ruby instead), that place isn't large-scale applications with performance and upkeep demands. If a project grows from a small perl script to a "multi-million dollar revenue stream," then I don't recommend changing the language (read my other post below). However, the original scope of these projects were obviously not to be large-scale web applications. They simply became that.
I hate Java, too. The hype is such that management seems to think it's the answer everything, but it's really just the (somewhat broken) syntax of C++ with less flexibility and the added fun of a VM.
Captain Negativity to the rescue. If you've got any other programming languages you'd like to throw out there, I'll be happy to bash them too...
Ruby is another write only language if you dont know it (actually arent they all!).
This is I presume simple example code. God only knows what kind of code a ruby "haXX0rzzzz" would produce:
The thing about this is, skilled Ruby programmers (that I've seen) produce beautiful, simple code, devoid of silly things like conditionals. These programs aren't hard to understand.
OTOH, the Perl mentality seems to be "I can do that in fewer keystrokes!"
These are obviously over-generalizations. I have seen good Perl code and lousy Ruby code. I just think that Ruby is more condusive to good code (personal preference, really).
Smarter people than myself have said it, if the people you have know a certain language, use that, don't force them to use something else even if it is conceived to be better.
True. But in the same vein, if you have lots of code already in a particular language, think long and hard before switching languages, even if your people are partial to a different one.
It can be especially unproductive to mix languages unnecessarily; you end up with lots of code just to get them to work together, and duplicate even more code.
AC is right. Perl is not the best choice as far as upkeep goes. This is especially true if you get those l33t p3rL haXX0rzzZ who feel the need to program in circles.
What is a better language than perl? Why, Ruby! (and not just because of Rails) However, for large projects where performance may be a significant factor, the answer for many of the back-end logic stuff would be something more like C/C++.
I agree with many other people posting. The language itself is not important. Good design and good people are what leads to good code. The language is only a tool.
At the time when there was a council concerning the promotion of a certain man, the council members were at the point of deciding that promotion was useless because of the fact that the man had previously been involved in a drunken brawl. But someone said, "If we were to cast aside every man who had made a mistake once, useful men could probably not be come by. A man who makes a mistake once will be considerably more prudent and useful because of his repentance. I feet that he should be promoted."
Someone else then asked, "Will you guarantee him?"
The man replied, "Of course I will."
The others asked, "By what will you guarantee him?"
And he replied, "I can guarentee him by the fact that he is a man who has erred once. A man who bas never once erred is dangerous." This said, the man was promoted.
Slashdot Mirror
keep in mind that IGN began by acquiring fan sites (n64.com, etc).
n64.com was always owned by IGN, although it wasn't apparent until the site became ign64.com. Read the response to the first question:
http://cube.ign.com/mail/2005-09-09.html
However, when I just need to do some basic config file editing I use Jove which is a scaled down version of Emacs that has the same keys as Emacs but loads as quickly as vi.
Look into using emacsclient or gnuclient so you can load Emacs as quickly as vi without removing the features that make it Emacs.
Yeah, I noticed that after I posted. I was hoping nobody else would.
Rails has gotten the most press, so it's naturally taken away some of the thunder. I haven't compared them extensively to claim one is better, because I don't care that much.
If we're talking languages, though, comparing Perl to Rails like comparing apples to apple pie. Perl vs. Ruby is a discussion (that I've had before).
What big-name projects is Perl being used for today? While it was once very big for web scripting, that arena now seems to be dominated by PHP, Ruby-on-Rails, ASP, JSP, and so forth.
The trends have moved towards frameworks. Perl now has Catalyst, which is "heavily inspired by such frameworks as Ruby On Rails, Maypole, and Spring," but it's coming a little late(r) to the party.
Even Pugs, a Perl 6 compiler, is written in Haskell rather than Perl.
I once had to write an interpreter for a subset of the OCaml language in OCaml for a class.
Ahh, but do you remember the ad campaign from Motorola that used The Rolling Stones' "You Can't Always Get What You Want" as the theme song?
I actually liked the "benchmark studies prove that Dell sucks" one - honest and to the point.
What is so special about that, that's how RAID is supposed to work? Remove failed drive, insert replacement, wait, data regenerated.
RAID 0 (striping) has no redundancy. I'm pretty sure that's what the grandparent meant.
Yeah, I did some more looking into ties, and the example I gave before is probably not the best one. However, learning about the feature has been a good experience.
As I understand it, ties are essentially ways of intercepting messages to make more complex structures look like standard types. This has a lot of application in databases, but could be used anywhere. It's a lot (if not exactly) like a Proxy Pattern, which I will return to.
However, I think the Ruby language itself removes the need for the need for this, because of the uniformity of objects - there's nothing special about a hash, array, etc. If I wanted to do the same thing, I would just write a simple interception class, and handle this kind of thing with the method_missing functionality.
Take a look at this Ruby implementation of a Proxy Pattern to get an idea of what I'm talking about:
http://www.rubygarden.org/ruby?ProxyPattern
This is an implementation of distributed system calls, but you can imagine (and I have done on several occasions) caching calls to a database abstracted through the same idea, making a database look like an Array. Heck, Ruby is so dynamic, you can even redefine the class method so that your interceptor class appears to have the right type!
I don't see how consistency in behavior and interface actually preclude anything, especially to those more familiar with the language. It is a Good Thing(tm) to be consistent, even if it means the language is still accessable to "the uninitiated." In fact, it makes someone already familiar with the paradigms more productive, because they have to look less stuff up, and have a clear idea of what to expect.
Look at Ruby's Og (which is in the same vein as tied hashes):
http://www.nitrohq.com/view/Og
Yes, it does some interesting things, but the interface to it doesn't have to be strange.
Just about every language out there has little nuances for which understanding will only come when one has a great deal of experience with the language involved. Things like Duff's Device that will catch you completely off guard if you are not expecting them.
Yes, but I prefer languages that minimize these nuances and unexpected behavior.
One of the reasons I love Ruby (standing in for Perl) is the sheer consistency of the libraries. Since all objects inherit from the same base class (with a good set of features), if I come across something new, chances are pretty good I know how to deal with it. There's no second guessing, no special types with extra functions you need to learn (yes, new classes have new member functions, but the basics don't change). Messages are handled uniformly to objects - it doesn't matter if it's actually data or a function, so they can be interchanged if the design warrants it. The list goes on...
These kinds of features allow you to fight less with the language and more with the problem.
Let's say you're in a typical Visual Basic shop. You estimate that a project is going to take the team 12 month to complete in VB. Now, let's say that it would take 3 months for the team to learn a more efficient language well enough to complete the project. Because the new language is so much more efficient, you'll be able to finish the project in 8 months instead of 12. So by learning a new language, not only do you have the project complete a month early, but you'll be able to do future projects that much more efficiently.
What makes this decision hard is not knowing those numbers before hand. Projects that jump on new(er) technology at the drop of a hat tend not to fare so well, even if the developers have lots of fun playing with the newest toys. It's rare that a new language/framework holds up to its initial hype.
Indeed. But the best drill press in the hands of a baker is just going to send someone to the hospital.
I'd suggest that anyone who's serious about developing software read this essay. It's highly enlightening.
Thank you for pointing to this - It's a great read. I have bookmarked it for later in-depth consumption.
In re-reading my post, I don't think I really said in this last bit what I intended (ironic, in a discussion about language). The language is important, but no language will handle design for you, despite any claims of the vendor. Even with a good language, you can write bad things. Also, many languages cater to particular programming styles.
Sometimes, it's also acceptable to use an inferior tool if:
- It's all you've got.
- Other parts of the system alreay use it.
- Your people already know it. (the cost of learning something new is never small)
- It's already proven to be good enough (to inspire confidence in those funding you).
Language choice is always a tradeoff. Most projects don't have the freedom to explore this, but those that do should.As to the "too much to remember" I'd answer, "No. Not really.". It's neat that a lot of the one-off stuff is there but you don't really need to commit it to memory.
The problem is, a good portion of people who loudly support Perl cite these kinds shortcuts as reasons they can write code quickly (and with as few characters as possible). If that's the case, then they probably use them. If I have to deal with their code, then I'm going to have to remember this stuff, or go look it up. Not every programmer has the luxury of not working with others.
And that was just correcting a newbish misunderstanding about the language -- if you know of a language where new programmers don't make any mistakes or misunderstand anything I'd love to learn it.
I'm starting to sound like a bit of an evangelist, but of any language I've seen, Ruby is the closest to what you've asked for. The behavior is very consistent. After a few chapters of the "Pickaxe" book (available online here - http://www.ruby-doc.org/docs/ProgrammingRuby/), you should be up and running.
I'll admit - I'm no Perl guru. I could make better arguments if I were. Because of my interest in languages, I'll get to it one of these days. I'm definately subject to some of the newbish misunderstandings. However, if I'm really going to learn a language, it's either needed (I learned Java for a course in distributed systems), or I'm excited about the features and design of the language.
For sharp contrast look at how C++ handles OO behaviors.
C++ is not the pinacle of OO design, it's just the one everyone knows. Like Perl (although, as you state, with a different approach) it has been added to a language which was not inherently object based.
Contrast this with Smalltalk, Eiffel, or Ruby, and you might understand why I don't like it.
Well, if you were trying to piss someone off I think you failed miserably. You made well reasoned arguments and presented them without being inflammatory. I happen to disagree with you but that's not enough to piss me off.
No, I wasn't trying. I actually enjoy having serious, non-inflamatory discussion about programming languages (hence the reason I've posted here quite a few times). I'm glad you're here backing up your side maturely.
I rarely go into a situation looking to piss people off, I just do anyways. Glad to hear I'm ineffective.
I'll close by saying that the important thing to me about Perl isn't if it's the perfect programming language or not. No, the important thing is that it let's me do the work I need to do quickly and easily while I get paid a handsome sum to do something I enjoy.
That's a good sentiment. I feel exactly the same way about Ruby (which I use at home and at work, whenever I'm not writing production code that has to be in C). But if we're talking about which language to use for a task, then these kinds of things should be the focus.
The particular project I was talking about simply put performance evaluation too late in the plan (in an embedded environment). Some people seem to think Java is a magic button you can push that does everything for you.
Perhaps the moral is "Java breeds mismanagement."
This thread is really starting to make my point for me. Perl is just too idiosyncratic. There's too much to remember, and I'd quite frankly rather spend my time thinking about design problems and algorithms than niche features.
Yes, there are some nice features for writing shell utilities (which is where Perl should be). But if we're talking large scale apps, my thoughts always go to object orientation, when things get more complex than processing text and command line options. Don't go telling me that Perl has superb OO features.
As much as webtrash gets a bad beat, developing a good application is a really complex problem, simply because of the limitations of the web.
I swear I'm done. I'll go piss off some Java people now, unless any Python junkies want to step up (I haven't yet seen much of that yet, and I'm surprised)...
Also, your sig is awesome.
If your main concern is programmer time, find a framework. You will take a performance hit, but you'll have most of the tedious work out of the way, letting your programmers focus on the stuff that matters.
Here! Here!
OCaml (notice the spelling, for people who are interested in learning more) is awesome. I'm too lazy to look up specifics, but I know it's been the tool of choice for several competitions where speed was a major factor. We had to use it for a programming languages class (a while ago), and I couldn't be happier about it.
The problem is, many people just can't wrap their minds around functional programming...
I think Perl gets put down a lot for being unmaintainable because it has allowed people to complete projects they otherwise could never have completed. I've been witness to several Java rewrites of to replace Perl projects and not one as been successful. This is despite the fact that the original Perl programmers "didn't know what they were doing" according to the java "software engineers".
I have seen Java projects fail because of the language, but for performance issues, and not because the language is inadequite (unless the project was written in Brainfuck). These projects probably had other reasons for failing.
I think my point is, if we're going back to the original question, is that, although Perl has its place (I don't like it, so I use Ruby instead), that place isn't large-scale applications with performance and upkeep demands. If a project grows from a small perl script to a "multi-million dollar revenue stream," then I don't recommend changing the language (read my other post below). However, the original scope of these projects were obviously not to be large-scale web applications. They simply became that.
I hate Java, too. The hype is such that management seems to think it's the answer everything, but it's really just the (somewhat broken) syntax of C++ with less flexibility and the added fun of a VM.
Captain Negativity to the rescue. If you've got any other programming languages you'd like to throw out there, I'll be happy to bash them too...
Ruby is another write only language if you dont know it (actually arent they all!).
This is I presume simple example code. God only knows what kind of code a ruby "haXX0rzzzz" would produce:
The thing about this is, skilled Ruby programmers (that I've seen) produce beautiful, simple code, devoid of silly things like conditionals. These programs aren't hard to understand.
OTOH, the Perl mentality seems to be "I can do that in fewer keystrokes!"
These are obviously over-generalizations. I have seen good Perl code and lousy Ruby code. I just think that Ruby is more condusive to good code (personal preference, really).
Smarter people than myself have said it, if the people you have know a certain language, use that, don't force them to use something else even if it is conceived to be better.
True. But in the same vein, if you have lots of code already in a particular language, think long and hard before switching languages, even if your people are partial to a different one.
It can be especially unproductive to mix languages unnecessarily; you end up with lots of code just to get them to work together, and duplicate even more code.
Perl is a write-only language
O, if only mod points hath I.
AC is right. Perl is not the best choice as far as upkeep goes. This is especially true if you get those l33t p3rL haXX0rzzZ who feel the need to program in circles.
What is a better language than perl? Why, Ruby! (and not just because of Rails) However, for large projects where performance may be a significant factor, the answer for many of the back-end logic stuff would be something more like C/C++.
I agree with many other people posting. The language itself is not important. Good design and good people are what leads to good code. The language is only a tool.
s/feet/feel/
I erred once. I want a promotion.
Have you ever submitted code to Linus, Alan, et. al.? They're total code nazis.
Exactly. We don't want any Nazis in charge of our defense systems. That's a security threat.
Lots of shameless prlugs, yes, but look at what's being advocated:
;-)
* More intuitive
* More inclusive
* Pattern recognition vs. "yes/no" type logic
Ah... ok, let's turn those 90 degrees:
* More context-aware
* There's more than one way to do it
* Logic using higher order comparison such as regular expressions and grammars
Hmmm... Perl anyone?
To me, this sounds like a job for OCaml! I'm not kidding.
1) Imagine a beowulf cluster of these...
2) ????
3) Profit!