Re: RAD vs. performance

Curtis W wrote:
Jon Harrop wrote:
Curtis W wrote:
Robbert Haarman wrote:
You also lose some convenience/brevity. For example, in Ocaml you must
use + for adding integers and +. for adding floats, so that the type
inferencer can inference the correct types. In Standard ML, you would
have to add a type annotation to functions that use the + operator
(which is special and applies to both ints and floats).

That's not intrinsic of static typing, but merely a limitation of
OCaml.

There is a tradeoff between overloading, type inference, error clarity
and performance. OCaml has chosen one solution and it is a comparatively
good one.

Unfortunately, said solution is fairly rigid when it comes to extending
code.

Which is ok because ints and floats have different semantics anyway.

def command1(x):
...

def command2(x, y):
...

commands = {
"c1": command1,
"c2": command2
}

command_name, args = get_command_from_user()
commands[command_name](*args)
---
As you can see, it would be impossible to infer whether or not the
number of arguments is valid for the given command at compile time.
However, because python is dynamically typed, it lets it slide and will
tell you at runtime if an error does occur. In a statically typed
language, you have to tell the compiler somehow that you know that
statement will not produce an error--usually with some sort of cast.

You might do this:

# let exec name args =
let command1 = function `A x -> `T1 x | _ -> invalid_arg "" in
let command2 = function `B (x, y) -> `T2 (y, x) | _ -> invalid_arg "" in
let commands = ["c1", command1; "c2", command2] in
(List.assoc name commands) args;;
val exec :
string -> [> `A of 'a | `B of 'b * 'c ] -> [> `T1 of 'a | `T2 of 'c * 'b ]
=
<fun>

But, again, this is bad OCaml code because it fails to leverage static
typing and, consequently, is likely to suffer from run-time errors and
require lots of unit tests and debugging. To get reliable software, you're
better off writing an IDL compiler in this case.

If you want an efficient compiler there's type inference ;) A well
written compiler for a dynamic language isn't inherently slower than
any other type of compiler,

There is an overwhelming amount of quantitative evidence to the contrary.

That's irrelevant, considering I was speaking theoretically. It's
completely possible to write a fast, dynamically typed language.

By sacrificing compilation speed and partial recompilation to an extent so
impractical that virtually nobody does this.

Using a decent type inferencer and code
analsys, it should be possible to produce an identical binary in most
situations.

Yes, using a compiler like Stalin that takes three orders of magnitude
longer to compile.

Perhaps, although that that would be nothing compared to the amount of
development time saved by emphasizing flexibility rather than speed.

On the contrary, it hinders development by slowing compile time and failing
to catch errors statically. Dynamic typing offers no extra "flexibility"
precisely because it is a special case of static typing.

You could argue that dynamic typing offers brevity in cases where static
typing is of no benefit. However, there is little evidence to support such
a claim. Look at my OCaml translation above, for example.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
.

Relevant Pages

  • Re: RAD vs. performance
    ... inferencer can inference the correct types. ... (which is special and applies to both ints and floats). ... If you want an efficient compiler there's type inference;) A well ... written compiler for a dynamic language isn't inherently slower than ...
    (comp.lang.misc)
  • Re: RAD vs. performance
    ... inferencer can inference the correct types. ... (which is special and applies to both ints and floats). ... If you want an efficient compiler there's type inference;) A well ... written compiler for a dynamic language isn't inherently slower than ...
    (comp.lang.misc)
  • Re: RAD vs. performance
    ... Thing if the compiler doesn't let you get away with this. ... command1 and command2 defined as before, and a lot of Common Lisp ... written compiler for a dynamic language isn't inherently slower than ... The difference is that, for static typing, you reject programs ...
    (comp.lang.misc)
  • Re: RAD vs. performance
    ... ints and floats into account. ... Floats are but one representation of numbers. ... dynamically typed language, you could just feed the above code through ... compiler would reject the program. ...
    (comp.lang.misc)
  • Re: RAD vs. performance
    ... Which is ok because ints and floats have different semantics anyway. ... better off writing an IDL compiler in this case. ... counts) yet still large numbers of cons cells are turning into garbage (at ...
    (comp.lang.misc)