Spot The Error

[Lawrence D'Oliveiro]

Not at all - I want to see what you conveniently left out.

I left out the stuff to reduce the amount of Java code you had to write.

That includes code needed to shut down cleanly, which is entirely missing.
Omitting that is scarcely professional even for a one-off script.

Shut what down cleanly?

In Java all that can be sucked in with under 10 statements as a property
list and writing a completely general purpose RDBMS -> CSV converter
would be a fairly trivial exercise.

Do it, then. For 39 fields from one table, and 8 from the second one.

 

[Lawrence D'Oliveiro]

Plenty of languages do not have an SVO sentence order; even English
eschews it some more poetic styles.

You’re not trying to claim that javadoc is “poeticâ€, are you?

When in Rome, do as the Romans do.

I’m not in Rome, and I’ve never been there, though I am from somewhere less
than a couple of thousand km from Java. You know, the actual, real place.

Javadoc is the most common documentation generator for Java

I don’t understand why you need a “documentation generatorâ€: does it
automatically put comments in the code for you? If not, what’s the point?

 

[Arved Sandstrom]

In message<[email protected]>, Joshua Cranmer wrote:

[ SNIP ]

I don’t understand why you need a “documentation generatorâ€: does it
automatically put comments in the code for you? If not, what’s the point?

Nobody _needs_ documentation generation. You might be content to
completely dispense with API documentation (in which case you wouldn't
be the first programmer who didn't know what a library did), or you
might be happy to keep the API docs completely separate from the code
(with all the practical consequences that entails), or you might only
work with libraries where you can access the source and read the
comments (unrealistic and cumbersome).

If, OTOH, you prefer to maintain the documentation *source* in the code,
with the code, _and_ you find it more convenient to have the finished
documentation be separately available (so you don't have to sift through
code to find it), then maybe an automated process that processes the
code+documentation source to produce finished documentation makes some
sense to you.

You've never written any docs for API end users, have you? _If_ you
have, and you had to pose the questions you did, you must love wasting
your time and making errors.

AHS

 

[Arved Sandstrom]

I left out the stuff to reduce the amount of Java code you had to write.


Shut what down cleanly?

Are you connecting to a database or aren't you? If you are, and you
believe your user code doesn't need to worry about disposing of
resources, are you consciously aware of what other code is taking care
of that for you?

[ SNIP ]

AHS

 

[Lew]

Joshua Cranmer wrote:

[ SNIP ]

I don’t understand why you need a “documentation generatorâ€: does it
automatically put comments in the code for you? If not, what’s the point?

Nobody _needs_ documentation generation. You might be content to completely
dispense with API documentation (in which case you wouldn't be the first
programmer who didn't know what a library did), or you might be happy to keep
the API docs completely separate from the code (with all the practical
consequences that entails), or you might only work with libraries where you
can access the source and read the comments (unrealistic and cumbersome).

If, OTOH, you prefer to maintain the documentation *source* in the code, with
the code, _and_ you find it more convenient to have the finished documentation
be separately available (so you don't have to sift through code to find it),
then maybe an automated process that processes the code+documentation source
to produce finished documentation makes some sense to you.

You've never written any docs for API end users, have you? _If_ you have, and
you had to pose the questions you did, you must love wasting your time and
making errors.

No, "Lawrence D'Oliveiro" loves being an ass and fomenting argument.

 

[Joshua Cranmer]

I don’t understand why you need a “documentation generatorâ€: does it
automatically put comments in the code for you? If not, what’s the point?

Some of us prefer not having to read the code to figure out how to use
it, especially in the case of libraries. For example, you can figure out
how to use Swing just from the Javadocs; you don't have to go reading
the Swing source code to find out what the methods do.

 

[Martin Gregorie]

You've never written any docs for API end users, have you? _If_ you
have, and you had to pose the questions you did, you must love wasting
your time and making errors.

I'm not certain what languages he knows apart from Python. Its preferred
documentation style is almost as unfriendly as Forth. Good Python style
puts a triple quoted line or two between the methof or function header
and the code body and that's about it:

def myfunction:
""" myfunction does blah blah blah """
code body is here

There's a fairly well-documented example here:
http://code.activestate.com/recipes/577540-python-binary-search-tree/

but as you can see, the overall impression is that the user is expected
to read the code rather than any separately maintained or presented
documentation. Reading through "Python in a Nutshell", which is fairly
well-regarded in the Python community, gives the same feeling.

That's not to say that all Javadocs are wonderful, especially when a lazy
programmer wrote the class, but at least the method signatures are
correct and the layout is neat and consistent.

 

[Lew]

That's not to say that all Javadocs are wonderful, especially when a lazy
programmer wrote the class, but at least the method signatures are
correct and the layout is neat and consistent.  

And there are published Javadoc comment conventions:
<http://www.oracle.com/technetwork/java/javase/documentation/
index-137868.html>
<http://download.oracle.com/javase/6/docs/technotes/tools/solaris/
javadoc.html>


Following the conventions forces you to be intentional, and therefore
culpable, if you omit information such as the purpose of a method
parameter.

The presence of well-established, published standards forces you to be
intentional, and therefore culpable, not to follow them.

 

[Martin Gregorie]

APL?

I'd forgotten about that! Is APL still used?

If so, now that the APL terminal[*] is presumably long dead, what is used
to edit and display APL programs?

Its easily the world's best write-only language. I remember hearing that
Ken Iverson himself once wrote a text editor in 25 lines of it - and then
couldn't understand it six months later. I last remember seeing it
running on an IBM 1130, thankfully, but never had to use it - at that
point in time I was using Jean where an IBMer would have used APL.


[*] IIRC it was based on a modified IBM Selectric with the special APL
golf-ball.

 

[Michael Wojcik]

I'd forgotten about that! Is APL still used?

Yes. How widely I couldn't say.

APL has at least one descendant, J, which is still in use, at least by
a few people; the forums at J Software are active. (Wasn't there a
subthread about J recently in one of cljp's interminable flamewars? I
believe I recall ignoring one.)

If so, now that the APL terminal[*] is presumably long dead, what is used
to edit and display APL programs?

Any system that can display the necessary characters. It's trivial
with modern GUIs. You use modifier keys to enter the APL characters.
See the comp.lang.apl FAQ for more information.

I even have an old DOS implementation somewhere that does its own
rendering - puts the screen in one of the old DOS graphics modes and
provides character glyph rendering, scrolling, etc. It can run under
Windows in virtual-86 mode, though only in full-screen mode, if memory
serves.

 

[Mike Schilling]

For example?

int i;
unsigned int u;

Quick, what type is (i + u)? How, exactly, is it calculated?

 

[Lawrence D'Oliveiro]

Are you connecting to a database or aren't you? If you are, and you
believe your user code doesn't need to worry about disposing of
resources, are you consciously aware of what other code is taking care
of that for you?

This is in a modern language which takes care of such cleanup for me.

 

[Lawrence D'Oliveiro]

int i;
unsigned int u;

Quick, what type is (i + u)? How, exactly, is it calculated?

Can’t think of any situation where I would care.

 

[Mike Schilling]

Can’t think of any situation where I would care.

Then there's our example, where a C developer doesn't actually understand
what goes on with unsigned, what unsigned arithmetic is.

 

[Mike Schilling]

[...]

Gosling: Quiz any C developer about unsigned, and pretty soon you
discover that almost no C developers actually understand what goes on
with unsigned, what unsigned arithmetic is.

For example?

int i;
unsigned int u;

Quick, what type is (i + u)? How, exactly, is it calculated?

Can’t think of any situation where I would care.

Then there's our example, where a C developer doesn't actually
understand what goes on with unsigned, what unsigned arithmetic is.

For what it's worth, I don't see how your example applies to Gosling's
comments. The question of type conversion for the + operator is not the
same as the simpler question of calculations purely involving only the
unsigned type. The quoted comment does not mention a signed type at all,
only unsigned, and so introducing the admittedly problematic question of
implicit type conversion seems non-responsive to me.

I think there are good reasons pro and con with respect to supporting
unsigned types, and different language designers will have different
priorities leading to different choices. But if we're to have a
productive discussion about those choices, it seems to me it is most
useful to focus on the question at hand, or at least to admit that other
questions are being introduced as they are in fact introduced.

Are there examples _specific_ to the above quote from Gosling that explain
what _he_ meant by that comment?

Unsigned arithmetic is, in itself, very straightforward, which is why I
proceeded directly to the tricky part: mixing it with signed types.

 

[Arved Sandstrom]

This is in a modern language which takes care of such cleanup for me.

Well, I always stand to have my horizons expanded, but I'm not aware of
any mainstream modern programming language that takes care of database
cleanup to the degree that you suggest. Various languages have (or will
have) aspects of automatic resource management (ARM) - Python with
"with" and context managers, Ruby with things like IO auto-closing
blocks, Java 7 ARM, .NET "using" statements with IDisposables etc etc,
many of which constructs apply to DB connections - but ones where you
can be so blithely unaware of any of the details don't immediately occur
to me.

AHS

 

[Mike Schilling]

Mike Schilling wrote:
...

Perhaps the answer it that if it hurts when you mix signed and unsigned
types, don't do it. Everything that could be done with mixed arithmetic
could be done using explicit conversion, which makes that set of
arithmetic rules and the result types obvious.

I suppose you could design a language that doesn’t allow them to be mixed,
but it would have been unlikely to happen in Java, since one of its main
design goals was to be C-like and C++-like; thus Java would most likely have
inherited their mess.

 

[Lawrence D'Oliveiro]

Well, I always stand to have my horizons expanded, but I'm not aware of
any mainstream modern programming language that takes care of database
cleanup to the degree that you suggest.

What “degree†would that be?

 

[Arved Sandstrom]

What “degree†would that be?

As in, you don't have to worry at all about any form of database
connection cleanup. In fact you so don't worry about the details that
you don't know what code - if any - is doing any disposal whatsoever.

That's what you said, and I was wondering what language did this for you.

AHS

 

[Lawrence D'Oliveiro]

As in, you don't have to worry at all about any form of database
connection cleanup.

Where did I say that?