Re: The Limitations of the CPAN

Ovid,

You really seem to be thinking a lot like I do, but a lot more eloquently. Seeing too much wrong-headed OOP, Ruby goodness, etc. Perl takes an immense amount of skill to wield carefully, and yes -- Java -- while I really hate it's shackles, is designed to keep folks without that constant consideration of every code change, somewhat on the right track.

I guess the thing is that Perl rapidly leads to very small, tight code that is sometimes not easily extensible (i.e. brittle and weakly connected), while Java quickly leads to code that is not easily extensible (i.e. too rigid and often glued together incestously).

Ruby is a good mix, and right now, I am coding my new apps in it, but I do have hopes for Perl 6, based on what I've seen in the community. However the Ruby mailing list has some folks that think very well about OOP and other things, they know what Java does wrong, and they use it to their advantage. It just depends how much Shock and Awe perl 6 brings and when it is first released.

Folks with perl maintaince problems should immediately check out Ruby, it solves a lot, and like Ovid said most of the things I get out of CPAN are things like database modules and such, which are already available in Ruby's core. Gems covers a few loose ends of things that should be in the core. Yes, i don't know where to find an Excel module or stuff, but server-side most of the time this isn't what you are looking for with the type of programming I usually end up doing.

Bottom line -- Perl's strength is in the modules and the flexibility of the language, but it does not always offer the flexibility to make things Rigid. Ruby offers the freedom to make something as Rigid or Flexible as needed, but does need maturing in the module category, but it has enough now.

Comment on Re: The Limitations of the CPAN

Replies are listed 'Best First'.
Re^2: The Limitations of the CPAN by dragonchild (Archbishop) on Nov 17, 2004 at 19:23 UTC
Java -- while I really hate it's shackles, is designed to keep folks without that constant consideration of every code change, somewhat on the right track. If you're not carefully considering every code change, then do you just blindly charge ahead, slingling code, and hoping you aren't on call when it breaks? Being right, does not endow the right to be rude; politeness costs nothing. Being unknowing, is not the same as being stupid. Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence. Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.	[reply]
Re^3: The Limitations of the CPAN by Anonymous Monk on Nov 17, 2004 at 19:42 UTC
"If you're not carefully considering every code change, then do you just blindly charge ahead, slingling code, and hoping you aren't on call when it breaks?" Straw-man. There are degrees. A simple code change in Java may be impossible to architecturally designed rigidity, while a simple change in Perl may devistate an entire architecture. Such changes are not immediately apparent. What is important is to both have power, convience, and the ability to enforce light discipline and future maintainability all in one. Perl is not a language that makes this automatic. You are much more likely to see Perl code devolve, as it takes incredible discipline to wield. Yes, I know people want to always have that discipline, I do too, but there are times when even we make mistakes.	[reply]


Think about Loose Coupling
	PerlMonks