I have come from an end user support (both hardware and software) background. Typically the "I can't print..." or "I can't read my mail..." type problems. This was many years ago in a Banyan Vines pre 5 environment.. I moved towards a more networking support implementation type role and looked after a team of 8 people installing small LANs into retail stores. As you can see... NO PROGRAMMING background at all.

I dabled in html and web page building (hardley design) for a while and came across Perl, but never paid much attention to it. (I even spent some time supporting OS2 and played a very little with Rexx.)

After several more moves, I find that I am at a place in life where I am really happy... I work for a small consulting company.. 11 of us internationally ... that specialise in enterprise management. Really exciting stuff. We architect both IT and Non-IT management solutions for corporate companies.

After implementing the management solutions we proposed for a while, I found that I could offer FAR more value if I customised our solutions. In fact I learned Perl because a customer I was contracting to, needed me to log a call in remedy from the management product we were using. It ALL started for me 'to see if I could do it'. From there, I was asked to do more and MORE.. till today .. I try and do almost anything in Perl (and now its expected that I can..).

For me, Perl fits beautifully because the developement time is really so short. How long would it take me to write a Win32 Service in C++(or anything else) as opposed to doing it in Perl (using the right modules of course)..? How easy would it be for me to write a socket client in any language for Win32 and then re-do it so I can port it to *nix..? Both these I have done, the portability of code I wrote on the win32 platform for a socket connection, being only slightly modified to run on Solaris.. and this was for eventlog stuff on the Win32 platform that had to be changed.. The types of things I need to code for are not needed to run faster than a speeding bullet, so speed is not really an issue..

So...why would I need to learn another language other than for the journey along a new path..?

-----Of all the things I've lost in my life, its my mind I miss the most.

So...why would I need to learn another language other than for the journey along a new path..?

You wouldn't. If you have the means to solve your problems already at your disposal then there is no need to learn another language.

That said, learning new languages will broaden and deepen you perspective on the way you view and do things. Learning C will give you a deeper respect for how things work a bit closer to the metal, and learning the likes of Scheme and Haskell will broaden your view on programming in general. I could go on listing the various languages and how they will benefit your understanding of programming and programming languages but I think what you probably want to hear is this - the status quo isn't a bad thing in your case, but it will certainly to be to your advantage to learn new things.
HTH

I must admit that I took a short look at C a while ago and was overwhelmed.. and just recently tried again. Since I have learned so much in Perl I find that I understand far more than the first time I tried.. I suspect that the same will be true of many languages I will come across in the future.

-----Of all the things I've lost in my life, its my mind I miss the most.

Methinks C would be a good thing to learn. Seeing that speed is one issue that might actually turn up one day, you'd have the skills to write modules in C ;) Personally, I'm attacking a problem right now that requires some C knowledge to go with me perl. That's a first for me personally. Thankfully I started as a C programmer.

As far as other languages, Java might not hurt for marketability. Not only that, but the similarities of other languages to Java would allow for easier steps to the rest.

Beyond that, I agree with some of the others here. You don't NEED to learn anything. But, where is the fun in that?

So...why would I need to learn another language other than for the journey along a new path..?

From a short term practical point of view, I have found that learning JavaScript has been extremely useful seeing as most if my work runs on a server and is viewed by a web browser client.

The two languags are reasonably complementary and not too different and it can be quite nice to get the client to run the display cruft while the server gets on with someone else. JS can also alow you to do much of the input validation on the client thus saving considerable effort in making the server reject malformed queries politely.

The other, longer term, reason for leaning a new language is that it helps you to think of things in new ways. TMTOWTDI is a big strength of perl, but many perl programmers who have learned perl after experience with other languages come with built-in assumptions because they map perl to $previous_language. I suspect that in a similar fashion your perl will get better if you learn some other languages in addition to perl.

it can be quite nice to get the client to run the display cruft while the server gets on with someone else.

Is it a closed environment where you have control over the clients? If not, I won't be able to view your site and a lot of other people won't either. Cause I don't usually enable JS - or am sometimes powered by lynx/links.

JS can also alow you to do much of the input validation on the client thus saving considerable effort in making the server reject malformed queries politely.

Yikes! What stops anyone from using a saved and edited HTML page or LWP or one of the million other possibilities to maliciously send you malformed input?

(This is a few days after this thread/post, but i felt it required a reply).

No where in dingus' post did he say that he blindly trusts the client. What he said was that using javascript to validate the form on the client side is much more efficient then using the equivalent Perl. Having a little box that pops up and says 'your password must be 3 letters long', is much more useful when you don't have to make a round trip to the server to see it. This is definately an issue with very long types of forms, where the prospect of possibly reentering all the data, merely because you forgot to put a space in your address or something equally petty, is a bad one. Not to mention it can save you, the developer, quite a lot of effort when you don't have to worry about returning a customized error doc for every single type of mistake the user could possibly make. If you perform the majority of the validation on the client side, then you can simply display an 'invalid data' error doc to the client, and not have to worry about every case.

So...why would I need to learn another language other than for the journey along a new path..?

To swipe an old saying that Apple once swiped:

The journey is the reward.

By getting out and seeing more of the world, you're exposed to different perspectives, different ways of approaching problems, and different tools. All of which you can bring back to enrich whatever rut you've chosen to live in.

I'm not a particularly great Perl programmer, but by having worked in Smalltalk many years back I can do things with objects in Perl that amaze people who think Perl is merely a scripting language. By having worked in C, C++, and Java (and *cough* VB), I can intelligently compare and contrast them. And if I get into a project where some of these languages need to co-exist, I'm not lost. By having debugged in all of these environments, I've amassed a big bag of tricks.

You can do a lot of things in Perl, but Perl isn't the world. Get out and travel a bit.

good call, I was going to write something along these lines as well... :-).

While I havnt had much experience with Java/C(++), I've done some VB, pascal (and delphi), plsql (and sql), js, basic, vbs perl, and all the "easy" languages to program in.

To change tact a little, I've found my archetitural skills are the skills I've honed further. The project's I've been involved in, perl has been sufficient (and more than capable), however the implementation of the design becomes the critical factor of the success of the project.

Moving from inline code, riddled with globals, to subroutines and passing references to a nice abstracted set of reusable modules has made life easier and more maintainable for me.

But really we are in agreement. It's well accepted wisdom in many places that programmers who can program in more languages can program better in any given language. This can be absolutely stunning to watch in practice. There have been a number of times I've seen someone with a dozen languages tucked away in their brain walking into a new language X and within a matter of days producing cleaner, better code than people who have spent twenty years mastering X. Specialization and focus can be very self destructive in this business.

A language is a tool, designed to solve a particular set of problems. General purpose programming languages are extremely versatile tools, and no doubt perl is one of the more extreme examples of that genre.

Even so, there is still, what I like to call, the "perl" viewpoint. It is the viewpoint of least resistance as it were, the place you tend to stand when looking at a problem to solve in perl.

The benefit of learning other languages is that they provide you with different places to stand. This is not restricted to programming languages, a good grounding in math will provide you with a particular place to stand when looking at certain types of problems. The advantage of having a large number of different places to choose from is that you are more likely to find the place that provides you with a view that makes the optimal solution obvious.

Let us take, for example, another node discussion that has recently been operating, on efficiently determining the positions and lengths of all the character runs in a particular string. A number of solutions were proposed initially, all perl, with varying degrees of efficiency.

Having done a considerable amount of programming, I was aware of two particular things about the problem proposed:

The optimal algorithm was simple, there were no fancy statistical tricks that could be employed to gain speed.

Therefore, the efficiency of the algorithm was the prime concern, notably avoiding any kind of copying or expensive assignment that was not necessary

My initial entry therefore was written using the Inline C module. Using this, I knew that I could control very closely the allocation of memory and avoid any unnecessary waste. The results spoke for themselves, my first example outperformed the best perl solution by a factor of two.

This is not so interesting as one of my subsequent experiments, in which I attempted to create a pure perl implementation which was as close as possible in its operation to that of the C version. A few small changes had to be made, but the end result was extremely effective. While it could not avoid entirely the costs imposed by perl itself, it was one of the two fastest perl implementations.

Thus it was my ability to stand and look at the problem from a C point of view, which led me to produce a somewhat counter-intuitive program in perl which actually performed extremely well.

This applies to many many languages.

Learning a pure OO language will provide you with an excellent place to stand when looking at problems which fall nicely into OO designs.

Learning a functional language will screw with your mind before providing you with a number of extremely effective methods of solving complex analysis and parsing problems.

Learning a stack based language will provide you with an understanding of the costs of various kinds of operations, as well as how to do things without recursion.

Learning assembler will teach you about the benefits of cache locality, how registers are used and their implications, and the implications of instruction ordering.

Learning C will teach you about allocating memory all in one chunk instead of a bit at a time, the costs, needs and implications of the various styles of memory management, the advantages of processing data in-place, and why you miss perl so very very much.

At the end of it all, you will (most likely) come back to perl with a new appreciation for the services it provides, a drive to experiment with features you never understood before (that have been hijacked from some of these languages and provide a toolkit that can be used to do "x-ish" solutions in perl), and a better understanding of your programs place in the system in general.

You will be a better programmer for it. No question. The main question you need to ask yourself is, do you want to be a better programmer? :)

Well, it's rather hard to know if something else would be a better fit for a particular problem without knowing it first, I'd think. Also (to risk being a heretic) it's not impossible that you might find a language (or languages) that you like more in general. It happened to me. :-)

I wonder how come that no one didn't tell yet anything about SQL :)
Whatever wizardry module you would use when confronting yourself with a DBMS, my opinion is that you still need some exposure to SQL.

++ I subscribe to C - this language still is the mother of us all :)
Of course, in an environment where speed and memory footprint are not important, you will hardly need C knowledge... but a time will come when... ;-)

A language that doesn't affect the way you think about programming is not worth knowing.-- Alan J. Perlis

Languages follow varying paradigmata. Each one allows you to approach problem from a different conceptual perspective. The fewer paradigmata you know, the more conceptual blind spots you have - all the world looks like nails if you are a hammer.

Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal).

Although I'd rather suggest Smalltalk as the language to teach class abstraction paradigma:

I made up the term object-oriented, and I can tell you I didn't have C++ in mind.-- Alan Kay

Java and C++ make you think that the new ideas are like the old ones. Java
is the most distressing thing to hit computing since MS-DOS.-- Alan Kay

Programming languages are human languages, and like any other human language they define what you can and can't easily express in them. Learning a different language means you learn a different way of thinking about things, and that can provide valuable insights into the solutions for a problem.

I'd really recommend you (or anyone) learns to program in at least some of the following languages (listed in alphabetical order):

APL

Assembly (Anyone's assembly, doesn't matter)

C

COBOL

Forth

Fortran

Haskell

Lisp

Prolog

Smalltalk

SQL (As much as anyone can program in SQL)

Other languages are fine, but C++, Java, Python, Objective C, or any of a hundred other languages aren't as good for giving you a clean view into a new way of thinking about problems. (Though trading Scheme for Lisp might not be bad)

I'm not recommending that anyone actually use these languages in production code in preference to any other language, but I do think they each express strongly a set of unique language characteristics, and as such are good for getting a handle on a way of thinking.