On 19.04.2024 01:50, Andrew Rowley wrote:
On 18/04/2024 8:29 pm, Rony G. Flatscher wrote:
The mileage of people here vary including the Java people themselves who have started to reduce
the need of explicit declarations like the new "var" (imitating JavaScript) instead of strict
types or foregoing the static main method such that one can at least code the main method without
the explicit declarations. The motivation about these changes is to make Java easier, reduce
typing needs and the like.
The Java var keyword is more like C# than Javascript. The variable still has a strict type - you
can only use var if the compiler can figure out the type from other information e.g.
var start = ZonedDateTime.now();
start is a ZonedDateTime. You can't use it before it is defined, you can't assign anything other
than a ZoneDateTime to it, you can't create a new variable called start in the same scope, whether
or not it is a ZoneDateTime. You can't e.g compare it to a LocalDateTime without specifying a
timezone for the LocalDateTime - that is one of those things that helps avoid errors.
var just reduces redundant code, e.g. specifying the type twice in the same
statement.
It is an attempt to apply dynamic typing to reduce the need to write the explicit type. This service
gets carried out by the compiler. In true dynamically typed languages you can reuse variables like
"start" or "tmp" to refer to values of different types. The context of interacting with them will
determine whether the interaction is correct or not, maybe an example:
a=123 -- a number
b="456" -- a number
say a+b -- yields: 579
b='xyz' -- a string
say a+b -- yields: Bad arithmetic conversion. Nonnumeric value
("xyz") used in arithmetic operation.
b=.dateTime~new -- current date and time
say b -- will display the current date and time, e.g:
2024-04-19T15:51:51.249000
say b~addWeeks(17) -- yields: 2024-08-16T15:51:51.249000
say a+b -- yields: Bad arithmetic conversion. Nonnumeric value ("a
DateTime") used in arithmetic operation.
A dynamic language when executing code needs nevertheless to check whether interaction with the
dynamically typed values is correct or not.
Of course a static and statically typed languages with a compiler must define as much rules as
possible, such that the compiler can check for them all. The more rules the more time consuming
and the more difficult to learn a language.
I think the syntax rules for Rexx are actually more complex than Java, because it is less likely
to flag an error if you do something that's not actually what you want.
No the Java syntax is all in all much more complex. You note that when teaching novices Java and
compare that to teaching novices Rexx or ooRexx (I have experiences in both).
E.g. string concatenation where variables are expected to be strings but maybe not, might not be
initialized, sometimes you need vertical bars but not always etc.
Well in Rexx concatenation rules are quite intuitive, surprisingly there is a blank concatenation
operator (a blank between concatenated strings), an abuttal concatenation operator (no blank between
concatenated strings) and using the explicit concatenation operator || (no blank between
concatenated strings). Novices have no problems to understand:
a=1
say a "- hello!" -- concatenation with a blank ...........: 1 - hello!
say a"- hello!" -- abuttal, concatenation without a blank: 1-
hello!
say a || "- hello!" -- concatenation with || operator .......: 1-
hello!
In Java (and many other programming languages) there is only the + concatenation operator available
(equivalent to Rexx' || operator), therefore one has always to use the + operator and has to write
something like:
int a=1;
System.out.println(a+" - hello!"); // blank between both
System.out.println(a+"- hello!"); // no blank between both
Of course this works, but it forces you to always use the + operator, whereas in the Rexx example it
does not, yet the Rexx statements are intuitively understood by novices. So this does not add
complexity per se.
Ad uninitialized variables: this is usually a no go in statically typed programming languages, the
Java compiler therefore warns about it and uses default values wherever possible which is fine.
Rexx defines the value of variables that have no explicit value assigned to them to be the name of
the variable in uppercase, so it does not cause a problem. (It does cause problems for programmers
who got trained to always make sure that a value is assigned to variables. This is the reason why
ooRexx has an option to activate checking for the use of uninitialized variables in Rexx programs to
appease those who are not accustomed to it or feel that it should not be allowed. ;) )
If you're used to the language you write it without thinking and avoid the traps, but the rules
are there nonetheless.
Java is relatively straightforward, and shares many rules with other languages - C++, C# etc. I'm
not saying Java is perfect - it has its own traps (int vs Integer etc) but I find it a much easier
language to work with.
Well Java was created as a safer language than C++ and in order to allow C++ programmers to quickly
switch to Java, the Java syntax adheres to C/C++ wherever it makes sense. Hence curly brackets for
blocks, the for loop, arrays which index starts at 0 and not at 1, and the like. Again, this is all
fine.
The point I have tried to make without explicitly expressing it is the following: IMHO a software
engineer should be able to command different type of programming languages, hence having a toolbox
of programming languages to become able to pick the language that best allows to solve a given
problem. Sometimes it even makes sense to mix and match different programming languages to solve a
problem, rather than following the hammer philosophy and force the use of a single programming language.
The litmus test is in complex application systems where macro and scripting abilities should be made
available to the (end) users, such that they become able to interact, to instrumentate or to extend
the functionality of such application systems the way they need it. Usually it is a no-brainer that
e.g. MS Office supplies that ability for its components Word, Excel, and the like by allowing
interaction with the documents using OLE, making it possible to use VBA. (ooRexx for Windows has the
ability on board to interact with any Windows OLE program including MS Office and its components,
like VBA.)
It is interesting that mayn authors of complex Java applications do not take into account the
necessity of supplying macro/scripting interfaces to their applications. To do so is quite easy in
Java (cf. javax.script package, the Java scripting framework that got devised by the expert group
JSR223, where I served as one of the scripting experts to devise it), yet, Java programmers often
see no need for supporting the Java scripting framework as they (wrongly) assume that everyone would
use Java anyway.
To conclude: like you I see the (strategic) importance of Java and its many benefits (portable and
powerful Java runtime environment, portable and powerful Java class libraries, security, maintenance
cycles, a lot of powerful open-source, etc.), especially for companies which can successfully avoid
lock-ins with such a move.
In addition, I see always a need for software engineers to command and support different kind of
programming languages to become able to use appropriate programming languages from their toolbox to
create efficient solutions for any kind of problems at hand. (E.g. one very important deployment
area has been for decades to empower end-users to become able to interact with complex software
systems on their own which became possible decades ago when VBA was invented and deployed for MS
Office a huge benefit of that package to this date. Such an important support is usually not offered
by complex Java applications.)
---rony
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
