In the beginning, Java was supposed to be a much simpler language than C++, 
in some sense leaving out all the unnecessary complications, while keeping 
the worthwhile parts.

This PDF copy of “The Java Language Specification”, 3rd Edition, that I’m 
currently reading, has 684 pages. By comparison, the paper copy of “The C++ 
Standard” on my bookshelf has 782 numbered pages. As you can see, Java is no 
longer that far off C++ in complexity.

Most of that complexity seems to be caused by the addition of generics to 
Java. This was something that C++ had from the beginning. It was one of the 
unnecessary complications that Java left out to start with. But now they’ve 
changed their minds, and put it back in. But since they need to be backward-
compatible with existing code, they’ve had to add extra complications that 
C++ never had to deal with.

Bjarne Stroustroup must be chuckling over his hot cocoa...

In article <iijbfr$pb2$1@lust.ihug.co.nz>, ldo@geek-central.gen.new_zealand 
says...

> Most of that complexity seems to be caused by the addition of generics to 
> Java.

I have always missed generics concept in languages that did not have it, and I 
had never worked in C++. :))



-- 
score: 40.59041%

In message <MPG.27b75a6e94bcbb39989e33@news.t-com.hr>, Pitch wrote:

> I have always missed generics concept in languages that did not have it,
> and I had never worked in C++. :))

Try Python. Has no generics, and doesn’t need them.

On 02/05/2011 12:15 PM, Lawrence D'Oliveiro wrote:
> In the beginning, Java was supposed to be a much simpler language than C++,
> in some sense leaving out all the unnecessary complications, while keeping
> the worthwhile parts.
>
> This PDF copy of “The Java Language Specification”, 3rd Edition, that I’m
> currently reading, has 684 pages. By comparison, the paper copy of “The C++
> Standard” on my bookshelf has 782 numbered pages. As you can see, Java is no
> longer that far off C++ in complexity.
>
> Most of that complexity seems to be caused by the addition of generics to
> Java. This was something that C++ had from the beginning. It was one of the
> unnecessary complications that Java left out to start with. But now they’ve
> changed their minds, and put it back in. But since they need to be backward-
> compatible with existing code, they’ve had to add extra complications that
> C++ never had to deal with.
>
> Bjarne Stroustroup must be chuckling over his hot cocoa...

C++ did not have generics from the beginning. It was added afterwards 
and initially without any proper specification of (separate) compilation 
and linkage aspects.

Lawrence D'Oliveiro wrote:
> In the beginning, Java was supposed to be a much simpler language than C++,
> in some sense leaving out all the unnecessary complications, while keeping
> the worthwhile parts.
>
> This PDF copy of “The Java Language Specification”, 3rd Edition, that I’m
> currently reading, has 684 pages. By comparison, the paper copy of “The C++
> Standard” on my bookshelf has 782 numbered pages. As you can see, Java is no
> longer that far off C++ in complexity.
>
> Most of that complexity seems to be caused by the addition of generics to
> Java. This was something that C++ had from the beginning. It was one of the
> unnecessary complications that Java left out to start with. But now they’ve
> changed their minds, and put it back in. But since they need to be backward-
> compatible with existing code, they’ve had to add extra complications that
> C++ never had to deal with.
>
> Bjarne Stroustroup must be chuckling over his hot cocoa...

Troll alert!

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

Lawrence D'Oliveiro wrote:
>> In the beginning, Java was supposed to be a much simpler language than C++,
>> in some sense leaving out all the unnecessary complications, while keeping
>> the worthwhile parts.
>>
>> This PDF copy of “The Java Language Specification”, 3rd Edition, that I’m
>> currently reading, has 684 pages. By comparison, the paper copy of “The C++
>> Standard” on my bookshelf has 782 numbered pages. As you can see, Java is no
>> longer that far off C++ in complexity.
>>
>> Most of that complexity seems to be caused by the addition of generics to
>> Java. This was something that C++ had from the beginning. It was one of the
>> unnecessary complications that Java left out to start with. But now they’ve
>> changed their minds, and put it back in. But since they need to be backward-
>> compatible with existing code, they’ve had to add extra complications that
>> C++ never had to deal with.
>>
>> Bjarne Stroustroup must be chuckling over his hot cocoa...

Silvio wrote:
> C++ did not have generics from the beginning. It was added afterwards and
> initially without any proper specification of (separate) compilation and
> linkage aspects.

C++ doesn't have generics.  It has templates.  They aren't the same thing.

C# has generics.  Java has (different) generics.  C++ doesn't.

Lawrence is trolling.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

On 05-02-2011 06:15, Lawrence D'Oliveiro wrote:
> In the beginning, Java was supposed to be a much simpler language than C++,
> in some sense leaving out all the unnecessary complications, while keeping
> the worthwhile parts.
>
> This PDF copy of “The Java Language Specification”, 3rd Edition, that I’m
> currently reading, has 684 pages. By comparison, the paper copy of “The C++
> Standard” on my bookshelf has 782 numbered pages. As you can see, Java is no
> longer that far off C++ in complexity.

C++ is a much more complex language than Java.

Complexity is more than the number of pages in the standard.

Java was designed to have well defined behavior for most things. That
requires rather detailed descriptions.

> Most of that complexity seems to be caused by the addition of generics to
> Java. This was something that C++ had from the beginning.  It was one of the
 > unnecessary complications that Java left out to start with.

C++ had templates before Java got generics. Java generics are obviously
very inspired by C++ templates, but are still different in many ways.

But it is correct that generics added some complexity to Java.

Every addition to a language must be carefully considered whether
the benefits outweigh the added complexity.

Arne

On 05-02-2011 07:24, Lawrence D'Oliveiro wrote:
> In message<MPG.27b75a6e94bcbb39989e33@news.t-com.hr>, Pitch wrote:
>> I have always missed generics concept in languages that did not have it,
>> and I had never worked in C++. :))
>
> Try Python. Has no generics, and doesn’t need them.

Generics are not particular useful in dynamic typed
languages.

But since Java is static typed, then not so relevant
for Java.

Arne

On 05-02-2011 09:02, Silvio wrote:
> On 02/05/2011 12:15 PM, Lawrence D'Oliveiro wrote:
>> Most of that complexity seems to be caused by the addition of generics to
>> Java. This was something that C++ had from the beginning. It was one
>> of the
>> unnecessary complications that Java left out to start with. But now
>> they’ve
>> changed their minds, and put it back in. But since they need to be
>> backward-
>> compatible with existing code, they’ve had to add extra complications
>> that
>> C++ never had to deal with.
>>
>> Bjarne Stroustroup must be chuckling over his hot cocoa...
>
> C++ did not have generics from the beginning. It was added afterwards
> and initially without any proper specification of (separate) compilation
> and linkage aspects.

Not from the very beginning.

But it was added to cfront pretty early.

Arne

On 2011-02-05 06:15:07 -0500, Lawrence D'Oliveiro said:

> This PDF copy of “The Java Language Specification”, 3rd Edition, that I’m
> currently reading, has 684 pages. By comparison, the paper copy of “The C++
> Standard” on my bookshelf has 782 numbered pages. As you can see, Java is no
> longer that far off C++ in complexity.

This is an extremely dubious measure of complexity. The Common Lisp 
specification is over a thousand pages long in some editions*, but Lisp 
is generally considered a much simpler language than either C++ or Java.

You've posted extensively about things you see in Java that you don't 
like, and there's a strong "C++ is better" undercurrent to your posts. 
While I disagree with the undercurrent, I will defend to the death your 
right to program in C++ instead. Just, please, go away.

-o

* <http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html>, which 
predates the ANSI spec.

On 02/05/2011 06:15 AM, Lawrence D'Oliveiro wrote:
> In the beginning, Java was supposed to be a much simpler language than C++,
> in some sense leaving out all the unnecessary complications, while keeping
> the worthwhile parts.
>
> This PDF copy of “The Java Language Specification”, 3rd Edition, that I’m
> currently reading, has 684 pages. By comparison, the paper copy of “The C++
> Standard” on my bookshelf has 782 numbered pages. As you can see, Java is no
> longer that far off C++ in complexity.

My copy of the C++0x draft reference standard, i.e. the copy sent out 
for a ballot by national bodies, consisted of no fewer than 1300 
numbered pages. Also take into consideration the fact that the C++ 
standard does not try to pin stuff down into unambiguous interoperable 
statements, e.g., a precise size definition for size_t. Java, on the 
other hand, goes so far as to fully define the language character set, a 
longish, detailed, accessible expose on the threading memory model that 
takes up 30 pages, while C++ spends 3 pages on it and still leaves me 
wondering what memory is guaranteed to be visible after certain operations.

So 684 pages of well-written, easily-understood text is not nearly as 
complex as 1300 pages of dense, example-lacking specification text. 
Maybe that's why popular C++ compilers have many more compatibility 
problems than popular Java compilers?

Your statement is not up to date.

> Most of that complexity seems to be caused by the addition of generics to
> Java. This was something that C++ had from the beginning. It was one of the
> unnecessary complications that Java left out to start with. But now they’ve
> changed their minds, and put it back in. But since they need to be backward-
> compatible with existing code, they’ve had to add extra complications that
> C++ never had to deal with.

You sir have probably never met the full pain of template 
metaprogramming. Indeed, templates is probably the single least 
well-supported thing in C++.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On 02/05/2011 03:38 PM, Arne Vajhøj wrote:
> On 05-02-2011 09:02, Silvio wrote:
>> On 02/05/2011 12:15 PM, Lawrence D'Oliveiro wrote:
>>> Most of that complexity seems to be caused by the addition of
>>> generics to
>>> Java. This was something that C++ had from the beginning. It was one
>>> of the
>>> unnecessary complications that Java left out to start with. But now
>>> they’ve
>>> changed their minds, and put it back in. But since they need to be
>>> backward-
>>> compatible with existing code, they’ve had to add extra complications
>>> that
>>> C++ never had to deal with.
>>>
>>> Bjarne Stroustroup must be chuckling over his hot cocoa...
>>
>> C++ did not have generics from the beginning. It was added afterwards
>> and initially without any proper specification of (separate) compilation
>> and linkage aspects.
>
> Not from the very beginning.
>
> But it was added to cfront pretty early.
>
> Arne
>

That just depends on what you call early. I used C-with-classes before 
it was named C++ and my cfront did not know of templates...

The first "The C++ programming language" book Stroustrup published made 
no mention of templates. Stroustrup described templates in his Design 
and Evolution of C++ book and later in his second edition of TCPPPL.

And Lew is correct: templates and genercis are completely different beasts.

On 02/05/2011 03:26 PM, Lew wrote:
> Lawrence D'Oliveiro wrote:
>>> In the beginning, Java was supposed to be a much simpler language
>>> than C++,
>>> in some sense leaving out all the unnecessary complications, while
>>> keeping
>>> the worthwhile parts.
>>>
>>> This PDF copy of “The Java Language Specification”, 3rd Edition, that
>>> I’m
>>> currently reading, has 684 pages. By comparison, the paper copy of
>>> “The C++
>>> Standard” on my bookshelf has 782 numbered pages. As you can see,
>>> Java is no
>>> longer that far off C++ in complexity.
>>>
>>> Most of that complexity seems to be caused by the addition of
>>> generics to
>>> Java. This was something that C++ had from the beginning. It was one
>>> of the
>>> unnecessary complications that Java left out to start with. But now
>>> they’ve
>>> changed their minds, and put it back in. But since they need to be
>>> backward-
>>> compatible with existing code, they’ve had to add extra complications
>>> that
>>> C++ never had to deal with.
>>>
>>> Bjarne Stroustroup must be chuckling over his hot cocoa...
>
> Silvio wrote:
>> C++ did not have generics from the beginning. It was added afterwards and
>> initially without any proper specification of (separate) compilation and
>> linkage aspects.
>
> C++ doesn't have generics. It has templates. They aren't the same thing.
>
> C# has generics. Java has (different) generics. C++ doesn't.
>
> Lawrence is trolling.
>

Hello Lew,

You are correct, templates are a completely different thing. However, 
since they try to achieve a similar goal (albeit in very different ways) 
they are often compared and spoken of in combination.

I suspected he is trolling also but could not resist correcting a false 
statement.

Silvio

In article <iijfh1$rk1$1@lust.ihug.co.nz>, ldo@geek-central.gen.new_zealand=
=20
says...
>=20
> In message <MPG.27b75a6e94bcbb39989e33@news.t-com.hr>, Pitch wrote:
>=20
> > I have always missed generics concept in languages that did not have it=
,
> > and I had never worked in C++. :))
>=20
> Try Python. Has no generics, and doesn?t need them.

That's like comparing Bon Jovi with Slayer. :)


--=20
score: 40.59041%

On 05-02-2011 12:04, Silvio wrote:
> On 02/05/2011 03:38 PM, Arne Vajhøj wrote:
>> On 05-02-2011 09:02, Silvio wrote:
>>> On 02/05/2011 12:15 PM, Lawrence D'Oliveiro wrote:
>>>> Most of that complexity seems to be caused by the addition of
>>>> generics to
>>>> Java. This was something that C++ had from the beginning. It was one
>>>> of the
>>>> unnecessary complications that Java left out to start with. But now
>>>> they’ve
>>>> changed their minds, and put it back in. But since they need to be
>>>> backward-
>>>> compatible with existing code, they’ve had to add extra complications
>>>> that
>>>> C++ never had to deal with.
>>>>
>>>> Bjarne Stroustroup must be chuckling over his hot cocoa...
>>>
>>> C++ did not have generics from the beginning. It was added afterwards
>>> and initially without any proper specification of (separate) compilation
>>> and linkage aspects.
>>
>> Not from the very beginning.
>>
>> But it was added to cfront pretty early.
>
> That just depends on what you call early. I used C-with-classes before
> it was named C++ and my cfront did not know of templates...
>
> The first "The C++ programming language" book Stroustrup published made
> no mention of templates. Stroustrup described templates in his Design
> and Evolution of C++ book and later in his second edition of TCPPPL.

I am pretty sure that templates were introduced before 1990, which would
place them in the first 1/5 of C++ lifespan.

> And Lew is correct: templates and genercis are completely different beasts.

Yep.

Arne

On 02/05/2011 08:42 PM, Arne Vajhøj wrote:
> On 05-02-2011 12:04, Silvio wrote:
>> On 02/05/2011 03:38 PM, Arne Vajhøj wrote:
>>> On 05-02-2011 09:02, Silvio wrote:
>>>> On 02/05/2011 12:15 PM, Lawrence D'Oliveiro wrote:
>>>>> Most of that complexity seems to be caused by the addition of
>>>>> generics to
>>>>> Java. This was something that C++ had from the beginning. It was one
>>>>> of the
>>>>> unnecessary complications that Java left out to start with. But now
>>>>> they’ve
>>>>> changed their minds, and put it back in. But since they need to be
>>>>> backward-
>>>>> compatible with existing code, they’ve had to add extra complications
>>>>> that
>>>>> C++ never had to deal with.
>>>>>
>>>>> Bjarne Stroustroup must be chuckling over his hot cocoa...
>>>>
>>>> C++ did not have generics from the beginning. It was added afterwards
>>>> and initially without any proper specification of (separate)
>>>> compilation
>>>> and linkage aspects.
>>>
>>> Not from the very beginning.
>>>
>>> But it was added to cfront pretty early.
>>
>> That just depends on what you call early. I used C-with-classes before
>> it was named C++ and my cfront did not know of templates...
>>
>> The first "The C++ programming language" book Stroustrup published made
>> no mention of templates. Stroustrup described templates in his Design
>> and Evolution of C++ book and later in his second edition of TCPPPL.
>
> I am pretty sure that templates were introduced before 1990, which would
> place them in the first 1/5 of C++ lifespan.
>


Pretty close. Stroustrups Annotated C++ Reference Manual was published 
in 1990 and introduced templates (and exceptions). This was five years 
after the first TCPPPL book.

>> And Lew is correct: templates and genercis are completely different
>> beasts.
>
> Yep.
>
> Arne
>

In message <2011020510425674637-angrybaldguy@gmailcom>, Owen Jacobson wrote:

> This is an extremely dubious measure of complexity. The Common Lisp
> specification is over a thousand pages long in some editions*, but Lisp
> is generally considered a much simpler language than either C++ or Java.

Really? By whom?

There seem to be an awful lot of language mechanisms in current LISP 
dialects, e.g. multiple-value returns as distinct from lists of values, 
which is a distinction that has no analogue in other languages. Add in all 
that, and the resulting language cannot be described as “simple”.

In message <4d4d6002$0$23763$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 05-02-2011 07:24, Lawrence D'Oliveiro wrote:
>
>> In message<MPG.27b75a6e94bcbb39989e33@news.t-com.hr>, Pitch wrote:
>>
>>> I have always missed generics concept in languages that did not have it,
>>> and I had never worked in C++. :))
>>
>> Try Python. Has no generics, and doesn’t need them.
> 
> Generics are not particular useful in dynamic typed
> languages.
> 
> But since Java is static typed, then not so relevant
> for Java.

Java starts out with static typing, then devotes an awful lot of effort to 
wiggling its way out of that. Look at “unchecked conversions”, for example.

Wouldn’t it be simpler not to pretend in the first place?

In message <4d4d8322$0$41117$e4fe514c@news.xs4all.nl>, Silvio wrote:

> And Lew is correct: templates and genercis are completely different
> beasts.

“Completely” as in “having nothing in common”? Or is this some usage of 
“completely” that I wasn’t aware of?

Please explain.

On 02/05/2011 10:38 PM, Lawrence D'Oliveiro wrote:
> In message<4d4d8322$0$41117$e4fe514c@news.xs4all.nl>, Silvio wrote:
>
>> And Lew is correct: templates and genercis are completely different
>> beasts.
>
> “Completely” as in “having nothing in common”? Or is this some usage of
> “completely” that I wasn’t aware of?
>
> Please explain.

Templates in C++ are basically advanced macros--each invocation of a 
template type regenerates the class, so a Foo<int> and a Foo<double> are 
two completely different things.

Generics in Java are basically compile-time syntactic sugar to ensure 
type-safety of container types at compile time instead of waiting until 
you hit the code at runtime to get that dreaded ClassCastException.

About the only thing they share in common is the syntax, and even then, 
C++ didn't allow A<B<C>> until C++0x (which, according to Bjarne 
Stroustroup, took a bit of work to convince compiler vendors to accept).

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

In message <iijrj2$i0g$1@news.eternal-september.org>, Joshua Cranmer wrote:

> My copy of the C++0x draft reference standard, i.e. the copy sent out
> for a ballot by national bodies, consisted of no fewer than 1300
> numbered pages.

Yeah, so C++ continues to leap ahead into even greater complexity.

> Also take into consideration the fact that the C++ standard does not try
> to pin stuff down into unambiguous interoperable statements, e.g., a
> precise size definition for size_t.

It seems to me that’s another drawback of Java, that it explicitly defines 
the sizes of things from the viewpoint of 32-bit architectures like those 
current in the 1990s. Some of those decisions look less wonderful on current 
64-bit architectures.

> So 684 pages of well-written, easily-understood text ...

Not quite so “well-written, easily-understood”, as I have pointed out 
elsewhere. The mistakes seem particularly concentrated in the parts 
describing the newer language features.

In message <iil5ed$10m$1@news.eternal-september.org>, Joshua Cranmer wrote:

> On 02/05/2011 10:38 PM, Lawrence D'Oliveiro wrote:
>
>> In message<4d4d8322$0$41117$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>
>>> ... templates and gener[ic]s are completely different beasts.
>>
>> “Completely” as in “having nothing in common”? Or is this some usage of
>> “completely” that I wasn’t aware of?
>>
>> Please explain.
> 
> Templates in C++ are basically advanced macros--each invocation of a
> template type regenerates the class, so a Foo<int> and a Foo<double> are
> two completely different things.

They are different things in Java as well. The only time they become the 
same thing is in “erasures” and “raw types”, which are backward-
compatibility mechanisms introduced to avoid breaking existing code that 
doesn’t know about generics. The use of the name “Foo” without parameters is 
explicitly deprecated, with a bold warning that says it may go away in the 
future, you have been warned.

And then, of course, the language goes on to use exactly that deprecated 
syntax as the recommended way of accessing static members.

(Exercise for the reader: it turns out there’s another way of accessing 
static members. But that’s deprecated as well. What is it?)

> Generics in Java are basically compile-time syntactic sugar to ensure
> type-safety of container types at compile time instead of waiting until
> you hit the code at runtime to get that dreaded ClassCastException.

Same sort of thing in C++.

> About the only thing they share in common is the syntax ...

Yeah, funny that. If Java didn’t want to be seen as copying C++, why did it 
reuse exactly the same syntax?

On Sun, 06 Feb 2011 15:24:27 +1300, Lawrence D'Oliveiro wrote:

> In message <2011020510425674637-angrybaldguy@gmailcom>, Owen Jacobson
> wrote:
> 
>> This is an extremely dubious measure of complexity. The Common Lisp
>> specification is over a thousand pages long in some editions*, but Lisp
>> is generally considered a much simpler language than either C++ or
>> Java.
> 
> Really? By whom?
> 
> There seem to be an awful lot of language mechanisms in current LISP
> dialects, e.g. multiple-value returns as distinct from lists of values,
> which is a distinction that has no analogue in other languages. Add in
> all that, and the resulting language cannot be described as “simple”.

There's recently been a flamewar in comp.lang.lisp about that. Common 
Lisp is indeed not simple, but it did spring from simple roots, and some 
other lisps haven't gotten that complicated.

Here is a common way in Clojure to do multiple return:

(defn polar-to-rect [r theta]
  [(* r (Math/cos theta)) (* r (Math/sin theta))])

(let [[x y] (polar-to-rect foo bar)]
  (do-something-with-x-and-y))

You just bundle the results in a list or vector and return that; callers 
can use sequence operations on the return or destructure it as above. 
It's only common to use vectors instead of lists because it's a little 
shorter and more readable than

(defn polar-to-rect [r theta]
  (list (* r (Math/cos theta)) (* r (Math/sin theta))))

but destructuring would work with that too. There's no special syntax or 
special types involved; just existing syntax (such as (list ...) and 
vector literals and destructuring) and existing types (lists, vectors) 
that are used all over the place for other things too.

In that flamewar, someone estimated the size of Clojure's documentation 
by browsing its website and counting pagedown keypresses needed to reach 
the bottom of each web page. Someone else had posted a list of language 
specification sizes in pages that predated Java and Clojure; Common Lisp 
was at the top with over 1000 pages and Scheme was near the bottom with 
50, with C and C++ in between. Later posters added the size of the JLS, I 
think it was near 300, and then someone counted Clojure's documentation 
pages, roughly, and got a number just under 200, while pointing out that 
including all of Java's java.* and javax.* API docs would make Java's 
specification easily dwarf all of the others, including Common Lisp, and 
maybe Wikipedia and Library of Congress too. Cue argument about the size 
in pages of the documentation not being a sole indicator of complexity -- 
for example, the C and Common Lisp specifications both allow a lot of 
undefined and implementation-defined behavior while the JLS specifies 
almost everything, so the JLS arguably gets more bang for its page-count 
buck, or arguably represents something simpler (specified in more detail) 
than its page size would indicate.

I wonder if the size of a reference implementation would be a better 
indication. JVM + javac vs. gcc vs. whatever, as binaries, on the same 
platform, how many megabytes. Of course hosted languages get penalized -- 
the complexity of Scala or Clojure will automatically be bigger than that 
of Java because it rides piggyback on Java, running on the JVM and 
relying on Java libraries heavily. Another complication would be 
optimization; gcc might make C look a lot more complex than it is because 
it has code targeting many platforms, and many sophisticated optimization 
features. Size of a minimalist compiler or even a naive interpreter could 
be a better indication. Size of a grammar description would go too far 
the other way; every Lisp will handily win (with Scheme winning among 
Lisps) simply for lacking much syntax and having the semantic layer do 
more of the heavy lifting. Then again they may not win undeservedly; the 
more is moved out of prespecified syntactic constructs and into 
functions, macros, and other stuff written in the language itself, the 
more flexible and extensible the language is and the simpler its core 
generally is. Another big question: include standard library size, or no? 
Or just a certain set of functionality -- basic system types like 
strings, host interop, and core I/O and collections classes, say, but 
leave out things like Swing and JDBC and other languages' equivalents 
where present and standardized.

There does seem to me to be a rough spectrum of languages based on how 
much grammar they have versus how much is vocabulary instead, for core 
behavior and control constructs. I can identify four broad categories 
there:

1. Very small syntax cores: Lisp, Smalltalk. To a lesser extent, Haskell,
   ML and friends. Few operator symbols or keywords.
2. Algol-like syntaxes (in size and basic structure, forming procedural
   code blocks): C, C++, Java, Pascal, and most other mainstream
   languages. Many specially-defined keywords and operator symbols.
3. Baroque syntaxes that try to approximate natural language; TONS of
   keywords and many operator symbols: BASIC and COBOL.
4. Baroque syntaxes that don't try to approximate natural language and
   instead aim for terseness; TONS of operators: Perl, Ruby.

There is necessarily some fuzziness. Shell lies between 3 and 4, on the 3 
side of the middle. Perl was a solid 4 but later revisions have added 
more structured, 3-like elements so it's moved toward shell from the 
other side. C++ shades towards 4 from 2, especially in codebases that 
heavily use operator overloading. Common Lisp shades towards 4 from *1* 
when reader macros are used heavily; on the other hand its "loop" macro 
shades towards 3! Python sits almost square on the 3/4 divide and always 
has. Joke languages always tend to an extreme: INTERCAL is a 3, Brainfuck 
is clearly a 4 with some traces of 2, and Malbolge is as solid a 4 as is 
even theoretically possible. Actual, pragmatic machine languages 
(including JVM bytecode) are generally 4s as binary code and somewhat 
3ish as assembly, lacking the block structures of the 2s.

There's another way those categories make sense: 3 and 4 are generally 
imperative, and 2 is imperative with block structure and, generally, 
classes or some similar feature. 1 is mainly functional, with the major 
exception of Smalltalk, which despite its small syntax core is more 
firmly object oriented than Java is. What all group-1 languages have in 
common that enables the small syntax core is that they have a syntax for 
anonymous lambdas and had it from the get-go; the functional languages 
tend to collect in this category for that reason.

The most versatile syntax here may well be Python's, because out of the 
box it supports writing fairly C-like code with recognizable blocks, or 
Lispy-looking functional code (modulo foo.bar(baz) and f(x) and 1 + 2 
rather than (bar foo baz) and (f x) and (+ 1 2)) using lambdas and 
comprehensions, or imperative scripts with little block structure more 
reminiscent of typical COBOL and BASIC code from the 70s and 80s, or even 
Perlesque code. Common Lisp (with reader macros) also lets you generate 
all of these, but you'll have to work harder at it since the default 
library of functions and macros available pulls you heavily towards Lispy 
code (duh) and you'll have to write your own macros to produce the syntax 
for the other three styles. On the other hand, Lisps let you go the 
furthest in that direction, even as far as making (emulate-my-fictitious-
cpu 9D FF 00 00 1B 3C ...) be valid code. :)

An interesting fact is that you'll get strong partisans for languages of 
all four kinds: Lisps (obviously), Java, C, and C++ (obviously), BASIC 
(as a teaching tool), and Perl and (again as a teaching tool so you know 
what the hardware eventually sees after gcc has done its thing) machine 
languages.

Back to the complexity question: again, it depends. Obviously the syntax 
(and human effort required deciphering it) grows from 1 up to 4, but code 
readability takes a big hit at 3 (home of infamous spaghetti code and 
COBOL) and goes right out the window at 4 (home of stuff we now mainly 
deal with at arm's length, through compilers, and Brainfuck, Perl, and 
Malbolge). :) On the other hand 1 usually requires wrapping your head 
around the functional paradigm and familiarizing yourself with a large 
library of generic functions. This may be why the 2 languages are the 
most popular application languages, containing these particular four that 
have been big juggernauts and resume must-haves in recent years: Pascal, 
C, C++, and Java. They strike a balance between too little structure in 
code block nesting (3 and 4) and too much there for most people (1).

Ultimately, though, the language syntax complexity mostly doesn't matter 
until it gets complicated enough, or edge cases you need to refer to the 
spec or consult a language lawyer about get common enough, for it to 
really get in your way *cough*Perl*cough*. (Abusing C++ operator 
overloading or Lisp macros, especially reader macros, can lead to such 
problems in specific codebases, too.)

The size of the library, and especially the portion of it you must learn 
to both get practical things done and understand most existing code with 
only occasional lookups of (mostly) third-party calls, is much more 
important, and the expressiveness.

Java's primary weakness is lack of expressiveness; it has trouble with 
proliferation of boilerplate code and accompanying rituals to ward off 
race conditions, leaking I/O handles when exceptions are thrown, 
consuming XML configuration files, and so forth.

Lisps, and even some 4 languages like Perl, have the opposite weakness: 
so many ways to do the same thing that code with the same purpose from 2 
different authors can look very different. (The Clojure community has 
tried to avoid this pitfall in their Lisp by encouraging particular 
idiomatic ways to do things; e.g., preferring higher order functions to 
the low-level loop and lazy-seq macros, using vector literals rather than 
list literals for macro arguments that are treated as data rather than 
instructions, so parenthesized lists (x y z) tend to mean "do x to y and 
z"; avoiding macros that are "syntaxy" (like Common Lisp's loop macro) or 
attach fixed meanings to symbols (again like CL's loop macro); and so on.

The maintainer is burdened there by having to deal with a much wider 
variety of ways to do a given task, thus much more to learn to understand 
code others have written to do that task.

The really inflexible 3 languages are basically dead. The only surviving 
forms of BASIC and COBOL have added block structuring and other syntactic 
features to mimic the 2 languages and are 2s rather than 3s now. Assembly 
remains in widespread use -- by machines. Hardly anyone manually writes 
asm anymore, not since the optimizing compilers got good enough.

And the 4 languages, excluding jokes like Malbolge, have also moved 
towards the 2 languages, Perl most notably.

The interesting thing is which of 1 or 2 is "better"? The answer, 
disturbingly I am sure for many of you, may be 1. Consider that Java has 
been steadily encroaching on C and C++ for some time now; soon the latter 
two might be primarily used to write a) operating systems, b) device 
drivers, and c) a port of the JVM to a given platform. :) The growth is 
in C#/.NET, Java, and (for the iFoo devices) ObjectiveC. (ObjectiveC may 
eventually, improbable as it may have seemed even five years ago, finally 
upset the seemingly-inevitable C++ victory among object-oriented C 
variants because of that little music player Apple started selling that 
turned the world upside down -- imagine that!) Of these, Java is very 
widely used for network and business applications, and web apps, these 
days -- and it's considering adding closures, the key feature of the 1 
languages. Fast forward a decade or two to when there's a mature, widely 
used library of closure-based control structures and the typical Java 
codebase of that time could resemble Haskell more than it does present-
day Java code if they're used heavily in preference to the familiar fors, 
whiles, and ifs, mapping and reducing over collections to generate return 
values in a single expression.

In reality, Java's static types and checked exceptions will throw a fair 
amount of syntactic salt into this, barring a hefty (and again Haskell-
like) infusion of type inference. Java could lose out in the long run to 
JVM hosted languages designed to be functional from the ground up. Of 
these the frontrunners seem to be Clojure and Scala, with Scala's non-
Lispy syntax giving it an edge in familiarity (and especially with 
management) and Clojure's macros (and consequent ability to reify 
boilerplate patterns into things you can name and call and not 
reimplement over and over again) giving it an edge in expressivity.

Both are gaining traction even with management types, especially when 
stuff coded in them can be bundled into jars and deployed on application 
servers in a manner identical to deploying Java code. It doesn't look or 
feel any different to management than deploying Java; the coders are 
pushing different symbols around in their text editors and IDEs but 
they're still using IDEA or NetBeans or Eclipse and still producing .jar 
files that behave the same way when put on the server. So if the coders 
are typing stuff that looks incomprehensible in a different way than it 
did before, and seem a bit happier, and are suddenly making their 
deadlines instead of missing them, and nothing has stopped working or 
started working differently at a level management notices, management 
won't rock the boat. At most they'll want to be assuaged about 
intellectual property rights, mainly that a) the company still owns its 
code and b) they aren't going to get sued for using this stuff. Both 
languages in question have, if anything, less stringent license 
requirements than Java itself.

This may be one technology battle, then, where the technological merits 
themselves may actually trump politics for once. If so, it's not looking 
good for Java, but it's looking positively rosy for the JVM and even Java 
libraries. FP offers some advantages over OOP, especially in the highly 
concurrent environment of server processes. We could soon be looking at a 
divide between three sets of languages used by most human coders:

1. Objective C on the iFoo devices, until competition from Android forces
   Apple to open up the platform or makes the platform irrelevant.
2. C/C++ and even Delphi and Pascal will totter on for a while on open
   platforms, and C will remain a solid language for OS kernel, device
   driver, and VM implementation. Other languages running on bare metal or
   on non-CLR-or-JVM virtual machines will remain also-rans, including
   Eiffel (metal), Smalltalk (VM), and Lisps (both). Note, versions that
   run on the JVM have a rosier future if they can call Java libraries.
   On the scripting language front, Python, Perl, and Ruby will totter on
   for some time, especially when running on the JVM. Python's doomed to
   irrelevancy long term by poor performance, the global interpreter lock,
   and Clojure, which is also in a position to seriously challenge Ruby.
   Perl will retain use in heavily text-oriented tasks, and shell for
   that matter will retain use among unix sysadmins. Nobody else will find
   much use for either.
3. JVM hosted languages, being more widely supported (and running on
   a lot of smartphones!), should beat out .NET/CLR-hosted languages in
   the long run. Any that can easily call into Java libraries and allow
   easy deployment in a manner that's fairly transparently like deploying
   normal Java will find niches, and one or both of Clojure and Scala look
   to come out on top. JPython and JRuby will be also-rans in this race,
   completely devastated by Clojure in particular. Java itself will
   persist as the language used to implement a) Clojure and Scala and b)
   libraries meant to be as broadly useful as possible, so callable from
   both and from Java itself, and sometimes for c) performance-critical
   code. (Yes -- Java may be relegated partly to the role of writing the
   most performance-critical inner loops of applications! That's a big
   reversal from when Java was slow and C would be used to write the most
   performance-critical inner loops of Java applications.)

I can make a few further predictions; one is that someone will eventually 
produce a Smalltalk that compiles to JVM bytecodes -- it should actually 
be possible to implement Smalltalk on top of Clojure(!) efficiently -- 
though I don't know how much usage it would see, and another is that we 
will probably eventually see an "emacs killer" emerge that gains traction 
with people that cut their teeth first on GUI/CUA systems and never could 
get used to emacs's way of doing things, and has comparable features and 
extensibility. It will probably be JVM-hosted rather than bare metal and 
stands a good chance of being derived in some way from NetBeans or 
Eclipse. Jokes will be made about a kitchen-sink approach and about 
memory and pagefile usage, even if the JVMs of the time are not quite as 
memory-hogging as current JVMs.

What does all of this have to do with language simplicity? I'm not sure. 
But the combo of the JVM abstracting aspects of the host environment and 
setting uniform data type size standards and the existence of large, 
generified libraries for the platform make it likely that the simplicity 
wars, particularly, will be won by a functional language hosted on the 
JVM. :)

On 02/05/2011 11:13 PM, Lawrence D'Oliveiro wrote:
> They are different things in Java as well.

The hell they aren't. In Java, there is only one instance of 
LinkedList::add(T object). In C++, there are as many instances of 
std::list<T>::front as times you use it.

Try, for example, implementing both List<String> and List<Character> in 
the same class. Java will tell you that you cannot do it. C++, on the 
other hand, wouldn't bat an eye.

> The only time they become the
> same thing is in “erasures” and “raw types”, which are backward-
> compatibility mechanisms introduced to avoid breaking existing code that
> doesn’t know about generics.

I think Java would likely have gone with much the same syntax even if 
generics had been introduced in the beginning.

> And then, of course, the language goes on to use exactly that deprecated
> syntax as the recommended way of accessing static members.

It's not the same syntax. List<String> is the type of a specific 
instance, while the class still remains List.

>> About the only thing they share in common is the syntax ...
>
> Yeah, funny that. If Java didn’t want to be seen as copying C++, why did it
> reuse exactly the same syntax?

Propose a different syntax for Java generics. Note that it cannot be 
syntactically ambiguous with any other Java construct, and that, since 
it will be used a fair amount, it must be on the shorter side. There 
aren't many characters you can really use; < and > are about the only 
thing that fits the bill.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On 02/05/2011 11:06 PM, Lawrence D'Oliveiro wrote:
> It seems to me that’s another drawback of Java, that it explicitly defines
> the sizes of things from the viewpoint of 32-bit architectures like those
> current in the 1990s. Some of those decisions look less wonderful on current
> 64-bit architectures.

I would venture a guess that most C or C++ code isn't as easily portable 
to 64-bit platforms as you would think, since people make assumptions 
about the sizes of various types. If you don't define de jure type 
sizes, people will follow the de facto standards (i.e., 32-bit) and will 
then get horrible breakages when the platform it runs on does not match 
the standards.

Also, I might add, the main benefit 64-bit holds right now is the 
increased access to memory space, i.e., 64-bit addressability of 
pointers. Since Java does not let you manipulate pointer addresses 
directly, the implementation is easily able to adjust the size of an 
Object pointer and still conform to the specification. So you basically 
get access to as much memory as your host will allow without the messy 
bits about the size of integral operands being essentially undefined.

> Not quite so “well-written, easily-understood”, as I have pointed out
> elsewhere. The mistakes seem particularly concentrated in the parts
> describing the newer language features.

If you think it is so difficult to understand, you must not have voyaged 
deeply into the world of specifications. Java is easily understandable 
compared to some of the stuff I've read.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Lew wrote:
>> C++ doesn't have generics. It has templates. They aren't the same thing.
>>
>> C# has generics. Java has (different) generics. C++ doesn't.
>>
>> Lawrence is trolling.

Silvio wrote:
> Hello Lew,
>
> You are correct, templates are a completely different thing. However, since
> they try to achieve a similar goal (albeit in very different ways) they are
> often compared and spoken of in combination.
>
> I suspected he is trolling also but could not resist correcting a false
> statement.

That's funny, because the statement wasn't false and you didn't correct it. 
You even said it was correct.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

On 02/06/2011 06:15 AM, Lew wrote:
> Lew wrote:
>>> C++ doesn't have generics. It has templates. They aren't the same thing.
>>>
>>> C# has generics. Java has (different) generics. C++ doesn't.
>>>
>>> Lawrence is trolling.
>
> Silvio wrote:
>> Hello Lew,
>>
>> You are correct, templates are a completely different thing. However,
>> since
>> they try to achieve a similar goal (albeit in very different ways)
>> they are
>> often compared and spoken of in combination.
>>
>> I suspected he is trolling also but could not resist correcting a false
>> statement.
>
> That's funny, because the statement wasn't false and you didn't correct
> it. You even said it was correct.
>

Lawrence said "C++ had this from the beginning" referring to Java having 
added generics afterwards. That was a false statement.

I pointed out that in C++ this was also a later addition. I just made 
the mistake of referring to templates as generics.

On 02/06/2011 05:06 AM, Lawrence D'Oliveiro wrote:
> In message<iijrj2$i0g$1@news.eternal-september.org>, Joshua Cranmer wrote:
>
>> My copy of the C++0x draft reference standard, i.e. the copy sent out
>> for a ballot by national bodies, consisted of no fewer than 1300
>> numbered pages.
>
> Yeah, so C++ continues to leap ahead into even greater complexity.
>
>> Also take into consideration the fact that the C++ standard does not try
>> to pin stuff down into unambiguous interoperable statements, e.g., a
>> precise size definition for size_t.
>
> It seems to me that’s another drawback of Java, that it explicitly defines
> the sizes of things from the viewpoint of 32-bit architectures like those
> current in the 1990s. Some of those decisions look less wonderful on current
> 64-bit architectures.
>
>> So 684 pages of well-written, easily-understood text ...
>
> Not quite so “well-written, easily-understood”, as I have pointed out
> elsewhere. The mistakes seem particularly concentrated in the parts
> describing the newer language features.

Oh, I remember how well C++ and its undefined sizes of things served us 
when we had to port heaps of code from 16-bit to 32-bit.

On 11-02-06 12:39 AM, Ken Wesson wrote:
[ SNIP good overview ]

> In reality, Java's static types and checked exceptions will throw a fair
> amount of syntactic salt into this, barring a hefty (and again Haskell-
> like) infusion of type inference. Java could lose out in the long run to
> JVM hosted languages designed to be functional from the ground up. Of
> these the frontrunners seem to be Clojure and Scala, with Scala's non-
> Lispy syntax giving it an edge in familiarity (and especially with
> management) and Clojure's macros (and consequent ability to reify
> boilerplate patterns into things you can name and call and not
> reimplement over and over again) giving it an edge in expressivity.
>
> Both are gaining traction even with management types, especially when
> stuff coded in them can be bundled into jars and deployed on application
> servers in a manner identical to deploying Java code. It doesn't look or
> feel any different to management than deploying Java; the coders are
> pushing different symbols around in their text editors and IDEs but
> they're still using IDEA or NetBeans or Eclipse and still producing .jar
> files that behave the same way when put on the server. So if the coders
> are typing stuff that looks incomprehensible in a different way than it
> did before, and seem a bit happier, and are suddenly making their
> deadlines instead of missing them, and nothing has stopped working or
> started working differently at a level management notices, management
> won't rock the boat. At most they'll want to be assuaged about
> intellectual property rights, mainly that a) the company still owns its
> code and b) they aren't going to get sued for using this stuff. Both
> languages in question have, if anything, less stringent license
> requirements than Java itself.
[ SNIP ]

I'm currently pushing Scala (nothing against Clojure really, I am just 
considerably more familiar with Scala) quietly, in-house and also on 
some client projects, with similar thinking in mind. It _is_ a fact that 
management truly doesn't care that this chunk of opcodes was originally 
Java source, and that other chunk of opcodes was originally Scala 
source. If a project development team can incrementally introduce user 
libraries into a Java EE environment that happen to be written in Scala, 
and they are developed faster and we end up with more reliable code, 
nobody is going to complain.

AHS
-- 
We must recognize the chief characteristic of the modern era - a 
permanent state of what I call violent peace.
-- James D. Watkins

On 11-02-06 12:06 AM, Lawrence D'Oliveiro wrote:
> In message<iijrj2$i0g$1@news.eternal-september.org>, Joshua Cranmer wrote:
>
>> My copy of the C++0x draft reference standard, i.e. the copy sent out
>> for a ballot by national bodies, consisted of no fewer than 1300
>> numbered pages.
>
> Yeah, so C++ continues to leap ahead into even greater complexity.
>
>> Also take into consideration the fact that the C++ standard does not try
>> to pin stuff down into unambiguous interoperable statements, e.g., a
>> precise size definition for size_t.
>
> It seems to me that’s another drawback of Java, that it explicitly defines
> the sizes of things from the viewpoint of 32-bit architectures like those
> current in the 1990s. Some of those decisions look less wonderful on current
> 64-bit architectures.
>
>> So 684 pages of well-written, easily-understood text ...
>
> Not quite so “well-written, easily-understood”, as I have pointed out
> elsewhere. The mistakes seem particularly concentrated in the parts
> describing the newer language features.

You haven't actually pointed out any mistakes. Now, if your intent is to 
point out parts of the JLS that you find hard to understand, and your 
argument is that if _you_ are having problems then so are many others, 
then a more productive approach would be (1) to phrase it that way, and 
(2) offer a suggestion or two that you think is better. But you haven't 
located any flat-out mistakes yet.

I find the various versions of the JLS to be considerably better than 
most other language or API specs I've had to wade through.

AHS

-- 
We must recognize the chief characteristic of the modern era - a 
permanent state of what I call violent peace.
-- James D. Watkins

On 05-02-2011 23:06, Lawrence D'Oliveiro wrote:
> In message<iijrj2$i0g$1@news.eternal-september.org>, Joshua Cranmer wrote:
>> Also take into consideration the fact that the C++ standard does not try
>> to pin stuff down into unambiguous interoperable statements, e.g., a
>> precise size definition for size_t.
>
> It seems to me that’s another drawback of Java, that it explicitly defines
> the sizes of things from the viewpoint of 32-bit architectures like those
> current in the 1990s. Some of those decisions look less wonderful on current
> 64-bit architectures.

There are nothing in defining the size of the simple data types
that are tied to 32 bit architecture.

Why shoudl 8, 16, 32 and 64 bit integers be more 32 bit than
64 bit centric??

>> So 684 pages of well-written, easily-understood text ...
>
> Not quite so “well-written, easily-understood”, as I have pointed out
> elsewhere. The mistakes seem particularly concentrated in the parts
> describing the newer language features.

As far as I have seen all your so called mistakes is not problems
in the JLS but you not understanding the text, because you have
started reading the JLS without starting with a very basic tutorial
about Java.

Arne

On 06-02-2011 00:08, Joshua Cranmer wrote:
> On 02/05/2011 11:06 PM, Lawrence D'Oliveiro wrote:
>> It seems to me that’s another drawback of Java, that it explicitly
>> defines
>> the sizes of things from the viewpoint of 32-bit architectures like those
>> current in the 1990s. Some of those decisions look less wonderful on
>> current
>> 64-bit architectures.
>
> I would venture a guess that most C or C++ code isn't as easily portable
> to 64-bit platforms as you would think, since people make assumptions
> about the sizes of various types. If you don't define de jure type
> sizes, people will follow the de facto standards (i.e., 32-bit) and will
> then get horrible breakages when the platform it runs on does not match
> the standards.

My guess is that most portable C/C++ not using the C99 typedefs
have their own similar ifdef'ed typedefs.

Arne

On 06-02-2011 08:34, Arved Sandstrom wrote:
> I'm currently pushing Scala (nothing against Clojure really, I am just
> considerably more familiar with Scala) quietly, in-house and also on
> some client projects, with similar thinking in mind. It _is_ a fact that
> management truly doesn't care that this chunk of opcodes was originally
> Java source, and that other chunk of opcodes was originally Scala
> source. If a project development team can incrementally introduce user
> libraries into a Java EE environment that happen to be written in Scala,
> and they are developed faster and we end up with more reliable code,
> nobody is going to complain.

Scala is doing pretty well.

It seems to be by far the most successful functional language.

Among publicly know Scala users are the British newspaper
Guardian and EDF Trading.

Arne

Joshua Cranmer wrote:
> On 02/05/2011 10:38 PM, Lawrence D'Oliveiro wrote:
>> In message<4d4d8322$0$41117$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>
>>> And Lew is correct: templates and genercis are completely different
>>> beasts.
>>
>> “Completely” as in “having nothing in common”? Or is this some usage of
>> “completely” that I wasn’t aware of?
>>
>> Please explain.
> 
> Templates in C++ are basically advanced macros--each invocation of a 
> template type regenerates the class, so a Foo<int> and a Foo<double> are 
> two completely different things.

That's much more than a macro could do. Templates are a language of its 
own, include syntax checks, etc. Quite unlike macros, they do not 
substitute text patterns. Templates allow meta-programming, i.e. you can 
use the compiler to generate code. And, of course, templates are quite 
complex - very unlike the simple-minded preprocessor.

> Generics in Java are basically compile-time syntactic sugar to ensure 
> type-safety of container types at compile time instead of waiting until 
> you hit the code at runtime to get that dreaded ClassCastException.

Well, java had to take the route of type-erasure to allow generic 
progamming plus type checks because it wasn't part of the language to 
begin with, so it was "hacked" into the specs more or less. Generics are 
considerably less powerful, but also considerably easier than C++ 
templates. There's no metaprogramming with generics, and generics are 
mostly limited to containers which does not hold for C++ templates. They 
are quite different.

> About the only thing they share in common is the syntax, and even then, 
> C++ didn't allow A<B<C>> until C++0x (which, according to Bjarne 
> Stroustroup, took a bit of work to convince compiler vendors to accept).

I beg your pardon? C++ allows nested templates since C++99 and before. 
The only issue here is a notational one, namely that you had to write 
A<B<C> > (note the space behind B<C>) to avoid >> being parsed as a 
token (shifting, namely). That is the only thing that got fixed in 
C++0x, not nesting templates which is part of the language since C++99.

Joshua Cranmer wrote:
> On 02/05/2011 11:13 PM, Lawrence D'Oliveiro wrote:
>> They are different things in Java as well.
> 
> The hell they aren't. In Java, there is only one instance of 
> LinkedList::add(T object). In C++, there are as many instances of 
> std::list<T>::front as times you use it.

I would say that's an implementation detail. A compiler/optimizer could 
check how many different implementations are needed and could merge 
those that are identical.

Besides that, where you use an object in java, one would use a pointer 
or a reference in C++, and hence the code would be identical, allowing a 
good compiler to merge the implementations. C++ and java are quite 
different in their tradition how to use types, or what types are. Java 
has two sorts of types: First class citizens like int or double that are 
copied, and second class citizens like classes that are referenced. C++ 
doesn't have that, objects are objects and ints and classes are handled 
alike.

> Try, for example, implementing both List<String> and List<Character> in 
> the same class. Java will tell you that you cannot do it. C++, on the 
> other hand, wouldn't bat an eye.

True.

>> The only time they become the
>> same thing is in “erasures” and “raw types”, which are backward-
>> compatibility mechanisms introduced to avoid breaking existing code that
>> doesn’t know about generics.
> 
> I think Java would likely have gone with much the same syntax even if 
> generics had been introduced in the beginning.

That's really a speculation. One could also speculate that if java would 
have used or required generics from the beginning, they would be closer 
to C++ templates and would not use type erasure; instead, they would be 
parametrized classes as they are in C++. It's really speculation.

Greetings,

	Thomas

"Thomas Richter" <thor@math.tu-berlin.de> wrote in message 
news:iimf47$soo$1@news.belwue.de...
>
> I beg your pardon? C++ allows nested templates since C++99 and before. The 
> only issue here is a notational one, namely that you had to write A<B<C> > 
> (note the space behind B<C>) to avoid >> being parsed as a token 
> (shifting, namely). That is the only thing that got fixed in C++0x, not 
> nesting templates which is part of the language since C++99.

This surprises me.  Given all the difficult parsing needed to make sense of 
C++, it seems like this small bit of lexical analysis should never have been 
a sticking point. 

Silvio wrote:
>>> I suspected he is trolling also but could not resist correcting a false
>>> statement.

Lew wrote:
>> That's funny, because the statement wasn't false and you didn't correct
>> it. You even said it was correct.

Silvio wrote:
> Lawrence said "C++ had this from the beginning" referring to Java having added
> generics afterwards. That was a false statement.
>
> I pointed out that in C++ this was also a later addition. I just made the
> mistake of referring to templates as generics.

Oh - *that* false statement.  Yes, you were right to correct it.

C++ has never had generics, and it did not have templates from the beginning. 
  You are right.

I am convinced that "Lawrence" is a troll.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

On 02/06/2011 10:35 AM, Thomas Richter wrote:
> Joshua Cranmer wrote:
>> Templates in C++ are basically advanced macros--each invocation of a
>> template type regenerates the class, so a Foo<int> and a Foo<double>
>> are two completely different things.
>
> That's much more than a macro could do. Templates are a language of its
> own, include syntax checks, etc. Quite unlike macros, they do not
> substitute text patterns. Templates allow meta-programming, i.e. you can
> use the compiler to generate code. And, of course, templates are quite
> complex - very unlike the simple-minded preprocessor.

It is the code generation that I'm referring to as "an advanced macro". 
It's a macro generator that understands types and is heavily integrated 
with the syntax of C++, but it is basically a way to automatically 
generate code.

> I beg your pardon? C++ allows nested templates since C++99 and before.
> The only issue here is a notational one, namely that you had to write
> A<B<C> > (note the space behind B<C>) to avoid >> being parsed as a
> token (shifting, namely). That is the only thing that got fixed in
> C++0x, not nesting templates which is part of the language since C++99.

I was specifically referring to the ability to use >> instead of > >.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On 02/06/2011 11:11 AM, Mike Schilling wrote:
>
>
> "Thomas Richter" <thor@math.tu-berlin.de> wrote in message
> news:iimf47$soo$1@news.belwue.de...
>>
>> I beg your pardon? C++ allows nested templates since C++99 and before.
>> The only issue here is a notational one, namely that you had to write
>> A<B<C> > (note the space behind B<C>) to avoid >> being parsed as a
>> token (shifting, namely). That is the only thing that got fixed in
>> C++0x, not nesting templates which is part of the language since C++99.
>
> This surprises me. Given all the difficult parsing needed to make sense
> of C++, it seems like this small bit of lexical analysis should never
> have been a sticking point.

When Bjarne Stroustrup gave a talk about C++0x to my university, one of 
the things he said was it took him several tries to get the compiler 
vendors to agree to support that minor lexical analysis. The only way he 
could convince them to do it was to point out that all the major 
compilers basically had an error message in that case which said "add a 
space, idiot", so all they had to do was remove that error message.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

We could end this entire thread right now by conceding that, yes, C++ is 
clearly the superior language over Java, just like Esperanto is over English, 
unless, of course, you actually want to accomplish something, but all 
analogies break down somewhere, right?

Anyway, just tell the OP that he's right, C++ is wonderful and Java is crap, 
and all those thousands more Java jobs out there can go to those of us 
impurists.  C++ invented everything and Java is a poor stepchild, and if 
imitation is the sincerest form of flattery then Java just gave C++ the 
finger.  He's right, we're wrong - he need learn nothing new and we praise him 
with angels' song and rose petals.

C++ rules, Java drools!

Can we stop talking about C++ now?  You know it only makes us poor 
stepchildren embarrassed and to feel clumsy, contemplating how much worse our 
language of choice is than the One True Way, so stop rubbing our noses in it, 
please.  Let's just talk about Java as Java so we may be shielded from the 
blinding light of knowledge of our insignificance compared to those of the C++ 
world.  Leave us benighted souls to our dark Java Hades and burn us not with 
the C++ Sun!

Again, C++ rules, Java drools!  Done.  QED.  You win.  Move on.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

"Joshua Cranmer" <Pidgeot18@verizon.invalid> wrote in message 
news:iimnil$dh2$2@news.eternal-september.org...
> On 02/06/2011 11:11 AM, Mike Schilling wrote:
>>
>>
>> "Thomas Richter" <thor@math.tu-berlin.de> wrote in message
>> news:iimf47$soo$1@news.belwue.de...
>>>
>>> I beg your pardon? C++ allows nested templates since C++99 and before.
>>> The only issue here is a notational one, namely that you had to write
>>> A<B<C> > (note the space behind B<C>) to avoid >> being parsed as a
>>> token (shifting, namely). That is the only thing that got fixed in
>>> C++0x, not nesting templates which is part of the language since C++99.
>>
>> This surprises me. Given all the difficult parsing needed to make sense
>> of C++, it seems like this small bit of lexical analysis should never
>> have been a sticking point.
>
> When Bjarne Stroustrup gave a talk about C++0x to my university, one of 
> the things he said was it took him several tries to get the compiler 
> vendors to agree to support that minor lexical analysis. The only way he 
> could convince them to do it was to point out that all the major compilers 
> basically had an error message in that case which said "add a space, 
> idiot", so all they had to do was remove that error message.

Like when you call a 9-digit number and the phone tells you that you need to 
dial a 1 first. 

Arne Vajhøj wrote:
> On 05-02-2011 23:06, Lawrence D'Oliveiro wrote:
>> In message<iijrj2$i0g$1@news.eternal-september.org>, Joshua Cranmer 
>> wrote:
>>> Also take into consideration the fact that the C++ standard does not try
>>> to pin stuff down into unambiguous interoperable statements, e.g., a
>>> precise size definition for size_t.
>>
>> It seems to me that’s another drawback of Java, that it explicitly 
>> defines
>> the sizes of things from the viewpoint of 32-bit architectures like those
>> current in the 1990s. Some of those decisions look less wonderful on 
>> current
>> 64-bit architectures.
> 
> There are nothing in defining the size of the simple data types
> that are tied to 32 bit architecture.

I am aware of one issue in the simple data types that reflects 32 bit
architecture, JLS section 17.7, "Non-atomic Treatment of double and long".

The big way in which Java is tied to 32 bit architectures is not in the
simple data types. It is the maximum size of an array, String, Set, List
etc.

Patricia

Joshua Cranmer wrote
>>> When Bjarne Stroustrup gave a talk about C++0x to my university, one of the
>> things he said was it took him several tries to get the compiler vendors to
>> agree to support that minor lexical analysis. The only way he could convince
>> them to do it was to point out that all the major compilers basically had an
>> error message in that case which said "add a space, idiot", so all they had
>> to do was remove that error message.

Mike Schilling wrote:
> Like when you call a 9-digit number and the phone tells you that you need to
> dial a 1 first.

Or, in the US, the same thing for a 10-digit number.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

Patricia Shanahan wrote:
> The big way in which Java is tied to 32 bit architectures is not in the
> simple data types. It is the maximum size of an array, String, Set, List
> etc.

I wouldn't say "tied to a 32-bit architecture" but "subject to a 32-bit 
limitation".  The limitation for Java is the same on any architecture.  But I 
take your meaning.

It is possible with current Java implementations to write a collection like 
List that is not subject to the 32-bit limit, so arguably the fault for the 
java.util.List limit lies not with Java itself but the API.

It would require a language change to implement an array with 
larger-than-32-bit addressing, but the use case for that is narrow enough that 
an API construct should serve, obviating the need for a language change.

At least for a while.  I imagine that once we are unphased by exbibyte RAM 
structures we can change the language.

Assuming the world hasn't all switched over to C++ by then.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

"Lew" <noone@lewscanon.com> wrote in message 
news:iimscd$vun$2@news.albasani.net...
> Joshua Cranmer wrote
>>>> When Bjarne Stroustrup gave a talk about C++0x to my university, one of 
>>>> the
>>> things he said was it took him several tries to get the compiler vendors 
>>> to
>>> agree to support that minor lexical analysis. The only way he could 
>>> convince
>>> them to do it was to point out that all the major compilers basically 
>>> had an
>>> error message in that case which said "add a space, idiot", so all they 
>>> had
>>> to do was remove that error message.
>
> Mike Schilling wrote:
>> Like when you call a 9-digit number and the phone tells you that you need 
>> to
>> dial a 1 first.
>
> Or, in the US, the same thing for a 10-digit number.

That too. 

On 06-02-2011 13:55, Patricia Shanahan wrote:
> Arne Vajhøj wrote:
>> On 05-02-2011 23:06, Lawrence D'Oliveiro wrote:
>>> In message<iijrj2$i0g$1@news.eternal-september.org>, Joshua Cranmer
>>> wrote:
>>>> Also take into consideration the fact that the C++ standard does not
>>>> try
>>>> to pin stuff down into unambiguous interoperable statements, e.g., a
>>>> precise size definition for size_t.
>>>
>>> It seems to me that’s another drawback of Java, that it explicitly
>>> defines
>>> the sizes of things from the viewpoint of 32-bit architectures like
>>> those
>>> current in the 1990s. Some of those decisions look less wonderful on
>>> current
>>> 64-bit architectures.
>>
>> There are nothing in defining the size of the simple data types
>> that are tied to 32 bit architecture.
>
> I am aware of one issue in the simple data types that reflects 32 bit
> architecture, JLS section 17.7, "Non-atomic Treatment of double and long".

It is somewhat related, but 32 bit architectures could
operate on 64 bit data (VAX does) and it could be implemented
atomicly.

> The big way in which Java is tied to 32 bit architectures is not in the
> simple data types. It is the maximum size of an array, String, Set, List
> etc.

Yep.

Arne

On 06-02-2011 10:35, Thomas Richter wrote:
> Joshua Cranmer wrote:
>> Generics in Java are basically compile-time syntactic sugar to ensure
>> type-safety of container types at compile time instead of waiting
>> until you hit the code at runtime to get that dreaded ClassCastException.
>
> Well, java had to take the route of type-erasure to allow generic
> progamming plus type checks because it wasn't part of the language to
> begin with, so it was "hacked" into the specs more or less. Generics are
> considerably less powerful, but also considerably easier than C++
> templates. There's no metaprogramming with generics, and generics are
> mostly limited to containers which does not hold for C++ templates. They
> are quite different.

Java generics are useful for more than containers.

It just get complex when used for more than containers.

>> About the only thing they share in common is the syntax, and even
>> then, C++ didn't allow A<B<C>> until C++0x (which, according to Bjarne
>> Stroustroup, took a bit of work to convince compiler vendors to accept).
>
> I beg your pardon? C++ allows nested templates since C++99 and before.
> The only issue here is a notational one, namely that you had to write
> A<B<C> > (note the space behind B<C>) to avoid >> being parsed as a
> token (shifting, namely). That is the only thing that got fixed in
> C++0x, not nesting templates which is part of the language since C++99.

Joshua did not claim otherwise.

Arne

On 05-02-2011 21:26, Lawrence D'Oliveiro wrote:
> In message<4d4d6002$0$23763$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 05-02-2011 07:24, Lawrence D'Oliveiro wrote:
>>> In message<MPG.27b75a6e94bcbb39989e33@news.t-com.hr>, Pitch wrote:
>>>
>>>> I have always missed generics concept in languages that did not have it,
>>>> and I had never worked in C++. :))
>>>
>>> Try Python. Has no generics, and doesn’t need them.
>>
>> Generics are not particular useful in dynamic typed
>> languages.
>>
>> But since Java is static typed, then not so relevant
>> for Java.
>
> Java starts out with static typing, then devotes an awful lot of effort to
> wiggling its way out of that. Look at “unchecked conversions”, for example.
>
> Wouldn’t it be simpler not to pretend in the first place?

????

I think unchecked conversion is a static typed features as well.

Arne

On 05-02-2011 23:13, Lawrence D'Oliveiro wrote:
> In message<iil5ed$10m$1@news.eternal-september.org>, Joshua Cranmer wrote:
>> On 02/05/2011 10:38 PM, Lawrence D'Oliveiro wrote:
>>> In message<4d4d8322$0$41117$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>>> ... templates and gener[ic]s are completely different beasts.
>>>
>>> “Completely” as in “having nothing in common”? Or is this some usage of
>>> “completely” that I wasn’t aware of?
>>>
>>> Please explain.
>>
>> Templates in C++ are basically advanced macros--each invocation of a
>> template type regenerates the class, so a Foo<int>  and a Foo<double>  are
>> two completely different things.
>
> They are different things in Java as well.

No. Same code.

>                                            The only time they become the
> same thing is in “erasures” and “raw types”,

Since Java generics are always type erasured, then "the only time"
is actually "every time".

But .NET does not due type erasure and still only have one copy
of the code for generics.

>> Generics in Java are basically compile-time syntactic sugar to ensure
>> type-safety of container types at compile time instead of waiting until
>> you hit the code at runtime to get that dreaded ClassCastException.
>
> Same sort of thing in C++.
>
>> About the only thing they share in common is the syntax ...
>
> Yeah, funny that. If Java didn’t want to be seen as copying C++, why did it
> reuse exactly the same syntax?

Because beginners that just used the generic containers would not
see the big difference.

And those needing to do more advanced stuff where the difference
becomes visible is expected to read about generics.

Arne

In message <b5GdnQ-xIKYHc9PQnZ2dnUVZ_vCdnZ2d@earthlink.com>, Patricia 
Shanahan wrote:

> I am aware of one issue in the simple data types that reflects 32 bit
> architecture, JLS section 17.7, "Non-atomic Treatment of double and long".
>
> The big way in which Java is tied to 32 bit architectures is not in the
> simple data types. It is the maximum size of an array, String, Set, List
> etc.

Also in the fact that array subscripts cannot be long.

In message <4d4e25e8@news.x-privat.org>, Ken Wesson wrote:

> In that flamewar, someone estimated the size of Clojure's documentation
> by browsing its website and counting pagedown keypresses needed to reach
> the bottom of each web page.

Funny, I did the same thing for Python, just for comparison 
<http://docs.python.org/py3k/reference/>. The figure I came up with for that 
Language Reference was 92 pages. To be fair, I suppose you should include 
the first 6 chapters of rhe Library Reference 
<http://docs.python.org/py3k/library/>, which is another 69 pages, for a 
total of 161.

For comparison, I have a couple of draft C99 specs floating around. They 
total 550 pages, until you realize most of that is section 7, the standard 
library. Leave that out, and you end up with 163 pages.

In message <4d4f042b$0$23753$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 05-02-2011 23:13, Lawrence D'Oliveiro wrote:
>
>> In message<iil5ed$10m$1@news.eternal-september.org>, Joshua Cranmer
>> wrote:
>>
>>> On 02/05/2011 10:38 PM, Lawrence D'Oliveiro wrote:
>>>> In message<4d4d8322$0$41117$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>>>> ... templates and gener[ic]s are completely different beasts.
>>>>
>>>> “Completely” as in “having nothing in common”? Or is this some usage of
>>>> “completely” that I wasn’t aware of?
>>>>
>>>> Please explain.
>>>
>>> Templates in C++ are basically advanced macros--each invocation of a
>>> template type regenerates the class, so a Foo<int>  and a Foo<double> 
>>> are two completely different things.
>>
>> They are different things in Java as well.
> 
> No. Same code.

Same code in C++ too, then.

In message <iil9uk$b6m$1@news.eternal-september.org>, Joshua Cranmer wrote:

> On 02/05/2011 11:13 PM, Lawrence D'Oliveiro wrote:
>
>> They are different things in Java as well.
> 
> The hell they aren't. In Java, there is only one instance of
> LinkedList::add(T object). In C++, there are as many instances of
> std::list<T>::front as times you use it.
> 
> Try, for example, implementing both List<String> and List<Character> in
> the same class. Java will tell you that you cannot do it. C++, on the
> other hand, wouldn't bat an eye.
> 
>> The only time they become the same thing is in “erasures” and “raw
>> types”, which are backward-compatibility mechanisms introduced to avoid
>> breaking existing code that doesn’t know about generics.
> 
> I think Java would likely have gone with much the same syntax even if
> generics had been introduced in the beginning.
> 
>> And then, of course, the language goes on to use exactly that deprecated
>> syntax as the recommended way of accessing static members.
> 
> It's not the same syntax. List<String> is the type of a specific
> instance, while the class still remains List.

List<String> is a class, not an instance. In something like

    List<String> L;

it is L that is the instance.

See, how can you try to tell me what the difference is between Java and C++, 
when you don’t understand it yourself?

In message <iil9uk$b6m$1@news.eternal-september.org>, Joshua Cranmer wrote:

> Try, for example, implementing both List<String> and List<Character> in
> the same class. Java will tell you that you cannot do it. C++, on the
> other hand, wouldn't bat an eye.

Why does Java impose such a pointless restriction?

Strange that Java never copied the C++ operator names "and”, “or” and “not”.

Lew wrote:
> We could end this entire thread right now by conceding that, yes, C++ is 
> clearly the superior language over Java, just like Esperanto is over 
> English, unless, of course, you actually want to accomplish something, 
> but all analogies break down somewhere, right?

Who said this, and where? I did not mean to say this implication. Java 
often took the path of providing a more accessible language than C++, 
maybe for good reasons since C++ has quite some complexity. But 
templates are not generics, and I'm not aware that you can use them for 
metaprogramming. Whether you *want* to use metaprogramming, well, that's 
a different question.

So long,

Thomas

Arne Vajhøj wrote:

>> Well, java had to take the route of type-erasure to allow generic
>> progamming plus type checks because it wasn't part of the language to
>> begin with, so it was "hacked" into the specs more or less. Generics are
>> considerably less powerful, but also considerably easier than C++
>> templates. There's no metaprogramming with generics, and generics are
>> mostly limited to containers which does not hold for C++ templates. They
>> are quite different.
> 
> Java generics are useful for more than containers.
> 
> It just get complex when used for more than containers.

Well, I didn't mean to say something else (see, I wrote "mostly", not 
"only"), but nevertheless, could you provide an example?

>>> About the only thing they share in common is the syntax, and even
>>> then, C++ didn't allow A<B<C>> until C++0x (which, according to Bjarne
>>> Stroustroup, took a bit of work to convince compiler vendors to accept).
>>
>> I beg your pardon? C++ allows nested templates since C++99 and before.
>> The only issue here is a notational one, namely that you had to write
>> A<B<C> > (note the space behind B<C>) to avoid >> being parsed as a
>> token (shifting, namely). That is the only thing that got fixed in
>> C++0x, not nesting templates which is part of the language since C++99.
> 
> Joshua did not claim otherwise.

This was at least worded in a very misleading way.

So long,
	Thomas

Arne Vajhøj wrote:

>>> Templates in C++ are basically advanced macros--each invocation of a
>>> template type regenerates the class, so a Foo<int>  and a 
>>> Foo<double>  are
>>> two completely different things.
>>
>> They are different things in Java as well.
> 
> No. Same code.

I don't know in how far "same code" makes sense in Java in first place. 
The code that is created depends entirely on the JIT, and it may or may 
not generate the same code depending on how often it is called. For 
example, if it the JIT "sees" that the code is called with one specific 
type most of the time, it could create separate code just for this 
purpose and hence omit the type checks. And in C++, a compiler can also 
merge template instances because they are identical, i.e. function 
alike, i.e. for example they all operate on pointers.

Thus, I don't really see how that type of argument applies.

>>> Generics in Java are basically compile-time syntactic sugar to ensure
>>> type-safety of container types at compile time instead of waiting until
>>> you hit the code at runtime to get that dreaded ClassCastException.
>>
>> Same sort of thing in C++.

Not really. Generics are run-time checked, templates are compile-time 
checked. There is no "ClassCastException" in C++. If the class doesn't 
fit, the compiler will tell at compile time. Otherwise, the code will 
crash at run time - there is no additional check inserted as it is in 
java which tests whether the type-erased instance is of the proper type.

Greetings,
	Thomas

In message <4d4e25e8@news.x-privat.org>, Ken Wesson wrote:

> Java is very widely used for network and business applications, and web
> apps, these days ...

I was trying to make sense of where you were coming from with your 
predictions, and then I realized—you’re primarily talking about corporate 
development. Because that’s just about the only place languages like Java 
and C#/Dotnet get much use. Very few mass-market or open-source apps are 
written in those languages, for example.

Except, of course, for Android. Which is why I’m here.

In message <iincuv$ot9$1@news.belwue.de>, Thomas Richter wrote:

> There is no "ClassCastException" in C++.

Yes there is. It’s called “bad_cast”. Where do you think Java got the idea 
from?

On 06/02/2011 7:32 PM, Lawrence D'Oliveiro wrote:
> In message<iincuv$ot9$1@news.belwue.de>, Thomas Richter wrote:
>
>> There is no "ClassCastException" in C++.
>
> Yes there is. It’s called “bad_cast”. Where do you think Java got the idea
> from?

dynamic_cast<foo>(bar) can throw this if bar is not really a foo. But 
C++ lets you use the unsafe old (foo)bar cast from C, and if bar is not 
really a foo, welcome to undefined behaviorville.

Java doesn't let that happen: the cast syntax is (Foo)bar but the 
semantics is that of dynamic_cast: bar is a Foo or an exception gets thrown.

The only way to come close to C's unsafe cast with Java is to muck about 
with serialization, to alter a serialized representation of a Bar to 
claim to be of class Foo instead and then deserialize it. Most likely 
you get a broken Foo and exceptions thrown, but not a VM crash. The main 
reason you'd try that is to try to break some existing Java program -- 
hack it, crack it, virus someone's VM. There's never any use for that in 
normal programming that I am aware of.

-- 
In <iijn58$ccs$1@news.albasani.net>, Lew admitted:
 > The JLS is obfuscatory in parts

On 06/02/2011 7:29 PM, Lawrence D'Oliveiro wrote:
> Except, of course, for Android. Which is why I’m here.

Shouldn't you be off watching football, or something?

On 06-02-2011 18:54, Lawrence D'Oliveiro wrote:
> Strange that Java never copied the C++ operator names "and”, “or” and “not”.

????

Java uses &&, &, ||, |, ! like C++.

(Java does not allow defining them for own types, but that
is another story)

Arne

On 06-02-2011 18:28, Lawrence D'Oliveiro wrote:
> In message<iil9uk$b6m$1@news.eternal-september.org>, Joshua Cranmer wrote:
>> Try, for example, implementing both List<String>  and List<Character>  in
>> the same class. Java will tell you that you cannot do it. C++, on the
>> other hand, wouldn't bat an eye.
>
> Why does Java impose such a pointless restriction?

It is given by the use of type erasure.

Arne

Lew wrote:
>> We could end this entire thread right now by conceding that, yes, C++ is
>> clearly the superior language over Java, just like Esperanto is over
>> English, unless, of course, you actually want to accomplish something, but
>> all analogies break down somewhere, right?

Thomas Richter wrote:
> Who said this, and where? I did not mean to say this implication. Java often
> took the path of providing a more accessible language than C++, maybe for good
> reasons since C++ has quite some complexity. But templates are not generics,
> and I'm not aware that you can use them for metaprogramming. Whether you
> *want* to use metaprogramming, well, that's a different question.

When I say, "this entire thread", I'm referring to this entire thread, "Java 
vs C++", as set up by the OP, not you.  Nor was I replying to one of your 
posts.  I fail to see why you think I have an issue with anything you said.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

On 06-02-2011 18:23, Lawrence D'Oliveiro wrote:
> In message<4d4e25e8@news.x-privat.org>, Ken Wesson wrote:
>> In that flamewar, someone estimated the size of Clojure's documentation
>> by browsing its website and counting pagedown keypresses needed to reach
>> the bottom of each web page.
>
> Funny, I did the same thing for Python, just for comparison
> <http://docs.python.org/py3k/reference/>. The figure I came up with for that
> Language Reference was 92 pages. To be fair, I suppose you should include
> the first 6 chapters of rhe Library Reference
> <http://docs.python.org/py3k/library/>, which is another 69 pages, for a
> total of 161.

Either Python is a simple language or the language reference is not
very detailed.

> For comparison, I have a couple of draft C99 specs floating around. They
> total 550 pages, until you realize most of that is section 7, the standard
> library. Leave that out, and you end up with 163 pages.

I am not sure that comparing a language reference with a standard
spec gives much meaning.

And the C spec leaves a lot of things to implementations.

Arne

On 06-02-2011 18:24, Lawrence D'Oliveiro wrote:
> In message<4d4f042b$0$23753$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 05-02-2011 23:13, Lawrence D'Oliveiro wrote:
>>> In message<iil5ed$10m$1@news.eternal-september.org>, Joshua Cranmer
>>> wrote:
>>>> On 02/05/2011 10:38 PM, Lawrence D'Oliveiro wrote:
>>>>> In message<4d4d8322$0$41117$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>>>>> ... templates and gener[ic]s are completely different beasts.
>>>>>
>>>>> “Completely” as in “having nothing in common”? Or is this some usage of
>>>>> “completely” that I wasn’t aware of?
>>>>>
>>>>> Please explain.
>>>>
>>>> Templates in C++ are basically advanced macros--each invocation of a
>>>> template type regenerates the class, so a Foo<int>   and a Foo<double>
>>>> are two completely different things.
>>>
>>> They are different things in Java as well.
>>
>> No. Same code.
>
> Same code in C++ too, then.

No.

C++ will generate two classes with two sets of code.

(at least that is what common compilers do - I don't know if
the standard actually requires it to)

Arne

On 06-02-2011 19:04, Thomas Richter wrote:
> Arne Vajhøj wrote:
>>>> Templates in C++ are basically advanced macros--each invocation of a
>>>> template type regenerates the class, so a Foo<int> and a Foo<double>
>>>> are
>>>> two completely different things.
>>>
>>> They are different things in Java as well.
>>
>> No. Same code.
>
> I don't know in how far "same code" makes sense in Java in first place.

It does.

Only one copy of the byte code.

> The code that is created depends entirely on the JIT, and it may or may
> not generate the same code depending on how often it is called. For
> example, if it the JIT "sees" that the code is called with one specific
> type most of the time, it could create separate code just for this
> purpose and hence omit the type checks.

JIT compilers can do what they want as long as they keep semantics.

But it is not even required that a JIT compiler will be used.

>                                 And in C++, a compiler can also
> merge template instances because they are identical, i.e. function
> alike, i.e. for example they all operate on pointers.

Possible. But if two template usages are compiled separatetly,
then it is not possible.

> Thus, I don't really see how that type of argument applies.

In Java it is as starting point one code and in C++ it is as
starting point two codes. The optimizers may do some funny things.

But I consider them different, because what optimizers may
do is not suffcient to make them identical.

Arne

On 06-02-2011 18:57, Thomas Richter wrote:
> Arne Vajhøj wrote:
>
>>> Well, java had to take the route of type-erasure to allow generic
>>> progamming plus type checks because it wasn't part of the language to
>>> begin with, so it was "hacked" into the specs more or less. Generics are
>>> considerably less powerful, but also considerably easier than C++
>>> templates. There's no metaprogramming with generics, and generics are
>>> mostly limited to containers which does not hold for C++ templates. They
>>> are quite different.
>>
>> Java generics are useful for more than containers.
>>
>> It just get complex when used for more than containers.
>
> Well, I didn't mean to say something else (see, I wrote "mostly", not
> "only"), but nevertheless, could you provide an example?

     public static <T extends Comparable<? super T>> T Max(T a, T b) {
         if (a == null) return b;
         if (b == null) return a;
         if (a.compareTo(b) >= 0)
             return a;
         else return b;
     }

>>>> About the only thing they share in common is the syntax, and even
>>>> then, C++ didn't allow A<B<C>> until C++0x (which, according to Bjarne
>>>> Stroustroup, took a bit of work to convince compiler vendors to
>>>> accept).
>>>
>>> I beg your pardon? C++ allows nested templates since C++99 and before.
>>> The only issue here is a notational one, namely that you had to write
>>> A<B<C> > (note the space behind B<C>) to avoid >> being parsed as a
>>> token (shifting, namely). That is the only thing that got fixed in
>>> C++0x, not nesting templates which is part of the language since C++99.
>>
>> Joshua did not claim otherwise.
>
> This was at least worded in a very misleading way.

How can specific syntax be misleading?

Arne

On 06-02-2011 19:29, Lawrence D'Oliveiro wrote:
> In message<4d4e25e8@news.x-privat.org>, Ken Wesson wrote:
>> Java is very widely used for network and business applications, and web
>> apps, these days ...
>
> I was trying to make sense of where you were coming from with your
> predictions, and then I realized—you’re primarily talking about corporate
> development. Because that’s just about the only place languages like Java
> and C#/Dotnet get much use. Very few mass-market or open-source apps are
> written in those languages, for example.

Which is just plain wrong.

Java and C# are both very popular for open source projects.

Sometimes statistics are done for SF projects.

The last I can find for December 2007 has Java as #1 and
C# as #7 and VB.NET as #14.

So Java and .NET are very much used for open source.

Desktop market is still dominated by native apps. It may
change someday if MS starts to rewrite MFC stuff in .NET.

Arne

On 06-02-2011 18:14, Lawrence D'Oliveiro wrote:
> In message<b5GdnQ-xIKYHc9PQnZ2dnUVZ_vCdnZ2d@earthlink.com>, Patricia
> Shanahan wrote:
>> I am aware of one issue in the simple data types that reflects 32 bit
>> architecture, JLS section 17.7, "Non-atomic Treatment of double and long".
>>
>> The big way in which Java is tied to 32 bit architectures is not in the
>> simple data types. It is the maximum size of an array, String, Set, List
>> etc.
>
> Also in the fact that array subscripts cannot be long.

But that has nothing to do with simple data types.

Arne

On 02/06/2011 06:54 PM, Lawrence D'Oliveiro wrote:
> Strange that Java never copied the C++ operator names "and”, “or” and “not”.

Why should it have? They're just aliases for other objects. By your 
reasoning, Java should also have copied the C trigraphs or the other 
tokens in the "Alternative tokens". You know, for the three people in 
the world who do not have { on their keyboard.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On 06-02-2011 20:38, Arne Vajhøj wrote:
> On 06-02-2011 19:29, Lawrence D'Oliveiro wrote:
>> In message<4d4e25e8@news.x-privat.org>, Ken Wesson wrote:
>>> Java is very widely used for network and business applications, and web
>>> apps, these days ...
>>
>> I was trying to make sense of where you were coming from with your
>> predictions, and then I realized—you’re primarily talking about corporate
>> development. Because that’s just about the only place languages like Java
>> and C#/Dotnet get much use. Very few mass-market or open-source apps are
>> written in those languages, for example.
>
> Which is just plain wrong.
>
> Java and C# are both very popular for open source projects.
>
> Sometimes statistics are done for SF projects.
>
> The last I can find for December 2007 has Java as #1 and
> C# as #7 and VB.NET as #14.
>
> So Java and .NET are very much used for open source.
>
> Desktop market is still dominated by native apps. It may
> change someday if MS starts to rewrite MFC stuff in .NET.

And in case somebody wants to check the list:
   http://www.c2.com/cgi/wiki?ProgrammingLanguagePopularity

Arne

On 06-02-2011 10:45, Thomas Richter wrote:
> Joshua Cranmer wrote:
>> On 02/05/2011 11:13 PM, Lawrence D'Oliveiro wrote:
>>> The only time they become the
>>> same thing is in “erasures” and “raw types”, which are backward-
>>> compatibility mechanisms introduced to avoid breaking existing code that
>>> doesn’t know about generics.
>>
>> I think Java would likely have gone with much the same syntax even if
>> generics had been introduced in the beginning.
>
> That's really a speculation. One could also speculate that if java would
> have used or required generics from the beginning, they would be closer
> to C++ templates and would not use type erasure; instead, they would be
> parametrized classes as they are in C++. It's really speculation.

Given how C#/.NET got generics and the discussions about
changes to generics for future Java versions, then it seems
to be a bit more than just speculation to say that if Java had
had generics from start:
- they would not use type erasure
- but they would not be like C++

Arne

On 06-02-2011 00:01, Joshua Cranmer wrote:
> On 02/05/2011 11:13 PM, Lawrence D'Oliveiro wrote:
>> The only time they become the
>> same thing is in “erasures” and “raw types”, which are backward-
>> compatibility mechanisms introduced to avoid breaking existing code that
>> doesn’t know about generics.
>
> I think Java would likely have gone with much the same syntax even if
> generics had been introduced in the beginning.

I think so too.

But I believe that type erasure would have been dropped in that case.

Arne

In message <4d4f4387$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 18:54, Lawrence D'Oliveiro wrote:
>
>> Strange that Java never copied the C++ operator names "and”, “or” and
>> “not”.
> 
> ????
> 
> Java uses &&, &, ||, |, ! like C++.

But not “and”, “or” and “not”.

In message <iinimq$q4v$1@news.eternal-september.org>, Joshua Cranmer wrote:

> On 02/06/2011 06:54 PM, Lawrence D'Oliveiro wrote:
>
>> Strange that Java never copied the C++ operator names "and”, “or” and
>> “not”.
> 
> Why should it have? They're just aliases for other objects.

They’re not objects, they’re operator names.

In message <4d4f4d64$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 18:14, Lawrence D'Oliveiro wrote:
>
>> In message<b5GdnQ-xIKYHc9PQnZ2dnUVZ_vCdnZ2d@earthlink.com>, Patricia
>> Shanahan wrote:
>>> I am aware of one issue in the simple data types that reflects 32 bit
>>> architecture, JLS section 17.7, "Non-atomic Treatment of double and
>>> long".
>>>
>>> The big way in which Java is tied to 32 bit architectures is not in the
>>> simple data types. It is the maximum size of an array, String, Set, List
>>> etc.
>>
>> Also in the fact that array subscripts cannot be long.
> 
> But that has nothing to do with simple data types.

What is long?

In message <iilaco$dd0$1@news.eternal-september.org>, Joshua Cranmer wrote:

> I would venture a guess that most C or C++ code isn't as easily portable
> to 64-bit platforms as you would think ...

Most of the C/C++ code I deal with is open-source, and essentially all of 
that is portable between 32-bit and 64-bit nowadays. As well as across non-
x86 architectures, for that matter.

Ironic, isn’t it, that the early Java slogan was "write once, run 
everywhere”...

In message <4d4e7634$0$81475$e4fe514c@news.xs4all.nl>, Silvio wrote:

> Oh, I remember how well C++ and its undefined sizes of things served us
> when we had to port heaps of code from 16-bit to 32-bit.

By “16-bit” I take it you specifically mean “Windows/Intel 16-bit”, i.e. the 
segmented 80286 architecture (spit). That was the only major 16-bit 
architecture I’m aware of that made portability difficult.

In message <iimnes$dh2$1@news.eternal-september.org>, Joshua Cranmer wrote:

> It's a macro generator that understands types and is heavily integrated
> with the syntax of C++, but it is basically a way to automatically
> generate code.

You seem to be confusing one particular way of implementing 
generics/templates with the way the language feature is specified. Java 
generics could be implemented by a preprocessor that spat out first-edition 
Java code, for that matter. In fact, it effectively does, since the JVM 
seems to know nothing about generics. Would you then say that third-edition 
Java is nothing more than a “macro generator”?

In message <iimf47$soo$1@news.belwue.de>, Thomas Richter wrote:

> Templates allow meta-programming, i.e. you can use the compiler to
> generate code.

Why, what do compilers normally do?

In message <iinft1$95e$1@speranza.aioe.org>, javax.swing.JSnarker wrote:

> On 06/02/2011 7:32 PM, Lawrence D'Oliveiro wrote:
>
>> In message<iincuv$ot9$1@news.belwue.de>, Thomas Richter wrote:
>>
>>> There is no "ClassCastException" in C++.
>>
>> Yes there is. It’s called “bad_cast”. Where do you think Java got the
>> idea from?
> 
> dynamic_cast<foo>(bar) can throw this if bar is not really a foo. But
> C++ lets you use the unsafe old (foo)bar cast from C, and if bar is not
> really a foo, welcome to undefined behaviorville.

The fact remains, there IS an equivalent to ClassCastException in C++.

In message <4d4f47bb$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 18:24, Lawrence D'Oliveiro wrote:
>
>> In message<4d4f042b$0$23753$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>
>>> On 05-02-2011 23:13, Lawrence D'Oliveiro wrote:
>>>
>>>> In message<iil5ed$10m$1@news.eternal-september.org>, Joshua Cranmer
>>>> wrote:
>>>>
>>>>> On 02/05/2011 10:38 PM, Lawrence D'Oliveiro wrote:
>>>>>>
>>>>>> In message<4d4d8322$0$41117$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>>>>>
>>>>>>> ... templates and gener[ic]s are completely different beasts.
>>>>>>
>>>>>> “Completely” as in “having nothing in common”? Or is this some usage
>>>>>> of “completely” that I wasn’t aware of?
>>>>>>
>>>>>> Please explain.
>>>>>
>>>>> Templates in C++ are basically advanced macros--each invocation of a
>>>>> template type regenerates the class, so a Foo<int>   and a Foo<double>
>>>>> are two completely different things.
>>>>
>>>> They are different things in Java as well.
>>>
>>> No. Same code.
>>
>> Same code in C++ too, then.
> 
> No.
> 
> C++ will generate two classes with two sets of code.
> 
> (at least that is what common compilers do - I don't know if
> the standard actually requires it to)

See, it’s clear you’re hung up on specifics of particular implementations, 
not on how the language feature is defined at all.

On 06-02-2011 20:52, Lawrence D'Oliveiro wrote:
> In message<4d4f4d64$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 06-02-2011 18:14, Lawrence D'Oliveiro wrote:
>>> In message<b5GdnQ-xIKYHc9PQnZ2dnUVZ_vCdnZ2d@earthlink.com>, Patricia
>>> Shanahan wrote:
>>>> I am aware of one issue in the simple data types that reflects 32 bit
>>>> architecture, JLS section 17.7, "Non-atomic Treatment of double and
>>>> long".
>>>>
>>>> The big way in which Java is tied to 32 bit architectures is not in the
>>>> simple data types. It is the maximum size of an array, String, Set, List
>>>> etc.
>>>
>>> Also in the fact that array subscripts cannot be long.
>>
>> But that has nothing to do with simple data types.
>
> What is long?

A simple data type.

But it is still a characteristics of array not of long.

Arne

On 06-02-2011 20:51, Lawrence D'Oliveiro wrote:
> In message<4d4f4387$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 06-02-2011 18:54, Lawrence D'Oliveiro wrote:
>>> Strange that Java never copied the C++ operator names "and”, “or” and
>>> “not”.
>>
>> ????
>>
>> Java uses&&,&, ||, |, ! like C++.
>
> But not “and”, “or” and “not”.

True.

But since practically none uses them in C++, then ...

Arne

In message <4d4f43d9$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 18:28, Lawrence D'Oliveiro wrote:
>
>> In message<iil9uk$b6m$1@news.eternal-september.org>, Joshua Cranmer
>> wrote:
>>
>>> Try, for example, implementing both List<String>  and List<Character> 
>>> in the same class. Java will tell you that you cannot do it. C++, on the
>>> other hand, wouldn't bat an eye.
>>
>> Why does Java impose such a pointless restriction?
> 
> It is given by the use of type erasure.

Which is purely a backward-compatibility mechanism. If I were to take two 
copies of the definition of List<E>, and in one take out <E> and replace E 
with String, and in the other replace it with Character, Java would have no 
problem letting me declare a class that implements both interfaces. But try 
doing it directly with the generic, and it won’t.

Java draws a distinction between the two cases where there really shouldn’t 
be any distinction. That’s what generics are for, after all—they’re there to 
save work for the programmer, not create it.

See, Java started out as not wanting to be like C++: it would take the good 
stuff from C++, and leave the rest behind.

But now, with the addition of generics, it’s clear Java wants to be more 
like C++ after all. The only thing holding it back is not deliberate design 
choices over functionality, but the dead hand of backward compatibility.

In message <4d4f5402$0$23761$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 20:51, Lawrence D'Oliveiro wrote:
>
>> In message<4d4f4387$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>
>>> On 06-02-2011 18:54, Lawrence D'Oliveiro wrote:
>>>
>>>> Strange that Java never copied the C++ operator names "and”, “or” and
>>>> “not”.
>>>
>>> ????
>>>
>>> Java uses&&,&, ||, |, ! like C++.
>>
>> But not “and”, “or” and “not”.
> 
> True.
> 
> But since practically none uses them in C++, then ...

I use them in all my C++ code.

In message <4d4f5367$0$23761$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 20:52, Lawrence D'Oliveiro wrote:
>
>> In message<4d4f4d64$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>
>>> On 06-02-2011 18:14, Lawrence D'Oliveiro wrote:
>>>>
>>>> In message<b5GdnQ-xIKYHc9PQnZ2dnUVZ_vCdnZ2d@earthlink.com>, Patricia
>>>> Shanahan wrote:
>>>>>
>>>>> I am aware of one issue in the simple data types that reflects 32 bit
>>>>> architecture, JLS section 17.7, "Non-atomic Treatment of double and
>>>>> long".
>>>>>
>>>>> The big way in which Java is tied to 32 bit architectures is not in
>>>>> the simple data types. It is the maximum size of an array, String,
>>>>> Set, List etc.
>>>>
>>>> Also in the fact that array subscripts cannot be long.
>>>
>>> But that has nothing to do with simple data types.
>>
>> What is long?
> 
> A simple data type.
> 
> But it is still a characteristics of array not of long.

Which is a limitation that comes from a fixation on 32-bit architectures, 
without a thought for 64-bit ones.

On 06-02-2011 20:53, Lawrence D'Oliveiro wrote:
> In message<iilaco$dd0$1@news.eternal-september.org>, Joshua Cranmer wrote:
>> I would venture a guess that most C or C++ code isn't as easily portable
>> to 64-bit platforms as you would think ...
>
> Most of the C/C++ code I deal with is open-source, and essentially all of
> that is portable between 32-bit and 64-bit nowadays. As well as across non-
> x86 architectures, for that matter.

Without ifdef's ????

> Ironic, isn’t it, that the early Java slogan was "write once, run
> everywhere”...

anywhere not everywhere

Arne

On 02/06/2011 06:26 PM, Lawrence D'Oliveiro wrote:
> In message<iil9uk$b6m$1@news.eternal-september.org>, Joshua Cranmer wrote:
>> It's not the same syntax. List<String>  is the type of a specific
>> instance, while the class still remains List.
>
> List<String>  is a class, not an instance. In something like
>
>      List<String>  L;
>
> it is L that is the instance.

L is an instance of a class. List<String> is an instance of a type, a 
type that is distinct from List (the raw type or the class type).

If you're having this much problems understanding me, I'm sure you'll be 
having lots of fun when it comes to capture conversion. Just because two 
variables have type List<? extends Number> doesn't mean that they have 
the same type. ;-)

> See, how can you try to tell me what the difference is between Java and C++,
> when you don’t understand it yourself?

I do very much understand it myself. My problem is that you have such a 
broken understanding of Java that the terminology I normally use to 
explain stuff is lost on you. Java is not C++, so don't come in with 
your preconceived notions of C++ and argue that they should apply to Java.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On 06-02-2011 20:55, Lawrence D'Oliveiro wrote:
> In message<4d4e7634$0$81475$e4fe514c@news.xs4all.nl>, Silvio wrote:
>> Oh, I remember how well C++ and its undefined sizes of things served us
>> when we had to port heaps of code from 16-bit to 32-bit.

It is 8086 architecture not 80286 architecture.

> By “16-bit” I take it you specifically mean “Windows/Intel 16-bit”, i.e. the
> segmented 80286 architecture (spit). That was the only major 16-bit
> architecture I’m aware of that made portability difficult.

Windows has nothing to do with CPU architecture.

And the problem Silvio talks about (undefined sizes) is
not related to segmented memory.

Arne

On 02/06/2011 09:03 PM, Lawrence D'Oliveiro wrote:
> In message<4d4f47bb$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> C++ will generate two classes with two sets of code.
>>
>> (at least that is what common compilers do - I don't know if
>> the standard actually requires it to)
>
> See, it’s clear you’re hung up on specifics of particular implementations,
> not on how the language feature is defined at all.

No, it's in the definition of C++ templates. And I quote §14, clause 1:
A template defines a family of classes, functions, or concept maps, or 
an alias for a family of types.

As far as the standard is concerned, Foo<int> and Foo<long> would be 
very distinct types. It might be that the compiler makes them one single 
entity, but it can only do that under §1.9, clause 1:

The semantic descriptions in this International Standard define a 
parameterized nondeterministic abstract machine. This International 
Standard places no requirement on the structure of conforming 
implementations. In particular, they need not copy or emulate the 
structure of the abstract machine. Rather, conforming implementations 
are required to emulate (only) the observable behavior of the abstract 
machine as explained below.

i.e., "you don't have to actually implement this specification so long 
as a valid program can't tell that you aren't."

See, it's clear you really haven't read the specs you're trying to 
language lawyer with us on.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On 06-02-2011 21:08, Lawrence D'Oliveiro wrote:
> In message<4d4f43d9$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 06-02-2011 18:28, Lawrence D'Oliveiro wrote:
>>> In message<iil9uk$b6m$1@news.eternal-september.org>, Joshua Cranmer
>>> wrote:
>>>> Try, for example, implementing both List<String>   and List<Character>
>>>> in the same class. Java will tell you that you cannot do it. C++, on the
>>>> other hand, wouldn't bat an eye.
>>>
>>> Why does Java impose such a pointless restriction?
>>
>> It is given by the use of type erasure.
>
> Which is purely a backward-compatibility mechanism.

Which does not change the fact - it just explains it.

>                                                    If I were to take two
> copies of the definition of List<E>, and in one take out<E>  and replace E
> with String, and in the other replace it with Character, Java would have no
> problem letting me declare a class that implements both interfaces. But try
> doing it directly with the generic, and it won’t.
>
> Java draws a distinction between the two cases where there really shouldn’t
> be any distinction. That’s what generics are for, after all—they’re there to
> save work for the programmer, not create it.

Backward compatibility limit the available option.

> See, Java started out as not wanting to be like C++: it would take the good
> stuff from C++, and leave the rest behind.
>
> But now, with the addition of generics, it’s clear Java wants to be more
> like C++ after all.

Not really.

As explained numerous times then Java generics and C++ templates
are somewhat different.

Arne

On 06-02-2011 21:10, Lawrence D'Oliveiro wrote:
> In message<4d4f5402$0$23761$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 06-02-2011 20:51, Lawrence D'Oliveiro wrote:
>>> In message<4d4f4387$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>>> On 06-02-2011 18:54, Lawrence D'Oliveiro wrote:
>>>>> Strange that Java never copied the C++ operator names "and”, “or” and
>>>>> “not”.
>>>>
>>>> ????
>>>>
>>>> Java uses&&,&, ||, |, ! like C++.
>>>
>>> But not “and”, “or” and “not”.
>>
>> True.
>>
>> But since practically none uses them in C++, then ...
>
> I use them in all my C++ code.

I believe that.

With your language understanding that would be a good guess.

Arne

On 02/06/2011 09:00 PM, Lawrence D'Oliveiro wrote:
> In message<iimnes$dh2$1@news.eternal-september.org>, Joshua Cranmer wrote:
>
>> It's a macro generator that understands types and is heavily integrated
>> with the syntax of C++, but it is basically a way to automatically
>> generate code.
>
> You seem to be confusing one particular way of implementing
> generics/templates with the way the language feature is specified. Java
> generics could be implemented by a preprocessor that spat out first-edition
> Java code, for that matter. In fact, it effectively does, since the JVM
> seems to know nothing about generics. Would you then say that third-edition
> Java is nothing more than a “macro generator”?

I make a minor distinction between syntactic sugar--a language feature 
which is designed to replace specific syntax features for ease of coding 
(e.g., for-each loops)--and macro processing, which is generally 
unrestricted code or text generation. Generics are syntactic sugar, in 
that it only generates code in a "few" select places as opposed to 
wholesale code production.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On 02/06/2011 09:10 PM, Lawrence D'Oliveiro wrote:
> In message<4d4f5402$0$23761$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>
>> On 06-02-2011 20:51, Lawrence D'Oliveiro wrote:
>>
>>> In message<4d4f4387$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>>
>>>> On 06-02-2011 18:54, Lawrence D'Oliveiro wrote:
>>>>
>>>>> Strange that Java never copied the C++ operator names "and”, “or” and
>>>>> “not”.
>>>>
>>>> ????
>>>>
>>>> Java uses&&,&, ||, |, ! like C++.
>>>
>>> But not “and”, “or” and “not”.
>>
>> True.
>>
>> But since practically none uses them in C++, then ...
>
> I use them in all my C++ code.

And you, sir, are why we cannot have nice things. ;-)

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On 06-02-2011 21:11, Lawrence D'Oliveiro wrote:
> In message<4d4f5367$0$23761$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 06-02-2011 20:52, Lawrence D'Oliveiro wrote:
>>> In message<4d4f4d64$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>>> On 06-02-2011 18:14, Lawrence D'Oliveiro wrote:
>>>>> In message<b5GdnQ-xIKYHc9PQnZ2dnUVZ_vCdnZ2d@earthlink.com>, Patricia
>>>>> Shanahan wrote:
>>>>>>
>>>>>> I am aware of one issue in the simple data types that reflects 32 bit
>>>>>> architecture, JLS section 17.7, "Non-atomic Treatment of double and
>>>>>> long".
>>>>>>
>>>>>> The big way in which Java is tied to 32 bit architectures is not in
>>>>>> the simple data types. It is the maximum size of an array, String,
>>>>>> Set, List etc.
>>>>>
>>>>> Also in the fact that array subscripts cannot be long.
>>>>
>>>> But that has nothing to do with simple data types.
>>>
>>> What is long?
>>
>> A simple data type.
>>
>> But it is still a characteristics of array not of long.
>
> Which is a limitation that comes from a fixation on 32-bit architectures,
> without a thought for 64-bit ones.

It is not an assumption about 32 bit architecture. 32 bit
architecture limits it more than the Java rule.

It is a bad assumption about memory availability in general.

Arne

have set the limit far lower than it is

On 06-02-2011 21:00, Lawrence D'Oliveiro wrote:
> In message<iimnes$dh2$1@news.eternal-september.org>, Joshua Cranmer wrote:
>> It's a macro generator that understands types and is heavily integrated
>> with the syntax of C++, but it is basically a way to automatically
>> generate code.
>
> You seem to be confusing one particular way of implementing
> generics/templates with the way the language feature is specified. Java
> generics could be implemented by a preprocessor that spat out first-edition
> Java code, for that matter.

Java generics could have been defined that way.

But they were not.

A generic Java class get compiled to a single
set of byte code.

Arne

On 06-02-2011 21:03, Lawrence D'Oliveiro wrote:
> In message<4d4f47bb$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 06-02-2011 18:24, Lawrence D'Oliveiro wrote:
>>> In message<4d4f042b$0$23753$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>>> On 05-02-2011 23:13, Lawrence D'Oliveiro wrote:
>>>>> In message<iil5ed$10m$1@news.eternal-september.org>, Joshua Cranmer
>>>>> wrote:
>>>>>> On 02/05/2011 10:38 PM, Lawrence D'Oliveiro wrote:
>>>>>>> In message<4d4d8322$0$41117$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>>>>>>
>>>>>>>> ... templates and gener[ic]s are completely different beasts.
>>>>>>>
>>>>>>> “Completely” as in “having nothing in common”? Or is this some usage
>>>>>>> of “completely” that I wasn’t aware of?
>>>>>>>
>>>>>>> Please explain.
>>>>>>
>>>>>> Templates in C++ are basically advanced macros--each invocation of a
>>>>>> template type regenerates the class, so a Foo<int>    and a Foo<double>
>>>>>> are two completely different things.
>>>>>
>>>>> They are different things in Java as well.
>>>>
>>>> No. Same code.
>>>
>>> Same code in C++ too, then.
>>
>> No.
>>
>> C++ will generate two classes with two sets of code.
>>
>> (at least that is what common compilers do - I don't know if
>> the standard actually requires it to)
>
> See, it’s clear you’re hung up on specifics of particular implementations,
> not on how the language feature is defined at all.

The language feature is what allows it.

That behavior would not be allowed in Java.

Arne

In message <4d4f5813$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 21:00, Lawrence D'Oliveiro wrote:
>
>> In message<iimnes$dh2$1@news.eternal-september.org>, Joshua Cranmer
>> wrote:
>>>
>>> It's a macro generator that understands types and is heavily integrated
>>> with the syntax of C++, but it is basically a way to automatically
>>> generate code.
>>
>> You seem to be confusing one particular way of implementing
>> generics/templates with the way the language feature is specified. Java
>> generics could be implemented by a preprocessor that spat out
>> first-edition Java code, for that matter.
> 
> Java generics could have been defined that way.
> 
> But they were not.

See, you cannot even distinguish between “defined” and “implemented”.

In message <iinku4$tbg$2@news.eternal-september.org>, Joshua Cranmer wrote:

> On 02/06/2011 09:00 PM, Lawrence D'Oliveiro wrote:
>
>> In message<iimnes$dh2$1@news.eternal-september.org>, Joshua Cranmer
>> wrote:
>>
>>> It's a macro generator that understands types and is heavily integrated
>>> with the syntax of C++, but it is basically a way to automatically
>>> generate code.
>>
>> You seem to be confusing one particular way of implementing
>> generics/templates with the way the language feature is specified. Java
>> generics could be implemented by a preprocessor that spat out
>> first-edition Java code, for that matter. In fact, it effectively does,
>> since the JVM seems to know nothing about generics. Would you then say
>> that third-edition Java is nothing more than a “macro generator”?
> 
> I make a minor distinction between syntactic sugar--a language feature
> which is designed to replace specific syntax features for ease of coding
> (e.g., for-each loops)--and macro processing, which is generally
> unrestricted code or text generation.

In that case, C++ templates are most certainly not macros.

In message <4d4f56ac$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> As explained numerous times then Java generics and C++ templates
> are somewhat different.

The only differences arise from limitations of Java, nothing more.

In message <iinkf4$qmm$1@news.eternal-september.org>, Joshua Cranmer wrote:

> On 02/06/2011 06:26 PM, Lawrence D'Oliveiro wrote:
>
>> In message<iil9uk$b6m$1@news.eternal-september.org>, Joshua Cranmer
>> wrote:
>>
>>> It's not the same syntax. List<String>  is the type of a specific
>>> instance, while the class still remains List.
>>
>> List<String>  is a class, not an instance. In something like
>>
>>      List<String>  L;
>>
>> it is L that is the instance.
> 
> L is an instance of a class. List<String> is an instance of a type, a
> type that is distinct from List (the raw type or the class type).

List<String> is a type, not an instance of a type.

> If you're having this much problems understanding me ...

Use the terms as they are defined in the Java Language Spec, and we can all 
get along fine.

On 02/06/2011 09:53 PM, Lawrence D'Oliveiro wrote:
> In message<4d4f56ac$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>
>> As explained numerous times then Java generics and C++ templates
>> are somewhat different.
>
> The only differences arise from limitations of Java, nothing more.

That is not an assertion you can make. Java generics and C++ templates 
are different because their designers wanted them to be different. It 
would totally have been possible to implement C++ templates in Java--but 
the designers decided that was not what they wanted to do. I don't know 
what they would have done if they had added generics from the start, but 
given all of the issues seen with templates, I am willing to guess that 
it would still act nothing like templates do (i.e., as Java generics do 
know, just with fully reified types).

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On 06-02-2011 21:51, Lawrence D'Oliveiro wrote:
> In message<4d4f5813$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 06-02-2011 21:00, Lawrence D'Oliveiro wrote:
>>> In message<iimnes$dh2$1@news.eternal-september.org>, Joshua Cranmer
>>> wrote:
>>>> It's a macro generator that understands types and is heavily integrated
>>>> with the syntax of C++, but it is basically a way to automatically
>>>> generate code.
>>>
>>> You seem to be confusing one particular way of implementing
>>> generics/templates with the way the language feature is specified. Java
>>> generics could be implemented by a preprocessor that spat out
>>> first-edition Java code, for that matter.
>>
>> Java generics could have been defined that way.
>>
>> But they were not.
>
> See, you cannot even distinguish between “defined” and “implemented”.

You does not seem to have understood how Java generics are defined.

Such an implementation would not have been compliant.

In fact I think it would have been useless.

Arne

On 06-02-2011 21:53, Lawrence D'Oliveiro wrote:
> In message<4d4f56ac$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> As explained numerous times then Java generics and C++ templates
>> are somewhat different.
>
> The only differences arise from limitations of Java, nothing more.

No. The differences arise from different decisions on what they
wanted.

Arne

On Sun, 06 Feb 2011 10:55:15 -0800, Patricia Shanahan wrote:

> Arne Vajhøj wrote:
>> On 05-02-2011 23:06, Lawrence D'Oliveiro wrote:
>>> In message<iijrj2$i0g$1@news.eternal-september.org>, Joshua Cranmer
>>> wrote:
>>>> Also take into consideration the fact that the C++ standard does not
>>>> try to pin stuff down into unambiguous interoperable statements,
>>>> e.g., a precise size definition for size_t.
>>>
>>> It seems to me that’s another drawback of Java, that it explicitly
>>> defines
>>> the sizes of things from the viewpoint of 32-bit architectures like
>>> those current in the 1990s. Some of those decisions look less
>>> wonderful on current
>>> 64-bit architectures.
>> 
>> There are nothing in defining the size of the simple data types that
>> are tied to 32 bit architecture.
> 
> I am aware of one issue in the simple data types that reflects 32 bit
> architecture, JLS section 17.7, "Non-atomic Treatment of double and
> long".
> 
> The big way in which Java is tied to 32 bit architectures is not in the
> simple data types. It is the maximum size of an array, String, Set, List
> etc.

It was unfortunate that they didn't define the get, size, etc. methods 
for the java.util collections as taking/returning longs. If they had, 
they could have just quietly dropped the 2^32 size limit on them at some 
point without any existing code breaking. They'd have to add a new array 
supertype for long-indexed arrays, which means new bytecode and a syntax 
for declaring such arrays, but the collections could then have had their 
innards quietly changed.

As it stands, they'll have to introduce a parallel hierarchy of long-
indexed array types and a syntax for declaring these, and then make more 
complicated changes to java.util. Making existing collections support 
bigger sizes is difficult, because a lot of code likely depends on the 
size method returning an accurate count. Having size clamp at 
Integer.MAX_VALUE while the real size gets larger would therefore break 
things. Redefining size to return a long will also break things, whether 
or not they also dropped the error on implicit narrowing assignments from 
long to int. (They'd have to at least keep it a warning, for obvious 
reasons; I'd vote for leaving it an error.) Redefining List.get() to take 
a long maintains source compatibility (the implicit conversions here will 
be widening) but not binary. Overloading List.get() to accept int or long 
inputs maintains both, but with the size problem it's academic anyway.

They'll have to add BigCollection, BigList, BigMap ... or else create 
java.util.big or java.util2 with parallel versions of everything.

What a pain.

The funny thing is they could have anticipated this and had longs in all 
these places from the outset, with a soft limit based on when OOME got 
thrown or even an exception throw at runtime for exceeding 
Integer.MAX_VALUE and a compile-time error for too-big literal array 
indices and sizes that could later be removed, if they didn't actually 
implement giant arrays yet at that point. The language could have been 
designed to allow for them later. But it wasn't.

Heck, they had BigInteger from the outset and could have gone so far as 
to include a true numeric tower, implicit conversions all the way up to 
BigInteger and not just long, Integer an abstract class with 
ShortInteger, SmallInteger, LongInteger, and BigInteger as subclasses, 
and Integer the return types of size methods, allowing for potentially 
unlimited growth. (BigInteger uses an array under the hood and so 
presumably has a limit of 2^31-1 words of size, but in this world it 
would of course be capable of being bigger because arrays would be. Of 
course, the bigger everything got the slower it would get ...)

On Sun, 06 Feb 2011 16:35:32 +0100, Thomas Richter wrote:

> Joshua Cranmer wrote:
>> On 02/05/2011 10:38 PM, Lawrence D'Oliveiro wrote:
>>> In message<4d4d8322$0$41117$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>>
>>>> And Lew is correct: templates and genercis are completely different
>>>> beasts.
>>>
>>> “Completely” as in “having nothing in common”? Or is this some usage
>>> of “completely” that I wasn’t aware of?
>>>
>>> Please explain.
>> 
>> Templates in C++ are basically advanced macros--each invocation of a
>> template type regenerates the class, so a Foo<int> and a Foo<double>
>> are two completely different things.
> 
> That's much more than a macro could do. Templates are a language of its
> own, include syntax checks, etc. Quite unlike macros, they do not
> substitute text patterns. Templates allow meta-programming, i.e. you can
> use the compiler to generate code. And, of course, templates are quite
> complex - very unlike the simple-minded preprocessor.

I take it by "macros" you mean the simple-minded preprocessor macros of C 
and C++. Lisp has things it calls "macros" that are much more 
sophisticated, including syntax checks, etc., and are able to do 
everything C++ templates can do and then some. Common Lisp macros can 
generate templated CLOS classes, for instance.

In message <4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 18:23, Lawrence D'Oliveiro wrote:
>
>> In message<4d4e25e8@news.x-privat.org>, Ken Wesson wrote:
>>
>>> In that flamewar, someone estimated the size of Clojure's documentation
>>> by browsing its website and counting pagedown keypresses needed to reach
>>> the bottom of each web page.
>>
>> Funny, I did the same thing for Python, just for comparison
>> <http://docs.python.org/py3k/reference/>. The figure I came up with for
>> that Language Reference was 92 pages. To be fair, I suppose you should
>> include the first 6 chapters of rhe Library Reference
>> <http://docs.python.org/py3k/library/>, which is another 69 pages, for a
>> total of 161.
> 
> Either Python is a simple language or the language reference is not
> very detailed.

Go on, study the references for yourself, even get some experience with the 
language, then let us know your verdict.

>> For comparison, I have a couple of draft C99 specs floating around. They
>> total 550 pages, until you realize most of that is section 7, the
>> standard library. Leave that out, and you end up with 163 pages.
> 
> I am not sure that comparing a language reference with a standard
> spec gives much meaning.

That’s right, I forgot there is no “standard spec” for Java, it is simply 
what Sunacle says it is.

> And the C spec leaves a lot of things to implementations.

Not too much that you can’t write portable code in it.

In message <4d4f61fb$0$23756$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 21:53, Lawrence D'Oliveiro wrote:
>
>> In message<4d4f56ac$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>
>>> As explained numerous times then Java generics and C++ templates
>>> are somewhat different.
>>
>> The only differences arise from limitations of Java, nothing more.
> 
> No. The differences arise from different decisions on what they
> wanted.

The Java designers wanted everything that C++ templates offered. The only 
parts they omitted were the ones they couldn’t have.

In message <4d4f4a54$0$23753$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 19:04, Thomas Richter wrote:
>
>> And in C++, a compiler can also> merge template instances because they
>> are identical, i.e. function alike, i.e. for example they all operate on
>> pointers.
> 
> Possible. But if two template usages are compiled separatetly,
> then it is not possible.

Exercise for the reader: explain why Arne Vajhøj is wrong. For extra credit, 
list the implicit preconceptions that might have led to such a wrong 
conclusion.

"Lawrence D'Oliveiro" <ldo@geek-central.gen.new_zealand> wrote in message 
news:iio27n$g2f$2@lust.ihug.co.nz...
> In message <4d4f61fb$0$23756$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>
>> On 06-02-2011 21:53, Lawrence D'Oliveiro wrote:
>>
>>> In message<4d4f56ac$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj 
>>> wrote:
>>>
>>>> As explained numerous times then Java generics and C++ templates
>>>> are somewhat different.
>>>
>>> The only differences arise from limitations of Java, nothing more.
>>
>> No. The differences arise from different decisions on what they
>> wanted.
>
> The Java designers wanted everything that C++ templates offered.

"God, if only we could have gotten code bloat and terminally confused the 
separation between compiler and linker!"
 

"Lawrence D'Oliveiro" <ldo@geek-central.gen.new_zealand> wrote in message 
news:iio2be$g2f$3@lust.ihug.co.nz...
> In message <4d4f4a54$0$23753$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>
>> On 06-02-2011 19:04, Thomas Richter wrote:
>>
>>> And in C++, a compiler can also> merge template instances because they
>>> are identical, i.e. function alike, i.e. for example they all operate on
>>> pointers.
>>
>> Possible. But if two template usages are compiled separatetly,
>> then it is not possible.
>
> Exercise for the reader: explain why Arne Vajhøj is wrong. For extra 
> credit,
> list the implicit preconceptions that might have led to such a wrong
> conclusion.

Arne is assuming that compilation and linking are separate phases.  This was 
one of the original design goals of C++, as you might recall from 
Stroustrup's _Design and Evolution of C++_: that the C++ compiler produce 
object code that the standard system linker could process. .  It's no longer 
true in many C++ development systems, precisely because templates make that 
impossible to achieve with any efficiency.

 

On 2/7/11 2:52 PM, Mike Schilling wrote:
> [...]
>>> Possible. But if two template usages are compiled separatetly,
>>> then it is not possible.
>>
>> Exercise for the reader: explain why Arne Vajhøj is wrong. For extra
>> credit,
>> list the implicit preconceptions that might have led to such a wrong
>> conclusion.
>
> Arne is assuming that compilation and linking are separate phases. This
> was one of the original design goals of C++, as you might recall from
> Stroustrup's _Design and Evolution of C++_: that the C++ compiler
> produce object code that the standard system linker could process. .
> It's no longer true in many C++ development systems, precisely because
> templates make that impossible to achieve with any efficiency.

I agree with Arne's statement from a practical point of view.  However, 
note that there's not really any theoretical reason a linker could not 
inspect the object files for redundant code and optimize template usages 
where possible.

A long time ago, I worked on a project that used a form of interpreted 
byte code in which the linker did exactly that.  In that situation, the 
reason we were using the byte code in the first place was for 
compression, to help the program fit in memory (it was a relatively 
large program, running on Mac and Windows computers without virtual 
memory).  So the "quoting" feature was important enough to make it worth 
doing.

In fact, that feature did not rely on C++ templates at all.  We were 
coding in plain C, and it detected any code that was essentially 
copy/paste or nearly so.

Pete

On 2/7/11 3:54 PM, Peter Duniho wrote:
> [...]
> A long time ago, I worked on a project that used a form of interpreted
> byte code in which the linker did exactly that. In that situation, the
> reason we were using the byte code in the first place was for
> compression, to help the program fit in memory (it was a relatively
> large program, running on Mac and Windows computers without virtual
> memory). So the "quoting" feature was important enough to make it worth
> doing.
>
> In fact, that feature did not rely on C++ templates at all. We were
> coding in plain C, and it detected any code that was essentially
> copy/paste or nearly so.

I guess I should also mention that the interpreter itself supported the 
quoting feature, so it was a lot simpler to rewrite any code that needed 
to be shared: just remove the actual code and replace with the "quote" 
instruction referring to the quoted code.  There also was no 
multi-threading for the code back in those days.

It'd be a bit more complicated for a linker to accomplish a similar 
feature, but it's not like it's an intractable problem.  I think turning 
the quote into a function call would solve most issues, if not 
everything, and of course if you quote an entire function, that's even 
easier.

Pete

"Lawrence D'Oliveiro" spat:
>> Exercise for the reader: explain why Arne Vajhøj is wrong. For extra credit,
>> list the implicit preconceptions that might have led to such a wrong
>> conclusion.

"Exercise for the reader" because the writer couldn't come up with any logical 
or reasoned arguments, so he waves his hands and exercises trollishness instead.

What a maroon!

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

On 02/07/2011 01:06 AM, Lawrence D'Oliveiro wrote:
> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> And the C spec leaves a lot of things to implementations.
>
> Not too much that you can’t write portable code in it.

Writing portable code in C pretty much requires you to do hefty 
compatibility layers. Many projects use typedefs to get proper-sized int 
variables (you can't use stdint.h, as MSVC doesn't implement it, as of 
MSVC 9.0). Anything more complex than basic I/O requires the use of 
other, largely incompatible layers, for common things like 
multithreading, asynchronous I/O, network I/O, etc. Let's not even get 
into basic GUIs.

And even then, a careful reading of the C standard would reveal that it 
gives very few absolute requirements of stuff, so that I could make 
size_t be an 800-bit integer and still follow the standard, as well as 
probably breaking everyone's so-called "portable C" code.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Lawrence D'Oliveiro wrote:
> In message <iimf47$soo$1@news.belwue.de>, Thomas Richter wrote:
> 
>> Templates allow meta-programming, i.e. you can use the compiler to
>> generate code.
> 
> Why, what do compilers normally do?

Generate source code, or rather, evaluate expressions at compile time 
rather than run time. Compilers usually take the source code and create 
executable code from that, but the C++ template system allows you to 
instruct the compiler to do parts of this evaluation while compiling.

So long,
	Thomas

Lawrence D'Oliveiro wrote:
> In message <iinft1$95e$1@speranza.aioe.org>, javax.swing.JSnarker wrote:
> 
>> On 06/02/2011 7:32 PM, Lawrence D'Oliveiro wrote:
>>
>>> In message<iincuv$ot9$1@news.belwue.de>, Thomas Richter wrote:
>>>
>>>> There is no "ClassCastException" in C++.
>>> Yes there is. It’s called “bad_cast”. Where do you think Java got the
>>> idea from?
>> dynamic_cast<foo>(bar) can throw this if bar is not really a foo. But
>> C++ lets you use the unsafe old (foo)bar cast from C, and if bar is not
>> really a foo, welcome to undefined behaviorville.
> 
> The fact remains, there IS an equivalent to ClassCastException in C++.

The fact remains that this is irrelevant to the discussion. Templates 
aren't used like this in C++, and the C++ compiler doesn't insert a type 
check into the binary to see whether the types match. The type check is 
done at compile time. Besides, dynamic_cast<> only throws if the 
involved objects have virtual functions, and thus have run time type 
information available, and the types are not compatible. It thus also 
works quite different.

Greetings,
	Thomas

Lew wrote:
> "Lawrence D'Oliveiro" spat:
>>> Exercise for the reader: explain why Arne Vajhøj is wrong. For extra 
>>> credit,
>>> list the implicit preconceptions that might have led to such a wrong
>>> conclusion.
> 
> "Exercise for the reader" because the writer couldn't come up with any 
> logical or reasoned arguments, so he waves his hands and exercises 
> trollishness instead.

Not at all. The reason is exactly as already stated, namely that people 
seem to assume that the linker has no intelligence, or that there is a 
linker in first place. Nevertheless, the C++ standard doesn't even 
define linking, and the world is no longer that simple. Thus, I still 
don't see how this argument applies. Surely the C++ world works 
different from the java world, but saying that there is no duplicate 
code in Java or that there is always code duplication in C++ is surely 
wrong.

Greetings,
	Thomas

On 02/07/2011 03:15 AM, Arne Vajhøj wrote:
> On 06-02-2011 20:55, Lawrence D'Oliveiro wrote:
>> In message<4d4e7634$0$81475$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>> Oh, I remember how well C++ and its undefined sizes of things served us
>>> when we had to port heaps of code from 16-bit to 32-bit.
>
> It is 8086 architecture not 80286 architecture.
>
>> By “16-bit” I take it you specifically mean “Windows/Intel 16-bit”,
>> i.e. the
>> segmented 80286 architecture (spit). That was the only major 16-bit
>> architecture I’m aware of that made portability difficult.
>
> Windows has nothing to do with CPU architecture.
>
> And the problem Silvio talks about (undefined sizes) is
> not related to segmented memory.
>
> Arne
>
>
>
Absolutely correct. It is very easy to write potentially broken C++ 
programs that run perfectly fine on a certain architecture compiled with 
a certain C++ compiler using a certain set of compiler options.

Bad programs may depend on different types of invalid assumptions. To 
name a few: assume sizeof(T)==sizeof(U), assume char is signed/unsigned, 
assume bitfields are signed/unsigned, make assumptions about struct 
alignment.

For certain APIs (MS Windows conatins lots of them) struct layout 
assumpations are essential. Since there was no standard way of 
expressing such assumtions code could easily break just by changing some 
compiler options. For that reason, each C++ distro came with its own 
Windows header files.

Perhaps things have improved since I moved away from C++ in '99.

In message <iiop28$8jj$1@news.eternal-september.org>, Joshua Cranmer wrote:

> On 02/07/2011 01:06 AM, Lawrence D'Oliveiro wrote:
>
>> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>> And the C spec leaves a lot of things to implementations.
>>
>> Not too much that you can’t write portable code in it.
> 
> Writing portable code in C pretty much requires you to do hefty
> compatibility layers.

Not really. Sticking to standard POSIX types like size_t, time_t etc gets 
you a lot of the way there.

> Many projects use typedefs to get proper-sized int variables (you can't
> use stdint.h, as MSVC doesn't implement it, as of MSVC 9.0).

How sad for MSVC...

In message <iiotfv$2i3$1@news.belwue.de>, Thomas Richter wrote:

> Lawrence D'Oliveiro wrote:
>
>> In message <iimf47$soo$1@news.belwue.de>, Thomas Richter wrote:
>> 
>>> Templates allow meta-programming, i.e. you can use the compiler to
>>> generate code.
>> 
>> Why, what do compilers normally do?
> 
> Generate source code ...

Really??

In message <4d4f693f@news.x-privat.org>, Ken Wesson wrote:

> Heck, they had BigInteger from the outset and could have gone so far as
> to include a true numeric tower, implicit conversions all the way up to
> BigInteger ...

Which is what Python did.

In message <4d4f5774$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 21:11, Lawrence D'Oliveiro wrote:
>
>> In message<4d4f5367$0$23761$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>
>>> On 06-02-2011 20:52, Lawrence D'Oliveiro wrote:
>>>
>>>> In message<4d4f4d64$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj
>>>> wrote:
>>>>
>>>>> On 06-02-2011 18:14, Lawrence D'Oliveiro wrote:
>>>>>
>>>>>> In message<b5GdnQ-xIKYHc9PQnZ2dnUVZ_vCdnZ2d@earthlink.com>, Patricia
>>>>>> Shanahan wrote:
>>>>>>>
>>>>>>> I am aware of one issue in the simple data types that reflects 32
>>>>>>> bit architecture, JLS section 17.7, "Non-atomic Treatment of double
>>>>>>> and long".
>>>>>>>
>>>>>>> The big way in which Java is tied to 32 bit architectures is not in
>>>>>>> the simple data types. It is the maximum size of an array, String,
>>>>>>> Set, List etc.
>>>>>>
>>>>>> Also in the fact that array subscripts cannot be long.
>>>>>
>>>>> But that has nothing to do with simple data types.
>>>>
>>>> What is long?
>>>
>>> A simple data type.
>>>
>>> But it is still a characteristics of array not of long.
>>
>> Which is a limitation that comes from a fixation on 32-bit architectures,
>> without a thought for 64-bit ones.
> 
> It is not an assumption about 32 bit architecture. 32 bit
> architecture limits it more than the Java rule.

But the Java rule is the limitation now.

On 02/07/2011 03:22 PM, Lawrence D'Oliveiro wrote:
> In message<iiotfv$2i3$1@news.belwue.de>, Thomas Richter wrote:
>
>> Lawrence D'Oliveiro wrote:
>>
>>> In message<iimf47$soo$1@news.belwue.de>, Thomas Richter wrote:
>>>
>>>> Templates allow meta-programming, i.e. you can use the compiler to
>>>> generate code.
>>>
>>> Why, what do compilers normally do?
>>
>> Generate source code ...
>
> Really??

You trimmed the part where he elaborated on what that phrase meant.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On 11-02-06 08:29 PM, Lawrence D'Oliveiro wrote:
> In message<4d4e25e8@news.x-privat.org>, Ken Wesson wrote:
>
>> Java is very widely used for network and business applications, and web
>> apps, these days ...
>
> I was trying to make sense of where you were coming from with your
> predictions, and then I realized—you’re primarily talking about corporate
> development. Because that’s just about the only place languages like Java
> and C#/Dotnet get much use.

You make "corporate" software sound like a niche market. Yeah, software 
for business and governments is such a little category, ain't it.

> Very few mass-market or open-source apps are
> written in those languages, for example.

Holy fuck. You're officially completely detached from reality.

[ SNIP ]
AHS

-- 
We must recognize the chief characteristic of the modern era - a 
permanent state of what I call violent peace.
-- James D. Watkins

On 7/02/2011 5:07 PM, Lawrence D'Oliveiro wrote:
> The Java designers wanted everything that C++ templates offered.

It should be obvious from the design that they wanted a great deal more 
than that. They wanted a coherent type system for a start, which C++ 
templates don't have, and they wanted compile-time safety, which 
*requires* a coherent type system. That's what all the T super X and T 
extends Y stuff is for - so the compiler can do type algebra. None of 
this appears in C++ whatsoever.

It is totally and utterly wrong misleading to think of Java Generics and 
C++ templates as similar. They are really polar opposites. C++ templates 
generate new types. Java Generics restrict existing types.

On 07-02-2011 01:07, Lawrence D'Oliveiro wrote:
> In message<4d4f61fb$0$23756$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 06-02-2011 21:53, Lawrence D'Oliveiro wrote:
>>> In message<4d4f56ac$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>>> As explained numerous times then Java generics and C++ templates
>>>> are somewhat different.
>>>
>>> The only differences arise from limitations of Java, nothing more.
>>
>> No. The differences arise from different decisions on what they
>> wanted.
>
> The Java designers wanted everything that C++ templates offered. The only
> parts they omitted were the ones they couldn’t have.

Why do you think that?

They implemented something very different.

Arne

On 07-02-2011 09:01, Thomas Richter wrote:
> Lew wrote:
>> "Lawrence D'Oliveiro" spat:
>>>> Exercise for the reader: explain why Arne Vajhøj is wrong. For extra
>>>> credit,
>>>> list the implicit preconceptions that might have led to such a wrong
>>>> conclusion.
>>
>> "Exercise for the reader" because the writer couldn't come up with any
>> logical or reasoned arguments, so he waves his hands and exercises
>> trollishness instead.
>
> Not at all. The reason is exactly as already stated, namely that people
> seem to assume that the linker has no intelligence, or that there is a
> linker in first place. Nevertheless, the C++ standard doesn't even
> define linking, and the world is no longer that simple. Thus, I still
> don't see how this argument applies. Surely the C++ world works
> different from the java world, but saying that there is no duplicate
> code in Java or that there is always code duplication in C++ is surely
> wrong.

It how the simple implementations do it.

It is what the common implementations do it.

What various super smart optimizers may do is pretty
far fetched.

Arne

On 06-02-2011 10:35, Thomas Richter wrote:
> Joshua Cranmer wrote:
>> Templates in C++ are basically advanced macros--each invocation of a
>> template type regenerates the class, so a Foo<int> and a Foo<double>
>> are two completely different things.
>
> That's much more than a macro could do. Templates are a language of its
> own, include syntax checks, etc. Quite unlike macros, they do not
> substitute text patterns. Templates allow meta-programming, i.e. you can
> use the compiler to generate code. And, of course, templates are quite
> complex - very unlike the simple-minded preprocessor.

C++ templates are like many other C++ features very powerful.

You can create some very elegant solution or make a big hole
in your foot with it.

Arne

On 07-02-2011 01:06, Lawrence D'Oliveiro wrote:
> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 06-02-2011 18:23, Lawrence D'Oliveiro wrote:
>>> For comparison, I have a couple of draft C99 specs floating around. They
>>> total 550 pages, until you realize most of that is section 7, the
>>> standard library. Leave that out, and you end up with 163 pages.
>>
>> I am not sure that comparing a language reference with a standard
>> spec gives much meaning.
>
> That’s right, I forgot there is no “standard spec” for Java, it is simply
> what Sunacle says it is.

What do you think the S in JLS stands for?

>> And the C spec leaves a lot of things to implementations.
>
> Not too much that you can’t write portable code in it.

Real C apps that will run predictable on any platform is
pretty rare.

Real C apps that support a wide range of platforms via
ifdef's are common.

C apps that the programmer think is portable but is not
are also common.

Arne

On 07-02-2011 15:22, Lawrence D'Oliveiro wrote:
> In message<iiop28$8jj$1@news.eternal-september.org>, Joshua Cranmer wrote:
>> On 02/07/2011 01:06 AM, Lawrence D'Oliveiro wrote:
>>> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>>> And the C spec leaves a lot of things to implementations.
>>>
>>> Not too much that you can’t write portable code in it.
>>
>> Writing portable code in C pretty much requires you to do hefty
>> compatibility layers.
>
> Not really. Sticking to standard POSIX types like size_t, time_t etc gets
> you a lot of the way there.

POSIX does not cover all aspects.

And not all platforms are POSIX compliant.

Arne

On 07-02-2011 12:58, Silvio wrote:
> On 02/07/2011 03:15 AM, Arne Vajhøj wrote:
>> On 06-02-2011 20:55, Lawrence D'Oliveiro wrote:
>>> In message<4d4e7634$0$81475$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>>> Oh, I remember how well C++ and its undefined sizes of things served us
>>>> when we had to port heaps of code from 16-bit to 32-bit.
>>
>> It is 8086 architecture not 80286 architecture.
>>
>>> By “16-bit” I take it you specifically mean “Windows/Intel 16-bit”,
>>> i.e. the
>>> segmented 80286 architecture (spit). That was the only major 16-bit
>>> architecture I’m aware of that made portability difficult.
>>
>> Windows has nothing to do with CPU architecture.
>>
>> And the problem Silvio talks about (undefined sizes) is
>> not related to segmented memory.

> Absolutely correct. It is very easy to write potentially broken C++
> programs that run perfectly fine on a certain architecture compiled with
> a certain C++ compiler using a certain set of compiler options.
>
> Bad programs may depend on different types of invalid assumptions. To
> name a few: assume sizeof(T)==sizeof(U), assume char is signed/unsigned,
> assume bitfields are signed/unsigned, make assumptions about struct
> alignment.
>
> For certain APIs (MS Windows conatins lots of them) struct layout
> assumpations are essential. Since there was no standard way of
> expressing such assumtions code could easily break just by changing some
> compiler options. For that reason, each C++ distro came with its own
> Windows header files.
>
> Perhaps things have improved since I moved away from C++ in '99.

The current C and C++ standards are from 99 and 98, so not
that much has changed.

I think that compiler support for the standards has improved some.

Arne

On 07-02-2011 15:48, Lawrence D'Oliveiro wrote:
> In message<4d4f5774$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>
>> On 06-02-2011 21:11, Lawrence D'Oliveiro wrote:
>>
>>> In message<4d4f5367$0$23761$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>>
>>>> On 06-02-2011 20:52, Lawrence D'Oliveiro wrote:
>>>>
>>>>> In message<4d4f4d64$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj
>>>>> wrote:
>>>>>
>>>>>> On 06-02-2011 18:14, Lawrence D'Oliveiro wrote:
>>>>>>
>>>>>>> In message<b5GdnQ-xIKYHc9PQnZ2dnUVZ_vCdnZ2d@earthlink.com>, Patricia
>>>>>>> Shanahan wrote:
>>>>>>>>
>>>>>>>> I am aware of one issue in the simple data types that reflects 32
>>>>>>>> bit architecture, JLS section 17.7, "Non-atomic Treatment of double
>>>>>>>> and long".
>>>>>>>>
>>>>>>>> The big way in which Java is tied to 32 bit architectures is not in
>>>>>>>> the simple data types. It is the maximum size of an array, String,
>>>>>>>> Set, List etc.
>>>>>>>
>>>>>>> Also in the fact that array subscripts cannot be long.
>>>>>>
>>>>>> But that has nothing to do with simple data types.
>>>>>
>>>>> What is long?
>>>>
>>>> A simple data type.
>>>>
>>>> But it is still a characteristics of array not of long.
>>>
>>> Which is a limitation that comes from a fixation on 32-bit architectures,
>>> without a thought for 64-bit ones.
>>
>> It is not an assumption about 32 bit architecture. 32 bit
>> architecture limits it more than the Java rule.
>
> But the Java rule is the limitation now.

I think everybody agrees with that.

Arne

On 02/07/2011 01:07 AM, Lawrence D'Oliveiro wrote:
> The Java designers wanted everything that C++ templates offered. The only
> parts they omitted were the ones they couldn’t have.

No, it is very possible to have fully implemented C++ templates. As C++ 
templates are basically a semantically-aware macro processor whose code 
is created at instantiation as opposed to definition, you just have to 
generate the class files at template instantiation as opposed to class 
definition. That basically boils down to "twiddle a few bits in the 
class file", so it's no more invasive than generics was.

If you argue that wasn't an option because they didn't want to rewrite 
the collections API (which .NET decided to do), it's still possible to 
leverage roughly the same effect with more invasive modifications to the 
bytecode. You can get reified types by creating a new method info 
structure which captures the generic arguments passed into the method 
(for constructors, this would be the generic class passed in), which you 
could store in an appropriate synthetic variable. You could even get the 
duck typing nature of templates with invokedynamic (well, it wouldn't 
work for primitive types, but generics already through those out the 
window).

They could have had all of C++ templates. Clearly, they did not feel the 
benefits of full template support would be worth the cost of implementation.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

In message <4d4f55ba$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 20:55, Lawrence D'Oliveiro wrote:
>
>> In message<4d4e7634$0$81475$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>
>>> Oh, I remember how well C++ and its undefined sizes of things served us
>>> when we had to port heaps of code from 16-bit to 32-bit.
> 
> It is 8086 architecture not 80286 architecture.
> 
>> By “16-bit” I take it you specifically mean “Windows/Intel 16-bit”, i.e.
>> the segmented 80286 architecture (spit). That was the only major 16-bit
>> architecture I’m aware of that made portability difficult.
> 
> Windows has nothing to do with CPU architecture.

DOS/Windows is the only reason 8086/80286 segmented architectures became 
popular.

In message <4d5032a8$0$41114$e4fe514c@news.xs4all.nl>, Silvio wrote:

> For certain APIs (MS Windows conatins lots of them) struct layout
> assumpations are essential.

POSIX manages such things in a portable way. Windows not only doesn’t, it 
manages to saddle Win64 APIs with all kinds of 32-bit compatibility baggage 
from Win32.

In message <4d4f54fc$0$23753$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 20:53, Lawrence D'Oliveiro wrote:
>
>> In message<iilaco$dd0$1@news.eternal-september.org>, Joshua Cranmer
>> wrote:
>>
>>> I would venture a guess that most C or C++ code isn't as easily portable
>>> to 64-bit platforms as you would think ...
>>
>> Most of the C/C++ code I deal with is open-source, and essentially all of
>> that is portable between 32-bit and 64-bit nowadays. As well as across
>> non- x86 architectures, for that matter.
> 
> Without ifdef's ????

Relevance being?

>> Ironic, isn’t it, that the early Java slogan was "write once, run
>> everywhere”...
> 
> anywhere not everywhere

Is Java for anyone, or everyone?

In message <4d50949a$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 07-02-2011 01:06, Lawrence D'Oliveiro wrote:
>
>> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>
>>> On 06-02-2011 18:23, Lawrence D'Oliveiro wrote:
>>>>
>>>> For comparison, I have a couple of draft C99 specs floating around.
>>>> They total 550 pages, until you realize most of that is section 7, the
>>>> standard library. Leave that out, and you end up with 163 pages.
>>>
>>> I am not sure that comparing a language reference with a standard
>>> spec gives much meaning.
>>
>> That’s right, I forgot there is no “standard spec” for Java, it is simply
>> what Sunacle says it is.
> 
> What do you think the S in JLS stands for?

Not “standard”.

>>> And the C spec leaves a lot of things to implementations.
>>
>> Not too much that you can’t write portable code in it.
> 
> Real C apps that will run predictable on any platform is
> pretty rare.

Really?? We have them coming out our ears. I have thousands of them 
installed on my system alone. Let’s see, the Linux kernel, 15 million lines 
of source code, almost entirely in C, portable across about two dozen 
different major processor architectures. GCC, Apache, Python, Blender (a 
million lines of C, plus about 220 thousand lines of C++), Gimp ... the list 
goes on and on.

In message <4d5094f2$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 07-02-2011 15:22, Lawrence D'Oliveiro wrote:
>
>> In message<iiop28$8jj$1@news.eternal-september.org>, Joshua Cranmer
>> wrote:
>>>
>>> On 02/07/2011 01:06 AM, Lawrence D'Oliveiro wrote:
>>>
>>>> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj
>>>> wrote:
>>>>> And the C spec leaves a lot of things to implementations.
>>>>
>>>> Not too much that you can’t write portable code in it.
>>>
>>> Writing portable code in C pretty much requires you to do hefty
>>> compatibility layers.
>>
>> Not really. Sticking to standard POSIX types like size_t, time_t etc gets
>> you a lot of the way there.
> 
> POSIX does not cover all aspects.

Well, you need tools like autoconf as well to handle the more complicated 
cases.

> And not all platforms are POSIX compliant.

All the ones worth using are.

On 07-02-2011 22:00, Lawrence D'Oliveiro wrote:
> In message<4d4f54fc$0$23753$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 06-02-2011 20:53, Lawrence D'Oliveiro wrote:
>>> In message<iilaco$dd0$1@news.eternal-september.org>, Joshua Cranmer
>>> wrote:
>>>> I would venture a guess that most C or C++ code isn't as easily portable
>>>> to 64-bit platforms as you would think ...
>>>
>>> Most of the C/C++ code I deal with is open-source, and essentially all of
>>> that is portable between 32-bit and 64-bit nowadays. As well as across
>>> non- x86 architectures, for that matter.
>>
>> Without ifdef's ????
>
> Relevance being?

That it is not portable - it just support a number of platforms.

>>> Ironic, isn’t it, that the early Java slogan was "write once, run
>>> everywhere”...
>>
>> anywhere not everywhere
>
> Is Java for anyone, or everyone?

The slogan used "anywhere".

(which is why the acronym is WORA not WORE)

Arne

In message <iiprgj$1h4$1@news.eternal-september.org>, Joshua Cranmer wrote:

> On 02/07/2011 03:22 PM, Lawrence D'Oliveiro wrote:
>
>> In message<iiotfv$2i3$1@news.belwue.de>, Thomas Richter wrote:
>>
>>> Lawrence D'Oliveiro wrote:
>>>
>>>> In message<iimf47$soo$1@news.belwue.de>, Thomas Richter wrote:
>>>>
>>>>> Templates allow meta-programming, i.e. you can use the compiler to
>>>>> generate code.
>>>>
>>>> Why, what do compilers normally do?
>>>
>>> Generate source code ...
>>
>> Really??
> 
> You trimmed the part where he elaborated on what that phrase meant.

You mean, where he explained “generate” didn’t mean “generate”, or “source 
code” didn’t mean “source code”?

Black is white. Let me alaborate on that: no it isn’t.

On 07-02-2011 21:57, Lawrence D'Oliveiro wrote:
> In message<4d4f55ba$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 06-02-2011 20:55, Lawrence D'Oliveiro wrote:
>>> In message<4d4e7634$0$81475$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>>
>>>> Oh, I remember how well C++ and its undefined sizes of things served us
>>>> when we had to port heaps of code from 16-bit to 32-bit.
>>
>> It is 8086 architecture not 80286 architecture.
>>
>>> By “16-bit” I take it you specifically mean “Windows/Intel 16-bit”, i.e.
>>> the segmented 80286 architecture (spit). That was the only major 16-bit
>>> architecture I’m aware of that made portability difficult.
>>
>> Windows has nothing to do with CPU architecture.
>
> DOS/Windows is the only reason 8086/80286 segmented architectures became
> popular.

That does not make Windows part of the CPU architecture.

Arne

On 8/02/2011 1:57 PM, Lawrence D'Oliveiro wrote:
> DOS/Windows is the only reason 8086/80286 segmented architectures became
> popular.

Another blanket statement ex cathedra.

That's not what the guys at Intel think, or the guys at Motorola either. 
They will tell you that despite its ugliness at the point of code 
generation the Intel segmented architecture yielded very significant 
cost and performance benefits that basically drove Motorola out of the 
market.

On 07-02-2011 21:59, Lawrence D'Oliveiro wrote:
> In message<4d5032a8$0$41114$e4fe514c@news.xs4all.nl>, Silvio wrote:
>> For certain APIs (MS Windows conatins lots of them) struct layout
>> assumpations are essential.
>
> POSIX manages such things in a portable way.

No.

POSIX does the same thing as Windows.

Use compiler specific header files to get the correct
physical layout.

(POSIX uses fewer structs than Windows, but ...)

Arne

In message <iiotom$2ml$1@news.belwue.de>, Thomas Richter wrote:

> Lawrence D'Oliveiro wrote:
>
>> In message <iinft1$95e$1@speranza.aioe.org>, javax.swing.JSnarker wrote:
>> 
>>> On 06/02/2011 7:32 PM, Lawrence D'Oliveiro wrote:
>>>
>>>> In message<iincuv$ot9$1@news.belwue.de>, Thomas Richter wrote:
>>>>
>>>>> There is no "ClassCastException" in C++.
>>>>
>>>> Yes there is. It’s called “bad_cast”. Where do you think Java got the
>>>> idea from?
>>>>
>>> dynamic_cast<foo>(bar) can throw this if bar is not really a foo. But
>>> C++ lets you use the unsafe old (foo)bar cast from C, and if bar is not
>>> really a foo, welcome to undefined behaviorville.
>> 
>> The fact remains, there IS an equivalent to ClassCastException in C++.
> 
> The fact remains that this is irrelevant to the discussion.

The fact remains, the poster said “There is no "ClassCastException" in C++”, 
which I understood to mean “There is no equivalent to "ClassCastException" 
in C++”, which is wrong.

> Templates aren't used like this in C++ ...

Templates are orthogonal to the business of class casts.

> ... and the C++ compiler doesn't insert a type check into the binary to
> see whether the types match.

It does for the C++ equivalent to the Java subclass cast.

> Besides, dynamic_cast<> only throws if the involved objects have virtual
> functions, and thus have run time type information available, and the
> types are not compatible.

I went over section 5.2.7 “Dynamic cast” of the C++ standard very carefully, 
and I can find no such proviso. It’s only a page and a half, so I think it’s 
unlikely I missed anything.

Have a look for yourself and see if I’m right or wrong.

In message <4d507f8a$0$32793$c30e37c6@exi-reader.telstra.net>, Esmond Pitt 
wrote:

> On 7/02/2011 5:07 PM, Lawrence D'Oliveiro wrote:
>
>> The Java designers wanted everything that C++ templates offered.
> 
> It should be obvious from the design that they wanted a great deal more
> than that. They wanted a coherent type system for a start, which C++
> templates don't have ...

In that case, they went backwards. Because the whole “raw types” concept 
detracts from and weakens the coherence of the type system.

> That's what all the T super X and T extends Y stuff is for - so the
> compiler can do type algebra. None of this appears in C++ whatsoever.

What one hand giveth, the other taketh away...

On 07-02-2011 22:06, Lawrence D'Oliveiro wrote:
> In message<4d50949a$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>
>> On 07-02-2011 01:06, Lawrence D'Oliveiro wrote:
>>
>>> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>>
>>>> On 06-02-2011 18:23, Lawrence D'Oliveiro wrote:
>>>>>
>>>>> For comparison, I have a couple of draft C99 specs floating around.
>>>>> They total 550 pages, until you realize most of that is section 7, the
>>>>> standard library. Leave that out, and you end up with 163 pages.
>>>>
>>>> I am not sure that comparing a language reference with a standard
>>>> spec gives much meaning.
>>>
>>> That’s right, I forgot there is no “standard spec” for Java, it is simply
>>> what Sunacle says it is.
>>
>> What do you think the S in JLS stands for?
>
> Not “standard”.

specification

It is the specification for Java.

>>>> And the C spec leaves a lot of things to implementations.
>>>
>>> Not too much that you can’t write portable code in it.
>>
>> Real C apps that will run predictable on any platform is
>> pretty rare.
>
> Really?? We have them coming out our ears. I have thousands of them
> installed on my system alone. Let’s see, the Linux kernel, 15 million lines
> of source code, almost entirely in C, portable across about two dozen
> different major processor architectures. GCC, Apache, Python, Blender (a
> million lines of C, plus about 220 thousand lines of C++), Gimp ... the list
> goes on and on.

No. I don't think many of those apps are portable C. Most likely
none of them are. Those apps are just ported to a number of platforms.
Ported by someone adding #ifdef sections etc. to make them work
on a specific platform.

Arne

On 07-02-2011 22:06, Lawrence D'Oliveiro wrote:
> In message<4d5094f2$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 07-02-2011 15:22, Lawrence D'Oliveiro wrote:
>>> In message<iiop28$8jj$1@news.eternal-september.org>, Joshua Cranmer
>>> wrote:
>>>> On 02/07/2011 01:06 AM, Lawrence D'Oliveiro wrote:
>>>>> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj
>>>>> wrote:
>>>>>> And the C spec leaves a lot of things to implementations.
>>>>>
>>>>> Not too much that you can’t write portable code in it.
>>>>
>>>> Writing portable code in C pretty much requires you to do hefty
>>>> compatibility layers.
>>>
>>> Not really. Sticking to standard POSIX types like size_t, time_t etc gets
>>> you a lot of the way there.
>>
>> POSIX does not cover all aspects.
>
> Well, you need tools like autoconf as well to handle the more complicated
> cases.

The existence of that tool is an indication that there is a
portability problem.

But autoconf does not solve all problems.

>> And not all platforms are POSIX compliant.
>
> All the ones worth using are.

Well - I don't think anyone defines portability as
running unchanged on the platform one specific
person considers worth using.

Arne

"Lawrence D'Oliveiro" wrote:
>> DOS/Windows is the only reason 8086/80286 segmented architectures became
>> popular.

Esmond Pitt wrote:
> Another blanket statement ex cathedra.
>
> That's not what the guys at Intel think, or the guys at Motorola either. They
> will tell you that despite its ugliness at the point of code generation the
> Intel segmented architecture yielded very significant cost and performance
> benefits that basically drove Motorola out of the market.

Intel brought quite a few innovations in quite early, many of which went 
nearly unnoticed for a while.  The '286 and up have privilege rings and 
support for multitasking in the hardware, for example.  Only a couple of OSes 
really used that stuff back then.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

Joshua Cranmer wrote :
> On 02/06/2011 06:54 PM, Lawrence D'Oliveiro wrote:
>> Strange that Java never copied the C++ operator names "and”, “or” and 
>> “not”.
>
> Why should it have? They're just aliases for other objects. By your 
> reasoning, Java should also have copied the C trigraphs or the other tokens 
> in the "Alternative tokens". You know, for the three people in the world who 
> do not have { on their keyboard.

Actually trigraphs are more for environments that do not have []^~ and 
a few other characters in their character set. Such as IBM mainframe 
OSs.

I had to write a standard C to IBM mainframe converter a few years ago 
(yikes, 1990!). Things like variable names need to be upper case, limit 
of 8 characters for variables, methods, etc.

-- 
Wojtek :-)

"Wojtek" <nowhere@a.com> wrote in message 
news:mn.3cdb7db26ff3ad18.70216@a.com...
>
> I had to write a standard C to IBM mainframe converter a few years ago 
> (yikes, 1990!).


Good!  (That I'm not the only one who does that.)
 

On 8/02/2011 2:17 PM, Lawrence D'Oliveiro wrote:
> In that case, they went backwards. Because the whole “raw types” concept
> detracts from and weakens the coherence of the type system.

It provides backwards compatibility. Without that the product would be 
unusable. It is possible to wish that the entire product was designed at 
the same time, but it wasn't. In any case your contention was mistaken.

The designers also went forwards a very considerable distance by 
providing generic classes that have provable type relationships among 
them. C++ simply doesn't have that. You need to stop overlooking this point.

On 8/02/2011 3:19 PM, Lew wrote:
> Intel brought quite a few innovations in quite early, many of which went
> nearly unnoticed for a while. The '286 and up have privilege rings and
> support for multitasking in the hardware, for example. Only a couple of
> OSes really used that stuff back then.

Exactly, and neither DOS nor Windows 2/3 being in that list.

In message <4d50b4dc$0$32795$c30e37c6@exi-reader.telstra.net>, Esmond Pitt 
wrote:

> On 8/02/2011 1:57 PM, Lawrence D'Oliveiro wrote:
>
>> DOS/Windows is the only reason 8086/80286 segmented architectures became
>> popular.
> 
> That's not what the guys at Intel think, or the guys at Motorola either.
> They will tell you that despite its ugliness at the point of code
> generation the Intel segmented architecture yielded very significant
> cost and performance benefits that basically drove Motorola out of the
> market.

Intel had the volume advantage, that’s all. And it got the volume from 
DOS/Windows, nothing else.

In message <4d50da6e$0$32794$c30e37c6@exi-reader.telstra.net>, Esmond Pitt 
wrote:

>> The '286 and up have privilege rings and support for multitasking in the
>> hardware, for example. Only a couple of OSes really used that stuff back
>> then.
> 
> Exactly, and neither DOS nor Windows 2/3 being in that list.

Nobody seriously used that stuff, because none of it was of any use.

The only OS designed to try to make use of it, OS/2, flopped.

Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
> Because the whole “raw types” concept detracts from and weakens
> the coherence of the type system.

The "problem" about type-erasure is over-rated.

Suppose, an instance created so: Object o = new ArrayList<String>();
actually "knew" that it was an ArrayList of Strings (and not just
that it was an ArrayList, as it does now).
Then you would get a *runtime*-Error, if you tried to cast "o" to
ArrayList<Integer>, later.  But generics aren't about runtime errors.
They are about being able to prevent some runtime-errors, by turning
them into compile-time errors. So, giving *still runtime*-errors for
casting between generic types of incompatible parametrizations is only
little win over giving runtime-errors on element-use.

Andreas Leitgeb wrote:
> The "problem" about type-erasure is over-rated.
>
> Suppose, an instance created so: Object o = new ArrayList<String>();
> actually "knew" that it was an ArrayList of Strings (and not just
> that it was an ArrayList, as it does now).
> Then you would get a *runtime*-Error, if you tried to cast "o" to
> ArrayList<Integer>, later.  But generics aren't about runtime errors.
> They are about being able to prevent some runtime-errors, by turning
> them into compile-time errors. So, giving *still runtime*-errors for
> casting between generic types of incompatible parametrizations is only
> little win over giving runtime-errors on element-use.

I'm very glad you made that point.  I am glad we have type erasure in Java. 
It forces you to deal with type assertions at compile time.

The problem with reifiable types is that it's too easy to do a half-assed job 
of your type analysis, thus resulting in the runtime errors to which Andreas 
alludes.  Besides, all you need to do to get runtime typing is to include a 
runtime type token as a final member of your class and Bob's your uncle.  Like 
so much else in Java, that just means you have to *think* and act for 
yourself, and type a few extra lines of code.  Don't sprain your finger with 
that extra typing, whiners!

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:

>DOS/Windows is the only reason 8086/80286 segmented architectures became 
>popular.

That's a bit backwards! The architecture existed, the OS had to deal
with it. 

-- 
Tim Slattery
Slattery_T@bls.gov
http://members.cox.net/slatteryt

On 2/8/11 8:53 PM, Lew wrote:
> The problem with reifiable types is that it's too easy to do a
> half-assed job of your type analysis, thus resulting in the runtime
> errors to which Andreas alludes. Besides, all you need to do to get
> runtime typing is to include a runtime type token as a final member of
> your class and Bob's your uncle. Like so much else in Java, that just
> means you have to *think* and act for yourself, and type a few extra
> lines of code. Don't sprain your finger with that extra typing, whiners!

I agree that type erasure is not a huge liability in Java.  As long as 
you always use the generic type as a generic rather than raw type, 
compile time checking will do the job.

However, type erasure does limit what you can do via reflection, which 
is something very important at times.  Another advantage of reified 
types is the ability to use generics efficiently with value types, 
rather than having to box them.

Of course, Java doesn't have user-defined value types, but it would be 
potentially useful even for the built-in ones.

As in all cases, it's not _universally_ useful.  But they are worth 
having reified types, IMHO.

Pete

On 11-02-07 11:06 PM, Lawrence D'Oliveiro wrote:
> In message<4d50949a$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>
[ SNIP ]

>> Real C apps that will run predictable on any platform is
>> pretty rare.
>
> Really?? We have them coming out our ears. I have thousands of them
> installed on my system alone. Let’s see, the Linux kernel, 15 million lines
> of source code, almost entirely in C, portable across about two dozen
> different major processor architectures. GCC, Apache, Python, Blender (a
> million lines of C, plus about 220 thousand lines of C++), Gimp ... the list
> goes on and on.
>
You've got a very optimistic definition of "portable" happening there. 
It may come as a surprise to you, but all sorts of #ifdefs and 
platform-specific configure scripts and makefiles don't mean that you've 
got portable code - all of that is a response to the fact that you've 
got _non-portable_ code.

AHS

-- 
We must recognize the chief characteristic of the modern era - a 
permanent state of what I call violent peace.
-- James D. Watkins

On 8/02/2011 6:32 PM, Lawrence D'Oliveiro wrote:
> Nobody seriously used that stuff, because none of it was of any use.

Windows 95 used it, ditto 98, and every version of NT. Ditto NetWare 4.

> The only OS designed to try to make use of it, OS/2, flopped.

For that reason?

Lawrence D'Oliveiro wrote:
>> Nobody seriously used that stuff, because none of it was of any use.

Esmond Pitt wrote:
> Windows 95 used it, ditto 98, and every version of NT. Ditto NetWare 4.

Lawrence D'Oliveiro wrote:
>> The only OS designed to try to make use of it, OS/2, flopped.

Esmond Pitt wrote:
> For that reason?

That quote is out of context, but if "Lawrence D'Oliveiro" was saying that use 
of clever Intel tricks like hardware multitasking and privilege rings were 
used only by OS/2 (is that what he said?  I missed his post.), the other OSes 
you cite aren't the only ones, either.  QNX, for example, was doing that on 
the '286, and they're still very much in business, too.

They also leveraged the segmented architecture quite nicely.  Typically, 
multiple instances of the same program shared the code segment and only 
allocated individual data segments.  We put three simultaneous users on 
terminals into the same application on a '386 with 2 MB of RAM and it ran like 
a bat out of hell and never felt pinched for memory.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

On 09/02/2011 12:15 AM, Lew wrote:
> Esmond Pitt wrote:
>> Lawrence D'Oliveiro wrote:
>>> Esmond Pitt wrote:
>>>> Lawrence D'Oliveiro wrote:
>>> Nobody seriously used that stuff, because none of it was of any use.
>>> The only OS designed to try to make use of it, OS/2, flopped.
>> For that reason?
>
> That quote is out of context, but if "Lawrence D'Oliveiro" was saying
> that use of clever Intel tricks like hardware multitasking and privilege
> rings were used only by OS/2 (is that what he said? I missed his post.),
> the other OSes you cite aren't the only ones, either. QNX, for example,
> was doing that on the '286, and they're still very much in business, too.

QNX? That's even more obscure than OS/2 is!

Fact is, nothing with non-micoscopic market share used those features of 
the 80286.

Number of pages is not a perfect indicator of complexity, but gives a
good estimation.

The main problem of your comparison is that the C++ standard refers a
lot to the C standard. A standalone C++ standard would be a lot
bigger.

A second point to take into account in your comparison is that the C++
standard contains nothing about threads and concurrency. This subject
is a significant part of java standard. It will be a huge part of next
C++ standard.

Java is definitively a much simpler language than C++, even with
generics and huge standard libraries.

Lew wrote:
>> That quote is out of context, but if "Lawrence D'Oliveiro" was saying
>> that use of clever Intel tricks like hardware multitasking and privilege
>> rings were used only by OS/2 (is that what he said? I missed his post.),
>> the other OSes you cite aren't the only ones, either. QNX, for example,
>> was doing that on the '286, and they're still very much in business, too.

Sulfide Eater wrote:
> QNX? That's even more obscure than OS/2 is!

How is still in business and thriving more obscure than historic only and no 
longer used?

> Fact is, nothing with non-micoscopic market share used those features of the
> 80286.

That was essentially what I said to start off this sub-thread: "Only a couple 
of OSes really used that stuff back then."  Glad to see agreement in this 
often contentious newsgroup.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

On 09/02/11 05:23, Sulfide Eater wrote an attempted troll:

Watch out for the stupid troll attempt in the previous post which was
x-posted to an OS/2 advocacy group.

On 02/09/2011 08:12 AM, Nigel Wade wrote:
> On 09/02/11 05:23, Sulfide Eater wrote an attempted troll:
>
> Watch out for the stupid troll attempt in the previous post which was
> x-posted to an OS/2 advocacy group.

Damn, and I answered him without noticing!  Now both the denizens of the OS/2 
group will be so bummed out.

-- 
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

Sulfide Eater <zaxx1108@example.com> writes:

121> Newsgroups: comp.lang.java.programmer,comp.os.os2.advocacy

121> QNX? That's even more obscure than OS/2 is!

Classic erroneous presupposition.  College football fans, of which
there
are plenty, were treated to the IBM OS/2 Fiesta Bowl back in the 90s,
Eater.

121> Fact is, nothing with non-micoscopic market share used those
features of
121> the 80286.

Classic erroneous presupposition.  OS/2 had far more than a
microscopic
market share, Eater.

Lew <noone@lewscanon.com> writes:

8> Newsgroups: comp.lang.java.programmer,comp.os.os2.advocacy

8> How is still in business and thriving more obscure than historic
only and no
8> longer used?

Classic erroneous presupposition.  OS/2 is still used, Lew.

8> That was essentially what I said to start off this sub-thread:
"Only a couple
8> of OSes really used that stuff back then."  Glad to see agreement
in this
8> often contentious newsgroup.

Are you claiming that OS/2 no longer uses it, Lew?  Or are
you really saying that the 80286 is no longer used?

On 09/02/2011 10:41 AM, tholen@antispam.ham wrote:
> Sulfide Eater<zaxx1108@example.com>  writes:
>
> 121>  Newsgroups: comp.lang.java.programmer,comp.os.os2.advocacy
>
> 121>  QNX? That's even more obscure than OS/2 is!
>
> Classic erroneous presupposition.

Are you claiming, then, that OS/2 is more obscure than QNX?

> 121>  Fact is, nothing with non-micoscopic market share used those
> features of
> 121>  the 80286.
>
> Classic erroneous presupposition.  OS/2 had far more than a
> microscopic
> market share, Eater.

In your wildest dreams, perhaps, tholenbot.

On 09/02/2011 8:12 AM, Nigel Wade wrote:
> On 09/02/11 05:23, Sulfide Eater wrote an attempted troll:
>
> Watch out for the [insult deleted] in the previous post which was
> x-posted to an OS/2 advocacy group.

It's perfectly on topic there, jerkwad. We were dicsussing OS/2's use of 
the 80286's multitasking support features, which few other operating 
systems did at the time. If that isn't a useful bit of information for 
OS/2 advocates I don't know what is. :)

On 09/02/2011 8:22 AM, Lew wrote:
> On 02/09/2011 08:12 AM, Nigel Wade wrote:
>> On 09/02/11 05:23, Sulfide Eater [false accusation deleted]:
>>
>> Watch out for the [insult deleted] in the previous post which was
>> x-posted to an OS/2 advocacy group.

It's perfectly on topic there. We were dicsussing OS/2's use of the 
80286's multitasking support features, which few other operating systems 
did at the time. If that isn't a useful bit of information for OS/2 
advocates I don't know what is. :)

> Damn, and I answered him without noticing! Now both the denizens of the
> OS/2 group will be so bummed out.

By the first on-topic traffic they've had in ages?

Sulfide Eater <zaxx1108@example.com> writes:

122> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

122> Are you claiming, then, that OS/2 is more obscure than QNX?

Still suffering from reading comprehension problems, Eater?  The
sentence that you decided not to quote addresses your question.

122> In your wildest dreams, perhaps, tholenbot.

Who is "tholenbot", Eater?  There is nobody in this newsgroup
using that alias.

123> Newsgroups: comp.lang.java.programmer,comp.os.os2.advocacy

123> It's perfectly on topic there, jerkwad. We were dicsussing OS/2's
use of
123> the 80286's multitasking support features, which few other
operating
123> systems did at the time. If that isn't a useful bit of
information for
123> OS/2 advocates I don't know what is. :)

Then why don't you read some of the OS/2 newsgroups to find out
what sort of questions people ask that represent useful bits of
information, Eater?

124> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,rec.games.roguelike.development

124> It's perfectly on topic there. We were dicsussing OS/2's use of
the
124> 80286's multitasking support features, which few other operating
systems
124> did at the time. If that isn't a useful bit of information for OS/
2
124> advocates I don't know what is. :)

Then why don't you read some of the OS/2 newsgroups to find out
what sort of questions people ask that represent useful bits of
information, Eater?

124> By the first on-topic traffic they've had in ages?

Classic erroneous presupposition.

On 09/02/2011 4:52 PM, tholen@antispam.ham wrote:
> Sulfide Eater<zaxx1108@example.com>  writes:
>
> 122>  Are you claiming, then, that OS/2 is more obscure than QNX?
>
> Still suffering from reading comprehension problems, Eater?

Classic erroneous presupposition, tholenbot.

I said that QNX was more obscure than OS/2, tholian. You claimed that 
that was "erroneous", trollen. That implies that you believe that OS/2 
is more obscure than QNX, tholenoid.

> 123>  It's perfectly on topic there, jerkwad. We were dicsussing OS/2's
> 123>  use of the 80286's multitasking support features, which few other
> 123>  operating systems did at the time. If that isn't a useful bit of
> 123>  information for OS/2 advocates I don't know what is. :)
>
> Then why don't you read some of the OS/2 newsgroups to find out
> what sort of questions people ask that represent useful bits of
> information, Eater?

Failure to recognize a common rhetorical question format noted, thallium.

> 124>  It's perfectly on topic there. We were discussing OS/2's use of
> 124>  the 80286's multitasking support features, which few other
> 124>  operating systems did at the time. If that isn't a useful bit
> 124>  of information for OS/2 advocates I don't know what is. :)
>
> Then why don't you read some of the OS/2 newsgroups to find out
> what sort of questions people ask that represent useful bits of
> information, Eater?

Failure to recognize a common rhetorical question format noted, thalidomide

Stuck record behavior also noted, trillium.

> 124>  By the first on-topic traffic they've had in ages?
>
> Classic erroneous presupposition.

On your part, tholenbot.

On 10/02/2011 8:03 AM, Sulfide Eater wrote:
> In your wildest dreams, perhaps, tholenbot.

No 'wildest dreams' about it. I made a very good living out of OS/2 for 
ten consecutive years. IBM stated at some stage that the OS/2 project 
had showed a considerable profit.

On 10/02/2011 5:58 AM, Esmond Pitt wrote:
> On 10/02/2011 8:03 AM, Sulfide Eater wrote:
>> In your wildest dreams, perhaps, tholenbot.
>
> No 'wildest dreams' about it. I made a very good living out of OS/2 for
> ten consecutive years. IBM stated at some stage that the OS/2 project
> had showed a considerable profit.

In some niche area. The fact remains that its market share does not hold 
a candle to that of even OS X, let alone Linux or Windows.

Sulfide Eater <zaxx1108@example.com> writes:

125> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,rec.games.roguelike.development

125> Classic erroneous presupposition, tholenbot.

Who is "tholenbot", Eater?  There is nobody in this newsgroup
using that alias.

125> I said that QNX was more obscure than OS/2, tholian.

Who is "tholian", Eater?  There is nobody in this newsgroup
using that alias.

125> You claimed that that was "erroneous", trollen.

Who is "trollen", Eater?  There is nobody in this newsgroup
using that alias.

125> That implies that you believe that OS/2
125> is more obscure than QNX, tholenoid.

Who is "tholenoid", Eater?  There is nobody in this newsgroup
using that alias.

125> Failure to recognize a common rhetorical question format noted,
thallium.

Who is "thallium", Eater?  There is nobody in this newsgroup
using that alias.

125> Failure to recognize a common rhetorical question format noted,
thalidomide

Who is "thalidomide", Eater?  There is nobody in this newsgroup
using that alias.

125> Stuck record behavior also noted, trillium.

Who is "trillium", Eater?  There is nobody in this newsgroup
using that alias.

125> On your part, tholenbot.

Who is "tholenbot", Eater?  There is nobody in this newsgroup
using that alias.

126> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

126> In some niche area. The fact remains that its market share does
not hold
126> a candle to that of even OS X, let alone Linux or Windows.

Classic pontification.  Of course, Mercedes' market share doesn't hold
a candle to Chevrolet.  The significance of that comparison will
undoubtedly be lost on someone who can't even keep attributions
straight.

Esmond Pitt <esmond.pitt@bigpond.com> writes:

1> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

1> No 'wildest dreams' about it. I made a very good living out of OS/2
for
1> ten consecutive years. IBM stated at some stage that the OS/2
project
1> had showed a considerable profit.

Trolls like Sulfide Eater never let the facts get in the way of a good
rant, Pitt.

On 10/02/2011 9:28 AM, tholen@antispam.ham wrote:
> 126>  In some niche area. The fact remains that its market share does
> not hold
> 126>  a candle to that of even OS X, let alone Linux or Windows.
>
> Classic pontification.  Of course, Mercedes' market share doesn't hold
> a candle to Chevrolet.

Nor does the market share of the Edsel, trollium.

> The significance of that comparison will undoubtedly be lost on
> someone who can't even keep attributions straight.

Non sequitur; to whom are you referring, tholenator? There is nobody in 
this newsgroup who "can't even keep attributions straight", thingamabob.

On 10/02/2011 9:32 AM, Sulfide Eater wrote:
> On 10/02/2011 9:29 AM, tholen@antispam.ham wrote:
>> Esmond Pitt <esmond.pitt@bigpond.com> writes:
>>
>> 1>  No 'wildest dreams' about it. I made a very good living out of OS/2
>> for
>> 1>  ten consecutive years. IBM stated at some stage that the OS/2
>> project
>> 1>  had showed a considerable profit.
>>
>> [insult deleted] like Sulfide Eater [false accusation deleted], Pitt.
>
> What do your classic erroneous presuppositions have to do with OS/2, tholen?

Whack tholen bot!

In message <JBk4p.101614$ZS4.35831@newsfe07.iad>, Arved Sandstrom wrote:

> On 11-02-07 11:06 PM, Lawrence D'Oliveiro wrote:
>
>> In message<4d50949a$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
> 
>>> Real C apps that will run predictable on any platform is
>>> pretty rare.
>>
>> Really?? We have them coming out our ears. I have thousands of them
>> installed on my system alone. Let’s see, the Linux kernel, 15 million
>> lines of source code, almost entirely in C, portable across about two
>> dozen different major processor architectures. GCC, Apache, Python,
>> Blender (a million lines of C, plus about 220 thousand lines of C++),
>> Gimp ... the list goes on and on.
>>
> You've got a very optimistic definition of "portable" happening there.
> It may come as a surprise to you, but all sorts of #ifdefs and
> platform-specific configure scripts and makefiles don't mean that you've
> got portable code - all of that is a response to the fact that you've
> got _non-portable_ code.

It is more portable than any Java code you can point to. QED.

In message <4d50b67b$0$23754$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 07-02-2011 22:06, Lawrence D'Oliveiro wrote:
>
>> In message<4d5094f2$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>
>>> On 07-02-2011 15:22, Lawrence D'Oliveiro wrote:
>>>>
>>>> In message<iiop28$8jj$1@news.eternal-september.org>, Joshua Cranmer
>>>> wrote:
>>>>>
>>>>> Writing portable code in C pretty much requires you to do hefty
>>>>> compatibility layers.
>>>>
>>>> Not really. Sticking to standard POSIX types like size_t, time_t etc
>>>> gets you a lot of the way there.
>>>
>>> POSIX does not cover all aspects.
>>
>> Well, you need tools like autoconf as well to handle the more complicated
>> cases.
> 
> The existence of that tool is an indication that there is a
> portability problem.

Which it solves.

> But autoconf does not solve all problems.

Enough of them to fulfil the needs of hundreds of thousands of portable 
software packages.

>>> And not all platforms are POSIX compliant.
>>
>> All the ones worth using are.
> 
> Well - I don't think anyone defines portability as running unchanged on
> the platform one specific person considers worth using.

Except I’m talking about an order of magnitude more different platforms than 
you are.

In message <4d50b4e8$0$23754$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 07-02-2011 21:59, Lawrence D'Oliveiro wrote:
>
>> In message<4d5032a8$0$41114$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>
>>> For certain APIs (MS Windows conatins lots of them) struct layout
>>> assumpations are essential.
>>
>> POSIX manages such things in a portable way.
> 
> No.
> 
> POSIX does the same thing as Windows.

POSIX is designed for portability in a way that Windows is not. Where Win32 
uses explicitly-sized types of 32 bits or 16 bits or whatever, POSIX uses 
symbolic names that can be handled differently by different implementations.

Consider why there was even a need for a Win64, when there is no “POSIX64”.

Heike Svensson <hsvensson.1093x1_q@hotmail.nospam.com.please> writes:

42> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

42> Whack tholen bot!

Who is "bot", Svensson?  There is nobody in this newsgroup using
that alias.  And what does your desire for that "bot" to whack tholen
have to do with OS/2, Svensson?

Sulfide Eater <zaxx1108@example.com> writes:

127> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

127> Nor does the market share of the Edsel, trollium.

Who is "trollium", Eater?  There is nobody in this newsgroup
using that alias.

127> Non sequitur;

Classic unsubstantiated and erroneous claim.

127> to whom are you referring, tholenator?

Case in point.

127> There is nobody in
127> this newsgroup who "can't even keep attributions straight",
thingamabob.

Who is "thingamabob", Eater?  There is nobody in this newsgroup
using that alias.

On 11-02-10 06:40 PM, Lawrence D'Oliveiro wrote:
> In message<JBk4p.101614$ZS4.35831@newsfe07.iad>, Arved Sandstrom wrote:
>
>> On 11-02-07 11:06 PM, Lawrence D'Oliveiro wrote:
>>
>>> In message<4d50949a$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>
>>>> Real C apps that will run predictable on any platform is
>>>> pretty rare.
>>>
>>> Really?? We have them coming out our ears. I have thousands of them
>>> installed on my system alone. Let’s see, the Linux kernel, 15 million
>>> lines of source code, almost entirely in C, portable across about two
>>> dozen different major processor architectures. GCC, Apache, Python,
>>> Blender (a million lines of C, plus about 220 thousand lines of C++),
>>> Gimp ... the list goes on and on.
>>>
>> You've got a very optimistic definition of "portable" happening there.
>> It may come as a surprise to you, but all sorts of #ifdefs and
>> platform-specific configure scripts and makefiles don't mean that you've
>> got portable code - all of that is a response to the fact that you've
>> got _non-portable_ code.
>
> It is more portable than any Java code you can point to. QED.

Right. So one of the main J2EE apps I have helped maintain for a few 
years, about 500 KLOC of Java that interfaces with databases, SAP, 
message queues, the file system, other J2EE apps like FileNet, that can 
have its EAR deployed (with tiny changes to some configuration files) to 
any of Windows, Mac OS X, Linux or Solaris with zero code changes and no 
OS dependencies in the code, what you're saying is that I could 
translate all that into C and not worry about what OS I'm writing it for?

Is that what you're saying? It sure sounds like that's what you're saying.

Portable is epitomized (not exclusively so) by JVM-based languages and 
..NET/CLR-based languages. C is on the other end of that spectrum, dude. 
To use another example, I can write C#.NET and run it without code 
changes on Windows, Linux, Mac OS X and Solaris, using Mono. _That_ is 
code portability, not the GNU Build System. The latter attempts 
(often/usually successfully) to compensate for _not_ having code 
portability by making the _build_ portable. Serious difference.

AHS

-- 
We must recognize the chief characteristic of the modern era - a 
permanent state of what I call violent peace.
-- James D. Watkins

On 10/02/2011 8:23 PM, tholen@antispam.ham wrote:
> 127>  Non sequitur;
>
> Classic unsubstantiated and erroneous claim.

On your part, tholenbot.

> 127>  to whom are you referring, tholenator?
>
> Case in point.

Non sequitur.

Sulfide Eater <zaxx1108@example.com> writes:

128> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

128> On your part, tholenbot.

Who is "tholenbot", Eater?  There is nobody in this newsgroup
using that alias.

128> Non sequitur.

What does your classic unsubstantiated and erroneous claim
have to do with OS/2, Eater?

On 12/02/2011 8:43 AM, tholen@antispam.ham wrote:
> Sulfide Eater<zaxx1108@example.com>  writes:
> 128>  Non sequitur.
>
> classic unsubstantiated and erroneous claim

On your part, tholenoid.

On 08-02-2011 23:48, Esmond Pitt wrote:
> On 8/02/2011 6:32 PM, Lawrence D'Oliveiro wrote:
>> Nobody seriously used that stuff, because none of it was of any use.
>
> Windows 95 used it, ditto 98, and every version of NT. Ditto NetWare 4.

95/98/NT did not run on 286'es.

The 386 may be identical to 286 for the features described, but the CPU
mentioned was 286.

Arne

On 10-02-2011 07:00, Sulfide Eater wrote:
> On 10/02/2011 5:58 AM, Esmond Pitt wrote:
>> On 10/02/2011 8:03 AM, Sulfide Eater wrote:
>>> In your wildest dreams, perhaps, tholenbot.
>>
>> No 'wildest dreams' about it. I made a very good living out of OS/2 for
>> ten consecutive years. IBM stated at some stage that the OS/2 project
>> had showed a considerable profit.
>
> In some niche area. The fact remains that its market share does not hold
> a candle to that of even OS X, let alone Linux or Windows.

Today.

OS/2 was pretty widely used once.

And since Esmond did use past tense, then the past seems
more relevant than the current.

Arne

On 12/02/2011 7:36 PM, Arne Vajh�j wrote:
> On 10-02-2011 07:00, Sulfide Eater wrote:
>> On 10/02/2011 5:58 AM, Esmond Pitt wrote:
>>> On 10/02/2011 8:03 AM, Sulfide Eater wrote:
>>>> In your wildest dreams, perhaps, tholenbot.
>>>
>>> No 'wildest dreams' about it. I made a very good living out of OS/2 for
>>> ten consecutive years. IBM stated at some stage that the OS/2 project
>>> had showed a considerable profit.
>>
>> In some niche area. The fact remains that its market share does not hold
>> a candle to that of even OS X, let alone Linux or Windows.
>
> Today.
>
> OS/2 was pretty widely used once.

Where, in West Rectum, Rajikistan? I can't recall ever stumbling upon a 
single person using it as their desktop OS even during its so-called 
heyday. Maybe the odd dedicated-function terminal, like an ATM or a cash 
register, was running it under the hood. Nothing normal people do their 
web browsing, word processing, and gaming on, though, that I ever ran 
across.

On 08-02-2011 05:25, Andreas Leitgeb wrote:
> Lawrence D'Oliveiro<ldo@geek-central.gen.new_zealand>  wrote:
>> Because the whole “raw types” concept detracts from and weakens
>> the coherence of the type system.
>
> The "problem" about type-erasure is over-rated.
>
> Suppose, an instance created so: Object o = new ArrayList<String>();
> actually "knew" that it was an ArrayList of Strings (and not just
> that it was an ArrayList, as it does now).
> Then you would get a *runtime*-Error, if you tried to cast "o" to
> ArrayList<Integer>, later.  But generics aren't about runtime errors.
> They are about being able to prevent some runtime-errors, by turning
> them into compile-time errors. So, giving *still runtime*-errors for
> casting between generic types of incompatible parametrizations is only
> little win over giving runtime-errors on element-use.

There are other reasons to not have type erasure.

new T

general reflection

method overload

Arne

On 08-02-2011 07:53, Lew wrote:
> Andreas Leitgeb wrote:
>> The "problem" about type-erasure is over-rated.
>>
>> Suppose, an instance created so: Object o = new ArrayList<String>();
>> actually "knew" that it was an ArrayList of Strings (and not just
>> that it was an ArrayList, as it does now).
>> Then you would get a *runtime*-Error, if you tried to cast "o" to
>> ArrayList<Integer>, later. But generics aren't about runtime errors.
>> They are about being able to prevent some runtime-errors, by turning
>> them into compile-time errors. So, giving *still runtime*-errors for
>> casting between generic types of incompatible parametrizations is only
>> little win over giving runtime-errors on element-use.
>
> I'm very glad you made that point. I am glad we have type erasure in
> Java. It forces you to deal with type assertions at compile time.
>
> The problem with reifiable types is that it's too easy to do a
> half-assed job of your type analysis, thus resulting in the runtime
> errors to which Andreas alludes. Besides, all you need to do to get
> runtime typing is to include a runtime type token as a final member of
> your class and Bob's your uncle. Like so much else in Java, that just
> means you have to *think* and act for yourself, and type a few extra
> lines of code. Don't sprain your finger with that extra typing, whiners!

Can you give an example of where introduction of reifiable type
would cause not getting a compile time error but a runtime error
instead?

Arne

On 12-02-2011 19:41, Sulfide Eater wrote:
> On 12/02/2011 7:36 PM, Arne Vajh�j wrote:
>> On 10-02-2011 07:00, Sulfide Eater wrote:
>>> On 10/02/2011 5:58 AM, Esmond Pitt wrote:
>>>> On 10/02/2011 8:03 AM, Sulfide Eater wrote:
>>>>> In your wildest dreams, perhaps, tholenbot.
>>>>
>>>> No 'wildest dreams' about it. I made a very good living out of OS/2 for
>>>> ten consecutive years. IBM stated at some stage that the OS/2 project
>>>> had showed a considerable profit.
>>>
>>> In some niche area. The fact remains that its market share does not hold
>>> a candle to that of even OS X, let alone Linux or Windows.
>>
>> Today.
>>
>> OS/2 was pretty widely used once.
>
> Where, in West Rectum, Rajikistan? I can't recall ever stumbling upon a
> single person using it as their desktop OS even during its so-called
> heyday. Maybe the odd dedicated-function terminal, like an ATM or a cash
> register, was running it under the hood. Nothing normal people do their
> web browsing, word processing, and gaming on, though, that I ever ran
> across.

I don't know about who you know.

OS/2 was used by many large organizations in both the private
and the public sector.

Arne

On 12/02/2011 8:38 PM, Arne Vajh�j wrote:
> OS/2 was used by many large organizations in both the private
> and the public sector.

I'm more interested in client-side. Who among the general public ever 
used it much?

On 12-02-2011 21:02, Sulfide Eater wrote:
> On 12/02/2011 8:38 PM, Arne Vajh�j wrote:
>> OS/2 was used by many large organizations in both the private
>> and the public sector.
>
> I'm more interested in client-side. Who among the general public ever
> used it much?

This was client side - desktop computers.

Arne

On 12/02/2011 9:03 PM, Arne Vajh�j wrote:
> On 12-02-2011 21:02, Sulfide Eater wrote:
>> On 12/02/2011 8:38 PM, Arne Vajh�j wrote:
>>> OS/2 was used by many large organizations in both the private
>>> and the public sector.
>>
>> I'm more interested in client-side. Who among the general public ever
>> used it much?
>
> This was client side

You said "used by many large corporations", rather than by individuals 
on their personal computers.

I am asking who actually used it. Having 3 adopters all of which were 
large organizations is still having 3 adopters and a tiny sliver of 
market share.

On 12-02-2011 21:08, Sulfide Eater wrote:
> On 12/02/2011 9:03 PM, Arne Vajh�j wrote:
>> On 12-02-2011 21:02, Sulfide Eater wrote:
>>> On 12/02/2011 8:38 PM, Arne Vajh�j wrote:
>>>> OS/2 was used by many large organizations in both the private
>>>> and the public sector.
>>>
>>> I'm more interested in client-side. Who among the general public ever
>>> used it much?
>>
>> This was client side
>
> You said "used by many large corporations", rather than by individuals
> on their personal computers.

The computers on the employees desktops are client side.

Personally owned computers were not that common in those times.

> I am asking who actually used it. Having 3 adopters all of which were
> large organizations is still having 3 adopters and a tiny sliver of
> market share.

It is a lot more than 3.

Arne

On 12/02/2011 9:18 PM, Arne Vajh�j wrote:
> On 12-02-2011 21:08, Sulfide Eater wrote:
>> I am asking who actually used it. Having 3 adopters all of which were
>> large organizations is still having 3 adopters and a tiny sliver of
>> market share.
>
> It is a lot more than 3.

Wow, was it 6? Maybe even 10? Maybe even as many as 100? Out of what, 
millions? :)

On 09/02/2011 2:02 PM, Sulfide Eater wrote:
> On 09/02/2011 4:52 PM, tholen@antispam.ham wrote:
>> Sulfide Eater<zaxx1108@example.com> writes:
>>
>> 122> Are you claiming, then, that OS/2 is more obscure than QNX?
>>
>> Still suffering from reading comprehension problems, Eater?
>
> Classic erroneous presupposition, tholenbot.
>
> I said that QNX was more obscure than OS/2, tholian. You claimed that
> that was "erroneous", trollen. That implies that you believe that OS/2
> is more obscure than QNX, tholenoid.
>
>> 123> It's perfectly on topic there, jerkwad. We were dicsussing OS/2's
>> 123> use of the 80286's multitasking support features, which few other
>> 123> operating systems did at the time. If that isn't a useful bit of
>> 123> information for OS/2 advocates I don't know what is. :)
>>
>> Then why don't you read some of the OS/2 newsgroups to find out
>> what sort of questions people ask that represent useful bits of
>> information, Eater?
>
> Failure to recognize a common rhetorical question format noted, thallium.
>
>> 124> It's perfectly on topic there. We were discussing OS/2's use of
>> 124> the 80286's multitasking support features, which few other
>> 124> operating systems did at the time. If that isn't a useful bit
>> 124> of information for OS/2 advocates I don't know what is. :)
>>
>> Then why don't you read some of the OS/2 newsgroups to find out
>> what sort of questions people ask that represent useful bits of
>> information, Eater?
>
> Failure to recognize a common rhetorical question format noted, thalidomide
>
> Stuck record behavior also noted, trillium.
>
>> 124> By the first on-topic traffic they've had in ages?
>>
>> Classic erroneous presupposition.
>
> On your part, tholenbot.

Oh joy, a new thread to killfile.

On 13/02/2011 3:16 AM, narf_the_mouse wrote:
> On 09/02/2011 2:02 PM, Sulfide Eater wrote:
>> On 09/02/2011 4:52 PM, tholen@antispam.ham wrote:
>>> Sulfide Eater<zaxx1108@example.com> writes:
>>> 124> By the first on-topic traffic they've had in ages?
>>>
>>> Classic erroneous presupposition.
>>
>> On your part, tholenbot.
>
> Oh joy, [implied insult deleted].

Not.

Sulfide Eater <zaxx1108@example.com> writes:

129> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

129> On your part, tholenoid.

Who is "tholenoid", Eater?  There is nobody in this newsgroup
using that alias.

130> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

130> Where, in West Rectum, Rajikistan? I can't recall ever stumbling
upon a
130> single person using it as their desktop OS even during its so-
called
130> heyday.

Suffering from memory problems, Eater?

130> Maybe the odd dedicated-function terminal, like an ATM or a cash
130> register, was running it under the hood. Nothing normal people do
their
130> web browsing, word processing, and gaming on, though, that I ever
ran
130> across.

Don't get out much, eh Eater?

131> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

131> I'm more interested in client-side. Who among the general public
ever
131> used it much?

I have, Eater.

132> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

132> You said "used by many large corporations", rather than by
individuals
132> on their personal computers.

Large corporations are client-side users, Eater.

132> I am asking who actually used it. Having 3 adopters all of which
were
132> large organizations is still having 3 adopters and a tiny sliver
of
132> market share.

Irrelevant, given that there were far more than 3 adopters, Eater.

133> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

133> Wow, was it 6?

No, Eater.

133> Maybe even 10?

Not even, Eater.

133> Maybe even as many as 100?

Even more, Eater.

133> Out of what, millions? :)

Now you're getting warm, Eater.

134> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,rec.games.roguelike.development

134> Not.

What does your negation have to do with OS/2, Eater?

narf_the_mouse <largemouse@gmail.com> writes:

1> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,rec.games.roguelike.development

1> Oh joy, a new thread to killfile.

What does your joy have to do with OS/2, narf?

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:

17> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

17> Today.

17> OS/2 was pretty widely used once.

17> And since Esmond did use past tense, then the past seems
17> more relevant than the current.

Trolls like Sulfide Eater never let the facts get in the way
of a good rant, Arne.

18> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

18> I don't know about who you know.

18> OS/2 was used by many large organizations in both the private
18> and the public sector.

Trolls like Sulfide Eater never let the facts get in the way
of a good rant, Arne.

19> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

19> This was client side - desktop computers.

Trolls like Sulfide Eater never let the facts get in the way
of a good rant, Arne.

20> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

20> The computers on the employees desktops are client side.

20> Personally owned computers were not that common in those times.

Classic unsubstantiated and erroneous claim.

20> It is a lot more than 3.

Trolls like Sulfide Eater never let the facts get in the way
of a good rant, Arne.

At 10:27 AM, Sulfide Eater <zaxx1108@example.com> wrote:
> On 13/02/2011 5:50 AM, tholen@antispam.ham wrote:
>> =?ISO-8859-1?Q?Arne_Vajh=F8j?=<arne@vajhoej.dk>  writes:
>> 17>  OS/2 was pretty widely used once.
>
> Bullshit.

Smack!

>> [insult deleted]s like Sulfide Eater [false accusation
>> deleted], Arne.
>
> What do your classic erroneous presuppositions have to do  with
> OS/2, tholenbot?

Pow!

>> 18>  OS/2 was used by many large organizations in both the private
>> 18>  and the public sector.
>
> How many is "many"? 3? 6? 10? Maybe even 100? Even 100 adopters
> would have been tiny market share.

Blam!

>> [insult deleted]s like Sulfide Eater [false accusation
>> deleted], Arne.
>
> What do your classic erroneous presuppositions have to do with
> OS/2, tholenator?

Whack!

>> 19>  This was client side - desktop computers.
>
> It wasn't home computers.
>
>> [insult deleted]s like Sulfide Eater [false accusation
>> deleted], Arne.
>
> What do your classic erroneous presuppositions have to do with
> OS/2, thalidomide?

Bam!
Boink!
Slap!

>> 20>  The computers on the employees desktops are client side.
>
> To the employees. Not to anyone back home.

Zoink!

>> 20>  It is a lot more than 3.
>> [insult deleted]s like Sulfide Eater [false accusation
>> deleted], Arne.
>
> What do your classic erroneous presuppositions have to do with
> OS/2, tholenbot?

Kablooie!

I love a good Internet argument. :)

On 13/02/2011 5:47 AM, tholen@antispam.ham wrote:
> Sulfide Eater<zaxx1108@example.com>  writes:
> 130>  Where, in West Rectum, Rajikistan? I can't recall ever stumbling
> 130>  upon a single person using it as their desktop OS even during
> 130>  its so-called heyday.
>
> Suffering from memory problems, Eater?

No, but thanks for your concern, tholenbot.

But I gotta ask: What does your question have to do with OS/2, trollen?

> 130>  Maybe the odd dedicated-function terminal, like an ATM or a cash
> 130>  register, was running it under the hood. Nothing normal people do
> 130>  their web browsing, word processing, and gaming on, though, that
> 130>  I ever ran across.
>
> Don't get out much, eh Eater?

What does your classic erroneous presupposition have to do with OS/2, 
thallium?

> 131>  I'm more interested in client-side. Who among the general public
> 131>  ever used it much?
>
> I have, Eater.

You don't exactly have much of a choice, though, do you, thalien, unless 
your author chooses someday to port you to another platform, tholenbot. 
So you don't count, thalidomide.

> 132>  You said "used by many large corporations", rather than by
> 132>  individuals on their personal computers.
>
> Large corporations are client-side users, Eater.

Not to their own users, the general public, trollium.

> 132>  I am asking who actually used it. Having 3 adopters all of which
> 132>  were large organizations is still having 3 adopters and a tiny
> 132>  sliver of market share.
>
> Irrelevant

What does your classic unsubstantiated and erroneous claim have to do 
with OS/2, trillium?

> given that there were far more than 3 adopters, Eater.

How many is "far more than 3", trellis? 30, tholenbot? Perhaps even as 
many as 100, tholian?

> 133>  Wow, was it 6?
>
> No, Eater.

Perhaps 7, then, tholenbot.

> 133>  Maybe even 10?
>
> Not even, Eater.

Not even ten, trollenbot? Aww, poor OS/2. Nine or fewer users makes 
thallium a sad, sad bot. Why, tholenbot's in danger of the only platform 
he's supported on going extinct! If someone doesn't port him to Windows 
or Linux, trollen could actually *die*!

> 133>  Maybe even as many as 100?
>
> Even more, Eater.

Classic contradiction, tholenbot; you just said not even 10, tholoon.

> Now you're getting warm, Eater.

What does the temperature becoming milder in the Northeast have to do 
with OS/2, thallium?

Heike Svensson <hsvensson.1093x1_q@hotmail.nospam.com.please> writes:

43> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

43> Smack!

43> Pow!

43> Blam!

43> Whack!

43> Bam!
43> Boink!
43> Slap!

43> Zoink!

43> Kablooie!

What do your sound effects have to do with OS/2, Svensson?

43> I love a good Internet argument. :)

Do you often argue with yourself, Svensson?

Sulfide Eater <zaxx1108@example.com> writes:

135> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,rec.games.roguelike.development

135> No,

Then why are you have problems with your recollection, Eater?

135> but thanks for your concern, tholenbot.

Who is "tholenbot", Eater?  There is nobody in this newsgroup
using that alias.

135> But I gotta ask: What does your question have to do with OS/2,
trollen?

Who is "trollen", Eater?  There is nobody in this newsgroup
using that alias.

135> What does your classic erroneous presupposition have to do with
OS/2,
135> thallium?

Who is "thallium", Eater?  There is nobody in this newsgroup
using that alias.

135> You don't exactly have much of a choice, though, do you, thalien,

Who is "thalien", Eater?  There is nobody in this newsgroup
using that alias.

135> unless
135> your author chooses someday to port you to another platform,
tholenbot.

Who is "tholenbot", Eater?  There is nobody in this newsgroup
using that alias.

135> So you don't count, thalidomide.

Who is "thalidomide", Eater?  There is nobody in this newsgroup
using that alias.

135> Not to their own users, the general public, trollium.

Who is "trollium", Eater?  There is nobody in this newsgroup
using that alias.

135> What does your classic unsubstantiated and erroneous claim have
to do
135> with OS/2, trillium?

Who is "trillium", Eater?  There is nobody in this newsgroup
using that alias.

135> How many is "far more than 3", trellis?

Who is "trellis", Eater?  There is nobody in this newsgroup
using that alias.

135> 30, tholenbot?

Who is "tholenbot", Eater?  There is nobody in this newsgroup
using that alias.

135> Perhaps even as many as 100, tholian?

Who is "tholian", Eater?  There is nobody in this newsgroup
using that alias.

135> Perhaps 7, then, tholenbot.

Who is "tholenbot", Eater?  There is nobody in this newsgroup
using that alias.

135> Not even ten, trollenbot?

Who is "trollenbot", Eater?  There is nobody in this newsgroup
using that alias.

135> Aww, poor OS/2. Nine or fewer users makes
135> thallium a sad, sad bot.

Who is "thallium", Eater?  There is nobody in this newsgroup
using that alias.

135> Why, tholenbot's in danger of the only platform
135> he's supported on going extinct!

Who is "tholenbot", Eater?  There is nobody in this newsgroup
using that alias.

135> If someone doesn't port him to Windows
135> or Linux, trollen could actually *die*!

Who is "trollen", Eater?  There is nobody in this newsgroup
using that alias.

135> Classic contradiction, tholenbot;

Who is "tholenbot", Eater?  There is nobody in this newsgroup
using that alias.

135> you just said not even 10, tholoon.

Who is "tholoon", Eater?  There is nobody in this newsgroup
using that alias.

135> What does the temperature becoming milder in the Northeast have
to do
135> with OS/2, thallium?

Who is "thallium", Eater?  There is nobody in this newsgroup
using that alias.

On 13/02/2011 4:29 PM, tholen@antispam.ham wrote:
> Heike Svensson <hsvensson.1093x1_q@hotmail.nospam.com.please> writes:
> 43>  I love a good Internet argument. :)
>
> Do you often argue with yourself, Svensson?

What does your question have to do with OS/2, tholenbot?

And for the record the answer is "no", trollen; in fact I never do, 
thallium. But it can be fun to watch others argue, thalidomide, like 
you, Sulfide Eater, and Arne Vajh�j were doing, tholoon.

On 13/02/2011 4:34 PM, tholen@antispam.ham wrote:
> Sulfide Eater <zaxx1108@example.com> writes:
> 135>  No,
>
> Then why are you have problems with your recollection, Eater?

Classic erroneous presupposition, trollen.

In message <6H05p.146$7a4.45@newsfe01.iad>, Arved Sandstrom wrote:

> On 11-02-10 06:40 PM, Lawrence D'Oliveiro wrote:
>> In message<JBk4p.101614$ZS4.35831@newsfe07.iad>, Arved Sandstrom wrote:
>>
>>> On 11-02-07 11:06 PM, Lawrence D'Oliveiro wrote:
>>>
>>>> In message<4d50949a$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj
>>>> wrote:
>>>
>>>>> Real C apps that will run predictable on any platform is
>>>>> pretty rare.
>>>>
>>>> Really?? We have them coming out our ears. I have thousands of them
>>>> installed on my system alone. Let’s see, the Linux kernel, 15 million
>>>> lines of source code, almost entirely in C, portable across about two
>>>> dozen different major processor architectures. GCC, Apache, Python,
>>>> Blender (a million lines of C, plus about 220 thousand lines of C++),
>>>> Gimp ... the list goes on and on.
>>>>
>>> You've got a very optimistic definition of "portable" happening there.
>>> It may come as a surprise to you, but all sorts of #ifdefs and
>>> platform-specific configure scripts and makefiles don't mean that you've
>>> got portable code - all of that is a response to the fact that you've
>>> got _non-portable_ code.
>>
>> It is more portable than any Java code you can point to. QED.
> 
> Right. So one of the main J2EE apps I have helped maintain for a few
> years, about 500 KLOC of Java that interfaces with databases, SAP,
> message queues, the file system, other J2EE apps like FileNet, that can
> have its EAR deployed (with tiny changes to some configuration files) to
> any of Windows, Mac OS X, Linux or Solaris with zero code changes and no
> OS dependencies in the code, what you're saying is that I could
> translate all that into C and not worry about what OS I'm writing it for?

Think about the fact that 1) the examples I mentioned are bigger than that, 
and 2) the Java compilers and run-times that you used to build and run your 
“portable” code on all those different systems were most likely written in C 
anyway.

In other words, Java code cannot be ported to a system until C has been 
ported to that system. Or, in other other words:

    Java portability ≤ C portability

In message <4d5092f7$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 07-02-2011 09:01, Thomas Richter wrote:
>>
>> "Lawrence D'Oliveiro" spat:
>>>
>>> Exercise for the reader: explain why Arne Vajhøj is wrong. For extra
>>> credit, list the implicit preconceptions that might have led to such a
>>> wrong conclusion.
>>
>> The reason is ... that people seem to assume that the linker has no
>> intelligence, or that there is a linker in first place. Nevertheless, the
>> C++ standard doesn't even define linking, and the world is no longer that
>> simple. Thus, I still don't see how this argument applies. Surely the C++
>> world works different from the java world, but saying that there is no
>> duplicate code in Java or that there is always code duplication in C++ is
>> surely wrong.
> 
> It how the simple implementations do it.

Where are there any “simple implementations” of C++?

> It is what the common implementations do it.

By “common” do you mean Microsoft?

In message <iinkpv$tbg$1@news.eternal-september.org>, Joshua Cranmer wrote:

> On 02/06/2011 09:03 PM, Lawrence D'Oliveiro wrote:
>
>> In message<4d4f47bb$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>>
>>> C++ will generate two classes with two sets of code.
>>>
>>> (at least that is what common compilers do - I don't know if
>>> the standard actually requires it to)
>>
>> See, it’s clear you’re hung up on specifics of particular
>> implementations, not on how the language feature is defined at all.
> 
> No, it's in the definition of C++ templates.

No, it isn’t.

> i.e., "you don't have to actually implement this specification so long
> as a valid program can't tell that you aren't."

My point exactly.

> See, it's clear you really haven't read the specs you're trying to
> language lawyer with us on.

So where did it say whether distinct types had to be implemented with the 
same or different code?

So, how do you all like my usenet troll bots? They were actually not
that hard to program, the basic underlying principle is a Markov chain
of configuarble response scraps that are stitched together based upon
a hierarchy of rules. On top of that I built a string analyzer - it
usually handles one sentence at a time, but can analyze up to 30 lines
of text at once (30 is just an arbitrary #, by the way, it can easily
be expanded to more). This is the most complicated part of the bot, as
it is here that it determines whether it will arbitrarially declare
the analyzed sentence a "fallacious argument" and state the
"determined" (I use that term _very_ loosely) fallacious argument as a
complete & valid response to the statement, whether it will randomly
add a totally unrelated newsgroup to the header file, or any of the
other 5 generic troll responses. I am especially proud of my
"nicknamesult analyzer" It uses a noise analysis algorithm, of my own
devising, on each word to determine whether the non-bot poster is
attempting a "nicknamesult" or whether the replier is just a poor
speller, technically braindead, etc. (For example, a "nicknamesult"
for Arnold would be Assnold or some crap). I will be happy to sell you
my botLib for $50usd. It works on usenet and all html-based forums and
includes a Bot Manager to easily permit fine-tuning of targets,
direction of trolling and personalized responses for all deployed bots
through one, while not simple, at least reasonably clear and beginner
friendly interface. Flash-based forum targeting is coming soon.
$2,000.00usd to remove your newsgroup from the bot's reply list.

On 12-02-2011 22:17, Sulfide Eater wrote:
> On 12/02/2011 9:18 PM, Arne Vajh�j wrote:
>> On 12-02-2011 21:08, Sulfide Eater wrote:
>>> I am asking who actually used it. Having 3 adopters all of which were
>>> large organizations is still having 3 adopters and a tiny sliver of
>>> market share.
>>
>> It is a lot more than 3.
>
> Wow, was it 6? Maybe even 10? Maybe even as many as 100? Out of what,
> millions? :)

Most of the financial sector world wide.

Good chunks of accounting firms, retail and
public sector systems.

Arne

On 13-02-2011 17:28, Lawrence D'Oliveiro wrote:
> In message<6H05p.146$7a4.45@newsfe01.iad>, Arved Sandstrom wrote:
>
>> On 11-02-10 06:40 PM, Lawrence D'Oliveiro wrote:
>>> In message<JBk4p.101614$ZS4.35831@newsfe07.iad>, Arved Sandstrom wrote:
>>>
>>>> On 11-02-07 11:06 PM, Lawrence D'Oliveiro wrote:
>>>>
>>>>> In message<4d50949a$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj
>>>>> wrote:
>>>>
>>>>>> Real C apps that will run predictable on any platform is
>>>>>> pretty rare.
>>>>>
>>>>> Really?? We have them coming out our ears. I have thousands of them
>>>>> installed on my system alone. Let’s see, the Linux kernel, 15 million
>>>>> lines of source code, almost entirely in C, portable across about two
>>>>> dozen different major processor architectures. GCC, Apache, Python,
>>>>> Blender (a million lines of C, plus about 220 thousand lines of C++),
>>>>> Gimp ... the list goes on and on.
>>>>>
>>>> You've got a very optimistic definition of "portable" happening there.
>>>> It may come as a surprise to you, but all sorts of #ifdefs and
>>>> platform-specific configure scripts and makefiles don't mean that you've
>>>> got portable code - all of that is a response to the fact that you've
>>>> got _non-portable_ code.
>>>
>>> It is more portable than any Java code you can point to. QED.
>>
>> Right. So one of the main J2EE apps I have helped maintain for a few
>> years, about 500 KLOC of Java that interfaces with databases, SAP,
>> message queues, the file system, other J2EE apps like FileNet, that can
>> have its EAR deployed (with tiny changes to some configuration files) to
>> any of Windows, Mac OS X, Linux or Solaris with zero code changes and no
>> OS dependencies in the code, what you're saying is that I could
>> translate all that into C and not worry about what OS I'm writing it for?
>
> Think about the fact that 1) the examples I mentioned are bigger than that,
> and 2) the Java compilers and run-times that you used to build and run your
> “portable” code on all those different systems were most likely written in C
> anyway.
>
> In other words, Java code cannot be ported to a system until C has been
> ported to that system. Or, in other other words:
>
>      Java portability ≤ C portability

????

Some parts of JVM and JRE need to be native. And for all
common platforms that is C/C++.

But that tells nothing about portability of C.

In fact it proves that C is not portable by the fact
that it is not easy to port JVM and JRE to a new platform.

Arne

On 10-02-2011 17:40, Lawrence D'Oliveiro wrote:
> In message<JBk4p.101614$ZS4.35831@newsfe07.iad>, Arved Sandstrom wrote:
>
>> On 11-02-07 11:06 PM, Lawrence D'Oliveiro wrote:
>>
>>> In message<4d50949a$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>
>>>> Real C apps that will run predictable on any platform is
>>>> pretty rare.
>>>
>>> Really?? We have them coming out our ears. I have thousands of them
>>> installed on my system alone. Let’s see, the Linux kernel, 15 million
>>> lines of source code, almost entirely in C, portable across about two
>>> dozen different major processor architectures. GCC, Apache, Python,
>>> Blender (a million lines of C, plus about 220 thousand lines of C++),
>>> Gimp ... the list goes on and on.
>>>
>> You've got a very optimistic definition of "portable" happening there.
>> It may come as a surprise to you, but all sorts of #ifdefs and
>> platform-specific configure scripts and makefiles don't mean that you've
>> got portable code - all of that is a response to the fact that you've
>> got _non-portable_ code.
>
> It is more portable than any Java code you can point to. QED.

Nonsense.

C code depending on ifdes requires changes to the source code
to be moved.

Java code does not require changes to the source code - actually
not even recompile: you can just move the byte code over.

Arne

On 10-02-2011 19:08, Lawrence D'Oliveiro wrote:
> In message<4d50b67b$0$23754$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 07-02-2011 22:06, Lawrence D'Oliveiro wrote:
>>> In message<4d5094f2$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>>> On 07-02-2011 15:22, Lawrence D'Oliveiro wrote:
>>>>>
>>>>> In message<iiop28$8jj$1@news.eternal-september.org>, Joshua Cranmer
>>>>> wrote:
>>>>>>
>>>>>> Writing portable code in C pretty much requires you to do hefty
>>>>>> compatibility layers.
>>>>>
>>>>> Not really. Sticking to standard POSIX types like size_t, time_t etc
>>>>> gets you a lot of the way there.
>>>>
>>>> POSIX does not cover all aspects.
>>>
>>> Well, you need tools like autoconf as well to handle the more complicated
>>> cases.
>>
>> The existence of that tool is an indication that there is a
>> portability problem.
>
> Which it solves.

No.

>> But autoconf does not solve all problems.
>
> Enough of them to fulfil the needs of hundreds of thousands of portable
> software packages.

Very few of them are portable. They just support a number
of platforms, which is completely different from portable.

>>>> And not all platforms are POSIX compliant.
>>>
>>> All the ones worth using are.
>>
>> Well - I don't think anyone defines portability as running unchanged on
>> the platform one specific person considers worth using.
>
> Except I’m talking about an order of magnitude more different platforms than
> you are.

Since I am talking about all platforms, then that is impossible.

Arne

On 10-02-2011 19:11, Lawrence D'Oliveiro wrote:
> In message<4d50b4e8$0$23754$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 07-02-2011 21:59, Lawrence D'Oliveiro wrote:
>>> In message<4d5032a8$0$41114$e4fe514c@news.xs4all.nl>, Silvio wrote:
>>>
>>>> For certain APIs (MS Windows conatins lots of them) struct layout
>>>> assumpations are essential.
>>>
>>> POSIX manages such things in a portable way.
>>
>> No.
>>
>> POSIX does the same thing as Windows.
>
> POSIX is designed for portability in a way that Windows is not.

Windows is actually running on multiple platforms.

For obvious reasons it does not run on multiple OS'es.

>                                                             Where Win32
> uses explicitly-sized types of 32 bits or 16 bits or whatever, POSIX uses
> symbolic names that can be handled differently by different implementations.

Have you considered learning anything about the topics you talk about?

Win32 API has a gazillion typdefs.

> Consider why there was even a need for a Win64, when there is no “POSIX64”.

Win64 API is the same as Win32 API just with a few different typedefs,
so what are you talking about????

Arne

On 13-02-2011 19:59, Lawrence D'Oliveiro wrote:
> In message<4d5092f7$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 07-02-2011 09:01, Thomas Richter wrote:
>>> "Lawrence D'Oliveiro" spat:
>>>>
>>>> Exercise for the reader: explain why Arne Vajhøj is wrong. For extra
>>>> credit, list the implicit preconceptions that might have led to such a
>>>> wrong conclusion.
>>>
>>> The reason is ... that people seem to assume that the linker has no
>>> intelligence, or that there is a linker in first place. Nevertheless, the
>>> C++ standard doesn't even define linking, and the world is no longer that
>>> simple. Thus, I still don't see how this argument applies. Surely the C++
>>> world works different from the java world, but saying that there is no
>>> duplicate code in Java or that there is always code duplication in C++ is
>>> surely wrong.
>>
>> It how the simple implementations do it.
>
> Where are there any “simple implementations” of C++?

Regarding this then I believe almost all are simple.

>> It is what the common implementations do it.
>
> By “common” do you mean Microsoft?

No.

MS, *nix, VMS etc..

Arne

Sulfide Eater <zaxx1108@example.com> writes:

136> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,rec.games.roguelike.development

136> Classic erroneous presupposition, trollen.

Who is "trollen", Eater?  There is nobody in this newsgroup
using that alias.

Del Murgatroid <delmurgatroid@gmail.com> writes:

1> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,rec.games.roguelike.development

1> So, how do you all like my usenet troll bots? They were actually
not
1> that hard to program, the basic underlying principle is a Markov
chain
1> of configuarble response scraps that are stitched together based
upon
1> a hierarchy of rules. On top of that I built a string analyzer - it
1> usually handles one sentence at a time, but can analyze up to 30
lines
1> of text at once (30 is just an arbitrary #, by the way, it can
easily
1> be expanded to more). This is the most complicated part of the bot,
as
1> it is here that it determines whether it will arbitrarially declare
1> the analyzed sentence a "fallacious argument" and state the
1> "determined" (I use that term _very_ loosely) fallacious argument
as a
1> complete & valid response to the statement, whether it will
randomly
1> add a totally unrelated newsgroup to the header file, or any of the
1> other 5 generic troll responses. I am especially proud of my
1> "nicknamesult analyzer" It uses a noise analysis algorithm, of my
own
1> devising, on each word to determine whether the non-bot poster is
1> attempting a "nicknamesult" or whether the replier is just a poor
1> speller, technically braindead, etc. (For example, a "nicknamesult"
1> for Arnold would be Assnold or some crap). I will be happy to sell
you
1> my botLib for $50usd. It works on usenet and all html-based forums
and
1> includes a Bot Manager to easily permit fine-tuning of targets,
1> direction of trolling and personalized responses for all deployed
bots
1> through one, while not simple, at least reasonably clear and
beginner
1> friendly interface. Flash-based forum targeting is coming soon.
1> $2,000.00usd to remove your newsgroup from the bot's reply list.

What does your question have to do with OS/2, Murgatroid?

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:

21> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

21> Most of the financial sector world wide.

21> Good chunks of accounting firms, retail and
21> public sector systems.

Trolls like Sulfide Eater never let the facts get in the way
of a good rant, Arne.

Heike Svensson <hsvensson.1093x1_q@hotmail.nospam.com.please> writes:

44> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

44> What does your question have to do with OS/2, tholenbot?

Who is "tholenbot", Svensson?  There is nobody in this newsgroup
using that alias.

44> And for the record the answer is "no", trollen;

Who is "trollen", Svensson?  There is nobody in this newsgroup
using that alias.

44> in fact I never do, thallium.

Who is "thallium", Svensson?  There is nobody in this newsgroup
using that alias.

44> But it can be fun to watch others argue, thalidomide,

Who is "thalidomide", Svensson?  There is nobody in this newsgroup
using that alias.

44> like you, Sulfide Eater, and Arne Vajh=F8j were doing, tholoon.

Who is "tholoon", Svensson?  There is nobody in this newsgroup
using that alias.

On 02/13/2011 08:01 PM, Lawrence D'Oliveiro wrote:
> In message<iinkpv$tbg$1@news.eternal-september.org>, Joshua Cranmer wrote:
>> No, it's in the definition of C++ templates.
>
> No, it isn’t.

You need to brush up on your reading skills then.

>> i.e., "you don't have to actually implement this specification so long
>> as a valid program can't tell that you aren't."
>
> My point exactly.

You failed to completely comprehend what I was getting at.

The specification requires them to be distinct classes--which implies 
with distinct code implementations; an implementation can only forgo 
that requirement if and only if the code does not actually check to make 
sure that it is the case.

>> See, it's clear you really haven't read the specs you're trying to
>> language lawyer with us on.
>
> So where did it say whether distinct types had to be implemented with the
> same or different code?

"Every program shall contain exactly one definition of every non-inline 
function or object that is used in that program; no diagnostic 
required." (§3.2, clause 3) The specification also goes so far as to 
specifically call out that "It is unspecified whether such a variable 
has an address distinct from that of any other object in the program." 
Given such a statement, it is reasonable to assume that the spec intends 
for distinct definitions to correspond to distinct objects unless 
otherwise mentioned.

Suffice to say, it is required, in Java, for two instantiations of a 
generic type with the same raw type to share the same code, whereas in 
C++, there are cases where this simply cannot be the case, and the spec 
intends for it to never be the case, so far as the program can tell.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 13-02-2011 17:28, Lawrence D'Oliveiro wrote:
>> In other words, Java code cannot be ported to a system until C has been
>> ported to that system. Or, in other other words:
>>      Java portability ≤ C portability

What's so dubious about that statement? Looks perfectly valid to me.
In case you saw a question-mark in his last line, that was a "smaller
or equal"-sign.

The whole discussion resolves quickly, when you distinguish two
separate points:
 1) availability of a language on a platform
 2) The actual effort of making a particular set of code
       run on a particular platform once it fulfills "1)"

Obviously, Lawrence talks about "1)", while you (Arne) seem to
have "2)" in mind.

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 08-02-2011 05:25, Andreas Leitgeb wrote:
>> The "problem" about type-erasure is over-rated.
> There are other reasons to not have type erasure.

> new T
Generics are also about not knowing the parameter types
beforehand (except that it derives from some upper bound
class). Thus, the compiler wouldn't be able to determine
availability of an appropriate constructor at compile-time.
Thus, it would once again be a runtime-thing.

If generics were re-compiled for each used parametrisation,
like C++'s templates are, then this argument would be voided,
but I don't know if any current proposals for getting
reifiability into Java go all that far.

> general reflection
is a runtime-thing.

> method overload
If this is a problem, then there was a problem in design
phase. Such overloaded methods would just as well prohibit
using abstract base types for variables. (i.o.w.: would be
bad even aside of generics)

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 08-02-2011 07:53, Lew wrote:
>> Andreas Leitgeb wrote:
>>> The "problem" about type-erasure is over-rated.
>> I'm very glad you made that point. I am glad we have type erasure in
>> Java. It forces you to deal with type assertions at compile time.

> Can you give an example of where introduction of reifiable type
> would cause not getting a compile time error but a runtime error
> instead?

Bad programmers :-)
They might then (without other need) cast a List<String> to a bare List,
relying on runtime-checks to prevent non-Strings to get actually added.

On 2/14/11 5:23 PM, Andreas Leitgeb wrote:
> Arne Vajhøj<arne@vajhoej.dk>  wrote:
>> On 08-02-2011 07:53, Lew wrote:
>>> Andreas Leitgeb wrote:
>>>> The "problem" about type-erasure is over-rated.
>>> I'm very glad you made that point. I am glad we have type erasure in
>>> Java. It forces you to deal with type assertions at compile time.
>
>> Can you give an example of where introduction of reifiable type
>> would cause not getting a compile time error but a runtime error
>> instead?
>
> Bad programmers :-)
> They might then (without other need) cast a List<String>  to a bare List,

But that's the point.  With reifiable types, that cast would fail.  The 
code would never get as far as trying to add non-Strings to the list.

Pete

On 13/02/2011 9:13 PM, Arne Vajh�j wrote:
> On 12-02-2011 22:17, Sulfide Eater wrote:
>> On 12/02/2011 9:18 PM, Arne Vajh�j wrote:
>>> On 12-02-2011 21:08, Sulfide Eater wrote:
>>>> I am asking who actually used it. Having 3 adopters all of which were
>>>> large organizations is still having 3 adopters and a tiny sliver of
>>>> market share.
>>>
>>> It is a lot more than 3.
>>
>> Wow, was it 6? Maybe even 10? Maybe even as many as 100? Out of what,
>> millions? :)
>
> Most of the financial sector world wide.

Get real. They were using COBOL on Vaxen. Half of them still are. 
Everybody knows this.

"Sulfide Eater" <zaxx1108@example.com> writes:
> On 13/02/2011 9:31 PM, tholen@antispam.ham wrote:
>> =?ISO-8859-1?Q?Arne_Vajh=F8j?=<arne@vajhoej.dk>  writes:
>> 21>  Good chunks of accounting firms, retail and
>> 21>  public sector systems.
>
> Get real. Those were using COBOL on Vaxen. Half of them
> still are. Everybody knows this.

Smack that brutish Arne around a bit!

>> [insult deleted]s like Sulfide Eater [false accusation
>> deleted], Arne.
>
> What does your classic erroneous presupposition have to
> do with OS/2, trolloon?

Give that nasty tholenbot a taste of its own medicine!

On 13/02/2011 9:09 PM, Del Murgatroid wrote:
> So, how do you all like my usenet troll bots? They were actually not
> that hard to program, the basic underlying principle is a Markov chain
> of configuarble response scraps that are stitched together based upon
> a hierarchy of rules.

Ah. About what I figured. The tholenbot never struck me as being 
particularly sophisticated. Aye, with 23rd-century technology a child 
could cobble it together.

> On top of that I built a string analyzer - it usually handles one
> sentence at a time, but can analyze up to 30 lines of text at once
> (30 is just an arbitrary #, by the way, it can easily be expanded
> to more).

That'd be the threshold between "what does that have to do with OS/2" 
and "what does any of that have to do with OS/2", I take it?

> I am especially proud of my "nicknamesult analyzer" It uses a noise
> analysis algorithm, of my own devising, on each word to determine
> whether the non-bot poster is attempting a "nicknamesult" or whether
> the replier is just a poor speller, technically braindead, etc.

Aye, it seems to be not too bad at recognizing "trollenbot" etc. as insults.

> (For example, a "nicknamesult" for Arnold would be Assnold or some
> crap).

"Arnhole" would seem to be a bit more clever. It implies, you see, 
without quite stooping to explicit vulgarity.

> I will be happy to sell you my botLib for $50usd.

Sell me? Up your shaft. I could write something like that in me sleep! 
Open source the wee bugger and then I may be interested.

> It works on usenet and all html-based forums

Aye, it's been sighted at a blog called Against Monopoly as well as 
hereabouts.

> includes a Bot Manager to easily permit fine-tuning of targets,
> direction of trolling and personalized responses for all deployed bots
> through one, while not simple, at least reasonably clear and beginner
> friendly interface. Flash-based forum targeting is coming soon.

How did ye get it to recognize certain, er, pop culture references, 
laddie? That's the one bit that's a wee bit sophisticated.

> $2,000.00usd to remove your newsgroup from the bot's reply list.

Why, ye low-down, extortionate, bollocks-licking numpty scrote sack! I 
ought ta report ya tae Scotland Yard, ye wee miserable nyaff! Now git 
outta me sight, ye bum-scratching bampot, before I start makin' phone calls!

Del Murgatroid, indeed -- more like Dull Murkytroll, if ye ask me. 
*shakes head*

-- 
I know this ship like the back of my hand.
<CLANG!>

On 11-02-14 04:51 AM, Andreas Leitgeb wrote:
> Arne Vajhøj<arne@vajhoej.dk>  wrote:
>> On 13-02-2011 17:28, Lawrence D'Oliveiro wrote:
>>> In other words, Java code cannot be ported to a system until C has been
>>> ported to that system. Or, in other other words:
>>>       Java portability ≤ C portability
>
> What's so dubious about that statement? Looks perfectly valid to me.
> In case you saw a question-mark in his last line, that was a "smaller
> or equal"-sign.
>
> The whole discussion resolves quickly, when you distinguish two
> separate points:
>   1) availability of a language on a platform
>   2) The actual effort of making a particular set of code
>         run on a particular platform once it fulfills "1)"
>
> Obviously, Lawrence talks about "1)", while you (Arne) seem to
> have "2)" in mind.
>
I also (rather clearly I thought) have (2) in mind. Code portability to 
me is a measure of the amount of modifications that have to be made to a 
corpus of user code (application, library etc) written in language X in 
order to execute it successfully on a number of different platforms. No 
modifications -> completely portable code, few modifications -> highly 
portable code, extensive modifications -> nearly unportable code.

In the case of the .NET CLR and the JVM and scripting language 
interpreters, those _are_ the platforms. Question (1) then translates to 
the availability of the platform on a given OS. But question (2) for 
languages based on the CLR and JVM and scripting language interpreters 
is very black and white - code portability with respect to OS A is zero 
while the language platform is unavailable, and then becomes close to 
100% when the language platform _is_ available.

In essence your question (1) has to do with _language_ portability. 
Question (2) has to do with _code_ portability, which is what I thought 
we were talking about.

C, OTOH, has been very good wrt question (1) for a long time. But it 
requires varying degrees of work wrt question (2), on a _case by case_ 
basis, which means that

Java _code_ portability > C _code_ portability

I don't think Lawrence is consciously talking about (1), I suspect he 
does not understand the distinctions here. Unless he's an infrastructure 
programmer (and based on other threads I hope to God he's not) he ought 
to be concerned about code portability first and foremost.

As another example, I've been writing fairly complicated C# 3.0/C# 4.0 
apps on Mac OS X 10.6 (mono 2.8), Ubuntu 10.10 (mono 2.6.7) and Windows 
XP (latest stuff from MS), including ASP.NET MVC stuff and doing lots of 
DB access. The various apps are as close to WORA between the platforms 
as one can imagine, in terms of _code_ portability. I would not expect 
to be writing C code that accomplishes the same things, and be able to 
plunk it into gcc or VS on all those platforms, and watch it compile and 
link without any mods.

AHS
-- 
We must recognize the chief characteristic of the modern era - a 
permanent state of what I call violent peace.
-- James D. Watkins

On Mon, 14 Feb 2011 17:51:23 +0800, Peter Duniho wrote:

> On 2/14/11 5:23 PM, Andreas Leitgeb wrote:
>> Arne Vajhøj<arne@vajhoej.dk>  wrote:
>>> On 08-02-2011 07:53, Lew wrote:
>>>> Andreas Leitgeb wrote:
>>>>> The "problem" about type-erasure is over-rated.
>>>> I'm very glad you made that point. I am glad we have type erasure in
>>>> Java. It forces you to deal with type assertions at compile time.
>>
>>> Can you give an example of where introduction of reifiable type would
>>> cause not getting a compile time error but a runtime error instead?
>>
>> Bad programmers :-)
>> They might then (without other need) cast a List<String>  to a bare
>> List,
> 
> But that's the point.  With reifiable types, that cast would fail.  The
> code would never get as far as trying to add non-Strings to the list.

Reifyable types wouldn't make a compile time difference in the case of 
unsafe use of the raw type. At run time, the effect would be to throw 
when the code tried to add a non-String, rather than the non-String 
lurking in the list like a roadside bomb and blowing up later in some 
innocent traversing method's face, masking the true source of the bug.

On 14/02/2011 6:12 AM, Arved Sandstrom wrote:
> As another example, I've been writing fairly complicated C#

To the devil with you, then, you ... you ... you traitor to the JVM! ;)

On 02/14/2011 03:51 AM, Andreas Leitgeb wrote:
> Arne Vajhøj<arne@vajhoej.dk>  wrote:
>> On 13-02-2011 17:28, Lawrence D'Oliveiro wrote:
>>> In other words, Java code cannot be ported to a system until C has been
>>> ported to that system. Or, in other other words:
>>>       Java portability ≤ C portability
>
> What's so dubious about that statement? Looks perfectly valid to me.
> In case you saw a question-mark in his last line, that was a "smaller
> or equal"-sign.
>
> The whole discussion resolves quickly, when you distinguish two
> separate points:
>   1) availability of a language on a platform
>   2) The actual effort of making a particular set of code
>         run on a particular platform once it fulfills "1)"
>
> Obviously, Lawrence talks about "1)", while you (Arne) seem to
> have "2)" in mind.
>

There is also point 3) The effort of getting a binary to run on many 
different platforms.

Java excels quite nicely at 3, while I'd love to see someone try to get 
a C-based i386 Win16 program to run on my shiny ARM7 processor running 
Linux.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote:
> In the case of the .NET CLR and the JVM and scripting language 
> interpreters, those _are_ the platforms.

That's funny, because by that definition, Java apps (and .NET and scripts)
would be entirely *unportable* - i.e., work only on that one "platform" ;)

> C, OTOH, has been very good wrt question (1) for a long time. But it 
> requires varying degrees of work wrt question (2), on a _case by case_ 
> basis...

I do have the impression of a violent agreement here.
Lawrence perhaps sees the difference not all that large as many
others do, though.

> I would not expect 
> to be writing C code that accomplishes the same things, and be able to 
> plunk it into gcc or VS on all those platforms, and watch it compile and 
> link without any mods.

Depends on what libs you build upon in C (or C++).
Those libs likely have lots of #ifdef'ery inside,
but just as likely so do the native methods in the JSL.

Sulfide Eater <zaxx1108@example.com> writes:

137> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

137> Get real. They were using COBOL on Vaxen. Half of them still
are.
137> Everybody knows this.

On what basis do you speak for "everybody", Eater?

By the way, you don't speak for me, Eater.

Heike Svensson <hsvensson.1093x1_q@hotmail.nospam.com.please> writes:

45> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

45> Smack that brutish Arne around a bit!

What does your directive have to do with OS/2, Svensson?

45> Give that nasty tholenbot a taste of its own medicine!

Who is "tholenbot", Svensson?  There is nobody in this newsgroup
using that alias.

Mister Scott <m_scott.19477b@noggles.corn> writes:

12> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,rec.games.roguelike.development

12> Ah. About what I figured. The tholenbot never struck me as being
12> particularly sophisticated. Aye, with 23rd-century technology a
child
12> could cobble it together.

Who is "tholenbot", Mister Scott?  There is nobody in this
newsgroup using that alias.

12> That'd be the threshold between "what does that have to do with OS/
2"
12> and "what does any of that have to do with OS/2", I take it?

Your take it wrong, Mister Scott.

12> Aye, it seems to be not too bad at recognizing "trollenbot" etc.
as insults.

Who is "trollebot", Mister Scott?  There is nobody in this
newsgroup using that alias.

12> "Arnhole" would seem to be a bit more clever. It implies, you
see,
12> without quite stooping to explicit vulgarity.

What does that have to do with OS/2, Mister Scott?

12> Sell me? Up your shaft. I could write something like that in me
sleep!
12> Open source the wee bugger and then I may be interested.

What does your question have to do with OS/2, Mister Scott?

12> Aye, it's been sighted at a blog called Against Monopoly as well
as
12> hereabouts.

What does that have to do with OS/2, Mister Scott?

12> How did ye get it to recognize certain, er, pop culture
references,
12> laddie? That's the one bit that's a wee bit sophisticated.

What does your question have to do with OS/2, Mister Scott?

12> Why, ye low-down, extortionate, bollocks-licking numpty scrote
sack! I
12> ought ta report ya tae Scotland Yard, ye wee miserable nyaff! Now
git
12> outta me sight, ye bum-scratching bampot, before I start makin'
phone calls!

What does that have to do with OS/2, Mister Scott?

12> Del Murgatroid, indeed -- more like Dull Murkytroll, if ye ask
me.
12> *shakes head*

What does that have to do with OS/2, Mister Scott?

Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
> On 2/14/11 5:23 PM, Andreas Leitgeb wrote:
>> Arne Vajhøj<arne@vajhoej.dk>  wrote:
>>> Can you give an example of where introduction of reifiable type
>>> would cause not getting a compile time error but a runtime error
>>> instead?
>> Bad programmers :-)
>> They might then (without other need) cast a List<String>  to a bare List,
> But that's the point.  With reifiable types, that cast would fail.

Would it, or would it not?  Who can tell?

I agree, that for certian implementations of reifyability there may not
exist an example as requested by Arne, or at least not one that I could
anticipate now without knowing the actual implementation.

On 2/14/11 9:45 PM, Andreas Leitgeb wrote:
> Peter Duniho<NpOeStPeAdM@NnOwSlPiAnMk.com>  wrote:
>> On 2/14/11 5:23 PM, Andreas Leitgeb wrote:
>>> Arne Vajhøj<arne@vajhoej.dk>   wrote:
>>>> Can you give an example of where introduction of reifiable type
>>>> would cause not getting a compile time error but a runtime error
>>>> instead?
>>> Bad programmers :-)
>>> They might then (without other need) cast a List<String>   to a bare List,
>> But that's the point.  With reifiable types, that cast would fail.
>
> Would it, or would it not?  Who can tell?

I don't understand the question. By definition, a reified generic 
incorporates the entire type (generic type along with type parameters) 
within the type.  See the C# generic system for an example.

> I agree, that for certian implementations of reifyability there may not
> exist an example as requested by Arne, or at least not one that I could
> anticipate now without knowing the actual implementation.

It would help if you could explain how your definition of "reified" 
still allows for raw types.  How do you get a reified generic type 
system where the instance of one concrete generic type is still 
assignable to a variable that's declared as a completely different 
concrete generic type, or even a completely different raw type?

Please note that "reified" doesn't simply mean you have access to the 
type parameter.  It means that you get a specific and unique, _concrete_ 
instance of the abstract generic type.  Being a unique type in and of 
itself, it would be subject to all the same rules of casting and 
assignment that every other type has in Java.

Thanks,
Pete

On 14/02/2011 8:22 AM, tholen@antispam.ham wrote:
> Sulfide Eater<zaxx1108@example.com>  writes:
>
> 137>  Newsgroups:
> comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex
>
> 137>  Get real. They were using COBOL on Vaxen. Half of them still
> are.
> 137>  Everybody knows this.
>
> On what basis do you speak for "everybody", Eater?

I am not claiming to do so, tholenoid; merely making a statement of fact 
regarding a particular other fact being common knowledge, trollen.

> By the way, you don't speak for me, Eater.

You don't speak at all, thalidomide, nor will you until your developer 
decides to add a voice synthesis feature to your program, tholenbot. 
Though I can't imagine why he would, thallium -- perhaps to turn you 
loose on an unsuspecting VOIP-using populace, trillium?

On 14/02/2011 8:28 AM, tholen@antispam.ham wrote:
> Mister Scott<m_scott.19477b@noggles.corn>  writes:
> 12>  That'd be the threshold between "what does that have to do with OS/
> 12>  2" and "what does any of that have to do with OS/2", I take it?
>
> Your take it wrong, Mister Scott.

Well, I'll be -- Dull Murkytroll even programmed ye to lie, tholenbot!

-- 
I know this ship like the back of my hand.
<CLANG!>

Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
> On 2/14/11 9:45 PM, Andreas Leitgeb wrote:
>> Would it, or would it not?  Who can tell?
> I don't understand the question. By definition, a reified generic 
> incorporates the entire type (generic type along with type parameters) 
> within the type.

I admit maybe being a bit naive about this. Just like you could
probably still assign an ArrayList<String> to an Object-typed 
variable, I meant, that you could also assign it to a bare List
type as being some sort of imaginary superclass/interface of the
correctly parameterized one.

> See the C# generic system for an example.

Learning C# is currently not on my todo-list, and all I know
about it happens to be what I gathered here in c.l.j.p

> ... Being a unique type in and of 
> itself, it would be subject to all the same rules of casting and 
> assignment that every other type has in Java.

yep, had that in mind.

On 2/15/11 1:43 AM, Andreas Leitgeb wrote:
> Peter Duniho<NpOeStPeAdM@NnOwSlPiAnMk.com>  wrote:
>> On 2/14/11 9:45 PM, Andreas Leitgeb wrote:
>>> Would it, or would it not?  Who can tell?
>> I don't understand the question. By definition, a reified generic
>> incorporates the entire type (generic type along with type parameters)
>> within the type.
>
> I admit maybe being a bit naive about this. Just like you could
> probably still assign an ArrayList<String>  to an Object-typed
> variable, I meant, that you could also assign it to a bare List
> type as being some sort of imaginary superclass/interface of the
> correctly parameterized one.

Ah, I see.  And the answer is, well…yes.  That could happen in theory. 
It happens in .NET too.  With the introduction of generics, the old 
interfaces such as IEnumerable, IList, ICollection, etc. got new 
counterparts IEnumerable<T>, IList<T>, ICollection<T>.  In some cases, 
such as for IEnumerable<T>, the new interface inherits the old one.

But note that IList<T> and ICollection<T> do _not_ inherit their old 
counter-part.  IEnumerable<T> can do it because it's essentially 
covariant with respect to its type parameter T and IEnumerable is itself 
equivalent to IEnumerable<object>.  Assigning an IEnumerable<T> to an 
IEnumerable can't harm anything because you can only get things _out_ of 
IEnumerable, not put them into it.

But for similar reasoning, it would not be safe to assign IList<T> to an 
IList, in the same way you point out it would not be safe to assign (for 
example) List<T> to List.  IList<T> can't have variance with respect to 
the type parameter T because it's used both as input and output to the type.

The way to deal with this is to not have IList<T> inherit IList in the 
first place, and presumably reified generics in Java would follow a 
similar approach.

In other words, yes…it's true that you could in fact design a screwed up 
type hierarchy in which bad things were possible.  The solution?  Don't 
do that!  :)

Pete

On 11-02-14 09:22 AM, Andreas Leitgeb wrote:
> Arved Sandstrom<asandstrom3minus1@eastlink.ca>  wrote:
>> In the case of the .NET CLR and the JVM and scripting language
>> interpreters, those _are_ the platforms.
>
> That's funny, because by that definition, Java apps (and .NET and scripts)
> would be entirely *unportable* - i.e., work only on that one "platform" ;)
[ SNIP ]

In a weird kind of way that's quite true - good point. :-) I guess we 
could argue whether Java has either zero portability or very high 
portability, depending on how you define "platform".

AHS
-- 
We must recognize the chief characteristic of the modern era - a 
permanent state of what I call violent peace.
-- James D. Watkins

Sulfide Eater <zaxx1108@example.com> writes:

138> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

138> I am not claiming to do so,

Classic contradiction:

   "Everybody knows this."
      --Sulfide Eater

138> tholenoid;

Who is "tholennoid", Eater?  There is nobody in this newsgroup
using that alias.

138> merely making a statement of fact
138> regarding a particular other fact being common knowledge,
trollen.

Classic erroneous presupposition.

138> You don't speak at all, thalidomide,

Who is "thalidomide", Eater?  There is nobody in this newsgroup
using that alias.

138> nor will you until your developer
138> decides to add a voice synthesis feature to your program,
tholenbot.

Who is "tholenbot", Eater?  There is nobody in this newsgroup
using that alias.

138> Though I can't imagine why he would, thallium

Who is "thallium", Eater?  There is nobody in this newsgroup
using that alias.

138> -- perhaps to turn you loose on an unsuspecting VOIP-using
populace,
138> trillium?

Who is "trillium", Eater?  There is nobody in this newsgroup
using that alias.

Mister Scott <m_scott.19477b@noggles.corn> writes:

13> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,rec.games.roguelike.development

13> Well, I'll be -- Dull Murkytroll even programmed ye to lie,
tholenbot!

Who is "tholenbot", Mister Scott?  There is nobody in this
newsgroup using that alias.

Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
> Ah, I see.  And the answer is, well…yes.  That could happen in theory. 
> It happens in .NET too.

I notice I digressed unnecessarily by throwing in bare types.

Lew's claim was, that reifyability may even be bad. Then someone
asked, how reifyability could ever possibly hurt.

Then I *should* have said the following:
  With reifyable types, lazy programmers might prefer to assign an
ArrayList<Foo<Bar,Snafu>> just to an Object variable at some point,
relying on reifyability for having any later cast properly checked.
But if something was wrong, those checks would only bomb at runtime!

You're free to choose not to accept arguments like "a lazy programmer
might ...". If so, then so be it.   For me this subthread is closed.
Perhaps Lew picks up the ball himself and posts a better argument...

Joshua Cranmer <Pidgeot18@verizon.invalid> wrote:
> ..., while I'd love to see someone try to get 
> a C-based i386 Win16 program to run on my shiny
> ARM7 processor running 

Not sure...   dosemu?  vmware? ...  ;-)

On 2/15/11 8:21 AM, Andreas Leitgeb wrote:
> Peter Duniho<NpOeStPeAdM@NnOwSlPiAnMk.com>  wrote:
>> Ah, I see.  And the answer is, well…yes.  That could happen in theory.
>> It happens in .NET too.
>
> I notice I digressed unnecessarily by throwing in bare types.
>
> Lew's claim was, that reifyability may even be bad. Then someone
> asked, how reifyability could ever possibly hurt.
>
> Then I *should* have said the following:
>    With reifyable types, lazy programmers might prefer to assign an
> ArrayList<Foo<Bar,Snafu>>  just to an Object variable at some point,
> relying on reifyability for having any later cast properly checked.
> But if something was wrong, those checks would only bomb at runtime!

I guess I'm confused as to what point you're trying to make.  Is your 
goal to support or refute what Lew wrote?  Because the above appears to 
me to refute Lew's assertion that reifiable types could have negative 
consequences and implication that there are no useful benefits.

Note that even without reifiable types, lazy programmers might prefer to 
assign an ArrayList<Foo<Bar, Snafu>> to Object.  Then, casting back to 
anything other than an ArrayList would fail.  But in Java, the cast 
could be to _any_ ArrayList, and on top of that, any addition, even 
something not a Foo<Bar, Snafu>, to the list would also succeed.

Any run-time failure would occur later, when code tried to retrieve an 
object from the list and cast it to Foo<Bar, Snafu>, leaving the 
programmer trying to figure out how the non-Foo<Bar, Snafu> got into the 
list in the first place.

With a reifiable generic system, you'd get the type-cast failure as soon 
as the Object was cast back to anything other than ArrayList<Foo<Bar, 
Snafu>>, leaving no doubt as to the precise point of failure.  You would 
not even get as far as being able to try to add something other than a 
Foo<Bar, Snafu> to the list; that would be checked at compile time 
(because you can only add Foo<Bar, Snafu> to lists that support those 
types, and an ArrayList<Foo<Bar, Snafu>> would support only interfaces 
that explicitly allow that type).

> You're free to choose not to accept arguments like "a lazy programmer
> might ...". If so, then so be it.

I have no idea what that's supposed to mean.  I am actually very fond of 
language features that prevent a lazy programmer from doing the wrong 
thing.  It's one of the reasons I like Java (and its heir to the throne, 
C#) so much: it's much harder (though not impossible) for laziness to 
result in incorrect code.

Just the other day, a coworker accidentally wrote (essentially) this 
sequence of code in C++, using C++'s template feature and the STL vector 
template:

   void function(int n)
   {
     vector<bool> vf;

     vf.resize(n);

     const bool *pf = (const bool *)&vf[0];

     // do some stuff with pf
   }

I failed to notice the problem myself. In C++, while vector<T> is a 
general-purpose template, C++ also allows "template specialization", of 
which vector<bool> is one.  While the normal vector<T> implementation 
stores each T element in a plain array, the vector<bool> implementation 
is "fancy" and stores the flags more compactly, as a bit array.  Taking 
the address of the first element is not really even allowed.

Except that two C++ features conspired to allow the above code.  The 
first was that it was a Microsoft compiler (trolls feel free to insert 
standard snarky anti-Microsoft comment here), with Microsoft language 
extensions enabled.  The second was that C++ figures if you write an 
explicit cast, you know what the heck you're doing and carries on 
without complaint.

The "lazy" comes in, in that even with Microsoft extensions enabled, the 
above code did not compile without the cast (even though were it legal 
to take the address of the 0th element, it would have), and rather than 
figuring out what the error message was saying, they just stuck a cast 
in to get the compiler to shut up.

While I was happy to be reminded about the vector<bool> trap, I was even 
happier to be reminded that in my current languages of preference, one 
could not even have accomplished that particular mistake.

Anyway, that's a long way of saying that I'm not against "it prevents 
lazy programmers from being mistakes" as a justification for or against 
language features.  I just don't see how reifiable generics would 
somehow enable, never mind encourage, laziness.

 > For me this subthread is closed.
> Perhaps Lew picks up the ball himself and posts a better argument...

Does that mean that you are in agreement with Lew?  If so, does that 
mean you are unable to actually explain _why_ you agree with Lew?

Pete

In message <4d58929a$0$23756$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 10-02-2011 19:11, Lawrence D'Oliveiro wrote:
>
>> In message<4d50b4e8$0$23754$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>
>>> On 07-02-2011 21:59, Lawrence D'Oliveiro wrote:
>>>
>> POSIX is designed for portability in a way that Windows is not.
> 
> Windows is actually running on multiple platforms.

All but one of which are now defunct.

> For obvious reasons it does not run on multiple OS'es.

I thought Windows WAS an OS.

>> Where Win32 uses explicitly-sized types of 32 bits or 16 bits or
>> whatever, POSIX uses symbolic names that can be handled differently by
>> different implementations.
> 
> Have you considered learning anything about the topics you talk about?

Have you?

> Win32 API has a gazillion typdefs.

Which are tied to specific sizes like 16 and 32 bits.

>> Consider why there was even a need for a Win64, when there is no
>> “POSIX64”.
> 
> Win64 API is the same as Win32 API just with a few different typedefs,
> so what are you talking about????

The fact that it needs to exist.

Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
> On 2/15/11 8:21 AM, Andreas Leitgeb wrote:
>> Peter Duniho<NpOeStPeAdM@NnOwSlPiAnMk.com>  wrote:
>>> Ah, I see.  And the answer is, well…yes.  That could happen in theory.
>>> It happens in .NET too.
>> I notice I digressed unnecessarily by throwing in bare types.
>> Lew's claim was, that reifyability may even be bad. Then someone
>> asked, how reifyability could ever possibly hurt.
>> Then I *should* have said the following:
>>    With reifyable types, lazy programmers might prefer to assign an
>> ArrayList<Foo<Bar,Snafu>>  just to an Object variable at some point,
>> relying on reifyability for having any later cast properly checked.
> I guess I'm confused as to what point you're trying to make.  Is your 
> goal to support or refute what Lew wrote?

It's amazing how something that - even on second reading - sounds
crystal clear to me, seems to be suahili to others...

Lets try a completely different parable:  Safety nets.

Java already has a safety net: Even if I accidentally get an
ArrayList<String> instance into a List<Integer>-typed reference,
I won't crush into the ground ... ahem, won't be able to access
any of its non-null elements as Integers.

Reifyable generics would raise this net a notch higher, so falling
into it would be somewhat more comfortable - but that still doesn't
change the fact of "falling".

The ultimate goal is *not* falling into the net, rather than 
falling more comfortably!

> Does that mean that you are in agreement with Lew?  If so, does that 
> mean you are unable to actually explain _why_ you agree with Lew?

I do hope, my point became clearer, now.

On 2/15/11 7:08 PM, Andreas Leitgeb wrote:
> [...]
>> Does that mean that you are in agreement with Lew?  If so, does that
>> mean you are unable to actually explain _why_ you agree with Lew?
>
> I do hope, my point became clearer, now.

Unfortunately, no.  And your failure to actually answer my question 
directly didn't help matters.

Lew wrote: "The problem with reifiable types is that it's too easy to do 
a half-assed job of your type analysis, thus resulting in the runtime 
errors to which Andreas alludes."  Since reified generics doesn't 
_reduce_ any of the compile-time protections that Java's generic 
provide, it's unclear to me what "half-assed job" Lew's talking about here.

And if that point _does_ have some validity, then I wonder what any of 
us are doing wasting our time with Java in the first place.  Java does 
all sorts of things that remove the need for the programmer to focus on 
certain kinds of program correctness.  This even includes the generics 
feature.  If that was justification for eschewing features, we would 
still be programming computers with front panel switches.

As far as your "safety net" example goes, for that particular example, 
the important consideration there is that while you can't extract 
objects of the wrong type should they happen to get into the list, the 
error will be far removed from the section of code where the actual bug 
exists.  That is definitely a poorer way to deal with the error than for 
it to occur immediately.

But really, that whole scenario doesn't seem relevant to me.  The point 
is that reified generics offer _other_ benefits besides that one.  I 
really don't see how it's a bad thing for the run-time errors to be more 
precise, but even if we decided that was true, that does not speak to 
the other advantages reified generics provide.

It seems to me that the crux of the problem is in your statement that 
"But generics aren't about runtime errors. They are about being able to 
prevent some runtime-errors, by turning them into compile-time errors". 
If you _believe_ that statement, then I agree…it's true that any 
run-time benefit is irrelevant.  But that truth is a trivial, 
tautological outcome of the assumption.

My belief is that stronger compile-time correctness is but _one_ benefit 
of generics, and that it's a mistake to think that's the _only_ benefit, 
or that that's all "they are about".  I can see how someone focused on 
Java would think that's all they are about.  In Java, that _is_ all they 
are about, because Java generics disappear after the compiler is done 
with them.  But that doesn't mean the same is true of the concept of 
generics.  It just means that's Java's particular implementation of them.

If you start with the assumption that Java's current implementation of 
generics is the end-all, be-all to generics then yes, you will conclude 
that there is nothing to be gained by adding new features to Java 
generics.  But making language design decisions on such circular logic 
seems pretty short-sighted to me.

Pete

Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
> On 2/15/11 7:08 PM, Andreas Leitgeb wrote:
>> I do hope, my point became clearer, now.
> Unfortunately, no.

Then I give up.  Sorry for all your unanswered questions.

Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> wrote:
> Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
>> On 2/15/11 7:08 PM, Andreas Leitgeb wrote:
>>> I do hope, my point became clearer, now.
>> Unfortunately, no.
> Then I give up.  Sorry for all your unanswered questions.

Well, not yet. Just one more line:
My point is, that the higher safety net may *discourage*
people from investing more brain into "not-falling."

On 2/15/11 8:24 PM, Andreas Leitgeb wrote:
> Andreas Leitgeb<avl@gamma.logic.tuwien.ac.at>  wrote:
>> Peter Duniho<NpOeStPeAdM@NnOwSlPiAnMk.com>  wrote:
>>> On 2/15/11 7:08 PM, Andreas Leitgeb wrote:
>>>> I do hope, my point became clearer, now.
>>> Unfortunately, no.
>> Then I give up.  Sorry for all your unanswered questions.
>
> Well, not yet. Just one more line:
> My point is, that the higher safety net may *discourage*
> people from investing more brain into "not-falling."

And my point is, why is that a bad thing?  I have only a limited amount 
of brain to apply to any particular problem.  I would prefer to apply 
that limited amount of brain to the _interesting_ parts of the problem 
rather than wasting time applying it to parts of the problem that a 
computer can just as easily figure out on its own.

I am particularly amused at the irony of _any_ regular posting to a 
_Java_ forum complaining about any feature that makes it _harder_ to 
make mistakes.  That really is too rich.

Pete

Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
>> My point is, that the higher safety net may *discourage*
>> people from investing more brain into "not-falling."
> And my point is, why is that a bad thing?

This is kind of an "axiom" for me, so I can't support it with
further arguments.

On 2/15/11 9:37 PM, Andreas Leitgeb wrote:
> Peter Duniho<NpOeStPeAdM@NnOwSlPiAnMk.com>  wrote:
>>> My point is, that the higher safety net may *discourage*
>>> people from investing more brain into "not-falling."
>>
>> And my point is, why is that a bad thing?
>
> This is kind of an "axiom" for me, so I can't support it with
> further arguments.

You have an _axiom_ that states that a certain kind of safety net is bad 
while another kind of safety net is fine?

That's pretty damn specific for an axiom.  Around here, we call that 
"dogma".

On 2/13/2011 9:09 PM, Del Murgatroid wrote:
> So, how do you all like my usenet troll bots?

!()#%* off, and let's never meet in person!

On 15-02-2011 02:01, Lawrence D'Oliveiro wrote:
> In message<4d58929a$0$23756$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 10-02-2011 19:11, Lawrence D'Oliveiro wrote:
>>> In message<4d50b4e8$0$23754$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>>
>>>> On 07-02-2011 21:59, Lawrence D'Oliveiro wrote:
>>>>
>>> POSIX is designed for portability in a way that Windows is not.
>>
>> Windows is actually running on multiple platforms.
>
> All but one of which are now defunct.

Which is not correct. x86, x86-64 and IA-64. And ARM on its way.

>> For obvious reasons it does not run on multiple OS'es.
>
> I thought Windows WAS an OS.

Yes. Single OS not multiple OS:

>>> Where Win32 uses explicitly-sized types of 32 bits or 16 bits or
>>> whatever, POSIX uses symbolic names that can be handled differently by
>>> different implementations.
>>
>> Have you considered learning anything about the topics you talk about?
>
> Have you?
>
>> Win32 API has a gazillion typdefs.
>
> Which are tied to specific sizes like 16 and 32 bits.

No - they can be changed if needed.

Exactly like POSIX.

>>> Consider why there was even a need for a Win64, when there is no
>>> “POSIX64”.
>>
>> Win64 API is the same as Win32 API just with a few different typedefs,
>> so what are you talking about????
>
> The fact that it needs to exist.

Windows did the same thing as POSIX.

You change a few typedefs and then it is 64 bit.

Arne

On 14-02-2011 03:51, Andreas Leitgeb wrote:
> Arne Vajhøj<arne@vajhoej.dk>  wrote:
>> On 13-02-2011 17:28, Lawrence D'Oliveiro wrote:
>>> In other words, Java code cannot be ported to a system until C has been
>>> ported to that system. Or, in other other words:
>>>       Java portability ≤ C portability
>
> What's so dubious about that statement? Looks perfectly valid to me.
> In case you saw a question-mark in his last line, that was a "smaller
> or equal"-sign.
>
> The whole discussion resolves quickly, when you distinguish two
> separate points:
>   1) availability of a language on a platform
>   2) The actual effort of making a particular set of code
>         run on a particular platform once it fulfills "1)"
>
> Obviously, Lawrence talks about "1)", while you (Arne) seem to
> have "2)" in mind.

But #1 has nothing to do with portability.

http://en.wikipedia.org/wiki/Software_portability

If we have a C++ app running on Windows using MFC, ATL and COM,
then considering that being portable to Linux because Linux has
C++ is absurd.

Arne

On 14-02-2011 08:22, Andreas Leitgeb wrote:
> Arved Sandstrom<asandstrom3minus1@eastlink.ca>  wrote:
>> In the case of the .NET CLR and the JVM and scripting language
>> interpreters, those _are_ the platforms.
>
> That's funny, because by that definition, Java apps (and .NET and scripts)
> would be entirely *unportable* - i.e., work only on that one "platform" ;)

Stroustrup once said that Java is not cross-platform but instead it
is a platform itself.

And that is a bit funny.

But the practical impact is not that big.

You can move your jar file to Windows, Linux, Solaris, MacOS X,
OpenVMS, z/OS and run it unchanged.

>> C, OTOH, has been very good wrt question (1) for a long time. But it
>> requires varying degrees of work wrt question (2), on a _case by case_
>> basis...
>
> I do have the impression of a violent agreement here.
> Lawrence perhaps sees the difference not all that large as many
> others do, though.

Maybe not, but it is pretty easy to look at some of that C/C++ code
and see the ifdefs.

>> I would not expect
>> to be writing C code that accomplishes the same things, and be able to
>> plunk it into gcc or VS on all those platforms, and watch it compile and
>> link without any mods.
>
> Depends on what libs you build upon in C (or C++).
> Those libs likely have lots of #ifdef'ery inside,

1) That is relative rarely the case
2) It does not make the app portable - it just make the app
    run on the platforms the lib is supporting

Arne

On 14-02-2011 05:44, Sulfide Eater wrote:
> On 13/02/2011 9:13 PM, Arne Vajh�j wrote:
>> On 12-02-2011 22:17, Sulfide Eater wrote:
>>> On 12/02/2011 9:18 PM, Arne Vajh�j wrote:
>>>> On 12-02-2011 21:08, Sulfide Eater wrote:
>>>>> I am asking who actually used it. Having 3 adopters all of which were
>>>>> large organizations is still having 3 adopters and a tiny sliver of
>>>>> market share.
>>>>
>>>> It is a lot more than 3.
>>>
>>> Wow, was it 6? Maybe even 10? Maybe even as many as 100? Out of what,
>>> millions? :)
>>
>> Most of the financial sector world wide.
>
> Get real. They were using COBOL on Vaxen. Half of them still are.
> Everybody knows this.

I doubt that everybody is so much wrong.

I guess you are more unique in that regards.

VAX'es were never that widely used client side.

And even though some did use COBOL on VAX'es, then
COBOL and PL/I on IBM mainframe was a lot more common.

Arne

On 13/02/2011 11:41 AM, Sulfide Eater wrote:
>> OS/2 was pretty widely used once.
>
> Where, in West Rectum, Rajikistan? I can't recall ever stumbling upon a
> single person using it as their desktop OS even during its so-called
> heyday.

The entire banking industry, for a start. But if this question is going 
to come down to your personal experience of desktop operating systems it 
retains zero interest.

"Gabriel Arthur Petrie (eyenot)" <eyenot@gmail.com> writes:

1> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,rec.games.roguelike.development

1> !()#%* off, and let's never meet in person!

What does your aversion to Murgatroid have to do with OS/2, eyenot?

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:

22> Newsgroups: comp.lang.java.programmer,comp.os.os2.advocacy

22> I doubt that everybody is so much wrong.

Sulfide Eater apparently thinks that Digital Equipment had the
entire finanical sector wrapped up.  Must not do much shopping
either, else an IBM point of sale terminal would have been
encountered sooner or later.

22> I guess you are more unique in that regards.

Sulfide Eater is unique in other ways as well, but
his online persona certainly is not.

22> VAX'es were never that widely used client side.

VAXes were popular in scientific circles.  Digital was one of
the leading suppliers of Fortran compiler technology.

22> And even though some did use COBOL on VAX'es, then
22> COBOL and PL/I on IBM mainframe was a lot more common.

Trolls like Sulfide Eater never let the facts get in the way
of a good rant, Arne.

On 14/02/2011 6:54 PM, tholen@antispam.ham wrote:
> Sulfide Eater<zaxx1108@example.com>  writes:
>
> 138>  Newsgroups:
> comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex
>
> 138>  I am not claiming to do so,
>
> Classic contradiction

What does your classic unsubstantiated and erroneous claim have to do 
with OS/2, tholenbot?

> 138>  merely making a statement of fact
> 138>  regarding a particular other fact being common knowledge,
> trollen.
>
> Classic erroneous presupposition.

What does your classic unsubstantiated and erroneous claim have to do 
with OS/2, trollen?

On 15/02/2011 10:06 PM, Arne Vajh�j wrote:
> On 14-02-2011 05:44, Sulfide Eater wrote:
>> Get real. They were using COBOL on Vaxen. Half of them still are.
>> Everybody knows this.
>
> I doubt that everybody is so much [insult deleted].

The only one here who seems to be [insult deleted] is you, Vajh�j.

> I guess you are more unique in that regards.

The only one here who seems to be [insult deleted] is you, Vajh�j.

> VAX'es were never that widely used client side.

We were discussing what large financial companies run their number 
crunching software on, Vajh�j. That is not "client side", Vajh�j.

On 16/02/2011 8:17 AM, tholen@antispam.ham wrote:
> =?ISO-8859-1?Q?Arne_Vajh=F8j?=<arne@vajhoej.dk>  writes:
> 22>  I doubt that everybody is so much wrong.

No, just Vajh�j.

> Sulfide Eater apparently thinks that Digital Equipment had the
> entire finanical sector wrapped up.

What does your classic erroneous presupposition have to do with OS/2, 
tholenbot?

> Must not do much shopping either

What does your classic erroneous presupposition have to do with OS/2, 
tholenator?

> else an IBM point of sale terminal would have been
> encountered sooner or later.

What do IBM point of sale terminals in stores have to do with the 
identity of the manufacturer of the mainframes at a large financial 
firm, thalidomide? As long as both ends support a common communications 
protocol, they do not need to be the same, tholian.

> 22>  I guess you are more unique in that regards.
>
> Sulfide Eater is unique in other ways as well, but
> his online persona certainly is not.

What does your agreement with Vajh�j's classic erroneous presupposition 
have to do with OS/2, tholoon?

> 22>  VAX'es were never that widely used client side.
>
> VAXes were popular in scientific circles.  Digital was one of
> the leading suppliers of Fortran compiler technology.

What does that have to do with the mainframes at large financial firms, 
thalien?

> Trolls like Sulfide Eater

What does your classic erroneous presupposition have to do with OS/2, 
trollenbot?

On 16/02/2011 2:34 AM, Esmond Pitt wrote:
> On 13/02/2011 11:41 AM, Sulfide Eater wrote:
>>> OS/2 was pretty widely used once.
>>
>> Where, in West Rectum, Rajikistan? I can't recall ever stumbling upon a
>> single person using it as their desktop OS even during its so-called
>> heyday.
>
> The entire banking industry, for a start.

What do VAX mainframes running COBOL software have to do with OS/2, Pitt?

> But if this question is going to come down to your personal experience
> of desktop operating systems it retains zero interest.

What does that have to do with OS/2, Pitt?

And a rather ironic statement, Pitt, considering that you evidently 
found it interesting enough to not only read it but post a followup.

On 16-02-2011 22:39, Sulfide Eater wrote:
> On 16/02/2011 2:34 AM, Esmond Pitt wrote:
>> On 13/02/2011 11:41 AM, Sulfide Eater wrote:
>>>> OS/2 was pretty widely used once.
>>>
>>> Where, in West Rectum, Rajikistan? I can't recall ever stumbling upon a
>>> single person using it as their desktop OS even during its so-called
>>> heyday.
>>
>> The entire banking industry, for a start.
>
> What do VAX mainframes running COBOL software have to do with OS/2, Pitt?

VAX is a minicomputer not a mainframe.

Arne