On Sat, 27 Jan 2024 11:09:56 +0100, Janis Papanagnou wrote:

What I [think to] know is that simple word permutations don't help for general cases of localization, so printf would just work for some
primitive application special cases.

In a project I worked on some years ago, I devised a custom string-
templating scheme for localization purposes, using keywords to represent
the variable bits. We got as far as handling Japanese and Chinese, plus a
few European languages.

I did have to make some small code changes. For example in Japanese the equivalent of “either «a», «b» or «c»” becomes something like “either «a»
or1 «b» or2 «c»”, with different words for “or1” and “or2”. In other
languages, the “or1” could just be a comma, as in the template with more than 3 cases. So you can see why I needed to add a template for exactly 3 cases.

As I recall, it took some explaining to the translators to get them to understand the scheme. They were not accustomed to working in terms of
abstract sentence/phrase structure with placeholders. I had to keep
supplying plenty of examples.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 27 Jan 2024 17:24:27 GMT, Scott Lurndal wrote:

Java, as a language, was rather well designed.

It tried to be simpler than C++. If you compare the respective sizes of
the core language manuals, you would have to agree it failed miserably.

And the cost of that “simplicity” was the leaving out of useful features like operator overloads for user types, unsigned integers, typedefs and generics (later added back in a hacky way).

Here’s a Java feature that might surprise some people: in C++, you use the word “new” to denote that a class instance is being allocated on the heap. A declaration without that word indicates that the instance is being
allocated on the stack.

In Java, as in Python, all class instances are allocated on the heap.
Therefore the word “new” becomes superfluous. And so Python gets rid of
it, reducing class instantiation to what looks like a function call on the class name.

Yet Java keeps the requirement to say “new”. Why?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27.01.2024 21:58, Lawrence D'Oliveiro wrote:

On Sat, 27 Jan 2024 11:09:56 +0100, Janis Papanagnou wrote:

What I [think to] know is that simple word permutations don't help for
general cases of localization, so printf would just work for some
primitive application special cases.

In a project I worked on some years ago, I devised a custom string- templating scheme for localization purposes, using keywords to represent
the variable bits. We got as far as handling Japanese and Chinese, plus a
few European languages. [...]

Allow me to say; this sounds very impressive to me!

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27.01.2024 18:24, Scott Lurndal wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

As someone who as programmed daily in C++ since 1989, usually

I started C++ around the same time, actually since C++'s beginning,
so probably only few years earlier. But today I use C++ only in my
private context since, professionally, I'm not programming any more.

in performance sensitive code, I've never found the C++ input
and output operators useful.

I'm sure whether one finds a language (or features of a language)
useful certainly depends on various factors; education, the area
of work, the specific company (including its culture), and own
personality (own experiences, and personal background, where from
one comes).

This is why I think it makes no sense to start a dispute here.
Either you have experienced the advantages, or you haven't, or only
partly.

The run-time cost both in space
and time is far more than the *printf formatting functions,
and they're less flexible when the formatting changes based,
e.g., on locale.

Runtime costs and memory space considerations had been relevant
in my DSP assembler deep-space-satellite-communication project
(in the late 1980's).

In my C++ projects it was irrelevant whether language feature A
was 10% faster or slower compared to language feature B. There
were other factors that influenced performance; like complexity
of the algorithmic solutions. And there were other requirements
that had precedence anyway; like robust and extensible designs.
Amongst many other things.

So all I can do, if you like - but I don't know whether it helps
you, since your experiences and background certainly differs -,
is to illustrate it with a small project where specifically the
feature of discussion helped to a clear and extensible design,
simply to use and integrate; a flexibility and robust solution.

In C++ I implemented an Application Management Interface - that was
already 30 years ago, before Java provided some library like that -
that made it possible to control any object instance in a software
component by (informally written) "interface.register(item)", and
you could then interrogate or change state of such registered items asynchronously during runtime by exchanging the de-/linearized data
through some text oriented IPC channel. There was no need to adjust
application logic and no functional dependencies. It was transparent
WRT the type of object (it could be, say, a primitive 'int' counter
or a complex 'Car' object); items of any complexity and type could
be controlled through any stream based communication interface. The
only precondition was that the object class provides operators '<<'
and '>>' for de-/serialization (and these operators were anyway
defined in our contexts, for obvious reasons), and (IIRC) that it
had the property "controllable" (an interface derivation). Thanks
to OO principles and (beside other features) C++'s '<<' operator.

(I don't want to imagine such functionality with printf and all
it's impact to the rest of the program system.)

Java (as a newer language) has also some advantages, but was in many
respects far behind C++ (IMO).

Wow, that's a strong statement. What led you to hold that opinion?

Experience with many programming languages (including Java), and
a pair of open eyes, and an open mind.

Java, as a language, was rather well designed.

(It would have never occurred to me to to make such a statement.)

The run-time costs,
however, precluded the use of Java in most of the projects that I've
worked on since Java was introduced.

This is just one observation. But, yes.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27.01.2024 22:04, Lawrence D'Oliveiro wrote:

[...]
In Java, as in Python, all class instances are allocated on the heap. Therefore the word “new” becomes superfluous. And so Python gets rid of it, reducing class instantiation to what looks like a function call on the class name.

Yet Java keeps the requirement to say “new”. Why?

If the "Why?" refers to the word "keeps" then the answer seems
obvious; compatibility, to not break existing code.
If you're asking why "in the first place" they introduced it; I
suppose to differentiate it from simple types, and to indicate
that such objects are subject to the garbage collector (when
getting unused).
Maybe it's useful to know how Simula (first OO language, thus
probably a paragon for other language designs) did it. Here you
had simple types (integer, real, character, etc.), the special
type 'text' (a string class but used also like a primitive one),
and the complex class types. The latter had an own declaration
syntax 'ref(class)name' and own ref-assignments ':-' as opposed
to value-assignments ':=', own comparison operators, and they
are subject to garbage collection. This appears to some degree
to be similar to Java.

But personally I don't mind the 'new' keyword in Java anyway.
Languages shall make it possible to produce readable code; with
Java I can do that (and probably even better than in C), so that
is not what prevents me from choosing Java.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 28 Jan 2024 17:42:29 +0100, Janis Papanagnou wrote:

On 27.01.2024 22:04, Lawrence D'Oliveiro wrote:

In Java, as in Python, all class instances are allocated on the heap.
Therefore the word “new” becomes superfluous. And so Python gets rid of >> it, reducing class instantiation to what looks like a function call on
the class name.

Yet Java keeps the requirement to say “new”. Why?

If the "Why?" refers to the word "keeps" then the answer seems obvious; compatibility, to not break existing code.
If you're asking why "in the first place" they introduced it; I suppose
to differentiate it from simple types, and to indicate that such objects
are subject to the garbage collector (when getting unused).

For simple types, you don’t need to use the type name at all, to create an instance of the type. So there would be no opportunity to use or not use
the type name. Hence the question about “new” is irrelevant in this case.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)