Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management
Thomas G. Marshall
...[thwack]...
> So a language that catches 95% of such errors at compile time has no
> advantages over one that catches none of them?
I'm violating one of my rules and cross posting this thing. If you don't
like it, ignore it, sue me later, vilify me now:
Robert C. Martin pointed out in this post in c.object, regarding static
typing and its overal worth when in conjunction with TDD:
Or for the clinally paranoid (like me):
Static typing comes at a cost. It increases coupling, and rigidity.
We accept this cost because of the safety. However, if our TDD
tests
are already providing that safety, we may decide to reconsider the
cost.
Way out of context, with apologies to RCM, but I think it's germane to this
current thread storm in comp.programming.
This thread is more general, but I'm asking the smalltalk crowd to beat this
up a bit--I suspect that many of them are going to disagree with me on this
(borrowed) assertion of mine, but then again, hopefully many of them will
support the notion:
Statically formed types (of statically typed languages)
mostly solve problems created by statically formed
types to begin with.
Which I believe to my horrible paraphrase of Paul Campbell, who turned me
180° around and caused me to agree with him, but I cannot find that post.
{author runs for cover}
I further posed <paraphrase claxon/> in the c.p thread:
Or clinically paranoid:
Accumulate all the time that establishing type safety
in java takes. All the extra effort to establish types,
and use them carefully, etc. Let's call that T1.
Accumulate all the time that you spend in smalltalk
chasing down bugs that occur from not having said
type safety handled at compile time. Let's call that T2.
Perhaps T1 > T2.
Now this is a different metric comparison from my boiled down original
(albeit borrowed) postulation:
The time accumulated developing and maintaining in
a statically typed language is D1.
The time accumulated developing and maintaining in
a dynamically typed language is D2
Perhaps D1 > D2
However incorrect or not, for expediency I'd like to assume for this thread
that "compile time type safety" and "statically typed languages" go 1:1
together. The purists can sue me on this later.
I'm a pundit of Java, and /was/ a huge advocate of statically typed
languages until it was made clear to me that perhaps the compile-time type
safety just doesn't deliver as much as statically typed pundits (like me)
think in terms of project completion and maintainability. I fully expect to
get drummed outta town on this.
Thomas Gagne
> <snip>
>
> Statically formed types (of statically typed languages)
> mostly solve problems created by statically formed
> types to begin with.
>
I thought that was my quote (from my webpage):
"Static typing catches the errors static typing creates."
;-)
Gerry Quinn
tgm2tothe...@replacetextwithnumber.hotmail.com says...
>
> Robert C. Martin pointed out in this post in c.object, regarding static
> typing and its overal worth when in conjunction with TDD:
>
> http://tinyurl.com/22xqy
>
> We accept this cost because of the safety. However, if our TDD
> tests
> are already providing that safety, we may decide to reconsider the
> cost.
There must be a third silver bullet we can add to make this thing really
fly...
- Gerry Quinn
Thomas G. Marshall
Didn't see that webpage, but if you're the one that turned me around on
this, then thanks (!!!), and sorry for misattributing it. I just couldn't
find the right post in that monster thread in c.o.
Andre Schnoor
Example: I'm working on a system with 550+ classes in deeply nested
inheritance trees, modelling a farily complex domain. The only time I
encountered problems related to dynamic (late) typing was a few months ago,
during a short phase of heavy refactoring, when I made a major redesign of
the model affecting a large number of classes at once.
I had to look after several critical places sensible to dynamic typing by
hand. Anyway, the whole redesign took me 6-8 hours, changing about 1MB of
source code. That was all. After this, everything was stable again.
This would not have been possible at all with anything other than agile,
dynamic typing (and the Smalltalk IDE in particular).
While in most statically typed languages typing issues can cause severe
crashes and a breakdown of the local electricity, in Smalltalk it's just a
little "oops": A quick fix usually takes a few seconds and then the
application continues running.
Static typing is a good thing if you want to feel safe when working on the
driver or OS level, hacking your way through unforgiving binary data
structures etc. But the more your model gets involved in higher-level
domains and real things from the world out there, it only slows you down.
Andre
Thomas Gagne
<snip>
>
>
> this, then thanks (!!!), and sorry for misattributing it. I just couldn't
> find the right post in that monster thread in c.o.
>
>
close and deliberate proximity to each other. I used to spend more time in
comp.lang.java.* than I do now, which is probably where I said it in more or
fewer words.
Thomas Gagne
"Having used both, I prefer dynamic typing to static typing. The only
errors Java and C++ catch for me are errors Java and C++ created in the
first place with static typing."
I knew I'd find it somewhere.
Chris Uppal
> This thread is more general, but I'm asking the smalltalk crowd to beat
> this
> up a bit--I suspect that many of them are going to disagree with me on
> this (borrowed) assertion of mine, but then again, hopefully many of them
> will
> support the notion:
>
> Statically formed types (of statically typed languages)
> mostly solve problems created by statically formed
> types to begin with.
I'm not addressing your main point, but the specific case of the new generics
(and covariant returns) in Java 1.5 is relevant.
These features add a whole new layer of complexity to the Java language, yet
they are /only/ there to allow code that would work /anyway/ to fit into the
Java statically typed mindset.
My personal opinion[*] is that the new features add more complexity than is
justified by either the improved reliability of static typechecking (small or
very small), or by the rather larger benefits to the code's self-documentation.
-- chris
[*] albeit, not having used the new stuff in anger yet.
Berislav Lopac
> I'm a pundit of Java, and /was/ a huge advocate of statically typed
> languages until it was made clear to me that perhaps the compile-time
> type safety just doesn't deliver as much as statically typed pundits
> (like me) think in terms of project completion and maintainability.
> I fully expect to get drummed outta town on this.
Let me be very brief in my take on this:
Static typing is Bad(TM) when it comes to primitive data, like strings and
especially numbers. The main reason to have static typing here is to track
memory use, and when a language has some kind of automated memory management
this takes care of itself.
When it comes to objects, static typing is Good(TM), because usually we need
a specific class (or superclass, or interface) to be passed around, and by
static typing we can ensure that the correct class is passed through instead
of checking all possible classes. So the wrong class is cought when passed,
and not when we try to do something with it, when it might be too late. Even
PHP, which has the most thorough dynamic typing I have seen, has included
'class hints' in its latest incarnation to help you ensure that only the
right class(es) are passed into a function.
Berislav
--
If the Internet is a Marx Brothers movie, and Web, e-mail, and IRC are
Groucho, Chico, and Harpo, then Usenet is Zeppo.
Christopher Barber
> Thomas G. Marshall wrote:
> > I'm a pundit of Java, and /was/ a huge advocate of statically typed
> > languages until it was made clear to me that perhaps the compile-time
> > type safety just doesn't deliver as much as statically typed pundits
> > (like me) think in terms of project completion and maintainability.
> > I fully expect to get drummed outta town on this.
>
> Let me be very brief in my take on this:
>
> Static typing is Bad(TM) when it comes to primitive data, like strings and
> especially numbers. The main reason to have static typing here is to track
> memory use, and when a language has some kind of automated memory management
> this takes care of itself.
I disagree. Static typing information also lets the compiler generate much
more efficient code.
Thomas Gagne
So you're willing to exchange expressiveness for more efficient code? When
speed is an issue *today* this makes sense and the necessary speed for *today*
should be identified as a requirement. But if that is one of static typing
benefits it is a blatant premature optimization. You'll be maintaining and
extending the code the rest of your life while hardware continues to get
faster. Hardware will be twice as fast and cheaper 18 months from now.
But even efficient code (after compilation) can't make up for bad designs.
Shayne Wissler
"Thomas Gagne" <tga...@wide-open-west.com> wrote in message
news:H8GdnXUhzpR...@wideopenwest.com...
> > I disagree. Static typing information also lets the compiler generate
much
> > more efficient code.
> >
> So you're willing to exchange expressiveness for more efficient code?
Actually, being able to specify where in memory you want a given object is a
form of expressiveness.
> When
> speed is an issue *today* this makes sense and the necessary speed for
*today*
> should be identified as a requirement. But if that is one of static
typing
> benefits it is a blatant premature optimization. You'll be maintaining
and
> extending the code the rest of your life while hardware continues to get
> faster. Hardware will be twice as fast and cheaper 18 months from now.
It doesn't matter how fast computers get--there will always be a need for
fast code that is tuned at a level that only statically-typed languages
allow. Again, they are more expressive than the dynamic languages in this
area, and this expressiveness is an absolute requirement for some kinds of
problems. Ideally we wouldn't be talking about dynamic vs. static; we'd have
a language that gave us the best of both.
Shayne Wissler
http://www.ouraysoftware.com
Isaac Gouy
-snip-
> I'm a pundit of Java, and /was/ a huge advocate of statically typed
> languages until it was made clear to me that perhaps the compile-time type
> safety just doesn't deliver as much as statically typed pundits (like me)
> think in terms of project completion and maintainability. I fully expect to
> get drummed outta town on this.
Is there something new?
Something not touched on in these long threads on comp.object
and comp.functional
Christopher Barber
> Christopher Barber wrote:
> > "Berislav Lopac" <berisla...@dimedia.hr> writes:
> >
> >>Thomas G. Marshall wrote:
> >>
> >>>I'm a pundit of Java, and /was/ a huge advocate of statically typed
> >>>languages until it was made clear to me that perhaps the compile-time
> >>>type safety just doesn't deliver as much as statically typed pundits
> >>>(like me) think in terms of project completion and maintainability.
> >>>I fully expect to get drummed outta town on this.
> >>
> >>Let me be very brief in my take on this:
> >>
> >>Static typing is Bad(TM) when it comes to primitive data, like strings and
> >>especially numbers. The main reason to have static typing here is to track
> >>memory use, and when a language has some kind of automated memory management
> >>this takes care of itself.
> > I disagree. Static typing information also lets the compiler generate much
> > more efficient code.
> >
> So you're willing to exchange expressiveness for more efficient code?
When appropriate, yes. IMHO, a good programming language should support both
static and dynamic typing ability and allow the programmer to choose when to
use static and dynamic typing techniques.
> When speed is an issue *today* this makes sense and the necessary speed for
> *today*
> should be identified as a requirement. But if that is one of static typing
> benefits it is a blatant premature optimization.
I don't think that choosing a programming language is a "premature
optimization". Porting code from one language to another can be quite
difficult and expensive, especially when the languages are different from each
other. I worked on one product that never managed to switch its extremely
slow Tcl code over to C++ in the course of two years and ultimately lost out
to competitors w/ more scalable implementations.
> You'll be maintaining and
> extending the code the rest of your life while hardware continues to get
> faster. Hardware will be twice as fast and cheaper 18 months from now.
More like two years, and then only at executing instructions. Furthermore, we
can antipate that the time it takes to see a double in performance is going to
get longer and longer in the future (when Moore first made his observation
about transistors the doubling period was around 6-months).
Furthermore, various forms of latency (memory, disk, communications) aren't
improving at anything like that rate and are ultimately bounded by the speed
of light. Dynamicly typed programs use more memory than (well-written)
staticly typed programs and thus incur a greater penalty for memory and disk
latency.
In practice, very few programs run twice as fast on a machine w/ double the
frequency.
> But even efficient code (after compilation) can't make up for bad designs.
True enough but that has nothing to do w/ static vs. dynamic typing.
- C
Dmitry A. Kazakov
> Thomas G. Marshall wrote:
>> I'm a pundit of Java, and /was/ a huge advocate of statically typed
>> languages until it was made clear to me that perhaps the compile-time
>> type safety just doesn't deliver as much as statically typed pundits
>> (like me) think in terms of project completion and maintainability.
>> I fully expect to get drummed outta town on this.
>
> Let me be very brief in my take on this:
>
> Static typing is Bad(TM) when it comes to primitive data, like strings and
> especially numbers.
Static typing is especially important when dealing with numbers. Things
like bounds checks, different number representation models, different
implementations of numeric operations: rounding, precision, accuracy,
exceptions etc, these are natively mapped to types and subtypes. Those
should checked at compile time.
> The main reason to have static typing here is to track
> memory use,
Static typing is used for early checks.
It has nothing to do with static vs. dynamic memory allocation. That's
static vs. dynamic object scope.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Thomas Gagne
> Thomas Gagne <tga...@wide-open-west.com> writes:
>
<snip>
>>So you're willing to exchange expressiveness for more efficient code?
>
>
> When appropriate, yes. IMHO, a good programming language should support both
> static and dynamic typing ability and allow the programmer to choose when to
> use static and dynamic typing techniques.
>
>
>
>
>>You'll be maintaining and
>>extending the code the rest of your life while hardware continues to get
>>faster. Hardware will be twice as fast and cheaper 18 months from now.
>
>
> More like two years, and then only at executing instructions. Furthermore, we
> can antipate that the time it takes to see a double in performance is going to
> get longer and longer in the future (when Moore first made his observation
> about transistors the doubling period was around 6-months).
Today we're expecting those advances to come inside a single chip. SMPs are
already becoming cheaper and whatever speed a single chip runs at can be
nearly doubled with a second.
>
> Furthermore, various forms of latency (memory, disk, communications) aren't
> improving at anything like that rate and are ultimately bounded by the speed
> of light. Dynamicly typed programs use more memory than (well-written)
> staticly typed programs and thus incur a greater penalty for memory and disk
> latency.
>
Latency isn't improved by static typing, and I don't have any memory
consumption information to compare between Java and Smalltalk. From what I've
noticed looking at both VM processes in memory it looks as though Smalltalk
consumes less RAM but I don't know if 'top' an accurate measurement. Accurate
for some things but perhaps not others--certainly all things are not equal so
it would be difficult to compare them. Of course, Java may not be the
representative static-typers would select -- they might prefer C or C++, and
they certainly would beat Smalltalk--but the typing systems aren't what's
being compared, the difference between statically bound compiled languages vs
dynamically bound and interpreted langauges is what would be measured there.
Thomas G. Marshall
> Thomas G. Marshall wrote:
>> I'm a pundit of Java, and /was/ a huge advocate of statically typed
>> languages until it was made clear to me that perhaps the compile-time
>> type safety just doesn't deliver as much as statically typed pundits
>> (like me) think in terms of project completion and maintainability.
>> I fully expect to get drummed outta town on this.
>
> Let me be very brief in my take on this:
If by that you want to bow out of this before it gets gut wrenching :), I
both agree, and envy you.
> Static typing is Bad(TM) when it comes to primitive data, like
> strings and especially numbers. The main reason to have static typing
> here is to track memory use, and when a language has some kind of
> automated memory management this takes care of itself.
>
> When it comes to objects, static typing is Good(TM), because usually
> we need a specific class (or superclass, or interface) to be passed
> around, and by static typing we can ensure that the correct class is
> passed through instead of checking all possible classes. So the wrong
> class is cought when passed, and not when we try to do something with
> it, when it might be too late. Even PHP, which has the most thorough
> dynamic typing I have seen, has included 'class hints' in its latest
> incarnation to help you ensure that only the right class(es) are
> passed into a function.
And what of the polymorphism /without/ inheritance? IYO, is that then /not/
an advantage that is worth it?
>
> Berislav
Thomas G. Marshall
90% OT, but this has been my argument /against/ using DSP's. They only
greatly slow the time-to-market, and slaughter maintainability. By the time
you get to market, the RISC systems will have caught up to your initial
bandwidth requirements anyway. They are usually a disaster all the way
around :)
Thomas G. Marshall
> Thomas Gagne <tga...@wide-open-west.com> writes:
...[rip]...
>> You'll be maintaining and
>> extending the code the rest of your life while hardware continues to
>> get faster. Hardware will be twice as fast and cheaper 18 months
>> from now.
>
> More like two years, and then only at executing instructions.
> Furthermore, we can antipate that the time it takes to see a double
> in performance is going to get longer and longer in the future (when
> Moore first made his observation about transistors the doubling
> period was around 6-months).
>
> Furthermore, various forms of latency (memory, disk, communications)
> aren't improving at anything like that rate and are ultimately
> bounded by the speed
> of light. Dynamicly typed programs use more memory than
> (well-written) staticly typed programs and thus incur a greater
> penalty for memory and disk latency.
>
> In practice, very few programs run twice as fast on a machine w/
> double the frequency.
That's not the entire story though. You need to take into account the
following issues:
Regardless of the speed of any one cpu, we
are now slamming more and more of them
together on single IC's.
Hitting the physics wall in disk storage is only
horrifying if you ignore the other types of storage
possibly or possibly not on the horizon. Think
hologram access inside a 1" cube.
The moore time is measuring between systems
of the utmost "power". Not the systems that are
of the high power yet affordable, which is what
impacts us the most. IMO there is a strangely
shorter lag between affordable systems than
between utmost systems.
...[slash]...
Thomas G. Marshall
> "Thomas G. Marshall"
> <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote in
> message news:<bgBGc.29088$MT5...@nwrdny01.gnilink.net>...
>
> -snip-
>> I'm a pundit of Java, and /was/ a huge advocate of statically typed
>> languages until it was made clear to me that perhaps the
>> compile-time type
>> safety just doesn't deliver as much as statically typed pundits
>> (like me)
>> think in terms of project completion and maintainability. I fully
>> expect to
>> get drummed outta town on this.
>
> Is there something new?
No, no, I was merely overstating the "drummed outta town" thing. I was
referring to how /hot/ this topic can be.
And everything seems a rehash in usenet anyway.
The reason for my statement had to center around the resistance I received
in comp.programming about this topic. I was running out of ways of making
the point, especially since I was a java pundit.
...[thwack]...
H. S. Lahman
The static vs. dynamic typing debate is inherently unresolvable with
today's technologies and available data. If there were a clear winner
it would have been obvious somewhere in the 2+ decades the issue has
been debated.
Nonetheless I think the debate often gets mired in arcane language
issues and examples at the expense of a more megathinker view...
>>So a language that catches 95% of such errors at compile time has no
>>advantages over one that catches none of them?
><snip>
> Static typing comes at a cost. It increases coupling, and rigidity.
> We accept this cost because of the safety. However, if our TDD
> tests
> are already providing that safety, we may decide to reconsider the
> cost.
I think this is a bit facile. It is well established in practice and
mathematically demonstrable that any testing effort benefits from having
multiple screens, even when the fault coverage of those screens largely
overlaps.
>
> <snip>
>
> Statically formed types (of statically typed languages)
> mostly solve problems created by statically formed
> types to begin with.
I also find this a bit facile. There is no question that static typing
places constraints on the software construction that can be annoying to
the developer. But I see that as a different issue than the problems
static typing solves.
Static typing provides an early, largely independent test screen that is
very much focused on the sorts of mechanical errors that plague human
activities (aka "assembly faults"). It also allows the production of
<somewhat> more efficient code.
The price of those benefits is that the developer has to sometimes "work
around" the type system. (How often is moot and that is one of the
reasons the debate is doomed to continue until someone collects some
real data.)
>
> <snip>
>
> Perhaps T1 > T2.
>
> <snip>
>
> Perhaps D1 > D2
The glib rejoinder here is that if developer effort were the primary
concern, one would be programming in an FPL rather than an OOPL in the
first place. The point is that the issue is far more complex than this.
In addition to the value of multiple screens, it is also well
established that it is valuable to find defects early, it is valuable to
focus on assembly faults, and it is valuable to provide cheap,
mechanical screens. Static type checking fairs well in almost any
objective view of testing software. The debate lies in the following
issues:
(1) How much additional effort, if any, is required deal with static
type systems. I know of no experimental data on this, so I don't see it
being quantified in my lifetime.
(2) Whether static testing becomes a crutch for sloppy development. The
reality is that the number of escapes from any test screen is directly
proportional to the number of defects detected. If developers get lazy
in writing code so that the compiler/interpreter is finding more
defects, that is a matter of developer discipline rather than a weakness
of static testing. IOW, monitor the process and make the developers
accountable.
(3) The cost of escapes. For complex software applications no system of
testing is perfect. (IMO, the best testing can possibly provide is
5-Sigma; one needs militant defect prevention to do better.) Basically
this comes down to evaluating the escapes w/ and w/o static testing to
determine if there is a difference in number, type, and repair cost.
Again, I know of no hard data on this, so I don't expect resolution in
my lifetime.
(4) Redundancy with dynamic type checking. The basic idea here is that
some form of type checking in inherently already done at run time in
languages where types are dynamic. There are lots of anecdotal examples
of errors that would be caught by static checking but would escape
dynamic type checking. Again, there is no solid experimental data to
indicate that the category of such defects is significant.
(5) The value of defect prevention. If the defects are not isolated in
static testing, how are they isolated? Clearly the combinatorial
problems of functional testing makes that problematic at best. Dynamic
type checking only covers some <undefined> fraction of the potential
problems per (4). So one is left with developer discipline in
practicing defect prevention to avoid inserting such defects into the
code at all. There are two problems here. The first is that it ignores
the value of multiple test screens. The second is that one still needs
to monitor the defect prevention process and the best way to do that is
via testing. So defect prevention really isn't an excuse for not
providing the test screen unless one can demonstrate the difference in
fault coverage between static and dynamic testing is insignificant.
[Apocryphal aside. Once one gets to 5-Sigma and beyond one is dealing
with ~ 1 defect/10 KLOC of code. To properly monitor the process one
must detect a reasonable sampling of all defect classes. So,
ironically, shops that use testing purely as a process monitoring tool
tend to do a lot more testing than shops that use testing as the primary
mechanism for achieving reliability. B-)]
(6) What creative angst the developer must pay to work around static
type systems. While I am sure this is an important issue to some, I
submit that is just an ego trip. IOW, keep focused on the prize: what
matters is that the customer gets correct, reliable, and cheap software
in a timely fashion. If some grunt work is required to get there, so be it.
While this analysis might seem to come down on the side of static
testing, the jury is still out because of the paucity of data to resolve
(1), (3), and (4). Until that data becomes available the debate will
remain a duel of opinions.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH
Thomas G. Marshall
> Responding to Marshall...
...[thwack]...
>> <snip>
>>
>> Perhaps T1 > T2.
>>
>> <snip>
>>
>> Perhaps D1 > D2
>
> The glib rejoinder here is that if developer effort were the primary
> concern, one would be programming in an FPL rather than an OOPL in the
> first place.
Not developer effort. Effort in development and maintainability. What it
takes to make the thang and keep it working. I'll recap for glib yucks :)
The time accumulated developing and maintaining in
a statically typed language is D1.
The time accumulated developing and maintaining in
a dynamically typed language is D2
Perhaps D1 > D2
But your post is taken well, thanks.
...[thwack]...
Thomas G. Marshall
>
> The static vs. dynamic typing debate is inherently unresolvable with
> today's technologies and available data. If there were a clear winner
> it would have been obvious somewhere in the 2+ decades the issue has
> been debated.
Ah. I was hoping this to /not/ be a debate over which was better per se,
but a debate over whether or not static typing gives you all that its
purported to.
Is there a difference? I think so, but if you don't, that's also fine by
me.
...[thwack]...
Ron Ruble
"Christopher Barber" <cba...@curl.com> wrote in message
news:psosmc4...@unicron.curl.com...
> "Berislav Lopac" <berisla...@dimedia.hr> writes:
<snip>
> I disagree. Static typing information also lets the compiler generate
much
> more efficient code.
Sorry, have to push back here. Static typing -simplifies-
the process of generating efficient code for the compiler
writer, but it actually -is- possible to generate code that
treats the data as if it were a static type even while
using a dynamically typed language. I recall reading
about some projects that did this.
-I- wouldn't be able to do it, but it appears it can be
done.
Christopher Barber
Yes, it can, but only in some cases.
Given a static type declaration, a compiler can generate efficient code
without knowing anything about how the variable gets set. Without this
declaration, the compiler needs a lot more information about the program to
have any chance of inferring the type. This basically ruins any chance at
separate compilation of modules.
Even w/ a good type inferencing system, the code may not be optimizable
because of the choices of dynamic types used in a given program. In such a
case, static type declarations wouldn't produce better code, but should make
it more clear where the problems lie.
Ian Upright
>I also find this a bit facile. There is no question that static typing
>places constraints on the software construction that can be annoying to
>the developer. But I see that as a different issue than the problems
>static typing solves.
Static typing doesn't "solve" anything, it merely enforces constraints that
developers put upon themselves. In most statically typed languages, they go
so far as forcing you to always have constraints, and these aren't something
that can be optional. You can't say, gee, for this part of the library,
it'd be really nice to have a constraint here. You are simply forced to
have constraints everywhere. This is highly restrictive.
>Static typing provides an early, largely independent test screen that is
>very much focused on the sorts of mechanical errors that plague human
>activities (aka "assembly faults"). It also allows the production of
><somewhat> more efficient code.
Performance is one of the most important and biggest arguments for static
typing, but agreed, it only produces <somewhat> more efficient code.
However, it does depend on the scenario. For certain hotspots, static
typing can be a big win. The critical thing is to find these hotspots and
optimize them where necessary.
>The price of those benefits is that the developer has to sometimes "work
>around" the type system. (How often is moot and that is one of the
>reasons the debate is doomed to continue until someone collects some
>real data.)
Here you pay it for added complexity and a real mess, where things can be
solved far more elegantly and simply by dynamic types. The mess and
complexity that is incurred, far outweighs any supposed "benefits" that
could be gotten by the developer putting themselves in a straightjacket.
Supposedly "safe" or not, if nobody can easily understand it, it's
definately crap code, and definately going to cost you in terms of
productivity, no matter how you figure that the supposed safety saves you in
productivity. For complex situations like this, it simply doesn't.
To sum up: There are times where you definately need dynamic typing. There
are times where you definately need static typing.
Dynamic languages that make static typing optional and *optionally* deliver
the performance of static typing, thereby allowing the user to define
additional constraints, is the future of programming languages.
Any language that doesn't offer both is just not ideal for solving real
world problems both elegantly and efficiently. Yet, we continue to debate
and argue static vs. dynamic, when both extremes have absolutely got it
wrong. I back up my statements with undisputed proof that people on the
usenet have been viciously debating dynamic vs. static typing for over 10
years. Quite simply, you just can't please everybody with one extreme or
the other. Quite simply, most applications have very performance
critical-hotspots that need some static typing, and an assortment of
high-level concepts that are easily and efficiently solved by elegant
dynamic designs.
Ian
Thomas G. Marshall
True in general, but thankfully, however, much of this thread isn't situated
at either extreme. I was really hoping to pose the initial post in such a
way that it wouldn't turn into
dynamic or static, which is better
instead of what I /really/ wanted:
static typing---is it really a big advantage?
And it seems to /mostly/ have worked.
Isaac Gouy
-snip-
> Ah. I was hoping this to /not/ be a debate over which was better per se,
> but a debate over whether or not static typing gives you all that its
> purported to.
Depends on what benefits you chose to imagine are claimed for static checking.
And how do /you/ define polymorphism without inheritance? (Got a code example?)
Ian Upright
wrote:
>True in general, but thankfully, however, much of this thread isn't situated
>at either extreme. I was really hoping to pose the initial post in such a
>way that it wouldn't turn into
>
> dynamic or static, which is better
>
>instead of what I /really/ wanted:
>
> static typing---is it really a big advantage?
>
>And it seems to /mostly/ have worked.
I think it's good. I think people in the Java/C++ camp have no longer
seemed to have fallen into a black hole of thinking that static typing is
where it is at. I think the significant adoption of Python proves that
there is definately a place in the world for dynamic types, and that it
isn't some irrational far fetched idea that is only limited to computer
scientists and researchers.
I can only hope that one day we will have higher-level languages that make
good sense both from a design perspective as well as a performance
perspective -- and as far as I've seen, we're certainly not there yet.
We're getting closer, but none of these languages are mainstream, and many
have relatively poor performance even though their designs are fully capable
of performing extremely well.
For me, the closest language today that meets my requirements and goals is
S#, and that is why I continue to experiment and develop with it. There are
certainly some other well thought out non-mainstream languages out there
that are worth looking into and experimenting with. Java? C++? Eiffel?
Smalltalk? Lisp? Perl? PHP? Surely lets hope none of these is the future
language 20 years from now.
Ian
Thomas G. Marshall
In arbitrary dynamic language hooblyhoo, (from the ansi-hooblyhoo spec) :) :
object1, has method() in it
unrelated object2, has method() in it.
elsewhere some function defined as
function(thing)
{
thing.method();
}
function(object1); // works
function(object2); // works
Berislav Lopac
That is correct. However, in Real Life (TM again :) ) the preference turns
from efficient code (as we had a drastic increase in computer power in past
decades) towards more efficient programming. Automated memory management
helps the latter immensely.
Manual memory management, and thus static typing, might still be quite
viable for the emerging mobile and other dedicated devices, but they are
often highly specialized, and (as someone said) just like with automatic
gear switching in cars, there is very few cases where manual memory
management can be much better than good automated MM.
Berislav Lopac
>> strings and especially numbers. The main reason to have static typing
>> here is to track memory use, and when a language has some kind of
>> automated memory management this takes care of itself.
>>
>> When it comes to objects, static typing is Good(TM), because usually
>> we need a specific class (or superclass, or interface) to be passed
>> around, and by static typing we can ensure that the correct class is
>> passed through instead of checking all possible classes. So the wrong
>> class is cought when passed, and not when we try to do something with
>> it, when it might be too late. Even PHP, which has the most thorough
>> dynamic typing I have seen, has included 'class hints' in its latest
>> incarnation to help you ensure that only the right class(es) are
>> passed into a function.
>
> And what of the polymorphism /without/ inheritance? IYO, is that
> then /not/ an advantage that is worth it?
If, by that, you mean that unrelated (ie. from different inheritance trees)
classes have the same method calls, I would call that a bad design. That's
what interfaces were invented for.
Berislav Lopac
Very well. And why are early checks important?
Coming from the scripting languages background (Javascript, PHP) and having
experience with compiled ones (C, C++, Java) I have trouble finding an
inherent advantage in early checks.
Berislav Lopac
<snip>
> what I /really/ wanted:
>
> static typing---is it really a big advantage?
I think you already know the answer, or you wouldn't need to ask the
question. The answer is, simply: sometimes it is, sometimes it isn't. As
this discussion has proven.
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> On Wed, 7 Jul 2004 14:00:01 +0200, Berislav Lopac wrote:
>>
>>> Thomas G. Marshall wrote:
>>>> I'm a pundit of Java, and /was/ a huge advocate of statically typed
>>>> languages until it was made clear to me that perhaps the
>>>> compile-time type safety just doesn't deliver as much as statically
>>>> typed pundits (like me) think in terms of project completion and
>>>> maintainability. I fully expect to get drummed outta town on this.
>>>
>>> Let me be very brief in my take on this:
>>>
>>> Static typing is Bad(TM) when it comes to primitive data, like
>>> strings and especially numbers.
>>
>> Static typing is especially important when dealing with numbers.
>> Things like bounds checks, different number representation models,
>> different implementations of numeric operations: rounding, precision,
>> accuracy, exceptions etc, these are natively mapped to types and
>> subtypes. Those should checked at compile time.
>>
>>> The main reason to have static typing here is to track
>>> memory use,
>>
>> Static typing is used for early checks.
>>
>> It has nothing to do with static vs. dynamic memory allocation. That's
>> static vs. dynamic object scope.
>
> Very well. And why are early checks important?
To eliminate bugs before Mars probe is on the orbit...
> Coming from the scripting languages background (Javascript, PHP) and having
> experience with compiled ones (C, C++, Java) I have trouble finding an
> inherent advantage in early checks.
Then you probably should not make sweeping generalizations.
Ian Upright
>That is correct. However, in Real Life (TM again :) ) the preference turns
>from efficient code (as we had a drastic increase in computer power in past
>decades) towards more efficient programming. Automated memory management
>helps the latter immensely.
>
>Manual memory management, and thus static typing, might still be quite
>viable for the emerging mobile and other dedicated devices, but they are
>often highly specialized, and (as someone said) just like with automatic
>gear switching in cars, there is very few cases where manual memory
>management can be much better than good automated MM.
Just because you have static typing, by no means do you require manual
memory management. In fact, with some modern GC's, you could potentially
get even *more* efficiency than using manual memory managment, depending on
the application of course.
Ian
Andre Schnoor
like "compile time" in dynamic languages like Smalltalk. Compilation happens
instantly and incrementally *while* the software is already running (maybe
for hours). I can't imagine any kind of static checks that might work under
these circumstances.
Another thing is: Hey, the only thing we are talking about is wether to
check if the right arguments are passed to a method/function. So what? If
such a mistake was made by the developer, it will popup for sure within
minutes (because the argument doesn't respond appropriately to the
subsequent messages) and be fixed immediately.
I believe the fear of dynamic typing is a relic from the era where typing
errors forced you to reboot your machine.
Andre
Berislav Lopac
My point was that I am pretty well experienced with both types of languages,
and I still don't see the advantage of early checks and primitive data types
in particular.
For example, if you have a variable containing a number, why would I get a
compile error if I try to use a float instead of an integer? If I use a
wrong value, I would still get an error at runtime even if it is of correct
type; but the two types are the same as far as humans are concerned, and it
should be the same for my programs.
Not to mention the case (often on the Web) when you have a string that is
actually a number; why should I have to take care of the conversion when the
language can do that for me?
As I said above, I have found nothing in favor of using strong typing when
it comes to primitive data -- primarily strings and numbers. It is still
useful to be able to define the type of a value when we talk about classes
and objects, but primitives should better be handled either as "typeless"
(like in PHP) or as objects of their own (like in SmallTalk; Java originally
had, and still has, primitive types, but have since included wrapper objects
for them).
James Thorpe
trees)
> classes have the same method calls, I would call that a bad design. That's
> what interfaces were invented for.
>
I think you just validated the original post. Interfaces are a solution
required by statically typed languages to a problem created by statically
typed languages.
James
Dmitry A. Kazakov
> Concerning this disussion, one important fact is: There is no such thing
> like "compile time" in dynamic languages like Smalltalk. Compilation happens
> instantly and incrementally *while* the software is already running (maybe
> for hours). I can't imagine any kind of static checks that might work under
> these circumstances.
Firstly, why they should work under such circumstances? Secondly, you are
wrong. Back in late 70s, IBM PL/1 debugger was capable to recompile code on
the fly without stopping the program. PL/1 was definitely a statically
typed language.
> Another thing is: Hey, the only thing we are talking about is wether to
> check if the right arguments are passed to a method/function. So what? If
> such a mistake was made by the developer, it will popup for sure within
> minutes (because the argument doesn't respond appropriately to the
> subsequent messages) and be fixed immediately.
Provided that the program goes through all possible paths of the code in
some finite time ("within minutes"). Sounds much like a halting problem!
Yep, customers will be happy to get "message not understood" after 2-weeks
of a car mileage test, because someone has modified some parameter type in
the everlasting incremental compilation process.
> I believe the fear of dynamic typing is a relic from the era where typing
> errors forced you to reboot your machine.
This era will never end. Errors cost from 0 to human life.
Berislav Lopac
I disagree. The problem is created by object-oriented languages; without
interfaces, we would have to check an incoming object for all possible
superclasses and/or methods to see if it is the right type.
Consider PHP5, which is a dynamically typed language, but which introduces
both interfaces and class hints; if we try to pass an object which is of a
wrong parentage, we get an error. If the object implements the correct
interface, we will know all the methods it should implement.
As I said before, static typing is not a problem for objects, and indeed is
preferred sometimes; it is primitive types where static typing is at best
inconvenient and at worst downright harmful.
Dmitry A. Kazakov
> Dmitry A. Kazakov wrote:
>> On Thu, 8 Jul 2004 08:31:37 +0200, Berislav Lopac wrote:
>>
>>>> Static typing is used for early checks.
>>>>
>>>> It has nothing to do with static vs. dynamic memory allocation.
>>>> That's static vs. dynamic object scope.
>>>
>>> Very well. And why are early checks important?
>>
>> To eliminate bugs before Mars probe is on the orbit...
>>
>>> Coming from the scripting languages background (Javascript, PHP) and
>>> having experience with compiled ones (C, C++, Java) I have trouble
>>> finding an inherent advantage in early checks.
>>
>> Then you probably should not make sweeping generalizations.
>
> My point was that I am pretty well experienced with both types of languages,
> and I still don't see the advantage of early checks and primitive data types
> in particular.
>
> For example, if you have a variable containing a number, why would I get a
> compile error if I try to use a float instead of an integer?
Because either:
1. Float and Integer were chosen as the best mapping model numbers for the
given application domain. If that was intentionally made, then there is a
reason why they should not be mixed. BTW, in a good statically typed
language there is no Integer or Float, but Buffer_Index, Vehicle_Speed,
Annual_Income etc.
2. When that was just an arbitrary choice, then the program is a garbage,
which should be rewritten in the terms of the most general type applied to
the given domain.
> If I use a
> wrong value, I would still get an error at runtime even if it is of correct
> type; but the two types are the same as far as humans are concerned, and it
> should be the same for my programs.
See 1.
> Not to mention the case (often on the Web) when you have a string that is
> actually a number;
Yes, guess which number is "0377" (*)?
> why should I have to take care of the conversion when the
> language can do that for me?
Because, the conversion made might be far from what you expect. PL/1 was
famous for its conversions between each and other type. The problem was
that the results were so surprising that it became as an example of a bad
language design. There is no conversion suitable for any reasonable
percentage of cases.
But all this is not an issue. You can define conversions you need.
> As I said above, I have found nothing in favor of using strong typing when
> it comes to primitive data -- primarily strings and numbers. It is still
> useful to be able to define the type of a value when we talk about classes
> and objects, but primitives should better be handled either as "typeless"
> (like in PHP) or as objects of their own (like in SmallTalk; Java originally
> had, and still has, primitive types, but have since included wrapper objects
> for them).
There is no difference between types and what is usually called "classes".
Primitive types are "classes" programmed by somebody else. Don't need them,
write your own!
And again. Except for pure mathematical or symbolic analysis applications
there is no strings or numbers. There are types, different ones, for which
implementation this or that built-in type was selected. When static typing
is made consistently, one can get full advantage of it:
-- Ada 95
type Buffer_Index is mod 256;
type Age is range 1..120;
X : Buffer_Index := 1;
Y : Age := X; -- Compile error
Languages, which do not distinguish numeric type cannot be honestly called
typed.
----
* In C++ it is 255. The first '0' indicates octal base.
Cristiano Sadun
news:ccjbd8$rjd$1...@ls219.htnet.hr:
> For example, if you have a variable containing a number, why would I
> get a compile error if I try to use a float instead of an integer? If
> I use a wrong value, I would still get an error at runtime even if it
> is of correct type; but the two types are the same as far as humans
> are concerned, and it should be the same for my programs.
>
Sometimes the cost of getting an error at runtime are too high.
Suppose you're running on an airplane and suddendly its navigation system
crashes since a bug is caught at runtime and the system doesn't know what
to do with it.
What we want to do is to minimize the chance of this.
There are obviously several ways to try to: for example, if you could
*tell* your system what to do with it at runtime ("ignore and reset!";
"restart from there!", etc). This is obviously not possible since often
even the programmer(s) of the system could not find out, for example, the
correct restart point in a timely fashion (i.e. before the plane, too,
crashes in a much more physical way :). Much less the pilot.
If you have a oracle test suite, which can exercise your software in
every meaningful way in a reasonable time, then you could spot all the
runtime errors by just ..running the test suite. Basically, you perform
an exploration of the all the meaningful states of your system and their
transition, in the meanwhile catching all the errors, which then you fix.
Iterate until there aren't no more errors, and voila'.
Trouble is, the error space is *big*. Writing test suites like that is
tricky - at least, I don't think I'm good enough to do that for seriously
large or complex systems. (one way is the one advocated by XPers and
agiles in general - write *few* tests, have them fail, implement the
*few* functionalities necessary, have the test succeeed and proceed in
general by small little steps. Yet, I'm pretty sure some bug still can
pass thru the net if the system's complex enough or I'm tired enough: and
it takes just *one* runtime error to take that plane down)
By using static typing, you play defensively. You give more information
to the compiler, which is way better than me at *not* getting tired
checking it. At the same time, it plays dumb, it doesn't try to play
smart: every piece does one thing, and does it well. You do that in
*addition* to tests.
You still end up with a chance for a runtime error, no doubt. But since
you're doing all you were doing before, *plus* static typing, the chance
is smaller.
So long you don't use casts too much, obviously. ;-)
Andre Schnoor
> > check if the right arguments are passed to a method/function. So what?
If
> > such a mistake was made by the developer, it will popup for sure within
> > minutes (because the argument doesn't respond appropriately to the
> > subsequent messages) and be fixed immediately.
>
> Provided that the program goes through all possible paths of the code in
> some finite time ("within minutes"). Sounds much like a halting problem!
If your domain model is well done, you don't need this 100% mathematical
security. No need to deal with the halting problem or any other NP-hard
proof. Given a proper object encapsulation, there aren't that many possible
paths to a method in practical applications (just look for the senders).
That's mostly theory.
The real serious errors are not related to passing the wrong parameter type.
They are about buggy algorithms and misunderstood domain rules - high-level
semantic errors. Just checking the types at compile time is not at all a
reason to feel safe.
Andre
Rene de Visser
news:Xns95209701955B4cr...@130.133.1.4...
> "Berislav Lopac" <berisla...@dimedia.hr> wrote in
> news:ccjbd8$rjd$1...@ls219.htnet.hr:
>
> > For example, if you have a variable containing a number, why would I
> > get a compile error if I try to use a float instead of an integer? If
> > I use a wrong value, I would still get an error at runtime even if it
> > is of correct type; but the two types are the same as far as humans
> > are concerned, and it should be the same for my programs.
> >
>
> Sometimes the cost of getting an error at runtime are too high.
Then I wouldn't be relying on static typing.
I'd use ACL2 instead.
Naturally there still the problem of getting the spec correct. So you'll be
wanting to simulate all the important cases anyway to make sure that
they produce what you were expecting.
Rene.
James A. Robertson
<berisla...@dimedia.hr> wrote:
>James Thorpe wrote:
>>> If, by that, you mean that unrelated (ie. from different inheritance
>>> trees) classes have the same method calls, I would call that a bad
>>> design. That's what interfaces were invented for.
>>>
>>
>> I think you just validated the original post. Interfaces are a
>> solution required by statically typed languages to a problem created
>> by statically typed languages.
>
>I disagree. The problem is created by object-oriented languages; without
>interfaces, we would have to check an incoming object for all possible
>superclasses and/or methods to see if it is the right type.
>
Wow, somehow Smalltalk has managed for nearly 30 years without
interfaces, and without static typing. How was that possible?
>Consider PHP5, which is a dynamically typed language, but which introduces
>both interfaces and class hints; if we try to pass an object which is of a
>wrong parentage, we get an error. If the object implements the correct
>interface, we will know all the methods it should implement.
>
>As I said before, static typing is not a problem for objects, and indeed is
>preferred sometimes; it is primitive types where static typing is at best
>inconvenient and at worst downright harmful.
>
>Berislav
<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView
Cristiano Sadun
news:ccjhj0$b7q$1...@news1.wdf.sap-ag.de:
> Then I wouldn't be relying on static typing.
The point was, *also* on static typing.
>
> I'd use ACL2 instead.
Don't know it.
>
> Naturally there still the problem of getting the spec correct. So
> you'll be wanting to simulate all the important cases anyway to make
> sure that they produce what you were expecting.
Yes. Incidentally, the risk of runtime exception cannot be reliably
nullified, but just made smaller.
Every tool that helps, I try and use. If I give the compiler as much
information as I (cheaply) can, it can tell me stuff that I would miss,
since a compiler's inifinitely more patient than I am.
Actually, both peer reviews, code inspection and extensive simulation
(which happens to be a looser form of testing) are part what it takes for
critical systems, but my was an example to emphatize the point.
Shayne Wissler
"Berislav Lopac" <berisla...@dimedia.hr> wrote in message
news:ccjbd8$rjd$1...@ls219.htnet.hr...
> > Then you probably should not make sweeping generalizations.
>
> My point was that I am pretty well experienced with both types of
languages,
> and I still don't see the advantage of early checks and primitive data
types
> in particular.
>
> For example, if you have a variable containing a number, why would I get a
> compile error if I try to use a float instead of an integer? If I use a
> wrong value, I would still get an error at runtime even if it is of
correct
> type; but the two types are the same as far as humans are concerned, and
it
> should be the same for my programs.
So often in this topic you see people confusing the idea of static languages
with the one they happen to be familiar with. So the concept of static
typing gets slammed over the fact that C++ has problems.
You're doing that here: if you wanted to be able to use any number as a
number, then Float and Int should be derived from Number, and you naturally
get that effect. (Additionally, you are wrong about the idea that Float and
Int are the same as far as humans are concerned. If they were the same to us
we wouldn't give them different names).
> Not to mention the case (often on the Web) when you have a string that is
> actually a number; why should I have to take care of the conversion when
the
> language can do that for me?
This is the same thing albeit in a more complex form (clearly we don't want
to derive Int from String, but there are other ways to deal with this in a
statically typed language).
Shayne Wissler
http://www.ouraysoftware.com
Dmitry A. Kazakov
>>> Another thing is: Hey, the only thing we are talking about is wether to
>>> check if the right arguments are passed to a method/function. So what?
> If
>>> such a mistake was made by the developer, it will popup for sure within
>>> minutes (because the argument doesn't respond appropriately to the
>>> subsequent messages) and be fixed immediately.
>>
>> Provided that the program goes through all possible paths of the code in
>> some finite time ("within minutes"). Sounds much like a halting problem!
>
> If your domain model is well done, you don't need this 100% mathematical
> security.
OK, let it be 50%. What does it mean, to have 50% security? That only 50%
of all paths need to be checked "within minutes"? That the probability of
program crash is 0.5? And finally, why any well done domain model should
ensure that x-level of security?
> No need to deal with the halting problem or any other NP-hard
> proof.
A proof is required to any answer given to the questions formulated by H.
S. Lahman in his post. Especially if the answer is "we need no checks,
because we can catch all that errors anyway". That is a bit too strong
statement, which needs some convincing grounds.
> Given a proper object encapsulation, there aren't that many possible
> paths to a method in practical applications (just look for the senders).
> That's mostly theory.
>
> The real serious errors are not related to passing the wrong parameter type.
> They are about buggy algorithms and misunderstood domain rules - high-level
> semantic errors. Just checking the types at compile time is not at all a
> reason to feel safe.
Not just type checking, but, as others have already pointed out, expressing
a part of semantics in terms of type relations. When types are accepted for
this purpose, and it would be silly to argue for a typeless system, then
the question arise, how to deal with this second class objects: types. So
to check whether a value has some type is only beginning of the story. It
is necessary to ease that check (by making a part of type information
static) to have higher levels checks.
Shayne Wissler
"James A. Robertson" <jar...@gosmalltalk.com> wrote in message
news:m3kqe0106okiouhl7...@4ax.com...
> >I disagree. The problem is created by object-oriented languages; without
> >interfaces, we would have to check an incoming object for all possible
> >superclasses and/or methods to see if it is the right type.
> >
>
> Wow, somehow Smalltalk has managed for nearly 30 years without
> interfaces, and without static typing. How was that possible?
Yes, it is amazing what people will put up with.
Shayne Wissler
http://www.ouraysoftware.com
Cristiano Sadun
> Wow, somehow Smalltalk has managed for nearly 30 years without
> interfaces, and without static typing. How was that possible?
Well, afaik Smalltalk isn't exactly the poster boy for a mainstream and
widely used programming language. Not a-la COBOL, C, C++, Java, VB etc, at
any rate (for smalltalk fans, this is not an observation of value, just an
observation of state).
So how it has managed or not isn't, at best, of great importance.
Thomas G. Marshall
> <snip>
>> what I /really/ wanted:
>>
>> static typing---is it really a big advantage?
>
> I think you already know the answer, or you wouldn't need to ask the
> question. The answer is, simply: sometimes it is, sometimes it isn't.
> As this discussion has proven.
Saying /sometimes/ is to invalidate the notion that static typing is
/always/ an advantage. Which validates my original point entirely.
Thomas G. Marshall
> On Thu, 8 Jul 2004 11:24:13 +0200, Andre Schnoor wrote:
...[rip]...
>> I believe the fear of dynamic typing is a relic from the era where
>> typing errors forced you to reboot your machine.
>
> This era will never end. Errors cost from 0 to human life.
But the likelihood is certainly not evenly distributed between those two
extremes.
I think that André has hit an interesting view point that hovers over this
entire discussion. Perhaps much of the love of type-safety is spurred on by
the days when disaster (complete system failure?) was more likely on the
horizon.
Thomas G. Marshall
And the question that is somehow lost again is /at what cost/ ?
Establishing a tightly typed hierarchy is time consuming, not a 0-seconds
endeavor.
Thomas G. Marshall
>> "Berislav Lopac" <berisla...@dimedia.hr> writes:
>>
>>> Thomas G. Marshall wrote:
>>>> I'm a pundit of Java, and /was/ a huge advocate of statically typed
>>>> languages until it was made clear to me that perhaps the
>>>> compile-time type safety just doesn't deliver as much as statically
>>>> typed pundits (like me) think in terms of project completion and
>>>> maintainability. I fully expect to get drummed outta town on this.
>>>
>>> Let me be very brief in my take on this:
>>>
>>> Static typing is Bad(TM) when it comes to primitive data, like
>>> strings and especially numbers. The main reason to have static
>>> typing here is to track memory use, and when a language has some
>>> kind of automated memory management this takes care of itself.
>>
>> I disagree. Static typing information also lets the compiler
>> generate much more efficient code.
>
> That is correct. However, in Real Life (TM again :) ) the preference
> turns from efficient code (as we had a drastic increase in computer
> power in past decades) towards more efficient programming. Automated
> memory management helps the latter immensely.
>
> Manual memory management, and thus static typing,
Are these orthogonal? I don't understand the causality in
either direction, mm .: st, or st .: mm.
Thomas G. Marshall
Java /ALWAYS/ had wrapper objects for them, and with 1.5 has established a
way to auto-convert between them.
>
> Berislav
Ian Upright
>Concerning this disussion, one important fact is: There is no such thing
>like "compile time" in dynamic languages like Smalltalk. Compilation happens
>instantly and incrementally *while* the software is already running (maybe
>for hours). I can't imagine any kind of static checks that might work under
>these circumstances.
You're absolutely wrong. S# is a superset of Smalltalk, and for example, if
you had a message signature of:
myFunction: <Integer> anInteger someThing: <Foo> aFoo
now at runtime you add/compile the method:
myFunction: <Float> anInteger someThing: <Foo> aFoo
and then remove the method :
myFunction: <Integer> anInteger someThing: <Foo> aFoo
There you go, you've just updated the static types of a method, in an
incrementally compiled Smalltalk.
In theroy, you could further spin off a statically compiled verifier, which
could go through a bunch of modified and dependant code and check it for
type integrity. At this point, after the integrity checks are made, it
could log it and/or notify the developer in some way if it fails, and it
could mark the methods in place as being certified static, and then the
jitter could potentially regenerate more optimial static code. If it hit
the new code before all that happened, it could throw exceptions in the case
where it fails.
I can have my cake and eat it too!
S# doesn't do this yet, nor does any language that works like this as far as
I'm aware, but I think it is entirely possible (and reasonable) to do so.
Ian
>Another thing is: Hey, the only thing we are talking about is wether to
>check if the right arguments are passed to a method/function. So what? If
>such a mistake was made by the developer, it will popup for sure within
>minutes (because the argument doesn't respond appropriately to the
>subsequent messages) and be fixed immediately.
>
>I believe the fear of dynamic typing is a relic from the era where typing
>errors forced you to reboot your machine.
>
>Andre
Thomas G. Marshall
following:
...[argument already understood thwacked]...
> By using static typing, you play defensively. You give more
> information to the compiler, which is way better than me at *not*
> getting tired checking it. At the same time, it plays dumb, it
> doesn't try to play smart: every piece does one thing, and does it
> well. You do that in *addition* to tests.
>
> You still end up with a chance for a runtime error, no doubt. But
> since you're doing all you were doing before, *plus* static typing,
> the chance is smaller.
The question arises /at what cost/ ? Refer back to my D1 D2 ponderings
upthread.
The supporters of dynamic casting here seem to fall into two camps:
Static typing can be valuable, but just isn't
worth the energy expenditure.
As well as
Static typing is inferior
IMO, most are in the former camp, BICBW.
>
> So long you don't use casts too much, obviously. ;-)
I don't anyone is arguing with you there. :)
Andre Schnoor
> > security.
>
> OK, let it be 50%. What does it mean, to have 50% security? That only 50%
> of all paths need to be checked "within minutes"? That the probability of
> program crash is 0.5? And finally, why any well done domain model should
> ensure that x-level of security?
Objects tend to be either generic (abstract algorithms, generic data
structures) or very domain specific. In the first case static typing renders
the objects nearly unsusable (as in Java), simply because what is intended
to be generic actually is not. In the second case, only a very narrow
selection of client objects communicate with each other (that is, the number
of potential peers is small). Therefore not having 100% security means you
get something around 99% security.
I agree that talking about % in this context is nonsense. What I mean is:
The chance to find fatal errors very quickly is extremely high. The better
your domain model, the smaller and better manageable your peer-to-peer
communication gets.
I experienced that in static languages domain models don't get worked out to
the level they should, simply because refactoring is such an annoying work
(due to static typing). I've seen a lot of verbosely coded Java classes with
a certain hard-wired feel of "safety" and correctness. However, this does
say nothing about hidden errors that come beyond the first compile.
Andre
Universe
<tgm2tothe...@replacetextwithnumber.hotmail.com> wrote:
> Isaac Gouy <ig...@yahoo.com> coughed up the following:
> > "Thomas G. Marshall"
> > <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote in
> > message news:<uoXGc.36360$MT5....@nwrdny01.gnilink.net>...
> >
> > -snip-
> >> Ah. I was hoping this to /not/ be a debate over which was better
> >> per se,
> >> but a debate over whether or not static typing gives you all that its
> >> purported to.
> >
> > Depends on what benefits you chose to imagine are claimed for static
> > checking.
> >
> > And how do /you/ define polymorphism without inheritance? (Got a code
> > example?)
>
>
> In arbitrary dynamic language hooblyhoo, (from the ansi-hooblyhoo spec) :) :
>
> object1, has method() in it
>
> unrelated object2, has method() in it.
>
> elsewhere some function defined as
>
> function(thing)
> {
> thing.method();
> }
>
> function(object1); // works
> function(object2); // works
Right. Polymorphism may be implemented via *delegation* -
aggregation, composition.
Delegation aggregates together, or composes together in one or more
code modules other relevant polymorphic code modules that perform role
behavior variations on a single theme.
Many tests and studies have shown that delegation can carry out the
same polymorphism as inheritance. Often delegation is a better
solution for various reasons. However in general delegation tends to
require more spatial and temporal resources than inheritance.
Elliott
--
OO FUNDAMENTALLY means using objects and the collaboration between
them as the primary kernel to:
1) conceptually understand and
2) to represent role responsible entities, forces, processes,
flows in a context.
I.e using objects and their collaboration as the primary modelling
construct
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Universe
> ... Ideally we wouldn't be talking about dynamic vs. static; we'd have
> a language that gave us the best of both.
Ahh Hemmm! C++
C++ does well for both imo. Still of course the dynamic<=>static
dialectic is not the only category of judgment/evaluation when
deciding what language to use where in a project.
Elliott
--
Science is about explaining the absolute OBJECTIVE
facts of each, or sets of, relative situational
context (the subjective).
H. S. Lahman
> Ah. I was hoping this to /not/ be a debate over which was better per se,
> but a debate over whether or not static typing gives you all that its
> purported to.
>
> Is there a difference? I think so, but if you don't, that's also fine by
> me.
Having spent a couple of decades in the electronics test business, I am
somewhat biased in that I see a big plus on the test side. IMO static
type checking does provide a major benefit that is very consistent with
fundamental test principles that go well beyond just software development.
The problem is that the practical value of the benefit is relative to
dynamic type checking and there is insufficient data to determine that
comparison.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH
H. S. Lahman
> Static typing doesn't "solve" anything, it merely enforces constraints that
> developers put upon themselves. In most statically typed languages, they go
> so far as forcing you to always have constraints, and these aren't something
> that can be optional. You can't say, gee, for this part of the library,
> it'd be really nice to have a constraint here. You are simply forced to
> have constraints everywhere. This is highly restrictive.
The primary problem that static typing is solving is software testing.
A secondary problem that static typing is solving is OOPL performance.
A tertiary problem that static typing is solving is enforcing good
development practices on the developer.
Universe
> Robert C. Martin:
>>
>> Static typing comes at a cost. It increases coupling, and rigidity.
>> We accept this cost because of the safety. However, if our TDD tests
>> are already providing that safety, we may decide to reconsider the
>> cost.
>>
>> Statically formed types (of statically typed languages)
>> mostly solve problems created by statically formed
>> types to begin with.
> I'm a pundit of Java, and /was/ a huge advocate of statically typed
> languages until it was made clear to me that perhaps the compile-time type
> safety just doesn't deliver as much as statically typed pundits (like me)
> think in terms of project completion and maintainability. I fully expect to
> get drummed outta town on this.
When I examine an issue I *try* (:- ) to look at big picture,
including the *history* and *context* of not only the topic, but also
of the participants.
RCM's conversion to being more for dynamic vs. static typing coincides
with his and others formal consolidation of practicing and advocating
for *spontaneous coding evolved system design creation".
Concomitant with this "hardening of the "fly by the seat of one's
pants" has been their deprecation, prior to the bulk and heart
*production* coding, of commitment to at least even minimal overall
investigation of the domain and use cases and based upon that
formulation of at least a minimal overall design plan architecture
It's no accident, as I see things, that the same folk's reliance upon
and promulgation of dynamic type coding has risen to a crescendo in
direct proportion to the above mentioned happenings.
Elliott
--
We propose that those with limited knowledge in a domain
suffer a dual burden: Not only do they reach mistaken
conclusions and make regrettable errors, but their
incompetence robs them of the ability to realize it.
Ian Upright
>Responding to Upright...
>
>> Static typing doesn't "solve" anything, it merely enforces constraints that
>> developers put upon themselves. In most statically typed languages, they go
>> so far as forcing you to always have constraints, and these aren't something
>> that can be optional. You can't say, gee, for this part of the library,
>> it'd be really nice to have a constraint here. You are simply forced to
>> have constraints everywhere. This is highly restrictive.
>
>The primary problem that static typing is solving is software testing.
>
>A secondary problem that static typing is solving is OOPL performance.
>
>A tertiary problem that static typing is solving is enforcing good
>development practices on the developer.
Obviously spoken by someone who hasn't had 10+ years experience with dynamic
as well as static languages.
Ian
>*************
>There is nothing wrong with me that could
>not be cured by a capful of Drano.
>
>H. S. Lahman
>h...@pathfindermda.com
>Pathfinder Solutions -- Put MDA to Work
>http://www.pathfindermda.com
>(888)-OOA-PATH
Universe
> Responding to Marshall...
>
> > Ah. I was hoping this to /not/ be a debate over which was better per se,
> > but a debate over whether or not static typing gives you all that its
> > purported to.
> >
> > Is there a difference? I think so, but if you don't, that's also fine by
> > me.
>
> Having spent a couple of decades in the electronics test business, I am
> somewhat biased in that I see a big plus on the test side. IMO static
> type checking does provide a major benefit that is very consistent with
> fundamental test principles that go well beyond just software development.
>
> The problem is that the practical value of the benefit is relative to
> dynamic type checking and there is insufficient data to determine that
> comparison.
CONTEXT - time, space, money, goal, etc. etc - is key to which,
dynamic or static typing - is better when. Often in the SAME
project, i.e for the same system in various places.
Elliott
--
Genuine OO starts from OOA: competent scientifically objective
investigation of some domain that is relative to other domains. Thus
we have objective investigation of some subjective context.
"Subjective" meaning that each specific domain has its own parameters,
has its own basis for what is "true" (for what is objectively domain
significant) based upon its own domain particular aspirations,
perceptions, necessitations, conceptions, and often unique principles
of operation.
So both opposites: the objective (the actual, the facts), as well as
the subjective (domain particularity determining what is actual, what
is fact) must be studied and experimented with in order to 1)
comprehend and 2) appropriately manage domain affairs resulting from
the collaboration of role responsible domain entities - be they man,
beast, fowl, or inanimate.
Universe
> Responding to Upright...
>
> > Static typing doesn't "solve" anything, it merely enforces constraints that
> > developers put upon themselves. In most statically typed languages, they go
> > so far as forcing you to always have constraints, and these aren't something
> > that can be optional. You can't say, gee, for this part of the library,
> > it'd be really nice to have a constraint here. You are simply forced to
> > have constraints everywhere. This is highly restrictive.
>
> The primary problem that static typing is solving is software testing.
>
> A secondary problem that static typing is solving is OOPL performance.
>
> A tertiary problem that static typing is solving is enforcing good
> development practices on the developer.
Often, not always, general reliance on dynamic over static typing
facilitates hacking. This does not seem to be true historically for
the Smalltalk community.
Elliott
--
> I spy wrote:
> Any hierarchy that mimics the real world is going to have flaws b/c guess
> what the real world has "flaws" too. A few birds don't fly. A few mammals do
> lay eggs. A few products don't support a feature or two. I dont see that as
> a case for doing away with hierarchy. Heck even mathematics has "flaws" - I
> can divide any two Numbers except for zero.
David Simmons
news:tfqqe0ht4rjllrnr1...@4ax.com...
> "Andre Schnoor" <andre....@web.de> wrote:
>
> >Concerning this disussion, one important fact is: There is no such thing
> >like "compile time" in dynamic languages like Smalltalk. Compilation
happens
> >instantly and incrementally *while* the software is already running
(maybe
> >for hours). I can't imagine any kind of static checks that might work
under
> >these circumstances.
FYI,
Dynamic languages in jitted architectures absolutely have static checks just
like any other compiler system.
Dynamic languages within jitted architectures perform the same steps as a
"statically compiled langugage", they just require a more sophisticated
model that supports the ability to temporally shift the steps and makes use
of dynamic runtime and schema change feedback to peridocially re-analyze and
recompile code.
The AOS VM, used for S# performs the following phases:
1) Source translation to IL.
2) IL packaging into dynamically loadable/unloadable modules (which can be
pure memory constructs). At this point, pre-jitting and inline analysis
based on the known type/data-flow schema can be performed if appropriate for
performance, or cross jitting to another platform like .NET.
3) Module loading (or if already loaded, dynamic schema updates when
modified).
4) Method binding
5) Method jitting
6) Method invocation (possibly re-jitting trampolines or inlining)
At any point where schema changes are introduced global analysis is
performed and caches are examined for impact.
Based on cache analysis methods may be re-analyzed.
Based on re-analysis new shadow/inlining methods may internally generated.
Based on re-analysis existing or newly generated methods may be re-jitted
with new code that exploits information derived from analysis of code flow
and heuristic type information.
If you flatten the "temporal" aspects by viewing the system as if schema
changes will never occur, then you effectively have exactly the same
scenario as what happens in a "simpler" language which compiles exclusively
based on a static type declaration model.
What this means is that a dynamic language VM can make adaptive
optimizations based on runtime heuristics and platform/machine
characteristics which cannot be made by languages which statically generate
machine code at compile time.
As has been probably send a zillion times in posts over the years on this
topic, the ideal language execution model is one that supports the ability
to provide declarative type information but does not "ever" require it.
There are numerous subtle issues relating to whether type information is
"behavioral" or "structural". I.e., whether type is used to enforce binding
contracts versus exploiting knowledge of representation for machine code
optimization and boxing/unboxing.
S# and the VM it runs are architected to support modularized
dynamic/real-time schema changes, native pre-emptive threading and exception
handling, support optional typing, and handle numerous issues relating to
foreign-function calling and cross-language interop.
-- Dave S. [www.smallscript.org]
Randal L. Schwartz
Ian> Obviously spoken by someone who hasn't had 10+ years experience
Ian> with dynamic as well as static languages.
Precisely. I contend that static typing is neither necessary nor
sufficient.
You cannot capture the correlative nature of data with static typing.
For example, for month and day number, you can say month is 1..12 and
day is 1..31, but for some values of month, day is really 1..28 or
1..29 (further depending on year!). So that means you have to write
tests to ensure that the correlative data relations are not violated.
And once you're creating tests to test things like that, you didn't
need the "1..31" data type in the first place! You could simply have
said "int" or "anything that responds to < > and =", and it still
would have been tested.
Therefore, static typing is insufficent. And since you're writing
tests to verify what typing would tell you, static typing is also not
necessary!
Static typing is like putting training wheels on a motorcycle. Nice
for the beginner, definitely a useless gadget for the experienced
person.
I firmly believe that *dynamic* *strong* typing is the key. Perl has
it. Smalltalk has it. And people get lots of stuff done faster.
Just another guy who has been around Smalltalk since 1980,
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
niko...@random-state.net
> problems. Ideally we wouldn't be talking about dynamic vs. static; we'd have
> a language that gave us the best of both.
FWIW, Common Lisp does: declarations are optional, and even without them
most serious compilers do a great deal of type-inference for both safety
and performance, yet semantically CL is extremely dynamic, and types are
associated with values, not places.
Cheers,
-- Nikodemus
Isaac Gouy
So, ad hoc polymorphism.
void main(String[] args){
println( "my adhoc method call".function );
println( new Thread().function );
}
abstract interface AdHoc {
String adhoc();
}
<AdHoc T> String function(T obj){ return obj.adhoc; }
class java.lang.String implements AdHoc;
adhoc(String a){ return "String adhoc method"; }
class java.lang.Thread implements AdHoc;
adhoc(Thread a){ return "Thread adhoc method"; }
I:\Nice\Test>java -jar adhoc.jar
String adhoc method
Thread adhoc method
See "Using kinds to type partially-polymorphic methods"
http://www1.elsevier.com/gej-ng/31/29/23/132/23/25/75003.pdf
Shall we try a pure functional language?
(Note: "In a type class definition one gives a name to a set of
overloaded functions")
Start = function 5 +++ function [1,2,3]
function a = adhoc a
class adhoc a :: a -> String
instance adhoc Int
where adhoc a = "Int overloaded function \n"
instance adhoc [a]
where adhoc a = "List overloaded function \n"
I:\Clean\Test>adhoc
Int overloaded function
List overloaded function
James A. Robertson
High productivity and fewer bugs is hard to tolerate, I'll admit...
>
>Shayne Wissler
>http://www.ouraysoftware.com
>
>
<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView
David Simmons
news:6RcHc.43384$a24.10448@attbi_s03...
It is amazing that people will put up with "interfaces", such as those in
Java, as a "requirement" to have to write a lot of redundant code that is
contractually untypesafe.
It is amazing that people will put up the design problems engendered by
brittle sealed/final semantics that only help the VM implementation of poor
language designs, at the expense of good design, architecture, and reuse
patterns.
Now, if some of these "required type declaration, statically compiled"
languages had interfaces that were truly mixins that provided
macro/implementation capability then we would actually see some benficial
productivity and re-use.
Now if some of these languages could actually handle real-time dynamic
schema changes, or provide generics without imposing godawful developer
declaration semantics then we would be on the right page...
-- Dave S. [www.smallscript.org]
>
>
> Shayne Wissler
> http://www.ouraysoftware.com
>
>
>
Costin Cozianu
>>
>>-snip-
>>
>>>Ah. I was hoping this to /not/ be a debate over which was better
>>>per se,
>>>but a debate over whether or not static typing gives you all that its
>>>purported to.
>>
>>checking.
>>
>>And how do /you/ define polymorphism without inheritance? (Got a code
>>example?)
>
>
>
> In arbitrary dynamic language hooblyhoo, (from the ansi-hooblyhoo spec) :) :
>
> object1, has method() in it
>
> unrelated object2, has method() in it.
>
> elsewhere some function defined as
>
> function(thing)
> {
> thing.method();
> }
>
> function(object1); // works
> function(object2); // works
>
>
>
Guess what: you get your example for free in OCAML, and it is statically
typed.
Not that the static typing of languages such as Java was really staying
in our way by preventing idioms like the above and all the other
programming problems were solved. We stumbled on this BIIIIG one, didn't
we ?
Should we quantify how long it would take us to declare an interface and
have the classes of o1 and o2 implement it ? Maybe 1 or 2 minutes.
Oh, well, those damn static tyopes really hurt our productivity. Gee.
All these arguments about static types hurting productivity are mostly
handwaving, or subjective experience of people here and there
*prematurely generalized*.
It is as if you talk yourself into having an allergy towards type
declaration, than of course you're gonna whine about type declarations
and, "surprise", you're gonna be slow in languages like Java.
But on the other hand if you take an objectiove and relaxed approach, it
doesn't really matter. Just study the sources of Oberon operating
system. Niklaus Wirth not only forces you to declare types, but also
forces you to declare all variables at the beginning of the block. Still
he and his collaborators are able to write beautiful software no problem.
There are tons of software masterpieces written in statically typed
languages that empirically *disprove* the (handwaving-based) claim that
static typing is a handicap. Also the practical experience with
challenges like ICFP contest is another empirical data point disproving
such theories.
I'll let you find the explanation for empirical data and draw the
conclusions.
Shayne Wissler
"David Simmons" <david....@smallscript.com> wrote in message
news:10er2u5...@corp.supernews.com...
> Now if some of these languages could actually handle real-time dynamic
> schema changes, or provide generics without imposing godawful developer
> declaration semantics then we would be on the right page...
If you heard me advocating one of those languagesyou mention as the right
alternative then you might have a point.
Shayne Wissler
http://www.ouraysoftware.com
Thomas G. Marshall
> "Shayne Wissler" <thalesN...@yahoo.com> wrote in message
> news:6RcHc.43384$a24.10448@attbi_s03...
>>
>> "James A. Robertson" <jar...@gosmalltalk.com> wrote in message
>> news:m3kqe0106okiouhl7...@4ax.com...
>>
>>>> I disagree. The problem is created by object-oriented languages;
>>>> without interfaces, we would have to check an incoming object for
>>>> all possible superclasses and/or methods to see if it is the right
>>>> type.
>>>>
>>>
>>> Wow, somehow Smalltalk has managed for nearly 30 years without
>>> interfaces, and without static typing. How was that possible?
>>
>> Yes, it is amazing what people will put up with.
>
> It is amazing that people will put up with "interfaces", such as
> those in Java, as a "requirement" to have to write a lot of redundant
> code that is contractually untypesafe.
>
> It is amazing that people will put up the design problems engendered
> by brittle sealed/final semantics that only help the
I'm with you, but what's this phrase mean?:
> VM implementation of poor language designs,
> at the expense of good
> design, architecture, and reuse patterns.
>
> Now, if some of these "required type declaration, statically compiled"
> languages had interfaces that were truly mixins that provided
> macro/implementation capability then we would actually see some
> benficial productivity and re-use.
>
> Now if some of these languages could actually handle real-time dynamic
> schema changes, or provide generics without imposing godawful
> developer declaration semantics then we would be on the right page...
Java's (and c++'s) <> syntax is horrible.
Java should have chosen the "of" keyword instead and say @#$%-off to all the
old code using "of" as an identifier. (I'm serious):
List of String list = new ArrayList();
list.add("hello");
(list instanceof List) // true
(list instanceof List of String) // true
(list instanceof List of Thing) // false
etc.
Thomas G. Marshall
>>>>>> "Ian" == Ian Upright <ian-...@upright.net> writes:
>
> Ian> Obviously spoken by someone who hasn't had 10+ years experience
> Ian> with dynamic as well as static languages.
>
> Precisely. I contend that static typing is neither necessary nor
> sufficient.
>
> You cannot capture the correlative nature of data with static typing.
>
> For example, for month and day number, you can say month is 1..12 and
> day is 1..31, but for some values of month, day is really 1..28 or
> 1..29 (further depending on year!). So that means you have to write
> tests to ensure that the correlative data relations are not violated.
>
> And once you're creating tests to test things like that, you didn't
> need the "1..31" data type in the first place! You could simply have
> said "int" or "anything that responds to < > and =", and it still
> would have been tested.
>
> Therefore, static typing is insufficent. And since you're writing
> tests to verify what typing would tell you, static typing is also not
> necessary!
>
> Static typing is like putting training wheels on a motorcycle. Nice
> for the beginner, definitely a useless gadget for the experienced
> person.
>
> I firmly believe that *dynamic* *strong* typing is the key. Perl has
> it. Smalltalk has it. And people get lots of stuff done faster.
>
> Just another guy who has been around Smalltalk since 1980,
What would you say were the most dramatic changes in smalltalk from then til
now?
Thomas G. Marshall
1 or 2 minutes for such an incredibly simple example that took me less than
a minute to clack out in the first place???? That seems like a nontrivial
impact to me...
Costin Cozianu
>>Should we quantify how long it would take us to declare an interface
>>and
>>have the classes of o1 and o2 implement it ? Maybe 1 or 2 minutes.
>>
>>Oh, well, those damn static tyopes really hurt our productivity. Gee.
>
>
> 1 or 2 minutes for such an incredibly simple example that took me less than
> a minute to clack out in the first place???? That seems like a nontrivial
> impact to me...
>
>
Well, of course you're absolutely objective and you are not inflating a
non-existent problem, or are you ?
I'm sure that if you program in Java you must face hundreds such tasks
each day ...
Christopher Barber
> Concerning this disussion, one important fact is: There is no such thing
> like "compile time" in dynamic languages like Smalltalk. Compilation happens
> instantly and incrementally *while* the software is already running (maybe
> for hours). I can't imagine any kind of static checks that might work under
> these circumstances.
Why not? Whenever you are compiling, whether while running the program or
not, you can perform static type checks.
Isaac Gouy
-snip-
> Suppose you're running on an airplane and suddendly its navigation system
> crashes since a bug is caught at runtime and the system doesn't know what
> to do with it.
>
> What we want to do is to minimize the chance of this.
>
> There are obviously several ways to try to: for example, if you could
> *tell* your system what to do with it at runtime ("ignore and reset!";
> "restart from there!", etc). This is obviously not possible since often
> even the programmer(s) of the system could not find out, for example, the
> correct restart point in a timely fashion (i.e. before the plane, too,
> crashes in a much more physical way :). Much less the pilot.
-snip-
After a quick look at Erlang, we might think their successful approach
to high reliability teleco software really could be described as 'log
and reset'.
See: http://www.artima.com/forums/flat.jsp?forum=226&thread=37878
Thomas G. Marshall
> <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote in
> message news:<Tb5Hc.10324$Xb4....@nwrdny02.gnilink.net>...
>
> So, ad hoc polymorphism.
>
> void main(String[] args){
> println( "my adhoc method call".function );
> println( new Thread().function );
> }
>
> abstract interface AdHoc {
> String adhoc();
> }
>
> <AdHoc T> String function(T obj){ return obj.adhoc; }
>
> class java.lang.String implements AdHoc;
> adhoc(String a){ return "String adhoc method"; }
>
> class java.lang.Thread implements AdHoc;
> adhoc(Thread a){ return "Thread adhoc method"; }
This /still/ uses an interface to get around the inheritance issue. That's
precisely the point.
In a dynamic language, there is nothing tying the two together for poly-m to
work.
J�rn W. Janneck
> Berislav Lopac <berisla...@dimedia.hr> coughed up the following:
>> Thomas G. Marshall wrote:
>> <snip>
>>> what I /really/ wanted:
>>>
>>> static typing---is it really a big advantage?
>>
>> I think you already know the answer, or you wouldn't need to ask the
>> question. The answer is, simply: sometimes it is, sometimes it isn't.
>> As this discussion has proven.
>
> Saying /sometimes/ is to invalidate the notion that static typing is
> /always/ an advantage. Which validates my original point entirely.
i wanted to stay out of this, but i need to ask:
apart from someone interested in setting up strawmen, who in your experience
has *ever* seriously claimed that static typing is *always* (i.e. at every
point in time, for every kind of code and application, under any
circumstance) an advantage? this must be someone who believes in statically
typed command-line interpreters and scripting languages, wants to statically
type postscript, believes latex would be better if it had static types,
likewise for sed, awk, and whatnot.
mind you, i am not saying that such a person cannot or does not exist, but
if i take your remark seriously, it would seem that you encounter this type
of person with sufficient regularity, and take their view on the matter
sufficiently seriously, to make you want to discuss that issue here. is that
really the case?
i mean, is this not like starting a thread with the goal of confirming that
the earth is not flat, after all?
-- j
JXStern
<h.la...@verizon.net> wrote:
>I also find this a bit facile. There is no question that static typing
>places constraints on the software construction that can be annoying to
>the developer. But I see that as a different issue than the problems
>static typing solves.
Yah.
Though it sounds profound, I'm not so sure that static typing is very
good at solving the same problems that it causes. If it were, the
whole concept would have been refactored long ago.
There is a style or habit of using static typing with big, complex
hierarchies, which may be somewhat less common in dynamically types
systems. But this is just style, I think, and not necessary to either
side.
I suspect that many of the "problems" seen are problems of typed
systems in general, and that switching between dynamic and static just
moves the chairs around on the deck.
Yeah, this was all wildly general gobbledegook, but it would be a lot
of work to make it explicit, and I might just have to change my
position if I understood fully what I was saying anyway.
:)
No silver bullets,
J.
David Simmons
wrote in message news:dmhHc.9248$Al5....@nwrdny03.gnilink.net...
> David Simmons <david....@smallscript.com> coughed up the following:
> > "Shayne Wissler" <thalesN...@yahoo.com> wrote in message
> > news:6RcHc.43384$a24.10448@attbi_s03...
> >>
> >> "James A. Robertson" <jar...@gosmalltalk.com> wrote in message
> >> news:m3kqe0106okiouhl7...@4ax.com...
> >>
> >>>> I disagree. The problem is created by object-oriented languages;
> >>>> without interfaces, we would have to check an incoming object for
> >>>> all possible superclasses and/or methods to see if it is the right
> >>>> type.
> >>>>
> >>>
> >>> Wow, somehow Smalltalk has managed for nearly 30 years without
> >>> interfaces, and without static typing. How was that possible?
> >>
> >> Yes, it is amazing what people will put up with.
> >
> > It is amazing that people will put up with "interfaces", such as
> > those in Java, as a "requirement" to have to write a lot of redundant
> > code that is contractually untypesafe.
> >
> > It is amazing that people will put up the design problems engendered
> > by brittle sealed/final semantics that only help the
>
> I'm with you, but what's this phrase mean?:
> > VM implementation of poor language designs,
In my opinion, as a VM designer, there is no excuse for exploiting/requiring
final/sealed semantics to implement VM functionality and core library
services.
The general problem is that core libraries inevitably proffer classes that
one will want to extend in some fashion or another. When access priviledges
of any kind prevent this from being possible it can become very problematic
for making a proper design [there are similar issues for managing derived
generics and typed arrays].
I'll give some examples from .NET:
Let's say I have an editor control that I want to expose as a .NET UI
component. The proper base class is called
<System.Windows.Forms.TextBoxBase>. Unfortunately the class is marked as
scope "internal" to the .NET core-library. So instead I have to subclass one
of its subclasses called <TextBox>, I then have to effectively un-inherit
some innapropriate behavior. But since many operations are not "virtual" I
am stuck with a lot of workaround goop.
Let's say I want to extend the <System.Windows.Forms.ImageList> class to be
a bit more intelligent and allow me to access images by name, rather than
just by index. To do this (given a single inheritance model) I need to
subclass ImageList. A wrapper simply will not do, because many parts of the
system require an ImageList member not something that "conforms to ImageList
protocol". But ImageList cannot be extended because of final/sealed
semantics. So again, more screwy poor design practices are imposed on me by
the system.
As in,...
c:\documents and settings\david.simmons\my documents\visual studio
projects\a2_muse\a2_debugger\muse\shell\museimagelist.cs(8,15): error
CS0509: 'Muse.MuseImageList' : cannot inherit from sealed class
'System.Windows.Forms.ImageList'
-- Dave S. [www.smallscript.org]
J�rn W. Janneck
> Christopher Barber wrote:
[snip]
>> I disagree. Static typing information also lets the compiler generate
much
>> more efficient code.
>>
> So you're willing to exchange expressiveness for more efficient code?
When
> speed is an issue *today* this makes sense and the necessary speed for
*today*
> should be identified as a requirement. But if that is one of static
typing
> benefits it is a blatant premature optimization. You'll be maintaining
and
> extending the code the rest of your life while hardware continues to get
> faster. Hardware will be twice as fast and cheaper 18 months from now.
nonetheless, runtime efficiency is always going to be a competitive
advantage---especially as so much code these days is written for mobile
devices that run on batteries, where more efficiency not only translates
into more speed/smaller latency, but also fewer watts, and thus longer
battery life or alternatively fewer grams and smaller space.
providing lots of static information about a program allows tools not only
to check for errors modularly, but also to perform computation at compile
time that leads to optimizations that would otherwise be intractably hard or
impossible to do. it is no coincidence that hardware languages (where these
optimizations are absolutely essential) are sometimes fascistically
statically typed---synthesis tools need a lot of static information to
effectively reduce circuits as much as possible, and pointing to sinking
hardware cost or moore's law just does not cut it in that domain.
-- j
[snip]
Thomas Gagne
<snip>
>
>
> nonetheless, runtime efficiency is always going to be a competitive
> advantage---especially as so much code these days is written for mobile
> devices that run on batteries, where more efficiency not only translates
> into more speed/smaller latency, but also fewer watts, and thus longer
> battery life or alternatively fewer grams and smaller space.
If I were programming in that space, I'd write it in as dynamic and high-level
a language possible, implement it on virtual hardware, then use performance
histograms to optimize the CPU and/or memory hogs out of the system. I should
end-up with a working prototype and ultimately a production version before the
competition--assuming they're using a lower-level statically typed language.
I'll end-up with a system that's easier to maintain, and better positioned to
take advantage of newer mini-devices with more memory and cpu available to
them (which is inevitable). Only the parts that must be married to or
optimized for the hardware will need rewriting.
Not a bad place to be.
Thomas G. Marshall
> Thomas G. Marshall wrote:
>> Berislav Lopac <berisla...@dimedia.hr> coughed up the following:
>>> Thomas G. Marshall wrote:
>>> <snip>
>>>> what I /really/ wanted:
>>>>
>>>> static typing---is it really a big advantage?
>>>
>>> I think you already know the answer, or you wouldn't need to ask the
>>> question. The answer is, simply: sometimes it is, sometimes it
>>> isn't.
>>> As this discussion has proven.
>>
>> Saying /sometimes/ is to invalidate the notion that static typing is
>> /always/ an advantage. Which validates my original point entirely.
>
> i wanted to stay out of this, but i need to ask:
>
> apart from someone interested in setting up strawmen, who in your
> experience has *ever* seriously claimed that static typing is
> *always* (i.e. at every point in time, for every kind of code and
> application, under any circumstance) an advantage? this must be
> someone who believes in statically typed command-line interpreters
> and scripting languages, wants to statically type postscript,
> believes latex would be better if it had static types, likewise for
> sed, awk, and whatnot.
No. In the context of this discussion, it is merely someone who doesn't
understand why static type safety isn't always a win-win situation.
> mind you, i am not saying that such a person cannot or does not
> exist, but if i take your remark seriously,
Yes. Take my remark seriously.
> it would seem that you
> encounter this type of person with sufficient regularity,
Unwarranted extrapolation. First you've mischaracterized the type of person
into some kind of idiot. They're not. Secondly, they just don't understand
that the type safety gained by statically typed languages isn't without a
cost.
> and take
> their view on the matter sufficiently seriously, to make you want to
> discuss that issue here. is that really the case?
Your tone of incredulity is misplaced.
At the beginning of this thread (and further up the same thread in
c.programming, for it was going there for a while) there was considerable
resistance to the notion that perhaps static typing wasn't always superior
to dynamic. Go read it, you'll see what I'm talking about. That's why I
enlarged it from the comp.programming arena into c.o and c.l.s. I was
grossly outnumbered in c.p.
...[thwack]...
J�rn W. Janneck
so you are saying then that dynamically-typed languages dominate that space?
or that people who are proficient in the use of dynamically-typed languages
do not care for money, since they clearly eschew the billions of dollars
that they could make by moving as predators into this market, eating their
statically-typed competitors' lunch?
because if what you say is true, it can only by either of these two, right?
and why do i need to rewrite part that need to be optimized? in fact, why
can i not just compile smalltalk to gates? i can compile vhdl, which, as you
know, has an elaborate static type system that does, indeed, occasionally
get in the way of expressing functionality. i am sure a smalltalk-to-gates
synthesis tool would easily upset the entire eda industry. why does it not
exist?
-- j
Thomas G. Marshall
>>> Should we quantify how long it would take us to declare an interface
>>> and
>>> have the classes of o1 and o2 implement it ? Maybe 1 or 2 minutes.
>>>
>>> Oh, well, those damn static tyopes really hurt our productivity.
>>> Gee.
>>
>>
>> 1 or 2 minutes for such an incredibly simple example that took me
>> less than a minute to clack out in the first place???? That seems
>> like a nontrivial impact to me...
>>
>>
>
> Well, of course you're absolutely objective and you are not inflating
> a non-existent problem, or are you ?
You had a point that it would only take 1 or 2 minutes to convert the code
segment to interfaces. I'm merely pointing out that when it takes less than
a minute to type out in the first place, those 1 or 2 minutes extra are a
big percentage.
Imagine how long it would take to Java-ise a larger code example.
> I'm sure that if you program in Java you must face hundreds such tasks
> each day ...
And all java programmers, at least the ones with experience, have been
coding such type organizations nearly non-stop. The point remains that it
isn't without cost.
J�rn W. Janneck
> Jörn W. Janneck <jwjanneck at yahoo dot com> coughed up the following:
>> Thomas G. Marshall wrote:
>>> Saying /sometimes/ is to invalidate the notion that static typing is
>>> /always/ an advantage. Which validates my original point entirely.
>>
>> i wanted to stay out of this, but i need to ask:
>>
>> apart from someone interested in setting up strawmen, who in your
>> experience has *ever* seriously claimed that static typing is
>> *always* (i.e. at every point in time, for every kind of code and
>> application, under any circumstance) an advantage? this must be
>> someone who believes in statically typed command-line interpreters
>> and scripting languages, wants to statically type postscript,
>> believes latex would be better if it had static types, likewise for
>> sed, awk, and whatnot.
>
> No. In the context of this discussion, it is merely someone who doesn't
> understand why static type safety isn't always a win-win situation.
but is this not what i said?
>> mind you, i am not saying that such a person cannot or does not
>> exist, but if i take your remark seriously,
>
> Yes. Take my remark seriously.
i try, really.
>> it would seem that you
>> encounter this type of person with sufficient regularity,
>
> Unwarranted extrapolation. First you've mischaracterized the type of
person
> into some kind of idiot. They're not.
well, "idiot" is a very strong word, but such a person would clearly be
oblivious to essentially everything to do with computers, so why would their
view on a particular typing discipline be of any consequence?
> Secondly, they just don't understand
> that the type safety gained by statically typed languages isn't without a
> cost.
if that were so, they would have to think that *every* algorithmic language
in existence would better be statically typed. since there are numerous
languages that are not (postscript, tex, scripting languages, awk, sed,
...), it would seem that such a person would have to hold the opinion that
they'd better be statically typed---which for some reason you explicitly
denied above.
this seems to be basic logic. what am i missing?
>> and take
>> their view on the matter sufficiently seriously, to make you want to
>> discuss that issue here. is that really the case?
>
> Your tone of incredulity is misplaced.
since i *am* incredulous, it would seem that it isn't.
i do not believe that you will find many serious people who would subscribe
literally to what you said above. those that do either do not know what they
are talking about, or what you are talking about. which leaves us with the
following options:
(a) you worry about the opinions of fools
(b) you get worked up about a misunderstanding
(c) you put up a strawman
i think the smart money is divided between (b) and (c).
> At the beginning of this thread (and further up the same thread in
> c.programming, for it was going there for a while) there was considerable
> resistance to the notion that perhaps static typing wasn't always superior
> to dynamic. Go read it, you'll see what I'm talking about. That's why I
> enlarged it from the comp.programming arena into c.o and c.l.s. I was
> grossly outnumbered in c.p.
without going back to the specific thread you mentioned, my experience with
these discussions is that people usually enter them with a number of
implicit assumptions, which they are either unaware of, or which they do not
bother to make explicit for any number of reasons.
in the scope where i believe reasonable views are to be found, objective
data to decide the issue in question for any specific case is hard to come
by, and what counts are preferences and, ultimately, success. what else
could there be?
-- j
Thomas Gagne
<snip>
>
>
> or that people who are proficient in the use of dynamically-typed languages
> do not care for money, since they clearly eschew the billions of dollars
> that they could make by moving as predators into this market, eating their
> statically-typed competitors' lunch?
>
> because if what you say is true, it can only by either of these two, right?
>
> and why do i need to rewrite part that need to be optimized? in fact, why
> can i not just compile smalltalk to gates? i can compile vhdl, which, as you
> know, has an elaborate static type system that does, indeed, occasionally
> get in the way of expressing functionality. i am sure a smalltalk-to-gates
> synthesis tool would easily upset the entire eda industry. why does it not
> exist?
>
Heck, usually I'm the one accused of histrionics. Who's to say I'm not
already in a place where I'm competing against those languages? I can't be
everywhere at once, try as I may. I need Hermione's time-turner.
Lower-level and statically-typed languages have a use, and I use them when
appropriate. The question at hand, I thought, is when is it appropriate? As
has been suggested by other posts that one language might be able to it all
doesn't strike me as plausible. C++ already tries to do that and is
too-complex (IMO) as a result. The older it gets and the more things added to
it (as is happening to Java) the more difficult it becomes to master. Better
to use multiple languages suited to their purpose than one that risks being a
master at none.
Costin Cozianu
> Costin Cozianu <c_co...@hotmail.com> coughed up the following:
>
>>Thomas G. Marshall wrote:
>>
>>>>Should we quantify how long it would take us to declare an interface
>>>>and
>>>>have the classes of o1 and o2 implement it ? Maybe 1 or 2 minutes.
>>>>
>>>>Oh, well, those damn static tyopes really hurt our productivity.
>>>>Gee.
>>>
>>>
>>>1 or 2 minutes for such an incredibly simple example that took me
>>>less than a minute to clack out in the first place???? That seems
>>>like a nontrivial impact to me...
>>>
>>>
>>
>>Well, of course you're absolutely objective and you are not inflating
>>a non-existent problem, or are you ?
>
>
>
> You had a point that it would only take 1 or 2 minutes to convert the code
> segment to interfaces. I'm merely pointing out that when it takes less than
> a minute to type out in the first place, those 1 or 2 minutes extra are a
> big percentage.
>
> Imagine how long it would take to Java-ise a larger code example.
>
>
Imagine that. I do for some years already. I've seen other people do it.
I've studied other how other people did it in languages as "bad" as
Pascal where you do have to declare all your variable at the beginning
of the block. Oh, never mind I've programmed a commercial program in
Pascal myself.
Let me tell you some hard learnt lesson: the difference between a good
programmer and a bad programmer *is not* that one programs in Pascal and
the other programs in Lisp.
If folks feel constrained that they program in Java, let me tell you
that they have bigger constraints to worry about, work on, and improve.
Static typing, it ain't that.
It's not the static typing that's staying in your way to reach
programming nirvana.
>
>>I'm sure that if you program in Java you must face hundreds such tasks
>>each day ...
>
>
> And all java programmers, at least the ones with experience, have been
> coding such type organizations nearly non-stop. The point remains that it
> isn't without cost.
>
>
Sure. It may have a devastating cost, a significant cost, or a
negligeable cost. But it does have a cost. And it has some benefits as well.
Some people want to hand wave their argumentation into convincing
everyone that the benefits are negligeable and the costs are
devastating. Unfortunately, there's no empirical data to sustain such
theory. Oh, well.
Cheers,
Costin
Berislav Lopac
> Ideally we wouldn't be
> talking about dynamic vs. static; we'd have a language that gave us
> the best of both.
PHP5. Everything is dynamic, but one can use class hints when passing
objects to functions/methods.
Of course, it's still a matter of debate what could be considered "best" of
either.
Berislav
--
If the Internet is a Marx Brothers movie, and Web, e-mail, and IRC are
Groucho, Chico, and Harpo, then Usenet is Zeppo.
Berislav Lopac
> On Thu, 8 Jul 2004 14:26:53 +0200, "Berislav Lopac"
> <berisla...@dimedia.hr> wrote:
>
>> James Thorpe wrote:
>>>> If, by that, you mean that unrelated (ie. from different
>>>> inheritance trees) classes have the same method calls, I would
>>>> call that a bad design. That's what interfaces were invented for.
>>>>
>>>
>>> I think you just validated the original post. Interfaces are a
>>> solution required by statically typed languages to a problem created
>>> by statically typed languages.
>>
>> I disagree. The problem is created by object-oriented languages;
>> without interfaces, we would have to check an incoming object for
>> all possible superclasses and/or methods to see if it is the right
>> type.
>>
>
> Wow, somehow Smalltalk has managed for nearly 30 years without
> interfaces, and without static typing. How was that possible?
Honestly, I have no idea, as I am not that familiar with Smalltalk. It
probably either has an internal mechanism that determines which methods an
incoming object might have and what to do when there is none you might use,
or the programmers write their own mechanisms each time, or something
completely different I am unable to imagine.
Can you tell me?
Peter Hermann
> Languages, which do not distinguish numeric type cannot be honestly called
> typed.
which is the major point of immaturity of Java, all C, Fortran, et. al. .
--
--Peter Hermann(49)0711-685-3611 fax3758 ica...@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)
Oliver Plohmann
> On Thu, 8 Jul 2004 11:24:13 +0200, Andre Schnoor wrote:
>
> > Concerning this disussion, one important fact is: There is no such thing
> > like "compile time" in dynamic languages like Smalltalk. Compilation happens
> > instantly and incrementally *while* the software is already running (maybe
> > for hours). I can't imagine any kind of static checks that might work under
> > these circumstances.
>
> wrong. Back in late 70s, IBM PL/1 debugger was capable to recompile code on
> the fly without stopping the program. PL/1 was definitely a statically
> typed language.
There is the so-called hot code replacement in Java which allows to
replace already loaded code without restarting the application. When
you use Java in conjunction with eclipse the working style is almost
the same as in Smalltalk. You can even change code in the debugger,
save the changes and the cursor jumps to the beginning of the method
and you can step through the method again. It does not work 100%
though as in Smalltalk. I don't know exactly why.
> > Another thing is: Hey, the only thing we are talking about is wether to
> > check if the right arguments are passed to a method/function. So what? If
> > such a mistake was made by the developer, it will popup for sure within
> > minutes (because the argument doesn't respond appropriately to the
> > subsequent messages) and be fixed immediately.
Firstly, problems don't always pop up immediately. Some bugs remain
luring in the software for months and years till they show up. There
are many famous examples for such bugs. Even if the problem will show
in little time, this doesn't mean that you are out of the mess. Let's
say the change was a bug fix that has to be made. Now this change has
to be made in a layer deep down in the layer stack, you didn't write
the code, the code is undocumented and there are many layers and
systems that use this layer. There is no way you can track all
affected code by browsing all senders, because there are simply too
many.
As long as you develop everything yourself and you build up your
system layer by layer, never touch a layer anymore after another one
has been placed on top of it your simple idealistic world works. But
when there are many developers, some of them don't document what they
are doing, you have to take over messy code that did not work in the
first place you have a problem.
>
> Provided that the program goes through all possible paths of the code in
> some finite time ("within minutes"). Sounds much like a halting problem!
>
> Yep, customers will be happy to get "message not understood" after 2-weeks
> of a car mileage test, because someone has modified some parameter type in
> the everlasting incremental compilation process.
>
> > I believe the fear of dynamic typing is a relic from the era where typing
> > errors forced you to reboot your machine.
I have developed many years in a row with Smalltalk. Then I had my
first Java project. I wasn't too happy. Then there was the deplyoment
phase of the system developed in Java. I never have had such a problem
free deployment phase before with Smalltalk. I was really puzzled. The
compiler telling you about type conflicts really does a great deal in
making this possible. In that project I changed so much code in one go
before re-testing things it was simply amazing. This would never have
been possible in Smalltalk. I would have had to test everything again
after only making a few changes. If you don't change the order methods
are called and everything compiles again, I often saw that the code
was working again as before.
To me the question is not whether static typing is beneficial or not.
It clearly is. I have seen it. The question is how much you have to
pay for it. If you use C++ you have too pay a lot and you are still
not sure that the types in your code match correctly. If I had the
choice between Smalltalk and C++ I would chose Smalltalk - simply
because what I have to pay for type safety in C++ is too much. In Java
the cost for static typing is really low. The additional coding effort
is neglectable. Eclipse and other tools do a great job in text
completion. Using eclipse the build process takes no time as in
Smalltalk as classes are compiled incrementally as well.
I have the suspicion that some people mess up the issue of
interactiveness with the typing issue. The main reason Smalltalk is
that productive is its high level of interactiveness and its unique
development environment. A dynamically typed language makes it easy to
implement an interactive system like Smalltalk but it is not
impossible do to it with a statically typed language (see eclipse,
Jikes, VisualAge for Java, and others).
I first though I don't say anything to what has been posted in this
thread. It is just the perfect topic for real hefty flame wars that
yield no benefit. But some statements were so superficial and careless
that I could't resist.
Cheers, Oliver
Dmitry A. Kazakov
> Dmitry A. Kazakov <mai...@dmitry-kazakov.de> coughed up the following:
>> On Thu, 8 Jul 2004 15:13:34 +0200, Andre Schnoor wrote:
>>
>>> Given a proper object encapsulation, there aren't that many possible
>>> paths to a method in practical applications (just look for the
>>> senders). That's mostly theory.
>>>
>>> The real serious errors are not related to passing the wrong
>>> parameter type. They are about buggy algorithms and misunderstood
>>> domain rules - high-level semantic errors. Just checking the types
>>> at compile time is not at all a reason to feel safe.
>>
>> Not just type checking, but, as others have already pointed out,
>> expressing
>> a part of semantics in terms of type relations. When types are
>> accepted for this purpose, and it would be silly to argue for a
>> typeless system, then
>> the question arise, how to deal with this second class objects:
>> types. So
>> to check whether a value has some type is only beginning of the
>> story. It
>> is necessary to ease that check (by making a part of type information
>> static) to have higher levels checks.
>
> And the question that is somehow lost again is /at what cost/ ?
> Establishing a tightly typed hierarchy is time consuming, not a 0-seconds
> endeavor.
To clarify things. Are arguing *against* types and typed languages?
If not, then carefully observe that modern "statically" typed languages do
not require all type checks be static. Actually you can derive everything
from the same root and elude compile time checks.
So answering your question, yes a software design has a non-zero cost. Is
it better not to design?
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Gerry Quinn
>
> Another thing is: Hey, the only thing we are talking about is wether to
> check if the right arguments are passed to a method/function. So what? If
> such a mistake was made by the developer, it will popup for sure within
> minutes (because the argument doesn't respond appropriately to the
> subsequent messages) and be fixed immediately.
That's a silly statement. How do you know you will test every way a
function may ever be called 'within a few minutes'?
> I believe the fear of dynamic typing is a relic from the era where typing
> errors forced you to reboot your machine.
And that statement makes it pretty clear how much importance we should
attach to your observations.
- Gerry Quinn
Dmitry A. Kazakov
>>> If your domain model is well done, you don't need this 100% mathematical
>>> security.
>>
>> OK, let it be 50%. What does it mean, to have 50% security? That only 50%
>> of all paths need to be checked "within minutes"? That the probability of
>> program crash is 0.5? And finally, why any well done domain model should
>> ensure that x-level of security?
>
> Objects tend to be either generic (abstract algorithms, generic data
> structures) or very domain specific. In the first case static typing renders
> the objects nearly unsusable (as in Java), simply because what is intended
> to be generic actually is not.
I do not like Java either. But it is irrelevant here. You are trying to
make point that generic programming (=programming in terms of type sets)
cannot be made in statically typed languages. Why?
> In the second case, only a very narrow
> selection of client objects communicate with each other (that is, the number
> of potential peers is small). Therefore not having 100% security means you
> get something around 99% security.
You forgot the implementation of those objects. How so you know that it is
safe?
> I agree that talking about % in this context is nonsense. What I mean is:
> The chance to find fatal errors very quickly is extremely high.
Yes, you just start your program and see it crashes: objective completed!
(:-))
> The better
> your domain model, the smaller and better manageable your peer-to-peer
> communication gets.
I do not know how you define domain model. But there are lots of well
formulated problems, which yet cannot be solved. To have a good model
implies nothing, it is a condition, but not a sufficient one.
> I experienced that in static languages domain models don't get worked out to
> the level they should, simply because refactoring is such an annoying work
> (due to static typing). I've seen a lot of verbosely coded Java classes with
> a certain hard-wired feel of "safety" and correctness. However, this does
> say nothing about hidden errors that come beyond the first compile.
You should explain something being (probably?) true for Java should be
valid for the whole concept of early (compile-time) checking ... of types.
Why it is only types, which should be checked as late as possible. Let's
imagine a mega dynamic language which does not check for syntax errors in
statements until run time. Would you like it? Would you argue that to find
a syntax error is a matter of seconds, when the program is running?