<story><title>The Logical Disaster of Null</title><url>https://rob.conery.io/2018/05/01/the-logical-disaster-of-null/</url></story><parent_chain><item><author>paulhodge</author><text>I have a pet peeve whenever people bring up the old &amp;quot;Billion dollar mistake&amp;quot; quote. Calling it a mistake means that it could have been avoided. But we couldn&amp;#x27;t have avoided null pointer errors (or some other name for the same thing) any more than humans could have avoided the bronze age. In the 60s and 70s we didn&amp;#x27;t have the &amp;quot;technology&amp;quot; to avoid null errors. By technology I mean production-ready languages with a static typing layer sophisticated enough to implement a Maybe&amp;#x2F;Optional type. Those languages weren&amp;#x27;t production ready until maybe around the 80s. And most of those compilers were themselves implemented in unsafe-null languages like C.&lt;p&gt;But anyway, that&amp;#x27;s history, now we have nice languages that have safe nulls, so the interesting questions moving forward are: why are people still creating new languages that have unsafe nulls (looking at you Go), and why are people still choosing to use languages with unsafe nulls?</text></item></parent_chain><comment><author>alkonaut</author><text>There were better languages but Unix won, and with that - C. A mistake we (whoever “we” are) repeated with JavaScript - we let the language win that was “there”, not the one we really needed.&lt;p&gt;Worse is better. Ease of deployment over ease of development.&lt;p&gt;As for the Q: why design languages with null (that is - incomplete or flawed type systems) &lt;i&gt;now&lt;/i&gt;? I have  o idea. I think the reasoning is that “worse is better” succeeded for JS, php, C, so it’s a viable path.&lt;p&gt;“Maybe an X” and “Definitely an X” are more different than string and number. If a language pretends string and number are distinct but at the same time has no distiction for “maybe X” - then it doesn’t have a very good type system.&lt;p&gt;Note that it doesn’t necessarily need to avoid null values for this. Non-nullables is mostly equivalent although less elegant. That is, “String s” means a string or null, while “String! s” means a non-null string (example from a C# vNext syntax).</text></comment>
<story><title>The Logical Disaster of Null</title><url>https://rob.conery.io/2018/05/01/the-logical-disaster-of-null/</url></story><parent_chain><item><author>paulhodge</author><text>I have a pet peeve whenever people bring up the old &amp;quot;Billion dollar mistake&amp;quot; quote. Calling it a mistake means that it could have been avoided. But we couldn&amp;#x27;t have avoided null pointer errors (or some other name for the same thing) any more than humans could have avoided the bronze age. In the 60s and 70s we didn&amp;#x27;t have the &amp;quot;technology&amp;quot; to avoid null errors. By technology I mean production-ready languages with a static typing layer sophisticated enough to implement a Maybe&amp;#x2F;Optional type. Those languages weren&amp;#x27;t production ready until maybe around the 80s. And most of those compilers were themselves implemented in unsafe-null languages like C.&lt;p&gt;But anyway, that&amp;#x27;s history, now we have nice languages that have safe nulls, so the interesting questions moving forward are: why are people still creating new languages that have unsafe nulls (looking at you Go), and why are people still choosing to use languages with unsafe nulls?</text></item></parent_chain><comment><author>tpush</author><text>There really isn&amp;#x27;t anything sophisticated about having sum types, ALGOL 68 had them in some form for crying out loud.</text></comment>