There's Only One Way To Do It

[jdporter]

I was pondering the question "Why do some people think they enjoy programming in Java?" Software engineers who use Java will tell you that they revel in the expressive power of that language, which enables their craft and creativity to flourish.

But wait! Java isn't like that, because Perl is like that... and they can't both be. Right? I think they can, because it happens at a different level.

In Perl, we feel liberated by the fact that (for example) Perl already has an auto-sizing array type built in; we don't have to invent that wheel yet again. Perl has approximately 3.2 jillion distinct features built in. Perl programmers can "focus on the application itself", on its high-level structures and algorithms, and not worry about, for example, how to iterate over a list of heterogeneous objects.

But in Java (and most other languages) the programmer needs to think not only about those higher-level issues, but also about the lower-level structures and algorithms, and to implement them — or at least to choose the desired ones from libraries of such things. This is why it takes 5 days and 1000 lines of code to write a "hello, world" CGI in Java. Or whatever.

So, in many critical respects, Perl is the language of Only One Way. There is only one way to implement a sequence: an array. There is only one way to implement an associative array: a hash. There is only one way to search for patterns in a string (setting aside the trivial index function). And so on. Of course, if you really wanted to, you could do any of these things another way. You could choose to ignore the power of the constructs perl gives you for free. You may decide that a singly-linked list is appropriate for your application, or maybe a b-tree. People do this with some regularity.

For example, there is only one way to do classes in Perl. That is, there is one intrinsic way, which uses namespaces, @ISA, the special semantics of the -> operator, and so on. But some folks have felt this style too limiting, or not limiting enough, or too arcane, or just simply not OO enough. Thus we now have Moose, and the plethora of modules in the Class:: namespace, as well as basic techniques such as "inside-out objects", message-based object protocols, etc. etc. Java, of course, gives you no choice at all about how to do OO.

So, while Perl goes to great lengths to permit more than one approach to any problem, there are certain questions for which Perl hands you a "no-brainer" answer on a silver platter. In these cases, we're pretty close to Only One Way.

Previous node on similar topic: TOOWTDI (There's Only One Way To Do It)

[exussum0]

Ok, I'm on the fence as a developer. I do both perl and java. Depends on who I’m doing it for or what it is, but I do know when to use the tools I have, even when in the language.

The problem with any language that has a tool-set, is that people will want to use the tools, sometimes too much. I'm not talking about things like DBI or what have you. I give you an example. I was once writing a throwaway script to fix up a data file in perl, and someone started telling me why I should use chomp vs chop (which I used), and the differences and what not. This was for a 20 line text file that was handed to me and needed to be fed into another process. All I wanted to do was take the 2 comma separated values and switch them around, per line. I know the file was uniform and it worked. Now this is a minor example, all about chop vs chomp. Was this a more production level thing or code that was to stay out in the wild, I would have made it do actual format checking and other things. Maybe even use a CSV module instead. But it's a tiny argument over that shows a case of over-engineering a solution. It's what a lot of people suffer from, independent of the tools around.

The amount they over engineer is a function of what is sitting in front of them. A default install of perl has a good few handfuls of modules. If it's a one off thing with comma delimited files, I certainly would not go through the effort of installing a CSV parser unless I would use it over and over or it's production level. It's an easier module to install, I admit, but it takes time -- and I will less likely "install something" on a case-by-case basis. Sue me. :)

Java on the other hand, comes with well over a few hundred different classes. On top of that, there are also a lot of tools (not functions per se) in the language, so you have OOP, private members, static methods, and what not, easily, readily available as well. Sometimes, you don't need OOP. Sometimes you don't need the security. Sometimes, you don't need to over engineer. We don't always need the abstraction.

Java can be done to mimic other languages, but most people see the tools in front of them, and use them as such. They over-engineer. In the perl community, we have the opposite problem. Things like CSV parsers, or WWW::Mechanize aren't so obvious and available with all distributions on a default install, that people don't use them enough. You get beginners, neophytes and even those starting to become wise, under engineering. Things like File::Find can be done, to someone's needs, in a few lines of perl. But if it's not there in a tidy little document explaining the world to them, how would they have known when they aren't used to it? My theory is, people who become wise in programming, learn what tools are available and when to use them. So they learn to less over-engineer in java, and engineer more in perl, doing the right things vs "less desirable way."

Back to your point of the "only way". Yes. Sometimes it's retarded to re-invent the wheel. WHY would I write my own DBI is beyond words for me, as it's a solid architecture that few have even mimicked. Why should I implement hashes and an OOP architecture vs letting perl do it for me in it's native form? I can't think of an easy reason at all beyond experimenting with code. There are one true ways, but it won’t stop people from not knowing any better. There's no one-stop-shop for looking up, how do I pull down a web page, or do massive calculations. There is the cpan search engine, but it's not as convenient as having the entire shebang packaged up with perl with a neat little index.html explaining everything. One way? Totally agreed. Will anyone truly understand it within their first few days or even years of using perl? Unfortunately no. It’s not an excuse or a call to arms. It’s just a fact. :\


-- "So far my experience has been that most people who go for certification have broad but not deep knowledge in the field and the flavor of the knowledge is academic. But every once in a while one finds a gem of a person who learns all the time and uses certification to prove it." -- on Orkut

[hardburn]

Java on the other hand, comes with well over a few hundred different classes.

A lot of which are redundant and tend to deprecate one method in favor of a method in another class instead of fixing what was wrong in the orginal (java.io.DataInputStream.readLine comes to mind). All of java.io.* could be reduced to a lot fewer classes if things weren't so overengineered.

[exussum0]

In defense of deprecation, running java using a deprecated function will warn you. As for the java io stuff, it is rather unweildy. Unwieldy? It's a view of how things should be. Some people agree with it, some people don't. It's a problem with complex systems. People are more likely to agree on the simple end of life, not the more complex ones :\


-- "So far my experience has been that most people who go for certification have broad but not deep knowledge in the field and the flavor of the knowledge is academic. But every once in a while one finds a gem of a person who learns all the time and uses certification to prove it." -- on Orkut

[herveus]

Howdy!

I think jdporter's thesis is that, for a select set of language features, there is only one useful way to do it.

Perl is a strongly typed language. You have three data types -- scalar, array, hash. You can't coerce a scalar into an array or a hash -- they are fundamental data types.

integer, float, decimal -- who needs the multiple names. They are all scalar values.

Note that I don't equate "strongly typed" with "bondage and discipline". Java does the B&D thing with data types, leading to the ever-popular downcast. They may claim to be Strongly Typed, but you can't do anything useful without having to subvert the type system to get data moved around.

[hardburn]

You have three data types -- scalar, array, hash.

There are a few other types, such as subroutines and filehandles, plus the umbrella glob type. Also, I would argue that array and hash should be considered subtypes of the type 'list', since you can coerce a hash into an array (which may or may not give a useful result). You could also consider blessed references to have their own type (that type being the package they were blessed into), but if you do, you have to remember that it's totally seperate from the rest of Perl's type system. It's also easy to subvert via re-blessing.

Java does the B&D thing with data types, leading to the ever-popular downcast. They may claim to be Strongly Typed, but you can't do anything useful without having to subvert the type system to get data moved around.

Java actually has a rather weak type system, preciely because of the subversion you mention (C and C++ exibit the same problem). A big mistake a lot of people have made is equating static typing = strong, and dynamic typing = weak. Perl is dynamically typed, but also very strong. C/C++/Java are statically typed, but are relatively weak.

Languages with a type system like C are usually only good for giving the compiler some optimization hints. Some would argue that it's more self-documenting, but given how easy it is to subvert, I think this could easily lead to more confusion than its worth.

[tachyon]

All I wanted to do was take the 2 comma separated values and switch them around, per line

And you needed chop() or chomp() or more than one line of code to do it? Get with the program dude - you need discover inplace editing :-) The supplementary backup file is nice when your brilliant solution turns out to have just destroyed 10,000 zone records, not that I would know :o)

perl -pi.bak -e "s/([^,]+),([^,\n]+)/$2,$1/" data

[dragonchild]

I think that the difference between intrinsic and required is the key. Perl has a definite way to do most things, but you aren't forced to do it that way, if that doesn't suit you. Perl6 will be even laxer in this regard. However, most people will do it the easy way, cause it's easy.

I think it's the real difference between Pascal and LISP. Pascal has very definite ways to do things. LISP doesn't. Now, there are a number of libraries that provide you with a way to do whatever in LISP, but you can modify them, mix them, or ignore them. You can't do that in Pascal, because Pascal doesn't let you.

Regardless of whether you think that the Pascal, Java, C++, LISP, or whatever way is better, the point is that Perl, LISP, and other loose languages allow you to choose if the predetermined way is the way you want. Pascal, Java, C++ - they don't. And, that's why I program in Perl.

[exussum0]

I'll speak on behlaf of java and C++. Don't have a choice in ways you can do things? In java, you have interfaces to implement if you want to look at in that level. So you have LinkList, ArrayList, DoubleLinkList (haven't confirmed that one) etc...

You also jave things like JAXP, JAXM and what not, plugable interfaces for doing XML. Don't want to use the plugged version, there are others that work as well, i.e. xmlpull(.org).

C++? You have the stl or your own home brewed ways. You have QT as well.


-- "So far my experience has been that most people who go for certification have broad but not deep knowledge in the field and the flavor of the knowledge is academic. But every once in a while one finds a gem of a person who learns all the time and uses certification to prove it." -- on Orkut

[EdwardG]

"...Perl matches the way I think pretty well, because what I mostly want in a computer language is a wide dynamic range. I want a language in which you can say both dirty, low-level stuff and fancy, high-level stuff. I want a language where both baby-talk and fluency are acceptable. Other computer languages tend to try to level those distinctions."


-- Larry Wall

As reported on Slashdot

[michaeld]

I fully agree with this. I describes what I think is one of the main advantages of Perl: "you can... but you don't have to....".

On the other hand, I was thinking: could it be that it's because of the fact they don't have all these possibilities in Java that some people prefer it?

I mean: the fact that they don't necessarily have to choose between 'baby-talk' and 'fluency' might convince people to use Java instead of Perl for instance. After all, it's one choice less to make...you just start coding

I quite like Perl, but I have to admit that all these possiblities (TIMTOWTDI) tend to make it harder for a beginner.

Any thoughts on this?

[EdwardG]

Like most complex choices, I think it probably comes down to personality and your preference for a certain style.

Going out on a limb, let me speculate that One Way To Do It probably suits army types more than English Lit majors, and TIMTOWTDI probably better suits the latter.

For me, it's been cool to be able to pick up the baby talk in no time flat, and then to be able to enjoy the ongoing experience of the swiss army bits and pieces.

I like not having a defined end point to my education.

[gmpassos]

You are just saying that you think that Perl is better than Java.

Well, as a Java consultant, Perl is much better than Java when talking in production. Also Perl is better in performance too, since Java speed is just crap, yes it is, why to try to conform with the turtle of Java when we know that all the other languages are faster. Let's stop to dream, and let's see the reality.

The only problem with Perl is that it doesn't have the loby that Java has. Soo, the stupid guys will think that Java is better than Perl because it has certification, etc... Soo, they pay me to coordinate the Java production of project. But with all the respect, Perl is better than Java, since I have real comparations with the 2 teams that I have here, and the Perl team is 3 times faster, with much more resources in their softwares, and with less erros. But I only still use Java, since I can't tell them to not use Java, since the client want a system in Java, and because they pay me very well.

I just think how stupid is to do a Java algorithm. Our programmers spend much more time looking in the Java docs, and finding examples at java.sun.com, than really doing the program. Soo, why any resource in Java doesn't have an intuitive way to use. A good example is to work with hashes, specially from the point of view of a Perl programmer, that use a hash just when it want, and the Java programemr does everything to avoid a hash to not use another different object interface in their algorithm.

Other funny thing in Java is the convertion of it's basic types. Soo, they have, char, byte, short, int, long, float, double and string. Soo, how I convert, let's say, string to double, and double to string. Now how I convert int to double? It just doesn't have a common way to do that! In Perl, well, we just never have this problem, since we have something very intelligent, SCALAR! just to show you how stupid is that, here are the ways to convert this types, from a convertion class that we have created:

 public static double Str2Double(String i) {
    if ( i.indexOf(".") >= 0 ) { int p = i.indexOf(".") ; i = i.substr
+ing(0,p) ;}
    
    double o ;
    try { o = Double.parseDouble(i) ;}
    catch (Exception e) { o = 0 ;}
    return o ;
  }

  public static String Double2Str(double i) {
    String o ;
    try { o = Double.toString(i) ;}
    catch (Exception e) { o = "" ;}
    
    if ( o.indexOf(".0") == (o.length()-2) ) { o = o.substring(0, (o.l
+ength()-2) ) ;}
    return o ;
  }

  public static double Int2Double(int i) {
    double o ;
    try { o = (double)i ;}
    catch (Exception e) { o = 0 ;}
    return o ;
  }

Soo, here we have a big static class, with all the convertion methods, what make our life easier. Also we have implemented the Scalar type in Java, what is even better. But why we don't have this resources that make life easier by default in Java? Why we need to develope them? Is simple, because they want that!

Other way to have a Perl programmer laughing is to compare the IO system of Java. For example, how we read a file in Java? Example:

  import java.io.RandomAccessFile ;

  ...

  java.io.File file = new java.io.File( "/tmp/file" ) ;
  RandomAccessFile stream = new RandomAccessFile(file , "rw") ;

  int len = 1024 ;
  String buffer ;
  
  try {
    byte[] b = new byte[len] ;
    int n = stream.read(b , 0 , len) ;
    if (n > 0) {
      buffer = new String(b,0,n) ;
    }
  }

With Perl is just open() and read():

  open(my $io,"/tmp/file") ;
  read($io, my $buffer , 1024) ;

The point is not the number of lines, is the number of resources that we need to learn and use to do this in Java. In Perl we need just to know the behavior of open() and read(). In Java, well, Is soo much thing that I just don't want to start to explain!

Other think that I don't understand is the Java "compilation". Everybody says that Java is "compiled". What a crap, the .class files are just bytecode. But we PerlMonks know that Perl also have it's own bytecode, very well parsed and optimized. Soo, why is sooooooo sloooowwww, to "compile" the .class files, and than why is sooooo slooowww to load and run a .class file?!!! All us know that the .class file is just operations for the Java VM, like a assembler code, that has nothing to do with the OO structure of a Java class. Actually we can have structured code for the Java VM machine, soo why is soo slow to run?

Well, the Java folks can try to defend Java, but what I say is just the reality show man! Java sux, but they pay. ;-P

[hardburn]

here are the ways to convert this types, from a convertion class that we have created:

What's wrong with java.lang.Double.parseDouble()?

[gmpassos]

The point is not "java.lang.Double.parseDouble()", is all the different ways to do that and USE that:

  Double.parseDouble(i) ;

  Double.toString(i) ;

  (double)i ;

Soo, for each basic type in Java we nee to use a class or object of a super type to can convert one type to other. And depending of the level of the origin type to the destiny type we can't use a static method of a class, we need to use type casting.

Note that for each one we nee to catch exceptions. Is just not a simple thing2thing() call! And type convertion shouldn't be an issue, since this a language thing, not a algorithm stuf.

[Anonymous Monk]

How would you write a cross-platform multi-threaded GUI application in Perl??

[jdporter]

As for "cross-platform", it depends on what you mean by that. Currently Perl is supported on hundreds more platforms than Java. "Write once, run anywhere" is still a myth for Java, but practical reality for Perl.

As for multi-threaded GUI application in Perl, there are (of course) many ways to do it. One good way that comes to mind is to use POE, which integrates very nicely with Tk. Cookbook example.

I think you'll have to be a lot more creative if you're trying to come up with examples of applications that Can't Be Done In Perl.

[gmpassos]

How about wxPerl?

It's more portable that the Java+Swing that you say that is soo cross-platform. Note that wxWindows will work in much more platform than swing, and Perl, well, I just don't need to say anything.

And I can't forgot to say that wxWindows is much more porwerfull and fast than swing, since wxWindows is based in the main GUI of each OS, soo, your app will looks like Windows on Windows and like Mac OS X on Mac OS X.

[Anonymous Monk]

I certainly won't use Java. Any GUI beyond a bouncing 2D ball in java is just to slow and klunky to use!

[tilly]

A year or two ago I ran across an interesting study on exactly this that was done several years ago. I can't find the study right now (I'd appreciate it if anyone who knows the one I'm talking about could post it), but the idea was that they took a reasonably complex but well defined problem and had it implemented by a variety of programmers in a variety of languages (C and Perl were in the list). They then compared how long the solutions took to implement, and how rapidly they ran.

As you might expect, the most rapidly implemented solutions were the ones done in the scripting languages. The fastest solutions were in C.

As you might not expect, the slowest solutions were in C. Furthermore the variation both in time to implement and runtime performance were far larger in C than in scripting languages.

What seemed to happen is that the scripting languages provided an obvious good approach to the problem, and everyone took that with decent results. In C there were many choices to make, with more difficult to see consequences for time to implement and runtime performance. (Which is exactly what you are talking about having happen.)

I'd wager that Java would have resembled C in this particular test, but without the performance.

[jdporter]

Sure, I participated in that study (by contributing a sample in Perl). The research was the work of a man named Lutz Prechelt. He published a paper entitled "An Empirical Comparison of Seven Programming Languages". CiteSeer has an entry for this paper, and has cached PDF and PostScript versions of it.

[tilly]

Thank you for the reference. Having re-read the results, my summary was inaccurate in a number of particulars (one reason that I try to double-check information before I post). However my memory was in some sense "morally correct".

I'd suggest that anyone who finds the topic interesting should skim the original paper and discover for yourself how I was wrong, and in what sense I was right.

[BUU]

I'm confused. First you say: "So, in many critical respects, Perl is the language of Only One Way." Then you say: "Of course, if you really wanted to, you could do any of these things another way. You could choose to ignore the power of the constructs perl gives you for free.".

So there isn't really "one way", just a very common way. Every example you mention has multiple ways to do it, there just happens to be one way thats very, very good and very easy. I consider this a feature. I get the flexibility to implement whatever solution I want, with the power of built in, well tested easy to use features that everyone should be familiar with.

[jdporter]

I think the last paragraph of the root node, above, sums it up pretty well.

[biosysadmin]

While Perl provides an obvious answer for many problems (such as implementing sequences as arrays as you mention), I think that you're right in saying that usage of these idiomatic expressions is highly dependent on their knowledge of the Perl language.

If there's one thing that I learned from teaching a college class in Perl, it's that some people learning Perl can come up with some amazingly creative (and often horridly inefficient) solutions to problems that have already been solved in some animal-themed book. For example, I had one kid who just loved storing sequences of single characters in an array. Something about it just sat right with him. Sometimes it's gotten to the point where I can recognize cheating on a project based on the bizarre idioms that are suddenly transferred from one person to another.

[jdporter]

I hear ya. I once worked on a project where I inherited some perl code from someone whose knowledge of arrays was limited to the following:
• Iteration: for $line ( @lines )
• Read from file: @lines = <FILE>;
• Write to file: print FILE @lines;
His code was rife with hacks like

  # add the new item to the list:
  open TMP, "> $tmp";
  print TMP @items;
  print TMP $new_item;
  close TMP;
  open TMP, "< $tmp";
  @items = <TMP>;
  close TMP;

It baffles and amazes me that someone could know how to read and write arrays to file, but not have learned about the push operator! Also disgusting was the fact that this person didn't know enough to put that snippet in a subroutine. He C&P'd it (and every other hack he ever devised) rampantly throughout his code.

[flyingmoose]

But in Java (and most other languages) the programmer needs to think no only about those higher-level issues, but also about the lower-level structures and algorithms

I don't agree this is a good thing. For a higher level language (one that uses a VM anyway), this is a sign of the failings of that said language. As for thinking about lower-level structures and algorithms, if that is your glory, you will have much more fun in C.

IMHO, Java is halfway between a lower-level language (without the functionality) and a higher-level language (without the expressive constructs).

Apologies to Van Halen, but it's the "Worst of Both Worlds". A good language allows both (the "Best of Both Worlds"), in both the gory detail of low-level programming, and the expressiveness of things such as (cleanly implemented) lambda functions -- and the programmer would be able to switch between them at his/her chosing, not based on internal requirement or language deficiency.

[jdporter]

I don't agree this is a good thing.

I didn't mean to say that it is a good thing, only that it may explain why some folks feel that Java (or some other language) gives them a very wide field in which to express their creativity. Of course, I could be totally off base. As gmpassos said, the mere fact of having to think about those mundane issues may be more of a drag. I would certainly find it so.

[JSchmitz]

I was pondering the question "Why do some people think they enjoy programming in Java?" Software engineers who use Java will tell you that they revel in the expressive power of the that language, which enables their craft and creativity to flourish.

Software engineers who use Java will tell you a lot of different things because there are a lot of different software engineers and lot of different projects.

If -- as this statement implies -- there is a narrow concensus about why people think they enjoy programming in Perl, it suggests that Perl is used in a narrow application space. The real question, then, is how Java compares to Perl for the tasks to which Perl is most popular. You'd expect Java to compare unfavorably, as does Perl when compared to Java in areas where Java dominates.

And while I'm on this paragraph, I'd like to know the difference between thinking you enjoy something and actually enjoying something, please.

In Perl, we feel liberated by the fact that (for example) Perl already has an auto-sizing array type built in; we don't have to invent that wheel yet again.

Java has had an autosizing array type in the core API since the initial release. This statement has been ignorant nearly for nearly 10 years.

Perl has approximately 3.2 jillion distinct features built in. Perl programmers can "focus on the application itself", on its high-level structures and algorithms, and not worry about, for example, how to iterate over a list of heterogeneous objects.

First of all, high-level structures and algorithms can be deeply concerned over how they iterate over a list of heterogenous objects. What is the iteration order? Can we modify the list while we iterate? If these questions are not relevant, the process of iterating over a list in Java requires no further deliberation. You get the Iterator from the List and, well, iterate.

But in Java (and most other languages) the programmer needs to think no only about those higher-level issues, but also about the lower-level structures and algorithms, and to implement them -- or at least to choose the desired ones from libraries of such things.

This is a misleading generalization. Choosing the library or core API set with which to implement a function is part of the implementation process of project in any programming language, including Perl. Choosing a library does not constitute worrying "about the lower-level structures and algorithms," it frees you from thinking about it further.

This is why it takes 5 days and 1000 lines of code to write a "hello, world" CGI in Java. Or whatever.

Even if this infantile hyperbole were accurate, this statement is an example of the author's cluelessness about software engineering. "Hello World!" is not a programming benchmark, it's an instructive example. Writing "Hello World!" in a language walks a novice through some of the basic steps needed to write more useful programs in that language.

Java imposes a certain amount of bureaucracy in it code, and its annoying when you don't need it, and great when you do. Writing "Hello World!" in Java introduces you to a lot of core concepts needed to write more complex java programs. It also takes a lot more source code than "Hello World!" deserves.
Writing "Hello World!" in Perl is trivial; it's not much more work than typing "Hello World!" in fact. But how much do you learn about Perl doing it? Can you use namespaces, associative arrays, "inside-out objects" or Regular Expressions? Does the student need to know any significant number of Perl's "3.2 jillion features" at all? No.
But after suffering through writing "Hello World!" in Java, a student is prepared to do quite a few more substantial things.
As far as whether Java or Perl is a more "productive" language, I can safely say that vendors of Perl-based "Hello World!" implementations are unlikely to face competition from Java versions. Application servers, however, are a different story.

So, in many critical respects, Perl is the language of Only One Way. There is only one way to implement a sequence: an array. There is only one way to implement an associative array: a hash. ... Of course, if you really wanted to, you could do any of these things another way.

This statement is also true, without substantial modification, of Java.

For example, there is only one way to do classes in Perl. That is, there is one intrinsic way, which uses namespaces, @ISA, the special semantics of the operator, and so on. But some folks have felt this style too limiting, or not limiting enough, or too arcane, or just simply not OO enough. Thus we have the plethora of modules in the Class:: namespace, as well as basic techniques such as "inside-out objects", message-based object protocols, etc. Java, of course, gives you no choice at all about how to do OO.

This is so far from being a true statement that it seems inaccurate to call it "false." Object Orientation is not a syntax, or a language, it is a methodology. This methodology has various flavors, and these can be followed with varying degrees of pain in any language. "Java ... gives you no choice at all about how to do OO," is a testament to the author's ignorance of OO, not Java's inflexibility in that area. Java syntax supports following a certain approach to OO, but it doesn't stop you from following another.
Same as Perl.

So, while Perl goes to great lengths to permit more than one approach to any problem, there are certain questions for which Perl hands you a "no-brainer" answer on a silver platter. In these cases, we're pretty close to Only One Way.

Again, this statement could be made -- verbatim -- about Java. The author has attempted to draw some kind of distinction between Java and Perl, and instead, drawn a distinction between himself and a programmer knowledgable about Java and OOD/OOP. -Charles Forsythe

jdporter - edited: formatted quotes to distinguish them from the new text.

[kutsu]

This is not only true of perl and Java. In my C++ class I learned many, easily 20+ lines of code, difficult ways to create unlimited arrays. Once I looked at the standard headers included with C++, this was 4 years ago, I noticed vector.

#include <vector>
#include <iostream>

std::vector<char> array;
char c = 0;

while(c != 'X' || c != 'x')
{
  //enter something or exit to quit
  std::cin>>c;
  array.push_back(c); //remind you of anything ;)
}
std::cout<<array.size()<<std::endl;
/* btw., the way I learned to get an arrays length was to create a sec
+ond int array as a counter*/

As for why the One Way, or more approapriately Best Way is ignored, that's a good question

[wolfi]

i'm fairly new to 'real' programming, but from what i gather and as blasphemic as it sounds, other languages might be better suited for some things, than perl. The reason is no fault of perl's, but in that it was originally designed to handle certain purposes (like data-management) and has grown into a wealth of other avenues. Whereas other languages were designed with some other primary focus in mind. (You're more likely to find chats and games written in java or C, rather than perl.)

i don't see these as weaknesses. I think of it as using the best tool for the job. Perl might not be the best for every job - but it is for so many. (And it's still evolving.)

but when it comes to Only One Way... I find perl to be very versatile and often wonder, if i'm not getting spoiled here; That when i move onto other languages, i'll be saying things like "but perl doesn't have any upper limits!" ;-)

You can use modules or write your own. You can use object-oriented syntax or standard. Write them as IFs..Else statements - write them as regexes. Use strict and warnings and taint... or write some quick and crude (and insecure) one. The list is endless, i'm sure.

there are rules, naturally. But the language seems very flexible and very intuitive to me. It allows you to write code, as you would understand it - and not in some one-way abstraction that only made sense to the guy inventing the language.

in short, cool discussion - but i don't agree :-)

[muba]

This is interesting, in a way.
But now what are you trying to say?

[adrianh]

Java, of course, gives you no choice at all about how to do OO.

I'd put forward things like AspectJ, AspectWerkz, JAC, JBoss AOP, Nanning, etc. as counter-examples to that statement ;-)