Re: Why we should (not?) have closures after all

On Oct 29, 8:18 am, Patrick May <p...@xxxxxxx> wrote:
Lew <l...@xxxxxxxxxxxxx> writes:
Patrick May wrote:
     Again, it's difficult to make a case (and you haven't) for lack
of capabilities being empowering.

That's because I don't make the claim that Java's supposed and
fictional "lack" of capabilities is what makes it empowering.

     You snipped what you did say, in just this sub-thread.  Here it is
again:

     A language should empower programmers to express their solutions
as elegantly and clearly as possible.  That requires supporting
techniques from multiple paradigms.

It doesn't "empower" programmers.  Elegant and clean are not the
design principles of Java; robust and stable are.

Empowering programmers does not *require* supporting "multiple
paradigms" [ . . . ]

You recognize that Java does not support multiple paradigms, so your
"supposed and fictional" comment is incorrect.

Not really.

The statement "Empowering programmers does not *require* supporting
"multiple paradigms"" does not state anything about whether any
particular language does or does not support multiple paradigms.

His "supposed and fictional" comment, furthermore, was a statement
that he wasn't making a claim that Java's lack of X made it
empowering. Even if he had said that Java did not support multiple
paradigms, that is still not a claim that its doing so makes it
empowering. At most, he implied that it doesn't make it DISempowering,
which isn't the same thing. He may in fact be claiming that Java's
lack of X neither makes it more nor less empowering.

Of course, only he can answer for sure, but these possibilities lie
open based on what we have read so far, which means that at this point
you cannot call his claim incorrect without risking committing the
same sin yourself by so doing.

(And since the thing you think was incorrect was "I don't make the
claim that X" in form, calling it incorrect is tantamount to calling
him a liar, which is pretty seriously rude especially if it proves to
be wrong!)

 You also explicitly state that empowering programmers does not require
supporting multiple paradigms, which is, in fact, arguing in favor of
lack of capabilities.

No. "X is not required" is a far cry from "~X is required". It may be
that neither is required. You might as well argue that someone saying
it's not necessary for a country to standardize on driving on the
right side of the road is arguing in favor of driving on the left,
instead of what he's actually doing, which is closer to arguing in
favor of countries having the freedom to choose either. He may
actually think left is better, but he may just think right isn't
worse. He needs to say more before you can infer a specific one of
those two.

[misquotes Lew]

Do not misquote Lew again. Your post contained supposed "quoted
material" that did not occur in the post that you followed up to nor
summarize material that did. That is incorrect. Stop being dishonest.

     By ignoring this point, your implicit argument is, indeed, that
lack of capabilities is empowering.

I don't think so. All we can conclude is that he's arguing that such a
lack is not necessarily DISempowering.

     You have quite a few unsupported assumptions in those few words
(showing that English is far more expressive than Java).  For example:

     - Java is robust.
     - Java's supposed robustness distinguishes it from other
       general purpose programming languages that do not
       share its other traits.
     - Strict typing is a net benefit.
     - Verbosity helps prevent errors.
     - A rich API is more empowering than alternatives.

I think the problem here may be a comparison of apples to oranges.

Dynamically typed languages are certainly unsuitable for writing
programs in the manner typical of languages with a distinct "write,
compile, test, debug" cycle, such as C, C++, and Java. Catching errors
at compile time in such languages is extremely cheap compared to
catching the same errors only at runtime, and since a large fraction
of all errors are type errors, static typing is a big win in such
languages.

On the other hand, languages like Smalltalk support a sort of "agile
development" that tends to blend writing, compiling, testing, and
debugging together. In particular one tends to write lots of short
methods and small classes and can easily write test cases and invoke
them in an immediate mode, without the baggage and typing and other
*work* involved in doing the same with, say, JUnit.

That makes run-time errors on a par with compile-time errors instead
of orders of magnitude more expensive. The big win from static typing
disappears, and a big loss appears in its place: the verbiage involved
in static typing slows down development, and, especially, makes it
less convenient to generate and run tests.

This means users primarily of "agile" languages see big costs and no
benefits to static typing, and users primarily of "write/compile/test/
debug" languages see big costs and no benefits to dynamic typing. And
end up talking past each other and arguing and getting into a "static
vs. dynamic typing rwar" like this thread is apparently becoming.

In practise, the two language types are suited to different uses:
static languages to building standalone, installable applications and
speed-critical ones, and dynamic languages for research, certain kinds
of mainly-local-hackers-use-it apps, and the like.

Dynamic languages aren't inherently useless for the former though. The
extant ones all seem to be; they all tend to suffer from at least two
of:
* Poor speed (usually due to no JIT compilation) (Smalltalk,
Python, Ruby, any Lisp or Scheme, with few exceptions --
JRuby may use JVM JIT)
* Poor API libraries, particularly regarding interfacing to
the host OS and filesystem (any Lisp or Scheme, most
Smalltalks)
* No GUI at all, or at least no easy and standardized way to
produce one (Lisps, Schemes, OCaml and pretty much every
other functional language -- but C and C++ too!)
* Poor or no concurrency support (most of the above, but also
C and C++)
* No easy way to deploy standalone applications (all of the
above)

The interesting thing is that the first and third are mainly
challenges of interpreted languages (to be precise, those not directly
compiled to native code) and once applied to Java as well. Hotspot,
executable JARs, and the widespread availability of a JVM on users'
machines have made Java apps no harder to deploy than e.g. Visual
Basic apps (which require a runtime DLL) or similarly, and several
have become quite popular, including Limewire (one of the top five
peer to peer apps), Azureus (another), Netbeans, and Eclipse.

The second is mainly an issue with languages developed more as
research or learning tools than as languages for writing actual real-
world computer software. These often end up with only a line-oriented
UI available (lots of the Lisp family and most functional languages)
at least without third-party stuff, and almost always have poor
interfacing to the host OS and filesystem, and to apps written in
other languages.

At this time, JRuby looks like the "agile" language implementation
that has come closest to overcoming all of those hurdles, followed by
Squeak. (Squeak has issues though. The GUI is not intuitive to deploy
-- it tends to come complete with the ability of the user to hack it
in ways that might destroy unsaved data, render the app unusable, and
the like -- and the concurrency and speed are abysmal. I mean, like,
cooperative multithreading is *soooo* 19-nevers! It's also not as easy
to hack as one would prefer. I tried to improve the hierarchy browser
once, and couldn't even *find* it, or parts of it. It was made so
abstract that finding the actual line of code responsible for behavior
X was nigh-impossible. For instance I got at the code for a menu
action that launched one and it referenced a class, but that class and
its superclasses had no apparent code in them to actually generate the
thing's layout and wire up the UI components with event listeners. The
menu code itself didn't seem to do it either. Some sort of dependency
injection may have been used, but I was damned if I could find where
it was coming from. It amounted to the extreme object-oriented end of
the spectrum of possible forms of spaghetti code.)

There are numerous existence proofs of high quality systems being built
with languages that do not suffer from Java's verbosity and other
limitations.

Name one common desktop application or other "it can be packaged up,
downloaded by users, and run" system of any serious size.

 There is no evidence that the benefits of strict typing
outweigh the costs.

See above. My suspicion is that strict typing exists in symbiosis with
one language use model and dynamic typing with another, and *neither*
is necessarily superior to the other, but *both* forms of typing
become bad when used with the wrong sort of language. (May be why
StrongTalk doesn't have much momentum.)

.