🚀 go-pugleaf

Steve Knight writes:
>
>In response to a claim (or observation) made by David Gudeman that
>"dynamically typed languages are generally half to a tenth the size
>of programs in statically typed languages" Dan Bernstein reasonably
>writes back.
> 
>] I don't believe you. Give an example.
> 
>Of course, this gets us into the foolish realms of anecdotes and virility 
>tests.

It's somewhat worse, IMHO, in that there is no such thing as a true
example.  A true example would be a drop-in replacement for another
program, maintaining its quirks and 'optimizations' as though they
were mandated by <<insert your favorite authority here>>.

It is also false (as Peter da Silva has indirectly pointed out) to
place all the credit for compactness on dynamic typing...  some
compactness is from dynamic linking (or its equivalent), some is
because startup code isn't needed, some might be because the program
is kept in a higher-level form (e.g. threaded code).

And some benefits come from incidental features (it being very easy
for example, to implement overlays on a system which doesn't have them
in the os, if you can manipulate 'object code' with your language
primitives, and call such routines with low overhead).  Perhaps what
we've been arguing is not so much for dynamic typing, but the
inclusion of additional types of high utility?

But what if that additional type is an array whose bounds are
maintained at run-time?  What if there are a large number of
primitives to support manipulations of the list, and so on?

Basically, dynamic-typing (the way I've been thinking about it)
applies to languages which allow more structure that if/then/else and
do/while.  Things like data-selection operations and iteration over
some sequence of values (where it DOESN'T MATTER what the data is, you
just want to select it, and so on).  I'm talking about making these
first-class functions in the language, not in the sense of 'this is an
ad-hoc feature which can be used to speed up performance on platform
X', but 'this is a language feature, intended to replace lower-level
operations'.  And to any argument that 'This can be done in C', I
respond, it can be done in assembly language too.  (And to any who say
"that's not portable", I add that it can even be done in 8086
assembly).

In so-called statically typed languages, you are forced to think and
program in a low-level fashion.  Dynamically typed languages (If I say
'array'-oriented or 'list'-oriented, do I exclude Icon or ML?) tend to
be higher-level languages.  It doesn't matter how fast your solution
is if it doesn't run.

Raul Rockwell