I like the ability, but not the necessity, of being able to use
static typing. Here is why:
1. Roger claims that it "only catches easy problems",
but just because they are "easy" does not mean that they are
trivial. Consider these rather expensive, and potentially deadly errors:
http://mentalfloss.com/article/25845/quick-6-six-unit-conversion-disasters
Any sort of strong typing here would have caught, and prevented these
errors, some of which were human and some computer-related.
2. My first experience with a strongly typed language was writing the
SISAL back end for the APEX APL compiler. It was very frustrating,
as the SISAL compiler kept complaining about things that I "knew"
were correct (but were not, of course...).
When I finally got the generated code to compile under SISAL, I was
gobsmacked to see that the generated code operated correctly, the
first time. This was an eye-opener. Or a gobsmacker, depending on
your point of view.
3. A major benefit of being able to exploit strong typing is that
communication errors can be prevented, or at least reduced, as we saw
in (1), particularly when more than one person is involved.
My metaphor to support strong typing is this:
You are standing behind a large instrument rack in a server room,
and are hooking up New Things. In a strongly typed system, the
plugs and sockets are such that you can not, physically, plug the
wrong plug into a seriously wrong socket -- LAN cables are one type,
video cables are another, power cables are a third type. This strong
typing does not, of course, prevent you from plugging a LAN cable
into the wrong server.
However, now let's look at the untyped server room: Visually, all
the plugs
are power plugs, and all the sockets are power sockets. Errors here
are usually very unpleasant and, at best, seriously confusing.
4. One key to the benefits of strong typing appears when you are able to
define your own data types, as is common in almost any good functional
array language. Here, you can define, for example, "propellant flow
rate"
in an engine, as "kg/sec", rather than as "double"
(double-precision float).
This definition prevents you from "plugging" the propellant flow
rate into,
e.g., the "propellant volume" (telling how much propellant is in
the tank).
A dynamically typed language affords you no assistance here whatsoever,
and it will be a mystery to someone following you (which may be you, six
months down the line) as to why you did it. That's assuming things
have not,
err, crashed in the interim.
Any language, strongly typed or not, that does not support
user-defined data
types, is a recipe for disaster, as well as not facilitating
communication of
algorithms. Hence, not a good tool of thought.
5. Another benefit of strong typing is that a good compiler (or interpreter)
can perform dimensional analysis on the types, thereby catching
potential problems statically, and also reducing the amount of work
you have
to do as a programmer.
For example, if I want to know how much propellant has been consumed,
I can do that as:
PropellantMass := PropellantFlowRate times BurnTime.
The former is defined as "kg/sec", and the latter as "sec", so
dimensional analysis gives
us the propellant mass that has been consumer, in "kg". If
PropellantMass
was defined as anything but "kg", something is wrong, and the type
checker
will detect this.
6. Modern functional array languages, such as SAC, are strongly typed,
but do not require the programmer to declare all variables. Like APL or
J, they infer data types by data flow analysis(DFA). In APEX, for
example,
most simple codes require typing only of the input argument types;
everything
else is determined by DFA.
Hence, strongly typed languages, done properly, provide significant
benefits to
the application writer, while not shackling the writer with the chains
of tedious
typing (Sorry!) of type declarations.
As for Roger's use of "super dynamic type", strongly typed languages
are in even better shape here, because the dispatch of a fast Boolean
reduction algorithm can be done statically.
Furthermore, in my own experience of implementing compilers
and interpreters for functional
arrays languages for nearly 50 years, the number of times in which
a non-Boolean array (e.g., X-Y) is Boolean-valued by coincidence,
rather than by
intent, is small, and the work required to analyze the array in order to
determine that fact, is rarely worth it, the non-Boolean cases having to
pay for the analysis time of the Boolean ones. There may be exceptions to
this, but, like in the CISC vs. RISC discussions, simpler usually wins out.
Bob
On 2016-12-29 10:30 AM, Roger Hui wrote:
For those who've used static typed languages, have you ever programmed in
a
dynamic typed language said to yourself, "static types would have
prevented
that problem"? Just curious.
I have programmed in C for over 25 years and APL for over 40 years. There
may have been a few occasions where I might have thought that, that static
types would have prevented some problem or other. These are far
outnumbered by the number of times where I used (and am using) "super
dynamic type" techniques. For example, to do +/b where b is a bit vector,
I don't do it a bit at a time. See
http://code.jsoftware.com/wiki/Essays/Sum_of_a_Bit_Array .
I suppose when I am programming in C the static typing does catch some
errors at compile time. It's hard to tell because I have long adjusted to
the static typing. But I have no doubt that static typing only catches
easy problems.
On Thu, Dec 29, 2016 at 3:39 AM, Jack Andrews <[email protected]> wrote:
"For those who are unfamiliar, TypeScript is a language that brings you all
the new features of JavaScript, along with optional static types. This
gives you an editing experience that can’t be beat, along with stronger
checks against typos and bugs in your code."
For those who've used static typed languages, have you ever programmed in a
dynamic typed language said to yourself, "static types would have prevented
that problem"? Just curious.
On 29 December 2016 at 02:23, Björn Helgason <[email protected]> wrote:
https://blogs.msdn.microsoft.com/typescript/2016/12/07/
announcing-typescript-2-1/
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
Robert Bernecky
Snake Island Research Inc
18 Fifth Street
Ward's Island
Toronto, Ontario M5J 2B9
[email protected]
tel: +1 416 203 0854
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
