Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re^2: Comparing languages

by aufflick (Deacon)
on Oct 21, 2005 at 05:54 UTC ( [id://501893]=note: print w/replies, xml ) Need Help??


in reply to Re: Comparing languages
in thread Comparing languages

I would disagree. You may validly choose a less efficient language for a valid reason. Or you may validly decide that you feel more comfortable with a language even though there are others that are slightly more efficient. But when a language takes significantly more developer time and effort than languages with a comparable application, I can't see why you would choose it without some really compelling overriding reason.

There have been many attempts to classify and compare languages empirically, and different measures have different levels of flaw and merit. Is there any empirical evidence that comparitively measuring programming languages is fundamentally flawed? I'm not saying there's not, in fact if anyone is aware of any I would be very interested in reading it.

Replies are listed 'Best First'.
Re^3: Comparing languages
by Perl Mouse (Chaplain) on Oct 24, 2005 at 09:21 UTC
    But when a language takes significantly more developer time and effort than languages with a comparable application, I can't see why you would choose it without some really compelling overriding reason.
    I can. Developer time is only one aspect of choosing a programming language, and IMO, not the most important one. Resource usage (CPU, memory, disk space) of the running application is a major consideration as well - you might decide it's not important, but you should consider it. Portability might be an issue. Stability certainly is - Perl does have an impressive list of open bugs. It's years ago that I had to code around a bug in a C compiler (be it gcc or a commercial compiler), but I do encounter a bug in Perl several times a year. (And, it being open source software, some get fixed, others have been open for many years). Another issue might be standardization. C has a standard, and there are many suppliers of C compilers - Perl doesn't have a standard, and there's only one "vendor". It's not always clear what is a bug, what is a feature, or what is an implementation artifact, which can cause headaches when upgrading. (Recently I had a case where an application failed at a customer. They were running Perl 5.8.1 as we said they should. But they were running Activeperl build XXX instead of the (slightly older) Activeperl build YYY we had tested with. Not that Perl was at fault, but it did things differently and some other server couldn't cope with that). As for developers, you will have to adapt your language of choice to you developers as well. If you have Java developers in house (because for the previous project, Java was the 'perfect' choice), you might be better off choicing Java or a similar language for your next project, even if Perl would be a 'better' choice when purely looking at the language angle. And if your developers absolutely loathe using Python, you'll have to make pretty good arguments to force it upon them.

    Developer time is one aspect. But it's just one of many. And it has never been a reason for me to pick Perl for a task. I pick Perl for different reasons.

    Perl --((8:>*

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://501893]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (7)
As of 2024-03-29 08:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found