Michael Cook <michael.cook / cisco.com> writes:

> >> This post offers good coverage of all sides of the issue - could you post 
> >> it to the RubyDiscussions section of the wiki on Rubygarden.com?
> >> 
> > Ok, check out
> >
> > http://www.rubygarden.org/ruby?DynamicVsStaticTyping
> 
> it doesn't seem unreasonable that a language should support both
> static and dynamic typing.  then, if i knew at compile time what the
> types would be, i could tell the compiler, and i could possibly
> expose some problems at compile time.  but if i didn't know the
> types at compile time, that would be okay too.

dynamic typing has 3 main disadvantages:
(1) slower (runtime)
(2) less space efficient (runtime)
(3) no correctness ensured (compile-time)


Why so?
(1) comes from the numerous type checks needed to ensure strong typing
(2) very reflexive (keeps a lot of information at runtime),
    non homogeneous data structures (think arrays)
(3) type checks are done at runtime


How dynamic typing can lessen those disadvantages:

(1) 
- JIT'ing permits to specialize some code over some types, hoisting the type
  checks.
- Type annotations can be used to help the compiler generating specialized
  code
- Rewritting some parts in a faster language (C / assembler / ...)

Those works quite nicely since the critical path is making most of the speed
(10% of the code takes more than 90% of execution time)

(2)
- The space efficiency is not really typical of dynamic typing. Java has the
same problems.
- Homogeneous data structures can be added in any languages (using type
annotations)
- Recoding the big data structures and its accessors in C is usually enough.

(3)
For correctness, the matter is harder IMO: correctness is not a matter of some
particular part of the code, it comes from the *whole* code.
- Adding type annotations only helps for the part where they are used.
- Adding a separate type checker over a dynamically typed language is hard:
  * heterogeneous data structures (it simplifies the language, the type
    declaration, no datatypes)
  * ability to create function/methods at runtime
  * incremental compilation/loading of packages
  * use of the same variable with values of different types
  * return values ignored (pb inherited from Algol68, useful when return value
    is not highly valued (error code...))

 Some solutions exist but do not compare with real static typing:
  * pychecker: checks for some common errors
  * soft typing: try to infere the types, but accepts every program that may
    work.
  Their limitations are quite important: checks are local. Global programs
analysis is hard, costly and error prone. Whereas the bigger advantages of
static typing appears when handling big & complex programs.

--
Pixel
programming languages addict      http://merd.net/pixel/language-study/