<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
I am mostly a believer in static types.<BR>
<BR>
Though there sure is an interesting place in<BR>
languages like C#, C++, ML, where the compiler<BR>
is *obligated* in many contexts to deduce static<BR>
type and in which it really isn't very controversial.<BR>
<BR>
This leads to, for example, qsort that can "easily"<BR>
inline the comparison function and beat C.<BR>
<BR>
C# has this nifty "LINQ" stuff where to actually<BR>
have the programmer state the static types<BR>
would be quite onerous.<BR>
<BR>
<BR>
A similar scenario is "expression templates" in C++.<BR>
Where you have a + b * c / d and the types<BR>
of a, b, c, d are a variety of vectors/matrices,<BR>
and there are no actual intermediate computations done,<BR>
just one inner loop, because the type of the overloads<BR>
doesn't hold an intermediate result but rather sort of "directions"<BR>
on how to proceed. See Todd Veldhuzien's fascinating work.<BR>
<A href="http://en.wikipedia.org/wiki/Expression_templates">http://en.wikipedia.org/wiki/Expression_templates</A><BR>
<BR>
<BR>
The dynamic type proponents do have strong arguments in some situations:<BR>
- You are going to throw out the code soon anyway, sometimes.<BR>
- You have to run it, test it, and that somewhat substitutes for whatever checks the "compiler" makes.<BR>
<BR>
- Jay<BR><BR><BR><BR><BR><BR> <BR>> Date: Sun, 17 Jan 2010 21:21:35 -0500<BR>> From: hendrik@topoi.pooq.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] in favor of mixed operators..<BR>> <BR>> On Sun, Jan 17, 2010 at 05:58:33PM -0800, Mika Nystrom wrote:<BR>> > <BR>> > Jay I think the following paragraph is important and demonstrates why<BR>> > this article is perhaps less relevant to Modula-3:<BR>> > <BR>> > When you write a function implementing a numeric algorithm (for example,<BR>> > calculating the phase of the moon) you typically expect the arguments<BR>> > to be specified as floating point numbers. However, since Python doesnt<BR>> > have type declarations, nothing is there to stop a caller from providing<BR>> > you with integer arguments. In a statically typed language, like C,<BR>> > the compiler will coerce the arguments to floats, but Python does no<BR>> > such thing the algorithm is run with integer values until the wonders<BR>> > of mixed-mode arithmetic produce intermediate results that are floats.<BR>> > <BR>> > Mika<BR>> > <BR>> > Jay K writes:<BR>> > >--_671e4a34-689a-4d86-98d3-1f8935f7844b_<BR>> > >Content-Type: text/plain; charset="iso-8859-1"<BR>> > >Content-Transfer-Encoding: quoted-printable<BR>> > ><BR>> > ><BR>> > >http://python-history.blogspot.com/2009/03/problem-with-integer-division.ht=<BR>> > >ml<BR>> > ><BR>> > ><BR>> > >He argues that for a "high level" language=2C of course<BR>> <BR>> He identifies python as a high-level language. His arguments about what <BR>> a high-level language should do are based on python's absence of static <BR>> typing. Thus he comes to his conclusion, having identified the concept <BR>> of "high level" with "no static typing". Presumably he thinls that <BR>> types are an inconvenience inflicted by the desire for run-time <BR>> efficiency. Many people believe this, failing entirely to notice that <BR>> static typing is a powerful tool in the pursuit of correctness.<BR>> <BR>> -- hendrik<BR> </body>
</html>