Programming vs Scripting

Normally I would agree with Larry's comments, but after working a few years in both scripting (Perl, Ruby) and programming (Java, C, C++) in many different language variations.  I think if I had to choose between one or the other, it would be it depends.

If I had a choice, it basically boils down to who is going to code and maintain it.  If the answer is anyone but me, myself and I, then I would go for a programming language rather than a scripting language.

Easy Onramps

Though I have to admit, the amount of effort to learn Perl myself is quite shallow, I learned to do most of the things I need to do within the first week of using Perl just because I code-build-run cycle is just one command, perl.

When I have to deal with other people, they would already know how to do the javac-java or at least use the Run As Java Application command on their IDE.  Without those, I don't think we'd even get them into our development teams.

Java/C# programmers are generally a dime a dozen.  Though you do get what you pay for.

So providing an easy onramp is good and all, but it is not a reason for me to get other people who are already trained as Java programmers to switch over.

TIMTOWTDI

"There is always more than one way to do it," is a very useful feature when I am coding for myself.  Not just coding, but I think well developed UIs should also follow that approach which I alluded to when I talked about Input Context Efficiency.

Having the option to do things differently reduces the amount of time I have to think about to get something working and focus more on getting what I need done.

When you are working in a large enough team, that freedom can backfire onto you.  Unless you are significantly diligent in your code reviews, TIMTOWDI can create a maintenance nightmare because everyone codes things their own way.

In Java, we have one conditional keyword: if.  In Perl, we have if and unless.

In Java, we have one way of writing "and": &&.  In Perl, we have && and and.

In Java, we have only one way of structuring our code: package containing classes containing methods.  In Perl, we can have an entire method in one file, or multiple classes of different names in the same file, multiple modules in a single file.

In Java, we have to explicitly define variables that we use.  In Perl, we have $_.

Granted that most of these problems can be handled automatically by some code review tools that are available in Perl and Java, I haven't found one for Perl that would integrate with the IDE as Checkclipse does.

early binding / late binding

Most scripting languages have a concept of late binding.  Which means that unlike Java, classes are not "final" and you can add new methods dynamically.

Although if I write code I may need to use that feature.  I would delay finding out about any errors until run-time.

If it were just me, then I would be creating some unit tests that would prove that the methods I call do work correctly.  Or sometimes since I would write something one off, I just let it fail at run-time when I run a test because it is easy enough to find the problem.

However, keeping track of 1000 methods in your head can be quite daunting too.  Not to mention typing it correctly.  Copy and paste may be safer, but it forces me to switch to my mouse to point to what I need to copy and paste.

Auto-completes do help out, but if one just thinks he typed something in correctly, and it fails at runtime.  Then the repercussions could be quite bad if it had been deployed to a production environment where change management processes are enforced.

I'd rather have something fail as early as possible rather than later.  Unit testing does help out with this one, but finding those kinds of developers are more difficult.  Especially if you have to deal with global resourcing.

Conclusion

As I have stated before, it basically boils down to is it for myself or for others.

If I have to write for others, I would use a programming language that would limit what I can do, and have almost everything defined including how to indent and casing.  Because that is easier for me than explaining how I do something in a language most people won't understand.

If I have to write for myself, I'd use whatever tool makes it easier for me.  Which in 90% of the time is Perl.