It all depends of the type of problems one is trying to solve. Unfortunately Perl is not the optimal answer to each and every problem.
In this context I'd like to mention Lisp (or Scheme if you prefer) for dynamic coding (code == data). By way of example, try to do genetic programming in Perl vs. Lisp, although one can obviously do it in Perl, it's way easier in Lisp.
When dealing with rule based problems and inference, Prolog or Clips is the way to go. Of course you can write your own inference engine if you must.
Even internet programming can be more convenient in Rebol than it is in Perl since it is much easier to distribute the runtime system over various computers.
Writing a parser is easy in Perl with Parse::RecDescent, but unfortunately it's sometimes prohibitively slow, so that one must resort to Java or C++ with a tool like AntLR.
When dealing with math problems, it's a lot easier to use Maple or Mathematica to get the symbolic maths done, and Matlab for the numerics.
As I said, it all depends on what problem you have to solve. The more programming languages, the more freedom, the less effort one has to spend. There's more than one way to do it and There's more than one language to code in.
Just my 2 cents, -gjb-
| [reply] |
2. So perhaps I have just reached a stage of desirelessness because I bask in the rays of the Almighty Programming Language.
I'm not sure I agree with this sentiment regarding APL. It's heavy use of non-standard glyphs in the language make the end result look a lot like line noise, difficult if not impossible for the non-initiated to comprehend. Arrays are dynamically allocated willy-nilly with no user managment. Code is even dynamically interpreted in a way such that programs can nearly write themselves in an interactive fashion! Scary stuff.
Oh, wait. You meant Perl?
Matt ;)
| [reply] |
Everything undergoes trials and tests from time to time, of varying severity and intensity. This includes Perl, yourself, and your Perl programming abilities.
When tested one can either be strong enough to resist without breaking, or supple enough to bend with the force applied and avoid the challenge even though you did not directly resist. Sometimes one way is correct, sometimes the other; somebothes both, and sometimes either.
However as you can be strong and supple in defence, so can the attack be strong or supple -- as one challenge can be forcefull and direct, another can be stealthy, agile and subtle, attacking a weakness you were never aware of so never knew how to defend (see 90% of attempts at crypto by people who know nothing about crypto). Here strength does not help your survival, indeed rigidity at the expense of versatility and suppleness will hamper your ability to overcome the challenge. You need innovation, initiative and vision to come up with a solution where you lack sufficient context to rely solely on your formal knowledge.
I am happy that the foundations of a skyscraper are deepset, solid and strong, and I am also happy that the upper storeys of the skyscaper will flex and sway in the wind -- the overall strength of the building comes from both these acting to complement, not weaken, the other.
Though many coding challenges can be overcome by brute force and encyclopeadic knowledge, there are many more that require understanding of the subtleties of the language and the problem, and an ability to innovate and grow solutions almost organically from where no formal specification exists for a brute strength fix to work. Strength and savvy in concert can overcome any problem where one on it's own would have failed.
| [reply] |