hardmath123.github.io/embracing-types.html at master · Hardmath123/hardmath123.github.io · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
<!DOCTYPE html>
<html>
    <head>
        <link rel="canonical" href="https://hardmath123.github.io/embracing-types.html"/>
        <link rel="stylesheet" type="text/css" href="/static/base.css"/>
        <title>Embracing Types - Comfortably Numbered</title>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
        <meta charset="utf-8"/>
        <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />
        <link rel="alternate" type="application/rss+xml" title="Comfortably Numbered" href="/feed.xml" />

        <!--
        <script src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
        <script>
            MathJax.Hub.Config({
                tex2jax: {inlineMath: [['$','$']]}
            });
        </script>
        -->


        <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.13.11/dist/katex.min.css" integrity="sha384-Um5gpz1odJg5Z4HAmzPtgZKdTBHZdw8S29IecapCSB31ligYPhHQZMIlWLYQGVoc" crossorigin="anonymous">
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.13.11/dist/katex.min.js" integrity="sha384-YNHdsYkH6gMx9y3mRkmcJ2mFUjTd0qNQQvY9VYZgQd7DcN7env35GzlmFaZ23JGp" crossorigin="anonymous"></script>
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.13.11/dist/contrib/auto-render.min.js" integrity="sha384-vZTG03m+2yp6N6BNi5iM4rW4oIwk5DfcNdFfxkk9ZWpDriOkXX8voJBFrAO7MpVl" crossorigin="anonymous"></script>
<script>
    document.addEventListener("DOMContentLoaded", function() {
        renderMathInElement(document.body, {
          // customised options
          // • auto-render specific keys, e.g.:
          delimiters: [
              {left: '$$', right: '$$', display: true},
              {left: '$', right: '$', display: false},
              {left: '\\begin{align}', right: '\\end{align}', display: true},
              {left: '\\(', right: '\\)', display: false},
              {left: '\\[', right: '\\]', display: true}
          ],
          // • rendering keys, e.g.:
          throwOnError : false
        });
    });
</script>


    </head>
    <body>
        <header id="header">
            <script src="static/main.js"></script>
            <div>
                <a href="/"><span class="left-word">Comfortably</span>&nbsp;<span class="right-word">Numbered</span></a>
            </div>
        </header>

        <article id="postcontent" class="centered">
            <section>
                <h1>Embracing Types</h1>
                <center><em><p>What isn’t wrong with static typing.</p>
</em></center>
                <h4>Sunday, February 8, 2015 &middot; 3 min read</h4>
<p>A lot of script kiddies, myself included, take a lot of pride in loathing
statically typed languages and being “purists”. But I’ve been doing some
reading about static typing (after realizing that many of the hackers I
respect are type-safety-fanatics) and I’ve realized that a lot of the reasons
that we have for hating type-safe languages aren’t truly valid.</p>
<p>Not that I’m converted. I’m still a firm believer that types belong to objects,
not to variables. But for the benefit of people who are still making a choice,
here are some of my misconceptions about type safety.</p>
<p>This post isn’t meant to persuade you one way or the other, because if you’re
going to join the Dark Side, it’s probably too late already.</p>
<h3 id="misconception-1-type-safe-means-hardcore-imperative-oop-">Misconception 1. Type-safe means hardcore imperative OOP.</h3>
<p>This probably stems from the huge popularity of Java, which has linked static
typing to aggressively object-oriented imperative programming. When I took AP
Computer Science, the distinction between Types and Objects was not made
clearly enough.</p>
<p>You can have OOP without static typing. There’s Pythonic duck typing:</p>
<blockquote>
<p>In other words, don’t check whether it IS-a duck: check whether it
QUACKS-like-a duck, WALKS-like-a duck, etc, etc, depending on exactly what
subset of duck-like behaviour you need to play your language-games with.</p>
<p>  (Alex Martelli, <a href="https://groups.google.com/forum/?hl=en#!msg/comp.lang.python/CCs2oJdyuzc/NYjla5HKMOIJ">source</a>)</p>
</blockquote>
<p>There’s Self’s prototypical inheritance, where all you have are objects (which
are pretty close to JavaScript Objects and Lua Tables when it comes to
implementing an OOPey system). There’s even Scheme OOP, with impure dispatch
functions as described in SICP.</p>
<p>But you can also have type-safe functional languages without an OOP framework
around it. The best examples of these are Haskell and ML, though I’m sure there
exist others. Haskell is as functional as it gets (arguable more so than
Scheme, because it <a href="http://xkcd.com/1312/">absolutely prohibits side-effects</a>,
i.e.  doesn’t have <code>set-car!</code>).</p>
<p>So you don’t need to give up functional code to embrace type safety.</p>
<h3 id="misconception-2-type-safety-causes-extreme-abstraction-and-code-inflation">Misconception 2. Type-safety causes extreme abstraction and code inflation</h3>
<p>Another one that I <a href="http://geek-and-poke.com/geekandpoke/2014/1/2/games-for-the-real-geeks-part-2">attribute to
Java</a>.
Though it’s <a href="https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition">completely
possible</a>
to be obnoxious about your types, for the most part it’s also completely
possible to write reasonable-looking flat-is-better-than-nested code. Just like
you can write C programs, for loops and all, in Scheme, and they’ll work, but
that’s a blatant abuse of recursion.</p>
<p>Looking at lots of Haskell code, it’s pretty clear that the levels of
abstraction you choose to implement are not directly correlated with the way
you use or misuse the type system.</p>
<h3 id="misconception-3-type-safety-is-a-hack-added-onto-languages-to-discipline-programmers-it-s-just-another-lint-">Misconception 3. Type-safety is a hack added onto languages to discipline programmers. It’s just another lint.</h3>
<p>We’re generally told that aside from some some cases where runtime typechecks
are needed (or C, where types determine memory usage), most of the time
typechecking information is just discarded when you actually compile the code.
In that sense, they seem to add little more value than well-placed, meaningful
comments.</p>
<p>And while that’s an acceptable way to look at it, it’s certainly worth
realizing that type theory is an established branch of computer science that
comes dangerously close to math. It is nontrivial to come up with a type system
that is “provably correct”, that is, a type system that is liberal enough to
accept programs that get stuff done, but conservative enough to reject programs
that do bad stuff (like access fields that don’t exist).</p>
<p>For example, consider functions that accept an Animal as input and return a
Truck as output. Is this a superclass of functions that accept Parrots as input
and return Vehicles as output? Or a subclass? How about classifying recursive
tuple types (such as <code>LinkedList&lt;T&gt;</code>, which could potentially be of type
<code>Tuple(T, LinkedList&lt;T&gt;)</code>)?</p>
<p>Even though type-safety is like a lint, it’s a very advanced, deep lint that
occasionally catches subtle bugs. It’s a sanity check that prevents you from
coding if it deems you insane.</p>
<h3 id="and-i-care-because-">And I care because…</h3>
<p>…because even though type safety is the enemy, it’s important to realize why
it’s so popular. In the world of CS, it’s important to Hoover up as many new
ideas as you can, even if you don’t agree with all of them.</p>
<blockquote>
<p>If you know yourself but not the enemy, for every victory gained you will
also suffer a defeat.</p>
<p>— Sun Tzu, <em>The Art of War</em>, III-18.</p>
</blockquote>

            </section>

            <div id="comment-breaker">&loz; &loz; &loz;</div>

        </article>
        <footer id="footer">
            <div>
                <ul>
                    <li><a href="https://github.com/kach">
                        Github</a></li>
                    <li><a href="feed.xml">
                        Subscribe (RSS feed)</a></li>
                    <li><a href="https://twitter.com/hardmath123">
                        Twitter</a></li>
                    <li><a href="https://creativecommons.org/licenses/by-nc/3.0/deed.en_US">
                        CC BY-NC 3.0</a></li>
                </ul>
            </div>

            <script>
                (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
                (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
                m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
                })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

                ga('create', 'UA-46120535-1', 'hardmath123.github.io');
                ga('require', 'displayfeatures');
                ga('send', 'pageview');
            </script>
        </footer>

    </body>
</html>