Modern Perl is newer and in it's fourth edition. It's also available for free to read.

Cheers,

Brent

algorithms are just what you implement using Perl, and for sure Perl has many many tools to help you in writing your own algorithms.

Good algorithms or bad ones depends on the coder, generally not on the language. There are also some primitive programming language, let'say vbscript that are unfriendly, there are others that are specialized to do something so they are not good for other tasks, let's say SQL. Perl is very flexible and generalistic, it was designed and is still maintatined and renewed to 'make easy tasks easy and complex tasks possible'.

And it is true! Al-Khwarizmi, ops algorithms are just the flow you want paint using a programming language, it depends on your skill and your background. Perl can bring you through all these steps and after years and decades you can still feel the challenge.

The world is full of not so well informed collegues, dont worry and go on.

L*

I would ask what constitutes a "proper programming language."

I learned algorithms using 1970's BASIC and 1960's FORTRAN. Talk about limited languages. Neither had support for data structures other than arrays and scalars, control structures were limited to if-then, for loops and goto.* We could compute determinants of matrices and bubblesort with the best of 'em. It just took a bit to write.

Perl contains the features right out of the box to implement algorithms: control structures, data structures, recursion, objects. Most of these have been enhanced via CPAN. My own experience and imagination are limited; I wonder what sort of algorithms your colleague has in mind that cannot be implemented in Perl. Especially those relevant to a beginner.

*But we were grateful to have them!

Perl provides many built-ins that implement algorithms that one might otherwise be tempted to write themselves. But nowadays, so do C++, Python, Ruby, and others.

There is nothing about Perl that would prevent someone from writing just about any general purpose algorithm. It may not be the best choice for every problem domain, but there is no reason why it cannot be a good playground for implementing and learning about algorithms. Someone already mentioned the book, Mastering Algorithms with Perl. While the book is quite old, it is still an excellent source.

I have a co-worker who recently implemented a compiler in Perl, complete with a lexer, parser, stack, heap, and a virtual cpu and runtime. It's not going to win any speed contests, but nothing about Perl prevented it from being a successful project for its intended purpose.

However, when learning algorithms using any high level language, it's important to avoid the pitfall of Schlemiel the Painter. It is easy to learn the basics of a language like Perl or Python, yet miss the significance of what's going on under the hood. But again, just because the common use of a language such as Perl is to consume the high level tools of the language, those tools do not prevent you from learning algorithms. As an example, Perl has sort built in. But you could still write your own Merge Sort in Perl. There is seldom a need to write a Linked List in Perl, but Mastering Algorithms with Perl will walk you through it.

Perl isn't the sort of language you would use to write a device driver, or a kernel. But it's just fine for learning algorithms, in my opinion.

Of course there is only one proper language for "learning algorithms" and that is MIX. All others are just interpreters of it to make some parts easier.

Having said that you now must realize its making parts easier that distinguishs one language from another. When learning sometimes it is important to understand what the fundamentals really are rather than them being hidden from you by a language structure. I can build binary trees and linked lists via perls dynamic hash and array allocations. Doing it in assembler(C) with mallocs and hard pointers and getting it to work is another matter, then dealing with the memory fragmentation as they are released is a whole new can of worms. Sometimes it helps to see the underlying mess to truly appreciate what perl does for you under the covers.

Perl will work as well as just about any other general language for learning about algorithms at the macro level. It has features that you already recognized that can make some things easier. But to really learn the nuts and bolts nothing beats ASM, but dayum its a pain in ASM too. You dont have to understand how a mechanical watch works to wear a rolex, but to truly appreciate one you have to understand how difficult it is to create precision gears.

wat? Hardware::Simulator::MIX :D

But that is MIX, not perl. True you might be using perl to run your MIX code, but that isnt using perl to learn, perl and the module just become yet another interpreter of your MIX code

True, using a high level language such as Perl has the advantage that the language implements for you things that you would need to implement yourself if you were using a lower language such as, say, C or Assembly (or MIX). So, you don't really need to learn how these things are implemented, well, most of the time. But that doesn't mean that you can't learn them if you wish. And sometimes, you actually have to learn them.

One example: hashes are a very efficient data structure in Perl, so that you most of the time don't have to implement your own search algorithm. And so what? Who cares, if you can do your job without having to roll out your own implementation of an efficient search algorithm? Having said that, I should point out that sometimes you need to implement your own version of a given basic algorithm. I came across such a case a few months ago on a forum, where the poster (a very good Perl programmer) had to deal with ranges for a genetic problem. Using hashes for that turned out to be impossible. And given the size of the input, the program was taking several days to run. I suggested a binary search algorithm which turned out to return the results within about one hour.

I certainly think that developers need to know basic algorithms. But that does not mean that you need to implement them each time they are needed. If your language or a library implements it for you, use it!

In my book, I explain the binary search algorithm and request the reader to implement it as an exercise. Because it is important to understand it. Even if the language offers ways to implement more effective search solutions in 99% of the case.

Just another example. Perl has a built-in sort function. So you may use the Perl sort function and never care about how it works. Then you'll never learn about sort algorithms. But Perl does not prevent you from learning them. My book shows pure Perl implementations of three different sort algorithms. The fact that the language can do it for you does not prevent you from learning these algorithms if you wish.

Finally, I agree that Mastering Algorithms with Perl is a great book. Get it, by all means. Another interesting one is Computer Science & Perl Programming.

Update: fixed a typo.

But there are two sides of this medal.

Some complain it's hard to read and/or to learn. They deny it to be "a proper language" because they have only one model in mind.

Others praise that they learned to master a rich tool set.

To answer your question: it's an excellent language to learn algorithms, because there are more than one way to implement them.

It's mainly an image problem!

For instance I remember reading about a conference on functional programing where some speakers were surprised to learn that Perl has closures and lexical variables.

"Perl has closures and lexical variables."

Yes but they are harder to read and learn than all other languages.

I totally disagree with that. It's in fact easy to read and to learn.

Are algorithms so important? A wise one once said: when the data is well organized the algorithm become a consequence.

What efficient means? Spend a week to polish an algorithm for someting executed twice a week is waste your time. Your human time is generally more important than CPU cycles.

Oh obviously there are case where algorithms are important: come here at the monastery, propose your problem and your solution; many neat brains will offer better solutions, cooler algorithms.

One example? search here at the monastery for primality test on numbers; you'll find many many different solutions and approachs. Then you can look at some good math module on cpan, and search how primality check is solved by these modules which have to be fast and reliable.

Now about the time to spend to learn other languages; learn is always a good thing and if you have time and will learn other language too. I've no so much time, or well i prefere doing something else but i can assure you that I know just Perl, i'm somehow intermediate (despite my monk level) with a long experience and every problem i needed to solve within computers i solved with Perl, also for curiousities and itchings i used Perl and i'm still happy with it.

Last suggestion; create an account on perlmonks, look and ask.

L*

Many replies already, but I would like to offer my own view... The OP is vague about the target depth in learning algorithms. If you're just starting out and have yet to develop algorithmic thinking abilities, Perl is a fantastic choice. As other monks have pointed out, a lot of the unnecessary distraction is hidden away and not relevant to programming in Perl (like memory management and types of variables). The fundamental data structures are part of the language, so you can immediately become used to the operations they support and how these fundamentals are applied in higher-level algorithms.

By "just" writing Perl programs, you'll get an intuitive understanding of lists, arrays, stacks, queues, hash tables, multidimensional data structures and operations on them without having to first study each one separately and in detail. Once you have that understanding, it's easier and faster to learn about the formal aspects of designing these data structures and algorithms on them.

If you're looking for the deepest algorithm expertise, Perl is still an interesting starting point, but it must be one among many other programming languages you know. For example, every time I read about or program in some other programming language, whether it's Pascal, Common Lisp, Haskell, C, C++, Go, Rust, Javascript, Python, R, XSLT, MMIX assembler or even GNU makefiles, I always learn something new that I can take and apply to programs I write in Perl.

There are some things that are hard to learn if you only know Perl. Memory management is one of them, as are references and the related ability to grasp indirection. You can simulate computer memory by allocating a large array and treating array indices as pointers to memory. But why would you do that in Perl? It serves no practical purpose. On the other hand, it's really hard to design efficient algorithms in Perl without understanding how it manages memory and what its benefits and drawbacks are, and it's hard to get an intuitive understanding of Perl's memory model without managing memory by hand.

So, you learn a lower level language without automatic memory management, like C. Even if you never become a full-time C programmer, that experience will influence how you design algorithms and how you write Perl programs. This influence goes both ways, because what you really learn after mastering the basics is different ways of thinking about computations. That knowledge and algorithmic thinking is transferable, and it doesn't matter in the end what programming language you use.