<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Why I like explicit typing</title>
	<atom:link href="http://tiago.org/cc/2008/12/31/why-i-like-explicit-typing/feed/" rel="self" type="application/rss+xml" />
	<link>http://tiago.org/cc/2008/12/31/why-i-like-explicit-typing/</link>
	<description>Software engineering in a computational biology environment</description>
	<lastBuildDate>Mon, 24 Oct 2011 21:36:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: James Iry</title>
		<link>http://tiago.org/cc/2008/12/31/why-i-like-explicit-typing/comment-page-1/#comment-450</link>
		<dc:creator>James Iry</dc:creator>
		<pubDate>Wed, 31 Dec 2008 16:27:53 +0000</pubDate>
		<guid isPermaLink="false">http://tiago.org/cc/?p=47#comment-450</guid>
		<description>When a language has inferred static types (Scala, Haskell, ML, F#, etc), an IDE has exactly as much information as when you explicitly annotate types.   Basically, inferred static typing can be thought of as the tool inserting the type annotations that you leave out. So scratch the IDE concern off your list for those languages.   Groovy is very different, so this reasoning doesn&#039;t apply there.

Usually static type inference does not cause an invalid program to type check.  But what it can do is give a static type error that&#039;s pretty far removed from the &quot;real&quot; source of the problem as seen by the programmer.  Scala requires type annotations on arguments to functions which is a bummer but on the plus side you don&#039;t tend to have that kind of chained inference problems.  In languages with fuller type inference (Haskell, ML, F#) it&#039;s common practice to annotate types on many or most top level definitions just to prevent that kind of problem.

Scala&#039;s compulsory type annotations on function arguments has to do with the limitations on currently known inference algorithms and how they relate to subtyping and overloading.  F# also has some, though far fewer, spots where it needs explicit type annotations.</description>
		<content:encoded><![CDATA[<p>When a language has inferred static types (Scala, Haskell, ML, F#, etc), an IDE has exactly as much information as when you explicitly annotate types.   Basically, inferred static typing can be thought of as the tool inserting the type annotations that you leave out. So scratch the IDE concern off your list for those languages.   Groovy is very different, so this reasoning doesn&#8217;t apply there.</p>
<p>Usually static type inference does not cause an invalid program to type check.  But what it can do is give a static type error that&#8217;s pretty far removed from the &#8220;real&#8221; source of the problem as seen by the programmer.  Scala requires type annotations on arguments to functions which is a bummer but on the plus side you don&#8217;t tend to have that kind of chained inference problems.  In languages with fuller type inference (Haskell, ML, F#) it&#8217;s common practice to annotate types on many or most top level definitions just to prevent that kind of problem.</p>
<p>Scala&#8217;s compulsory type annotations on function arguments has to do with the limitations on currently known inference algorithms and how they relate to subtyping and overloading.  F# also has some, though far fewer, spots where it needs explicit type annotations.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

