Not my intention to start a flame war. I believe every language has its own fans and they'll defend it bitterly that it is the best and only language everyone needs or need to learn.
It stems more from a paradox of choice. As mentioned, I am OK with programming in Perl, Python and PHP, and for a given requirement, I can probably implement 3 exact same versions of it in each language. Just that I was wondering if they are different in some way that makes them easier for certain situation or requirements.
For example, if you want to do task A, use language X. For task B, use language Y. Language Z is designed for C. And so on.
The answer is always YES. Creators of the languages often come from certain background in their own field. Like most of us, they are master of some and jacks of the rest. Their envision to their own programming languages will definitely have certain biased towards doing well in some areas but not in the rest. Some of these decisions are conflicting in nature, like if you want dynamic metadata to the language, there will be runtime information during execution. More memory will be required to accomodate the dynamics and hence data are not as compact, more dereferencing are required during variables access. If a programming language can accomodate infinite recursion then stack space must be dynamic in nature and therefore more performance lost. As such each programming language will have its pro and cons, resulting in them performing better in some specific cases that uses those features.
Years back when I'm doing an overseas project, I used 3 programming languages across the whole solution, namely Java, Groovy and Perl. Java for the main system, Groovy for cron where it requires Oracle JDBC drivers but I want the dynamic nature of the language and Perl for other system administration scripts.
Any wise developers will want to choose the right tool for the right job. Bulldozing their way using just one programming language when you know there is a better one out there is a limitation one inflict upon oneself.
That is why a developer need to be versatile to know as much programming languages as possible to release these limitation. It take time to learn any programming language, to know how to make use of the features properly and understand the penalty or cost in using specific features. You don't decide last minute to use a programming language. Over time you identify the feature of each programming language by experimenting with it, like using it for less important tasks in a project as a trial. As you discover more about the programming language, you can then choose to introduce them into more important areas of future projects. That's how one can eventually pick up more skills along the way.
At a commercial project level yes, these considerations are important. For personal projects, we have more leeways.
My personal (biased) preference has always been convenience with its platform having tons of common built-in functions provided, without having to hunt around for third party extensions, packages and modules.
I remember Java didn't have a Base64 encoder/decoder built-in.
But at least it provided decent basic networking and cryptographic functions.
To answer your doubt on Java, yes there is a built in Base64 encoder/decoder
Code:
import sun.misc.BASE64Encoder;
import sun.misc.BASE64Decoder;
But as the namespace indicate, these are not public API and hence not recommended for use. However over the years, there are so many projects that I have come across uses them.
Well you can have your biased, it's your growth into software development. For me, I don't care if it's built in or not. When I assess a programming language, I assess the ecosystem as a whole. Setting yourself the limitation is not wise in my opinion. An example of the Base64 component you required has been part of the Apache Commons Library for a long time, so I don't feel affected by whether it's built in or not. Java has been a very easy programming language and extremely easy to drop in any Java libraries due to the extremely well defined inheritance model. You will find it is a lot more difficult and confusing when working with C++ packages since there is no single root inheritance model for C++. Java enforce the root to be Object class and interface, which makes adding any packages into a system as simple as mounting a new filesystem into any part of the filesystem.
Managed memory model not only provides highly secure development platform, but also consistent memory management across packages. For C/C++, all these are not consistent across packages you get from various owners. Some expect the caller to allocate the memory, some expect the callee to allocate the memory. In Java, no such nonsense since references is all that matters, not one exclusively own it.
I started playing with Perl in 1996 or 1997. At first, I didn't find it too bad actually, having learnt programming in C. Later on, I started to dislike it for the way special variables are used and the implicitness of their meanings based on context for example the omniscient $_ sprinkled everywhere. I prefer things to be clearly labelled, but it's a personal opinion and preference.
There are good practices on how one can code in Perl. I code in both manners depending on situation. When I am creating a proper system using Perl, I don't use implicit $_ unless it is necessary. I will use
Code:
use strict;
use warnings;
to ensure no sloppy coding. I will use plentiful of comments through out the program and proper indentation too. For example the if..else statement
Code:
if (...) { # reason
} else { # reason
}
When using RE, I will assign the output instead of let it assigned to $_. Even if the output is $_, I will first assign it to a variable for later use instead of working on the $_ repeatedly. For example this regular expression capturing group
Code:
# concise manner
my($digits,$alpha) = $expr =~ /([0-9]+)([A-Za-z]+)/;
# sloppy manner
$expr =~ /([0-9]+)([A-Za-z]+)/;
# Using $1 for $digits and $2 for $alpha
# while loop manner
while ($expr =~ /...../sg) {
my $match = $_;
# work with $match instead of $_
}
If I'm coding perl as part of a shell script, I can afford to be sloppy as such
Code:
#!/usr/bin/bash
OUTPUT=`ls | perl -ne 'tr/[a-z]/[A-Z]/; print'`;
When dealing with any programming languages, good developers don't let the syntax enforce the discipline. They should enforce discipline in their pattern of development. In this way, whichever programming language it is, it makes little difference. It's like know various dialects of Tamil, each different in specific way, but not all that different from each other.
Well, Perl 6 is taking a long time to come with proper OOP while they rewrote everything under Parrot engine I believe. Perl 5 introduced a hacky form of OO like JavaScript and used
bless to link an associative array to a class when it is actually a package with some functions. It looks like heresy to me.
It didn't feel too bad, until I went to Java and saw OO that is clean, straightforward and pristine. Python shows similar characteristics. If it's OO, it has to be
real OO. Not something that looks like OO. Again my personal preference.
Well indeed Larry and his gang has been taking a long time to push out Perl 6. Larry introduced something I don't know if we wanna consider it neat, but Perl 6 can be parsed using Perl 6. My last review of the language also know it is going to break a lot of Perl 5 programs. So I will believe it will take awhile before Perl 6 will be on track.
Don't be too anal about how things works. Important is they work. I think I have long forgiven such eccentricity in programming languages, so it doesn't bother me like it did years back.
But when it comes to parsing lines of text files and matching patterns using regular expressions, Perl is godlike by making it trivial. Python and Java probably need more lines of codes and formatting to do the same thing.
So far no programming languages that I came across matches up to Perl for RE. Ruby has it close enough, but Perl has features that makes RE not-RE, such as code embedded inside the expression.
So I have found someone who has written command line scripts in PHP.
I thought in real life nobody uses PHP this way though it has always been there. 99% uses PHP for web applications.
Well a tool is just a tool. Why limit yourself to what it can do. I have written shell script and C programs for Web CGI too. For PHP, all you need to do is install the PHP CLI package.
That's why when dealing with binary data and files, I still prefer to write it in C/C++/Java/C#. But I think I should just learn to stomach
pack and
unpack format syntax.
I don't know what is your take to pack and unpack, but it seems alright to me. If it is about performance, I find it often much over-rated in discussion. Realistic optimization is to optimise 80% for 20% of the code. As long as 20% of the code where bottleneck are discovered and the speed gain is 80%, one will already see great improvement in the overall application. As time goes, newer revision of the same application may gain better performance from a new architecture.
If you find pack and unpack a performance issue, then you should consider changing the data format, or changing that portion of code to be written using something else. If it is a OCD thing, then probably there is no solution to it, perhaps to pop a few pills
