Lambda the Ultimate

(An error left from earlier unfinished update fixed..)

The rescue is coming - everyday we hear of more and more statically typed "schemes" :-)

Personally I believe that very soon some offspring of Scheme with static (inferred) types and tamed call/cc (cupto?) will be the next language of choice for the next hackers :-)

I have mixed feelings about tools like IDEA. On the one hand, I see that IDEA does nice things and I can believe it's better for Java programming than Emacs. On the other hand, some aspects feel like a "high-tech solution to the wrong problem."

In particular, it seems like one of the biggest problems for people writing and refactoring Java is typing all the type declarations. IDEA seems to tackle this by writing a full type-inferencer within the editor, so that it can figure this out for you. That's clever and fancy, but doesn't it seem more appropriate to do this in the language/compiler than in the editor? This would seem to make refactoring Java considerably harder than (say) ML or Erlang as I far as I can see.

P.S., my favourite all-round development environment is Emacs Lisp in Emacs - really outstanding I reckon!

ANNOUNCE: Smalltalk Refactoring Tool 1994-05-11

The paragraphs on Rename Method (Dynamic Refactoring) are to the point.

The current Refactoring Browser standard in VW includes these:

Class-oriented Refactorings
• Create a Subclass
• Rename a Class and its References
• Safely Remove a Class
• Change a Class to a Sibling
• Add a Variable
• Rename a Variable and its References
• Remove a Variable
• Move a Variable to/from a Subclass
• Create Variable Accessors
• Make a Variable Abstract/Concrete

Mea culpa, I should have said that knowing static type info enables more refactoring types :-)

But seriously, refactoring by definition must preserve functionality. This means preserving various invariants. And what is type info if not (incomplete) specification of invariants?

I do not say you absolutely need this type info in the language, it just helps. Otherwise your refactoring tool tries to come up with invariants all by itself.

Autocompletion is less influenced by presence of types, if you mean just selecting from a list of all tokens of an appropriate metatype visible in the workspace.

My working knowledge is limited to Java, lately developing on Eclipse for Eclipse. There are many places where the list of tokens is dramatically reduced giving greater usability. E.g., after a dot you see just names of members, in the scope of a class you see just members and classes, etc.

If your autocompletion tool filters names like this, it already infers static type info, doesn't it?

Waiting for a counter-blow ;-)

static type info enables more refactoring types
What additional refactoring types? Would they make sense in an untyped language?

refactoring by definition must preserve functionality
OTOH if we can define new rewrite rules for the refactoring tool then we can change functionality in powerful ways: Transformation of an Application Data Layer.

Knowing more than AST of code (e.g., pre- and postconditions, variants/invariants, type info, etc.) makes code transformation tool more user-friendly (e.g., less error-prone, easier to use, more automated).

OTOH: Ignoring this knowledge by the tool effectively forces the user of the tool to manage this knowledge by her/himself (themselves for pairs).

Humility isn't required, but it helps ;-)

I could state stronger version, with "plain text" instead of "AST", but I am trying to be humble ;-)

I agree that writing elisp in emacs is good, but not as nice as Java in IDEA. I'd really like to know what type of thing each variable is meant to hold (of course this requires more types in elisp but ...)

I thought the Smalltalk RB did do some amount of type inference. Of course, it could do type inference, and given a "whole world" assumption that inference could be extensive as with the Stalin compiler for Scheme.

I am recalling a lot from several years ago based on an earlier implementation. As it is, I believe there are some changes that are performed by instrumenting code, catching them at run time, and handling them in some way. Maybe it does some patching at runtime, I am getting out on a limb here.

Neither does the Smalltalk RB force the programmer to keep more in her head. So I do not buy this argument: Ignoring this knowledge by the tool effectively forces the user of the tool to manage this knowledge.

That seems like speculation and does not match with my experience. Maybe I am unaware of what I am keeping in my head when using Smalltalk, but I can say at a minimum it is not a burden that makes me less productive so far, relative to any statically checked language.

But what it all comes down to for me is that the Smalltalk RB is roughly as expressive as those for Java, if not moreso. So while in theory an RB based on explicit type information *could* be more powerful than one based on implicit type information, in *practice* that delta does not yet appear to be significant.

1. Refactoring (and generally code transformation) is powered by knowledge about code. Whether this knowledge is encoded in the types of the language, or in IDE's metadata, or is inferred by the refactoring tool, or just sits in the developer's head - influences only "non-functional" aspects. 2. The same knowledge helps improving quality of autocompletion.

I am not against dynamically-typed languages, some of my favorite languages are dynamically-typed ;-)

Your intentions have nothing to do with it. You are merely a pawn in the force underlying the original density fluctuations of the universe!

I should consult the Oracle about my destiny and oneness ;-) Or was it the Microsoft :-D