John said:
My oh my, weren't you the one who wasn't aware of POD? If you think that
"the industry" selects a language because it's well fitted for the tasks
at hand you are more then naive.
John, I don't want this to sound ugly. I had decided to ignore your
remark. I formed the conclusion that you had no idea what you were
talking about. Please let me explain myself, and then maybe you will
understand what I am talking about.
Many times, software and software products have what is called an
application programming interface, or API. The API constitutes the
public interface of the language or application. 'Interface' consists
of the properties and methods of the product, that is, the public and
private members of the product, the public and private methods of the
interface, the different kinds of constructors, detailed information
including since, deprecated, version, return values, parameters, and so
on. This is what is known as external documentation. For the Java API,
see
http://java.sun.com/reference/api/.
There is also what is called internal documentation. Internal
documentation consists of the programmer written comments embedded with
within the source code, or contained in separate text or README files
included with the application. Both external and internal documentation
are important, because they serve different purposes. The overall
purpose is the same, to document the code, but an API is more specific
and standardized than POD.
The javadoc utility produces a Java API of your code. You can write an
application, run javadoc, and WITHOUT ANY FURTHER EFFORT ON THE
PROGRAMMER'S PART have a full API of your application. POD is an HTML
type of utility which, by contrast with javadoc, requires the
programmer to document his code. As an example, with a Perl module, the
programmer typically would have his lexical variables at the top of the
script, the dispatch logic next, and his user defined subs at the
bottom. The programmer, in order to use POD, would have to separately
document each variable and each sub. By contrast, in a Java pacakge,
the utility produces documentation which describes each variable, its
access and type, each method, its type and return value, the
constructors of the instantiable classes, and so on.
I am very well aware of the Perl criticisms of a compiled, strongly
typed language like Java, or C, or C++, and you don't have to lecture
me about these differences. My point is that Java and Perl are
different languages, with different advantages and weaknesses. In some
ways, Perl is superior to Java, and in other ways, Java is superior to
Perl. One of the advantages to Java is the utility to automatically
generate an API with no effort on the programmer's part. Yes, I know
that the programmer is required to declare the type of the variable or
reference, and the type and return values of each method, can only
return one value from a method, and so on. I'm not going to takes sides
in this debate. I think the effort is similar, Java requires it up
front while Perl leaves the programmer free to neglect it if he
chooses.
"The industry" selects, usually, the best tools at hand for any
particular job. "The industry" is not a monolithic structure, but the
sum of all the parts. I am part of the industry, you are part of the
industry, we all are part, just like we are all part of "the economy."
Just as you can look at all the individual transactions and talk about
"the economy" or "the market" you can look at all the software
architects, engineers, and programmers, and make statements about "the
industry."
I live in an area where there are a lot of technology jobs in banking
and insurance. Many of these use COBOL. The schools, colleges, and
universities in my area still churn out COBOL programmers. I know COBOL
programmers, and even though I don't know COBOL, I understand why 'the
industry' uses COBOL -- it's the best tool for the job at hand. Not
Java, and not Perl.
I hope I didn't insult you by this explanation. If you don't know about
APIs, you might want to investigate. One last thing -- Java has tools
that let you draw UML diagrams, such as class diagrams, and generate
code. I teach OO programming in Java at a local university (hence my
verbosity) and I see a lot of harm in using these kinds of tools in
learning a language. I see a lot of managers who have been taught OO
development, but don't have the programming background to understand
the nuts and bolts. HOWEVER, these kinds of foward engineering tools
(as in Rational Rose or Eclipse, for example) can be great timesavers
for the journeyman programmer. With Perl, I think this kind of tool
would be impossible, because of the free from nature of the language. I
don't see this as either a detriment or an advantage, but simply an
aspect of the tool which makes it better or worse for some particular
job.
Best, Charles Carter.