Re: Java is slow!

"Roedy Green" <my_email_is_posted_on_my_website@xxxxxxxxxxxxxx> wrote in
message news:atld22djdqktec32mnpi26q5685kruoqlv@xxxxxxxxxx
So the trend will be toward languages that let you get the program
correct quickly and one that can be tested without a lot of quirky
internal interactions.

That has been the trend for a very long time now.

Not really. The evolution has been painfully slow. Look at Algol.
Java is not all that different.

Java is quite different, in that it is Object-Oriented.

But there is a much bigger difference: Java is a *success*.

Computers of the time could not run Algol acceptably,
and it was not widely used. Java is doing far better.

For decades I have been calling for languages with features such as
the following, which I implemented to some extent in my own language,
Abundance.

1. uniform naming. To the programmer, the database, computational
and display variables should be logically the same thing.

What is a "display variable"?

I do agree that the database/application dichotomy is harmful, though,
and annoyingly persistant.

2. declarational programming. You put as much information as possible
at the spot a variable is declared, bounds, prompts, validation, type,
mandatory input, field labels.

Clearly much has already been done here!

Type systems are much more sophisticated now, obviously.

The new Attributes/Annotations means you have have things
like field labels attached. And its extensible!

Properties can do validation (in their setters). But this is done
imperatively, and perhaps you want to do it declaratively.

3. Associated temporaries. Temporary variables associated with
"serious" variables that automatically have the same type. You should
be able to change the type of serious variable and the code should
continue to work.

This sounds like type inference. Like so:

var a=b+c;

And 'a' is declared so that its static type is that of the expression
'b+c'; if 'b' or 'c' is changed to a different type, 'a' changes too.

This is coming in C# 3.0, but I do hope they change that 'var'
keyword. Everyone who sees it thinks it means "variant"! :(

4. Style *** layouts. You should not be specifying specific layout
details in your code any more than you should in HTML. You should be
declaring something akin to a CSS style *** that does the precise
layout based on CSS-like tags on the variables.

I'm not sure I understand this. Are you asking for some kind of
improved pretty-printer for your source?

5. Business classes. Finally we have a Calendar class, but the fool
thing still can't handle a pure date to save its life. But we need
other business objects, e.g. international addresses, phone numbers,
zips, email addresses, websites, names (to deal with sorting names Mc
Mac St.), credit cards, ISBN numbers, postal codes, SIN numbers,
states, provinces, currency (including prices in some base currency or
currency basket converted as needed to local currency). The validation
rules need to come from auto-updating plug-in code NOT the
programmer's problem! This stuff is invented from scratch over and
over and over.

I think you are quite right here; there's considerable scope for reusable
code in the things you name. Today, you have to handwrite this
stuff. I can understand not bothering to offer a stock ISBN number
class, but not having "Date" is mystifying.



.