<?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: Tell us why your language sucks</title>
	<atom:link href="http://www.drmaciver.com/2008/02/tell-us-why-your-language-sucks/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.drmaciver.com/2008/02/tell-us-why-your-language-sucks/</link>
	<description></description>
	<lastBuildDate>Mon, 06 Feb 2012 22:56:11 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Jason</title>
		<link>http://www.drmaciver.com/2008/02/tell-us-why-your-language-sucks/#comment-1515</link>
		<dc:creator>Jason</dc:creator>
		<pubDate>Fri, 03 Dec 2010 05:06:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.drmaciver.com/wordpress/?p=85#comment-1515</guid>
		<description>The Evil Mangler

When it comes to Haskell, the elephant in the room is the Evil Mangler.  It is no misnomer.  To mangle code in order to accomplish a workaround or an optimization hack is no small evil.  It goes against the modularity and reuse principle which is the core of Haskell philosophy.  It is the wrong way to write a compiler, period.  Just like C++ uses name-mangling, Haskell uses code-mangling.  It is all evil.  Haskell should have been bootstrapped from assembly on some high-speed computer and then used to port itself.  It should never have been developed by means of kludgy hacks.  It should have been a pure boot job, not a combination of Perl, C, and itself.  So you believe in pure functional programming?  I do too.  And I also believe in pure bootstrapping.</description>
		<content:encoded><![CDATA[<p>The Evil Mangler</p>
<p>When it comes to Haskell, the elephant in the room is the Evil Mangler.  It is no misnomer.  To mangle code in order to accomplish a workaround or an optimization hack is no small evil.  It goes against the modularity and reuse principle which is the core of Haskell philosophy.  It is the wrong way to write a compiler, period.  Just like C++ uses name-mangling, Haskell uses code-mangling.  It is all evil.  Haskell should have been bootstrapped from assembly on some high-speed computer and then used to port itself.  It should never have been developed by means of kludgy hacks.  It should have been a pure boot job, not a combination of Perl, C, and itself.  So you believe in pure functional programming?  I do too.  And I also believe in pure bootstrapping.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason</title>
		<link>http://www.drmaciver.com/2008/02/tell-us-why-your-language-sucks/#comment-1501</link>
		<dc:creator>Jason</dc:creator>
		<pubDate>Sat, 20 Nov 2010 03:54:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.drmaciver.com/wordpress/?p=85#comment-1501</guid>
		<description>An example of what I mean:

Anyone who has done functional programming has probably encountered the function map.  Something like map sq [1,2,3,4,5] computes to [1,4,9,16,25].  map is easy to write, but no one writes it oneself.  Rather, map is a built-in function.  My radical opinion is that map should never be built-in.  It should be available in a library, but the library should exist as actual source code that would compile or run in that language.  The library should not be mere object code that was compiled by another language.

map is easy to understand.  It can be explained mathematically.  One can easily get a handle on exactly what map does and use it with confidence.  There are many good tutorials that include map in their examples of the power of functional programming.  It should be the same with every level of abstraction from the simplest to the most complex.  The documentation should always be available as open-source information.  If the abstraction has a basis in a mathematical theory, that theory should be included in the documentation, so that anyone using the construct can understand and use it with confidence.

For example, you have probably seen list abstraction, which is similar to set abstraction.  As a mathematician, I like set abstraction.  As a programmer, I avoid list abstraction, unless I know how it is implemented in the language core.</description>
		<content:encoded><![CDATA[<p>An example of what I mean:</p>
<p>Anyone who has done functional programming has probably encountered the function map.  Something like map sq [1,2,3,4,5] computes to [1,4,9,16,25].  map is easy to write, but no one writes it oneself.  Rather, map is a built-in function.  My radical opinion is that map should never be built-in.  It should be available in a library, but the library should exist as actual source code that would compile or run in that language.  The library should not be mere object code that was compiled by another language.</p>
<p>map is easy to understand.  It can be explained mathematically.  One can easily get a handle on exactly what map does and use it with confidence.  There are many good tutorials that include map in their examples of the power of functional programming.  It should be the same with every level of abstraction from the simplest to the most complex.  The documentation should always be available as open-source information.  If the abstraction has a basis in a mathematical theory, that theory should be included in the documentation, so that anyone using the construct can understand and use it with confidence.</p>
<p>For example, you have probably seen list abstraction, which is similar to set abstraction.  As a mathematician, I like set abstraction.  As a programmer, I avoid list abstraction, unless I know how it is implemented in the language core.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason</title>
		<link>http://www.drmaciver.com/2008/02/tell-us-why-your-language-sucks/#comment-1500</link>
		<dc:creator>Jason</dc:creator>
		<pubDate>Sat, 20 Nov 2010 03:33:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.drmaciver.com/wordpress/?p=85#comment-1500</guid>
		<description>Functional programming is supposed to be: formal, reliable, mathematical, and bug-free.  Functional programming filled with built-in high-level constructs that no one really understands is not.  The core should be tiny, with all over-your-head abstractions derived, not built-in.</description>
		<content:encoded><![CDATA[<p>Functional programming is supposed to be: formal, reliable, mathematical, and bug-free.  Functional programming filled with built-in high-level constructs that no one really understands is not.  The core should be tiny, with all over-your-head abstractions derived, not built-in.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason</title>
		<link>http://www.drmaciver.com/2008/02/tell-us-why-your-language-sucks/#comment-1499</link>
		<dc:creator>Jason</dc:creator>
		<pubDate>Sat, 20 Nov 2010 03:28:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.drmaciver.com/wordpress/?p=85#comment-1499</guid>
		<description>I agree about documentation.  That is a beef I have with almost any language out there.  The language is usually bigger than I want.  Certainly, no one completely understands it, unless it is Scheme as taught by Sussman, who by the way did not teach me let-wreck.</description>
		<content:encoded><![CDATA[<p>I agree about documentation.  That is a beef I have with almost any language out there.  The language is usually bigger than I want.  Certainly, no one completely understands it, unless it is Scheme as taught by Sussman, who by the way did not teach me let-wreck.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: shiny666</title>
		<link>http://www.drmaciver.com/2008/02/tell-us-why-your-language-sucks/#comment-1488</link>
		<dc:creator>shiny666</dc:creator>
		<pubDate>Sat, 06 Nov 2010 00:29:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.drmaciver.com/wordpress/?p=85#comment-1488</guid>
		<description>to be fair my incompetence at functional programming, and in general, is just as frustrating</description>
		<content:encoded><![CDATA[<p>to be fair my incompetence at functional programming, and in general, is just as frustrating</p>
]]></content:encoded>
	</item>
</channel>
</rss>

