I know what "de facto" means, but I still not sure that I would call it a  
standard, de facto or otherwise, simply because it is popular.  Although I  
can see why you could argue that.  To me, "standard" implies something  
more than just popularity.  It implies that it's popularity would  
contribute to it being a better choice than some other alternative (often  
to aid interoperability), and that I would be disadvantaged by not  
choosing the "standard".  If 80% of people use PHP for their server-side  
scripting, it doesn't make it a better choice for me than it would be if  
only 10% of people used it.  However, if 80% of people use Internet  
Explorer then that makes its interpretation of HTML a de facto standard,  
and I would be disadvantaged by choosing to ignore it when developing a  
website.

Dan.

It's as though they miss the point of their own pet languages ;-)

(BTW, I found Xah Lee's recent x-post on the subject of pet languages and the
high priest thereof -- the philosopher one -- interesting, well argued, and
relevant.   Things are looking up.)

The other thing that irritates me, from the same pople, is the standard line
"declarative typing is unnecessary because we have unit tests which catch type
errors (as well as lots of other errors)".   I have nothing against testing (of
any variety), and (as readers in c.l.j.p may remember) I'm no great fan of
static declarative typing either.  It's the "because" that gets up my nose.

In my experience (and I was very surprised to find this when I switched from
Java to Smalltalk), unit tests don't /find/ type errors because people don't
/make/ type errors (or only very rarely).  So, once again, the high priests
seem not to understand the virtues of their own languages.   I can understand
them missing the weaknesses, but they should be able to articulate the positive
points...

This has not been my experience.  It requires a different mind-set (and a new
set of learned skills), but I find it no harder to pick apart well-written
Smalltalk code than I do well-written Java code -- it's basically a matter of
switching from a focus on /type/ to a focus on /behaviour/.  (Working with
badly-written code in either language is like being staked out on an ants nest,
of course.)  Once you have made that switch (which took me quite a while, I
admit), it is just as easy to "penetrate" existing Smalltalk code as Java
(actually, it's quite a bit easier, but mostly as a side-effect of the reduced
verbosity -- which is a trivial issue -- and for other reasons which have
nothing to do with the dynamic/static debate).

Mind you, I don't know how well my experience would carry over to other
dynamically typed languages.  I suspect that the Smalltalk programming
environment (which is no mere "IDE") has a lot to do with this, so -- for all I
know -- doing real programming in Ruby (which only has IDEs -- if that) might
be as frustrating for me as you suggest it would be for you.

It's certainly true that the further away one gets from the boring, vanilla,
crank-out-another-application, style of coding, the more the tradeoff between
the respective benefits of static and dynamic approaches swings in favour the
latter.

   -- chris

[me:]

I suspected as much ;-)

Well, I disagree.  (Ignoring the trivial, Crowlean, "Do as thou wilt shall be
the whole of the law", type system.)  I think that the term can be and is
properly applied.  A generalisation of the classical notion, I agree, but not
an awkward or misleading one.

Hmm.  I would be reluctant -- /extremely/ reluctant -- to talk of a "standard
text" on this subject.  (And, as it happens, wouldn't be keen to accept Pierce
as the standard anyway since I've never heard of it ;-)   Classical type
systems in logic and mathematics have little (IMO) to do with programming
languages -- for instance it would be as wrong to speak of a "static" (locution
for "compile-time") type system in a mathematical context as it would to talk
of a "dynamic" (locution for "runtime") one.

It would certainly be completely wrong to speak of dynamically-typed languages
having dynamic type /analysis/ -- analysis is a static concept[*].  But talking
about type /systems/ is not the same as talking about type /analysis/.  In an
extreme case it might be that the system existed, and was well-defined, but
wasn't subject to analysis.  Such a system might not be much use (who knows ?),
but the idea is not /incoherent/.  Dynamic languages certainly have type
systems -- there is an abstract logic of what [sequences of] operations have
meaning.  Depending on the structure of the language that might or might not
resemble a classical type system.  But it certainly exists -- how else could
anyone understand even one line of code in a dynamically typed language,
there'd be nothing to have a mental model /of/ ?

([*] Except that some implementations /do/ in fact do dynamic type analysis --
the Self implementation which fed into HotSpot for instance ;-)

The other use of the phrase "type system" is to mean "that part of the language
system which does type checking".  In C++ that part is in the compiler.  In
Java it is split between the compiler and runtime.  In Smalltalk it's all in
the runtime.  You may not like that particular use of the phrase, but it seems
to have become established.  To me it seems perfectly reasonable -- so I use
it ;-)  But feel free to translate my uses of the term (in that sense) into
"type checker" if you wish.

Consider the following assertion.  The price that statically analysed languages
pay is that  they must accept an impoverished type system (logic of allowable
operations) in order to have a practically implementable ("tractable";-) type
checker.  Dynamic languages, on the other hand, have a type system (logic)
which is /exactly/ as wide as is possible, but at the cost of a type checker
working at runtime.  You may or may not agree with the assertion;  but my point
is that the assertion is meaningful.  We can coherently /compare/ the type
systems of C++, Java, and Smalltalk, which would not be possible if I were
abusing language by attaching the same phrase to incomparable concepts, or if
Smalltalk could not be said to have a type system at all.

   -- chris

Just for background information: the Refactoring Browser is considered to be an
absolutely essential tool by many (most?) Smalltalk programmers.  It is used
all the time, which argues that it is at least adequate in practise.

Indeed I'm regarded as something of a weirdo for refusing to use its facilities
(I don't like automated refactoring of any kind -- in any language).

I don't think vtables are widely regarded as the best implementation technique,
even for languages which can use them.  Routinely jumping through an
indirection is a killer.  Inline dispatch, with a fallback to vtable lookup,
seems to be the Done Thing These Days.  Also see the "polymophic inline caches"
of Self -- a set of techniques which are applicable to static and dynamic
languages.  Although apparently PICs are not as valuable for Java, where a
simpler inline cache (plus vtables) does as good, or better, job with less
complication.  (Presumably because megamorphic call sites are less common in
Java than in Self or Smalltalk -- although I don't know what part of that is
because the static type system can resolve method calls more precisely, and
what part is just down to differences in the ways that the languages are used.)

That's escape analysis, and it can be done as easily (albeit more
conservatively) in dynamic languages as static ones.  (Always assuming that the
language isn't /so/ dynamic that the concept of "a variable" can't be isolated
from runtime behaviour.)

   -- chris

I did say, 'depends upon what type you want'  I didn't mean that to come
across as using them to document Types relations that are done by type
systems.

This is never a problem - the unit tests are considered as high a value
(or more) as the production code and therefore always compiled and run
as part of the build.

If they don't compile (because they haven't been kept up to date) then
the build fails.

If they don't ALL pass (because they haven't been kept upto date) then
the build fails.

Basically they either are up to date or the build fails.

Unit tests are best written in the same language as the code, as they
are only to describe what the code IS and how to USE it.

Their target audience is developers.

Acceptance Tests on the other hand should indeed be in a domain specfic
langauage. As this allows the stakeholders, testers and developers to
understand what the system is supposed to do.

Units tests are for Building the Code Right.

Acceptance Tests  are for Building the Right Code

Having the unit tests in a parallel directory structure is only one of a
few standard ways of organising them.  Lots of teams have the test code
in the same directory as the production code.

And yet it doesn't in practice this does not seem to be the case....

I haven't yet found a tool for statically typed languages that work
99.99% of the time (Eclipse, IntellJ, etc).

I don't personally find that the language type system has any impact on
usability or reliability.

Chris Uppal has already answered this one better than I can.

Thats funny...  you say they are infected by a religion with the words
'god help them'

Aside from TDD or unit testing being nothing more than a design(TDD) or
testing (unit tests) approaches.  Why would it be a harmful thing ?

Both approaches are simply means of ensuring the code does as we expect.

Lots of languages today include elements to make the life of developers
easy (frameworks, compilers, meta data, generics, templates etc), so why
is adding Unit testing support considered a bad thing?

Having worked in languages which are more difficult to unit test than
Java or Ruby is, it would be a 'god send' (pun intended) if they were
able to have testability as part of the language framework.

I dont think this ever was the case really, there has certainly been
more non-xp shops using Smalltalk then xp-shops.

The same is true for Unit testing, TDD and Smalltalk