Re: RAD vs. performance

Dr Jon D Harrop wrote:
Curtis W wrote:
You do have to care about the internal representation. That is my
point. Trying to brush it under the carpet by providing a consistent
interface is asking for trouble.

You only have to care when you interpret the numbers, not when you
calculate them.

Nonsense. I already gave transitivity as a counter-example.
Perhaps that was a bad example. Think about it this way: a number is
basically any object that can add, subtract, mutliply, etc. itself in a
compliant manner. Integers and floats are specific types of numbers,
thus they fulfull the number interface and can be used interchangeably.
Your argument is that, because a float and an int deviate slightly when
performing said operations, they shouldn't have the same interface.
Using this logic, there would be no need for polymorphism or any other
such relationship device, because according to you objects whose
interfaces don't do exactly the same things shouldn't be possible. On
the contrary, this is the very defintion of inheritance and
polymorphism--objects that deviate from each other but implement a
specific interface. This is exactly what this discussion is about; if
you want even more proof, consider this: if you end up writing
identical code to handle different types, /they have the same
interface/.

No, it has the advantage that the rest of your program can be
statically type checked. If most of your code is not in the dynamically
typed interface, then that benefit is worth having, otherwise it is
not.

Ok, and what do you gain by having the rest of your program "statically
type checked"?

Reliability.
How does this differ from dynamic typing?

Has anyone ever made a compiler for a dynamically typed language that gets
performance comparable to that of statically typed languages without having
massively longer compile times?

I don't know. I think so. But does it really matter?

Of course it matters. I'm not about to ditch statically typed languages
with compilers that exist and work because someone thinks that it might
be possible to write a compiler for a dynamically typed language that
offers the same benefits. Especially when all the evidence indicates
that this is wrong.

This is a purely theoretical debate; nobody's trying to force you to
use dynamic typing, we're merely correcting your misconceptions about
dynamic typing.

Your theory is so detached from reality that it is worthless.
To be honest, I'd have to say your responses as of late are worthless.
This has absolutely no content in it what-so-ever; it's rather hard to
discuss something when you just fling accusations around. It's starting
to get really annoying having to milk the reason out of you when you
could just do the courteous thing and simply include it the first time.

What's important
isn't if anyone _has_, but if it's _possible_. I think it is,

I think it isn't even theoretically possible. Just look at the work
Stalin has to do to get decent run-time performance.

I think it is. Of course, we could go on all day like this, so would
you like to, perhaps, provide a reason why you think so?

Get good run- and compile-time from a dynamically typed language?
Because you need whole-program optimisation for a start.
No, you don't. Whole program optimisation is only required if you want
the compiler to do it for you. Of course, the least amount of work
required to get a fast program would be to do whole program
optimisation, although I tend to do optimisation stuff /after/ I've
finished developing it. I don't know about you, but it seems to me
doing the whole program optimisation for each release would take far
less time than doing it manually.

I've already
walked you through a type inference example for my dynamically typed
language; it's your turn.

From my point of view, you have stated that you believe you can easily
do something that mankind has been trying and failing to do for 50
years.
What? This whole thread is about dynamic languages that are compiled,
with several being listed. The only thing I'll probably add is giving
the programmer more control when it comes to removing flexibility when
necessary (and therefore increasing speed).

Any way you cut it, if you "develop" a dynamic type system to provide
the benefits of a static type system then you've reinvented the static
type system.

What is your reasoning behind this outlandish claim?

The benefits of static typing come at compile time. In order to get
those benefits, you must be doing static checking. That isn't
outlandish, it's obvious.
No. Just because a language does static type checks doesn't make it
static any more than a language using dynamic checks makes it dynamic
(see: bounds checking, etc).

.

Relevant Pages

  • Re: RAD vs. performance
    ... interface is asking for trouble. ... I'm not about to ditch statically typed languages ... use dynamic typing, we're merely correcting your misconceptions about ... The benefits of static typing come at compile time. ...
    (comp.lang.misc)
  • Re: RAD vs. performance
    ... what Ocaml does is horrible butchery. ... type checking work to compile time as possible. ... that it is possible to invent dynamically typed languages that compile ... dynamically typed languages are necessarily slow (at run time or compile ...
    (comp.lang.misc)
  • Re: creaping coupling......
    ... but it is a more strict contract than required. ... "I am capable of implementing things via interface XYZ i.e. ... consider specifically that we compile, deploy and then we delete a method to ... IWriteable pipe = new Pipe; ...
    (comp.object)
  • Re: RAD vs. performance
    ... thus they fulfull the number interface and can be used interchangeably. ... Have you noticed a lot of repeated code between sets and floats? ... Because you need whole-program optimisation for a start. ... The alternative is static typing, ...
    (comp.lang.misc)
  • Re: ActiveX.exe question
    ... > the public interface still need registered in order to use them. ... Compile AXExe.exe against a Share on the TestPC ... Open a Standard-Exe-Project on your DevelopPC and name it AXTest ... Compile AXTest.exe against the Share on the TestPC ...
    (microsoft.public.vb.general.discussion)