Why Java's math expression (power) is so inconvenient and error prone?

[Shawn]

Hi,

My program need a lot of calculation of power. In many programming
languages,

2**3 = 8; //or
2^3 = 8;

The syntax is clean and easy. But in Java,

Math.pow(2, 3) = 8; //It is so long, and complicated and error prone

Again, in many languages,

EXP(1) = 2.7 //e value

But in Java,

Math.pow(Math.E, 1) = 2.7 //You see, so complicated

Normally, in one calculation, 2**3 or EXP(3.5) is only part of
expression, like "a + b**3 + EXP(-a)". In Java, it will be very long and
error prone!

 

[Mark Thornton]

Hi,

My program need a lot of calculation of power. In many programming
languages,

2**3 = 8; //or
2^3 = 8;

That may be short but your example illustrates the problem: lack of a
universal standard symbol (in ascii). Of course 2^3 already means
something else in Java.

The syntax is clean and easy. But in Java,

Math.pow(2, 3) = 8; //It is so long, and complicated and error prone

It may be longer but not error prone. You can eliminate the repeated use
of Math with static import:

import static java.lang.Math.*

then

pow(2,3)

Again, in many languages,

EXP(1) = 2.7 //e value

But in Java,

Math.pow(Math.E, 1) = 2.7 //You see, so complicated

Math.exp(1)

or with a static import, just

exp(1)

Mark Thornton

 

[pkriens]

Shawn, you have no idea how right you are ... Unfortunately, there are
many domains where Java is very unsuitable, just think of how silly it
is that you need to do s1.equals(s2) instead of s1 = s2. Any idea how
much you need to compare strings in a business app? Or the fact that
you can not switch on a String or other object type for some mysterious
rationale?

Lets face it, Java is not a very elegant language. They had objects, so
everything had to become a class, well almost. For some weird
optimization reason we have /primitive types/ and they shout you right
in the face at the most inconventient times. Operator overloading was
killed (which would have allowed you to do 2^3) because it was abused
heavily in C++.

I think that part of the problem is that languages are designed by
language experts. Notice how their first goal usually is to become
self-hosting. Obviously constructions that are needed to write parsers
tend to overwhelm the minds of the language designers. SQL, XML,
business logic, engineering problems, mathematics, are not really in
the forefront of their minds I think.

Interestingly, a key figure in the Java Language Specification is
creating a new language (while working for Sun!) for exactly your
mentioned reason: the unreadability of Java for domain specific
languages, where math is their focus, they want to replace Fortran. Guy
Steele gave a very interesting talk about fortress on the OOPSLA 2006
last week in Portland (domain specific languages seem to becoming big
anyway).

http://research.sun.com/projects/plrg/

Interestingly, they have operator overloading. They argue (justly imho)
that operator overloading was a problem in C++ because there were so
few operators to choose from in ASCII. However, today we have Unicode
allowing us to use symbols with well defined meanings: ∞, ∨, ∧,
⊆,≡, √, etc. These symbols are a lot easier to read for domain
experts than "all we have is method calls". And if people want to abuse
it ... hey it is their life and job. Any decent programmer will use
overloading operators to stay within the intended meaning.

Though a language is syntactic sugar, it is imho important. The closer
the language is to the domain, the easier it is to understand what it
does in your domain. An extreme form of non-domain specific languages
is XML when used for humans. Reading an ant script or XSLT program is
horrendously hard because the expressions are so far removed from what
you are doing. Not only is this error prone, it is also harder to write
and read.

For example, just think of the sillyness that we have thousands if not
millions of programmers writing business applications that involve
transactions, data sources, databases, and many small data entities.
Java is very unsuitable for those applications because it does not
natively support any of those things, they must all be implemented as
classes. They all have to be encoded as method calls. This wastes many
man years everyday and uncounted cost due to increased errors and hard
to understand code. Did you ever try to discuss a domain problem with
your customer together with the Java code?

Also on the OOPSLA 2006 was a presentation of Intentions. They had as
example system that had 400 pages of requirements and domain knowledge
for a 20.000 page system. Why do we need to expand this 50x? Their
solution was to create a domain specific language that could reduce the
expansion to around 2000 pages.

Java missed a surprising number of important concepts, and the lanugage
designers have no excuse because most of the near fatal misses were
available in Smalltalk (functions and blocks as objects [closures],
operator overloading, abstracted primitive integers, well designed
collections, etc. It is interesting though to see how many Smalltalkers
nowaday are working in Java and JCP moving the language forward!).

However, the Java language was close to C++ and corrected some of the
glaring mistakes of C++, add a couple of hundred million advertising
campaign and you have an explanation why Java became popular.

Don't get me wrong, I make a living in Java code and it is definitely
less error prone than C++. It clearly was an improvement. I do not want
to leave Java because the amount of libraries is awesome, and some are
actually decent! However, I hope that the industry will support more
languages that are more domain oriented. It would be nice if these
languages could be build on the Java library and VM so we can use the
languages without a great cost during runtime. I definetely see a trend
here. My only fear is that computer science students have lost the
ability to write parsers because XML is so convenient for the
programmer and who cares about the customer ...

Kind regards,

Peter Kriens

 

[Mark Thornton]

Shawn, you have no idea how right you are ... Unfortunately, there are
many domains where Java is very unsuitable, just think of how silly it
is that you need to do s1.equals(s2) instead of s1 = s2. Any idea how
much you need to compare strings in a business app?

This might be a reasonable argument if only there weren't so many ways
to compare strings. The usual default comparison (selected by computer
scientists) is also frequently the wrong choice in business applications.

Lets face it, Java is not a very elegant language. They had objects, so
everything had to become a class, well almost. For some weird
optimization reason we have /primitive types/ and they shout you right
in the face at the most inconventient times. Operator overloading was
killed (which would have allowed you to do 2^3) because it was abused
heavily in C++.

Except that the C inheritance meant that the ^ operator was already in
use for numeric types and thus not available for exponentiation.

Interestingly, a key figure in the Java Language Specification is
creating a new language (while working for Sun!) for exactly your
mentioned reason: the unreadability of Java for domain specific
languages, where math is their focus, they want to replace Fortran.

I don't consider Fortran to be all that readable either; we are just
used to it.

Interestingly, they have operator overloading. They argue (justly imho)
that operator overloading was a problem in C++ because there were so
few operators to choose from in ASCII. However, today we have Unicode
allowing us to use symbols with well defined meanings: ∞, ∨, ∧,
⊆,≡, √, etc. These symbols are a lot easier to read for domain
experts than "all we have is method calls".

Those operators only have well defined meanings in mathematics. One of
the problems with overloading in C++ was its use for all sorts of non
mathematical purposes. This problem started right at the beginning with
the example set by overloading << for output. Unicode would have allowed
a more appropriate symbol, but it would still be a new coinage for that
symbol, not an existing well defined meaning.

it ... hey it is their life and job. Any decent programmer will use
overloading operators to stay within the intended meaning.

Essentially mathematics is the only domain where operators have a well
defined meaning of long standing (centuries). However very few languages
are written just for mathematicians. So it is all but inevitable that
any language which permits significant operator overloading will find it
being extensively used for purposes where the relationship of the
operator to action is not immediately obvious or "within the intended
meaning".

However, the Java language was close to C++ and corrected some of the
glaring mistakes of C++, add a couple of hundred million advertising
campaign and you have an explanation why Java became popular.

And that massive set of standard libraries.

Mark Thornton

 

[RedGrittyBrick]

However, today we have
Unicode allowing us to use symbols with well defined meanings: ∞, ∨,
∧, ⊆,≡, √, etc. These symbols are a lot easier to read for domain
experts than "all we have is method calls".

You're not reinventing this are you?
http://tinyurl.com/y59nkm
;-)

 

[Guest]

Shawn, you have no idea how right you are ... Unfortunately, there are
many domains where Java is very unsuitable, just think of how silly it
is that you need to do s1.equals(s2) instead of s1 = s2. Any idea how
much you need to compare strings in a business app?

And ?

..equals and == has different semantics in Java.

It is not that difficult to learn.

And when you are beyond beginner level, then the typing process
is insignificant in the development so number of keystrokes does not
matter.

Or the fact that
you can not switch on a String or other object type for some mysterious
rationale?

That is not something unique for Java. It is rather common in
languages.

I think that part of the problem is that languages are designed by
language experts. Notice how their first goal usually is to become
self-hosting. Obviously constructions that are needed to write parsers
tend to overwhelm the minds of the language designers. SQL, XML,
business logic, engineering problems, mathematics, are not really in
the forefront of their minds I think.

I think you are rigth on that one.

Languages are a backyard of computer science academia.

Though a language is syntactic sugar, it is imho important. The closer
the language is to the domain, the easier it is to understand what it
does in your domain. An extreme form of non-domain specific languages
is XML when used for humans. Reading an ant script or XSLT program is
horrendously hard because the expressions are so far removed from what
you are doing. Not only is this error prone, it is also harder to write
and read.

The strictness and easy validation of XML makes it very non error prone.

But it can be hard to read. Especially with a lot of namespace stuff.

For example, just think of the sillyness that we have thousands if not
millions of programmers writing business applications that involve
transactions, data sources, databases, and many small data entities.
Java is very unsuitable for those applications because it does not
natively support any of those things, they must all be implemented as
classes. They all have to be encoded as method calls. This wastes many
man years everyday and uncounted cost due to increased errors and hard
to understand code. Did you ever try to discuss a domain problem with
your customer together with the Java code?

I am not aware og any mainstream languages that has support for those.

Java missed a surprising number of important concepts, and the lanugage
designers have no excuse because most of the near fatal misses were
available in Smalltalk (functions and blocks as objects [closures],
operator overloading, abstracted primitive integers, well designed
collections, etc. It is interesting though to see how many Smalltalkers
nowaday are working in Java and JCP moving the language forward!).

Scary considering how well SmallTalk did commercially.

Arne

 

[Luc The Perverse]

I am not aware og any mainstream languages that has support for those.

Didn't Cobol?

 

[pkriens]

It is easy to get lost in details with these discussions and start
comparing language features. I am not promoting to go to Smalltalk. I
only want to make clear that Java is just not very expressive because
it has only a few crufty constructs making programs overly verbose (or
crufty as I call it). XML is the extreme form of this where you have to
wrestle through the cruft to see the relevant content, but Java is
often not much better.

Cruft makes programs hard to read and understand and that is bad imho.

It is easy to stab at the lack of adoption for Smalltalk. Theirs is a
sad story of too early, lack of focus, and too much out of mainstream.
However, I do not think anybody that has looked at the language can
look at Java with dry eyes.

.equals and == has different semantics in Java.

I therefore used '=' in the post because in the mathematical sense it
is equality and not assignment. (Smalltalk used the arrow for
assignment).

And when you are beyond beginner level, then the typing process
is insignificant in the development so number of keystrokes does not
matter.

No the typing is not that much of an issue, it is the READING that is
important! Having to hold 5 pages into mind or 1 makes a difference.

[Switching on strings ] That is not something unique for Java. It is rather common in
languages.

Yes, stupidity is widespread. But what is the rationale? The result is
that people start using if () then else if() then else ... ad nausuem
which is easy to get wrong and hard to read and probably less eficient
than the compiler could have done it. Or better with the right language
that has blocks/closures, a method could be made that performs the
switch.

Kind regards,

Peter Kriens

Shawn, you have no idea how right you are ... Unfortunately, there are
many domains where Java is very unsuitable, just think of how silly it
is that you need to do s1.equals(s2) instead of s1 = s2. Any idea how
much you need to compare strings in a business app?

And ?

.equals and == has different semantics in Java.

It is not that difficult to learn.

And when you are beyond beginner level, then the typing process
is insignificant in the development so number of keystrokes does not
matter.

Or the fact that
you can not switch on a String or other object type for some mysterious
rationale?

That is not something unique for Java. It is rather common in
languages.

I think that part of the problem is that languages are designed by
language experts. Notice how their first goal usually is to become
self-hosting. Obviously constructions that are needed to write parsers
tend to overwhelm the minds of the language designers. SQL, XML,
business logic, engineering problems, mathematics, are not really in
the forefront of their minds I think.

I think you are rigth on that one.

Languages are a backyard of computer science academia.

Though a language is syntactic sugar, it is imho important. The closer
the language is to the domain, the easier it is to understand what it
does in your domain. An extreme form of non-domain specific languages
is XML when used for humans. Reading an ant script or XSLT program is
horrendously hard because the expressions are so far removed from what
you are doing. Not only is this error prone, it is also harder to write
and read.

The strictness and easy validation of XML makes it very non error prone.

But it can be hard to read. Especially with a lot of namespace stuff.

For example, just think of the sillyness that we have thousands if not
millions of programmers writing business applications that involve
transactions, data sources, databases, and many small data entities.
Java is very unsuitable for those applications because it does not
natively support any of those things, they must all be implemented as
classes. They all have to be encoded as method calls. This wastes many
man years everyday and uncounted cost due to increased errors and hard
to understand code. Did you ever try to discuss a domain problem with
your customer together with the Java code?

I am not aware og any mainstream languages that has support for those.

Java missed a surprising number of important concepts, and the lanugage
designers have no excuse because most of the near fatal misses were
available in Smalltalk (functions and blocks as objects [closures],
operator overloading, abstracted primitive integers, well designed
collections, etc. It is interesting though to see how many Smalltalkers
nowaday are working in Java and JCP moving the language forward!).

Scary considering how well SmallTalk did commercially.

Arne

 

[Martin Gregorie]

Didn't Cobol?

Only for CODASYL databases (i.e. IDMS) and via a preprocessor which made
these statements look like standard COBOL.

COBOL 85 didn't have native support for any of these things or a
preprocessor. The nearest it came was the COPY statement, which is just
"include" with some limited name substitution.

The current language specification doesn't extend the language beyond
COBOL 85 in any of these areas.