Java is just arbitrary and confusing for no reason.
Richard Kettlewell <invalid@invalid.invalid> wrote:
I donrCOt get on well with Java either, but I think the last two
examples are written in an unnecessarily obscure fashion. I think you
would normally write the following:
Integer a = 2, b = 3;
Integer c = Integer.max(a, b);
...which is certainly a trifle verbose, but not actively misleading.
I could've been clearer, I s'pose, but it was my point that there are,
for a random subset of math functions, multiple ways to write the same
thing, using classes with no direct relationship - java.lang.Math isn't
a subclass of java.lang.Number and its subclasses, nor the other way
around, nor is there some kind of Math<T> interface that they both
implement. (In fact, these methods aren't even part of Number - they
only belong to its subclasses individually!)
Why, then, do they duplicate functionality? Why some methods and not
others? Why are the methods for specific Number types static instead of specific to the object, so that one could at least have Math.round(num)
for arbitrary number variables, but Double.round() for reflexive
rounding of a specific Double object?
It's just arbitrary and weird.
ItrCOs not like Java has a monopoly on being arbitrary and weird!
int fputs(const char *s, FILE *stream);
int fprintf(FILE *stream, const char *format, ...);
Whether the stream argument is first or last depends which function
yourCOre using.
On Sat, 07 Feb 2026 15:36:18 +0000, Richard Kettlewell wrote:
ItrCOs not like Java has a monopoly on being arbitrary and weird!
int fputs(const char *s, FILE *stream);
int fprintf(FILE *stream, const char *format, ...);
Whether the stream argument is first or last depends which function
yourCOre using.
After all these years I use 'man fputs' more than I should. Then you throw in the similar functions that take an int file descriptor rather than a FILE*.
I'd still rather deal with that arbitrariness than C++'s streams.
I deal with those by remembering that fputs() can have any number
of arguments, so we might as well get the file pointer out there first.
On 2026-02-07, rbowman <bowman@montana.com> wrote:
On Sat, 07 Feb 2026 15:36:18 +0000, Richard Kettlewell wrote:
ItrCOs not like Java has a monopoly on being arbitrary and weird!
int fputs(const char *s, FILE *stream);
int fprintf(FILE *stream, const char *format, ...);
Whether the stream argument is first or last depends which function
yourCOre using.
After all these years I use 'man fputs' more than I should. Then you
throw in the similar functions that take an int file descriptor rather
than a FILE*.
I'd still rather deal with that arbitrariness than C++'s streams.
I deal with those by remembering that fputs() can have any number of arguments, so we might as well get the file pointer out there first. On
the other hand, putc() only has one argument, so fputc() adds the file pointer at the end. Then I just have to remember how the arguments go
with fgets() - and I've replaced it with getline(), which is quite
similar. I always read strings and parse them myself, so that about
covers I/O for me.
On Sat, 07 Feb 2026 21:26:55 GMT, Charlie Gibbs wrote:
On 2026-02-07, rbowman <bowman@montana.com> wrote:
On Sat, 07 Feb 2026 15:36:18 +0000, Richard Kettlewell wrote:
ItrCOs not like Java has a monopoly on being arbitrary and weird!
int fputs(const char *s, FILE *stream);
int fprintf(FILE *stream, const char *format, ...);
Whether the stream argument is first or last depends which function
yourCOre using.
After all these years I use 'man fputs' more than I should. Then you
throw in the similar functions that take an int file descriptor rather
than a FILE*.
I'd still rather deal with that arbitrariness than C++'s streams.
I deal with those by remembering that fputs() can have any number of
arguments, so we might as well get the file pointer out there first. On
the other hand, putc() only has one argument, so fputc() adds the file
pointer at the end. Then I just have to remember how the arguments go
with fgets() - and I've replaced it with getline(), which is quite
similar. I always read strings and parse them myself, so that about
covers I/O for me.
man fputs
SYNOPSIS
#include <stdio.h>
int fputc(int c, FILE *stream);
int putc(int c, FILE *stream);
int putchar(int c);
int fputs(const char *restrict s, FILE *restrict stream);
int puts(const char *s);
On Sat, 07 Feb 2026 15:36:18 +0000, Richard Kettlewell wrote:
ItrCOs not like Java has a monopoly on being arbitrary and weird!
int fputs(const char *s, FILE *stream);
int fprintf(FILE *stream, const char *format, ...);
Whether the stream argument is first or last depends which function
yourCOre using.
After all these years I use 'man fputs' more than I should. Then you
throw in the similar functions that take an int file descriptor rather
than a FILE*.
I'd still rather deal with that arbitrariness than C++'s streams.
On 2026-02-08, rbowman wrote:
On Sat, 07 Feb 2026 21:26:55 GMT, Charlie Gibbs wrote:
I deal with those by remembering that fputs() can have any number of
arguments, so we might as well get the file pointer out there first. On
the other hand, putc() only has one argument, so fputc() adds the file
pointer at the end. Then I just have to remember how the arguments go
with fgets() - and I've replaced it with getline(), which is quite
similar. I always read strings and parse them myself, so that about
covers I/O for me.
man fputs
(It looks to me, albeit still undercaffeinated, that Charlie simply mixed/mistyped that function name. Could it perhaps be meant to be fprintf()?)
On Sat, 07 Feb 2026 21:26:55 GMT, Charlie Gibbs wrote:
I deal with those by remembering that fputs() can have any number
of arguments, so we might as well get the file pointer out there first.
Er, no, it doesnrCOt.
Java is just arbitrary and confusing for no reason.
So is the real world
True enough, and it is to some degree a question of taste - but JavaIt's just arbitrary and weird.
ItrCOs not like Java has a monopoly on being arbitrary and weird!
[...]
IrCOd suggest that any language that doesnrCOt start out with odd corners like this will grow them over time as it responds to new thinking, new requirements, etc.
Richard Kettlewell <invalid@invalid.invalid> wrote:
IrCOd suggest that any language that doesnrCOt start out with odd corners
like this will grow them over time as it responds to new thinking, new
requirements, etc.
True enough, and it is to some degree a question of taste - but Java
does, to my mind, strike a particular balance of vices that remind me
of the main thrust of Kernighan's criticism of Pascal: not only does it suffer from misfeatures and frustrations, but it provides no real way
to work around them from within itself.
To a lesser extent, at least; the core language *does* allow the
programmer to define new constructs that can be used (to some extent)
in place of existing ones, whereas vanilla Pascal didn't. If I don't
like the organization of the Math class, f'rexample, I'm free create my
own. But there are practical limits to this - I can't snap my fingers
and make everything *else* in the standard library recognize MyMath's
way of doing things. The deeper some annoyance lies within the system,
the more you'd have to uproot in order to fix it.
#define print System.out.println
...or somesuch, because Gosling & co. didn't see fit to provide a pre- processor.
True enough, and it is to some degree a question of taste - but Java
does, to my mind, strike a particular balance of vices that remind me of
the main thrust of Kernighan's criticism of Pascal: not only does it
suffer from misfeatures and frustrations, but it provides no real way to
work around them from within itself.
On Fri, 13 Feb 2026 11:30:12 -0800, John Ames wrote:
#define print System.out.println
...or somesuch, because Gosling & co. didn't see fit to provide a pre-
processor.
Or typedefs.
On Fri, 13 Feb 2026 11:30:12 -0800, John Ames wrote:
True enough, and it is to some degree a question of taste - but Java
does, to my mind, strike a particular balance of vices that remind me of
the main thrust of Kernighan's criticism of Pascal: not only does it
suffer from misfeatures and frustrations, but it provides no real way to
work around them from within itself.
I had hopes for Java in the late '90s. 'Java in a Nutshell', 2nd edition iirc, was fairly concise. You'd need a damn big nut for the 7th edition. I was working with the AVR processors so my 'hello world' project was a
simple emulator. Not happening in Java.
AWT wasn't bad but then they introduced Swing. The mantra at the time if
you were upset at the glacial performance was to get a newer, faster machine, Right.
I did like Visual J++, but its relationship to Sun Java was loose, leading to Sun shutting it down. It took a while but Microsoft eventually came up with C#, which is what Java (and Visual C++) should have been.
We had one Java application that suffered from extensive mission creep
over the years. I seldom worked on the code and always did with my fingers crossed.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 59 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 25:30:05 |
| Calls: | 810 |
| Files: | 1,287 |
| Messages: | 196,025 |