«

Jim Cochrane wrote:
> In article <laOtc.4545$>, Harri Pesonen wrote:
>
>>C# is technically better than Java, because
>
> When I read this I thought: "Oh, good - I don't know much about C#, maybe
> I'll learn something about why it may be better than Java." But then I
> read this: "it is a next generation product." and thought: "How
> disappointing - He does not really give a reason, but just uses an
> essentially meaningless phrase. He doesn't even give any kind of
> definition for 'next generation product', which might have at least given
> some sense of why C# is technically better than Java."

Simple. Just like Java builds on C++ and Visual Basic, C# and VB.NET
build on Java. Java took the best features from C++ and Visual Basic:

* C++: classes and general syntax
* VB: ease of development, virtual machine, no freeing of objects, COM,
UI components

Java added garbage collection, JIT compiling and a reasonably good
library (Java Platform API). Since then many of the original library
features have been deprecated and replaced with new versions, and whole
new APIs have been added to fix the problems in the original ones:

AWT => Swing
IO => NIO
Date => Calendar

C# and .NET platform have been designed to have the best features from
Java, without the burden of deprecated API or language features. Java
1.5 proves that C# is/was ahead of Java in many ways. .NET platform
performs better than Java in Windows, because it uses native Win32 UI
features, while Swing suffers from bugs and incompabilities and is slower.

C# has "using" statement that makes sure that the resource is freed
(disposed) correctly.

In C# "switch" statement works with strings.

C# has structs for creating new primitive types.

Did I mention that C# has verbatim strings, which are good for regular
expressions and multi-line SQL statements...

I could go on, but C# is simply superior to Java (in Win32). I hope that
Java gets better, Java 1.5 sounds very promising.

Harri

On Fri, 28 May 2004 23:40:48 +0300, Harri Pesonen <>
wrote or quoted :

>Why would anyone want that Java is not improved?

It is not a matter of whether people want it improved, it is a matter
of whether they consider you proposal an improvement, or worth the
hassle of learning yet another syntax wrinkle. There is value to
simplicity. Most of my ideas for improvements are documented in
http://mindprod.com/jgloss/bali.html

So far the only ones Sun have implemented are enum and extended for
over collections (using somewhat different syntax that I suggested.)

C# however, has implemented a number of them.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

On Sat, 29 May 2004 00:28:55 +0300, Harri Pesonen <>
wrote or quoted :

>Ask anybody that does SQL development. Also adding verbatim string to
>java compiler would be trivial.

These should perhaps be added to IDEs and SCIDs and leave the base
language alone.


see http://mindprod.com/projects/scid.html

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Harri Pesonen wrote:
> C# and .NET platform have been designed to have the best features from
> Java, without the burden of deprecated API or language features. Java
> 1.5 proves that C# is/was ahead of Java in many ways.

Yes, you're right that C# is/was ahead of Java in many ways. It was
just the ludicrous extension of that as a way to prove that *everything*
in C# is better than Java that was ridiculous. We all understand by now
that you like these "literal" strings from C#. (At least, those of us
who aren't completely oblivious do...). I, on the other hand, consider
them an incomplete attempt to complicate the language so as to avoid a
relatively painless problem. And yes, I do JDBC programming with SQL
strings all the time.

> I could go on, but C# is simply superior to Java (in Win32). I hope that
> Java gets better, Java 1.5 sounds very promising.

It's really not that simple. Specifically, C# suffers from the
disadvantage that it's really a rather complex language with a lot more
gotchas to look out for than Java; a lot more situations where it's
rather non-obvious what's going on. It represents a language that's a
lot heavier on the syntactic sugar than Java is. Essentially, it comes
from a considerably different language design philosophy.

Hopefully, Java 1.5 takes those genuinely good ideas from C# that are
really compatible with its language design, but still remains its own
language with its own advantages. It looks like that balance is largely
happening (although I'd be pushing for leaving out a few more things
like the new for loop syntax and static imports). Obviously, some
people in charge have more of a vision for what Java should be than
simply trying to make it as much like C# as possible.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

> Java is harder than Python in many ways. On the other hand, Java has
> code completion and compile time type checking.

Umm ... what ? Java does not have "code completion".
A very strange statement to make, I might add.

> string "replace" function that works as expected.

It has done since 1.2.

Stick to Python

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

Tony Morris wrote:
> > string "replace" function that works as expected.
>
> It has done since 1.2.

Mmm? As far as I can tell, this is not wrong. Java has had
String.replace(char, char) since the beginning (well before 1.2), but
String.replace(String, String) is new in 1.5.

1.4 added replaceAll(String, String) and replaceFirst(String, String),
but they indeed don't work as expected given the use of regular
expressions... and that makes them suitable for only a small subset of
the cases where 1.5's replace(String, String) is useful [namely, where
the pattern and replacement text are both known at compile time].

I'm interested where you got 1.2 from.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Harri Pesonen wrote:

> > > http://bugs.sun.com/bugdatabase/view...bug_id=4472509
> >
> > The problem with Sun's RFE system is that there doesn't seem to be a
> > way to vote /against/ things.
>
> Why would anyone want that Java is not improved?

I /certainly/ want Java to be improved. But this proposal isn't an improvement
in my book.


> Java 1.5 focuses on
> "Ease of Development". It does it by taking many things from C#:

A poor place to look, in my not particularly knowledgeably opinion.

There are lots of things that I'd like to see changed; messing around with
syntax to make an easy tasks imperceptibly easier is not on the list.


Just to put my money where my mouth is (iyswim), here are a few of the things
/I'd/ like to see (but don't expect that I ever shall).

* Rules for interfaces relaxed so that a method can satisfy an interface if it
is at least as visible as the interface rather than being required to be
public.

* The built-in type char expanded to 32 bits (not quite as radical a change as
it sounds, since chars are mostly handled internally as 32-bit anyway).

* String refactored to allow physical storage of character-sequence data in
UTF-8, UCS-2, UTF-16, or UTF-32 (and, perhaps, other formats too).

* NoSuchMethodException to be specified to record the values of the parameters
to the method call. (And similarly for assigns to non-existent fields.)

* Find some way of removing the clutter of from mis-designed API left over from
Java's early days.

* Deprecate wait(), and notify[All]() (and, perhaps, even "synchronized") and
replace them with something that doesn't require the brains of a Turing or a
Von Newman to get right. The new APIs in 1.5 are a step in the right
direction here.

* Retrofit arrays with a common superclass(es) other than Object, and make them
act as proper Collections. Allowing array syntax for "real" Collections is
probably a worthwhile bit of sugar.

* Deprecate /anonymous/ inner classes, which I think experience has shown to be
badly obfuscating.

* ...but add proper closures.

* Since they've insisted on cluttering-up the language with so many frivolous
constructs that it's not reasonable to expect ordinary skilled programmers to
be able to do any real meta-programming, there should be support for it at the
language definition level.

* Using fixed-width arithmetic with silent wrap-around /by default/ is an
engineering disaster. Such low-level arithmetic should be /available/ as an
optimisation to advanced programmers who can deal with the implications, but
there's no way it should ever have been the default.

* I'd like to remove generics before they even appear, and instead focus on
trying to /reduce/ the amount of early, static, analysis that the Java compiler
imposes on the JVM semantics.

* I'd /really/ like to get rid of the non-OO mess we currently have with
"constructors" and "static methods", but that's too much even to dream of, I
suppose... If we can't have that then at least allow constructors to inherit.

*** stuff for the JVM rather than Java-the-language ***

* The JVM developers to stop thinking of modifying a class definitions as a
mere
debugging aid, and make it work properly, at full speed, and be non-optional.

* The JVM developers to implement their /own/ spec for re-starting JVM
instances within one process (and ideally allow more than one).

* Add a way to discover all instances of a class at runtime. Should be
reasonably fast too. (NB: /not/ a debugging feature)

* Similarly, add a way to discover all effervescences to an object at runtime.

In short: concentrate on making stuff /simpler/ and more /general/, not on
trying to out-Perl Perl.

-- chris

Tony Morris wrote:

>>Java is harder than Python in many ways. On the other hand, Java has
>>code completion and compile time type checking.
>
> Umm ... what ? Java does not have "code completion".
> A very strange statement to make, I might add.

It is impossible to have a decent code completion in Python, because the
language is so dynamic. Java is so strictly type defined that code
completion is always possible.

Harri

Chris Uppal wrote:

> There are lots of things that I'd like to see changed; messing around with
> syntax to make an easy tasks imperceptibly easier is not on the list.
>
>
> Just to put my money where my mouth is (iyswim), here are a few of the things
> /I'd/ like to see (but don't expect that I ever shall).
>
> * Rules for interfaces relaxed so that a method can satisfy an interface if it
> is at least as visible as the interface rather than being required to be
> public.
>
> * The built-in type char expanded to 32 bits (not quite as radical a change as
> it sounds, since chars are mostly handled internally as 32-bit anyway).
>
> * String refactored to allow physical storage of character-sequence data in
> UTF-8, UCS-2, UTF-16, or UTF-32 (and, perhaps, other formats too).
>
> * NoSuchMethodException to be specified to record the values of the parameters
> to the method call. (And similarly for assigns to non-existent fields.)
>
> * Find some way of removing the clutter of from mis-designed API left over from
> Java's early days.

This would be good for beginner Java programmers like me. NetBeans tells
that the method is deprecated in code completion if I recall correctly.

> * Deprecate wait(), and notify[All]() (and, perhaps, even "synchronized") and
> replace them with something that doesn't require the brains of a Turing or a
> Von Newman to get right. The new APIs in 1.5 are a step in the right
> direction here.
>
> * Retrofit arrays with a common superclass(es) other than Object, and make them
> act as proper Collections. Allowing array syntax for "real" Collections is
> probably a worthwhile bit of sugar.
>
> * Deprecate /anonymous/ inner classes, which I think experience has shown to be
> badly obfuscating.
>
> * ...but add proper closures.
>
> * Since they've insisted on cluttering-up the language with so many frivolous
> constructs that it's not reasonable to expect ordinary skilled programmers to
> be able to do any real meta-programming, there should be support for it at the
> language definition level.
>
> * Using fixed-width arithmetic with silent wrap-around /by default/ is an
> engineering disaster. Such low-level arithmetic should be /available/ as an
> optimisation to advanced programmers who can deal with the implications, but
> there's no way it should ever have been the default.
>
> * I'd like to remove generics before they even appear, and instead focus on
> trying to /reduce/ the amount of early, static, analysis that the Java compiler
> imposes on the JVM semantics.
>
> * I'd /really/ like to get rid of the non-OO mess we currently have with
> "constructors" and "static methods", but that's too much even to dream of, I
> suppose... If we can't have that then at least allow constructors to inherit.
>
> *** stuff for the JVM rather than Java-the-language ***
>
> * The JVM developers to stop thinking of modifying a class definitions as a
> mere
> debugging aid, and make it work properly, at full speed, and be non-optional.
>
> * The JVM developers to implement their /own/ spec for re-starting JVM
> instances within one process (and ideally allow more than one).
>
> * Add a way to discover all instances of a class at runtime. Should be
> reasonably fast too. (NB: /not/ a debugging feature)
>
> * Similarly, add a way to discover all effervescences to an object at runtime.
>
> In short: concentrate on making stuff /simpler/ and more /general/, not on
> trying to out-Perl Perl.

Hehe, I have such a simple wish compared to yours... and as I said, I am
pretty happy with the improvements in Java 1.5.

Harri

Roedy Green <look-> writes:

> On Fri, 28 May 2004 19:01:07 +0300, Harri Pesonen <>
> wrote or quoted :
>
> >
> >Perhaps there could be better terminators, like {"How about this then?"}
> >or <"And this?">. There are also a couple of characters that are not
> >normally used: ´Would this be cool?´ `Probably not.`
>
> The generic solution would be to allow you to choose the terminator:
> e.g.
> @$abc$

Yes, for example, in the Curl language, simple verbatime strings look like
|"abc"|, but you can add an arbitrary tag as well: |foo"abc"foo|, or you can
specify the number of characters in the string, as in |3"abc"3|. The latter
form is useful for machine generated code.