Category Theory for Programmers (2014) [pdf]

compare

>The average high schooler

with

>motivated high school student

certainly we all underestimate the difficulty of material (obverse of the dunning-krueger effect) but it says it does at least hint at it right there.

but honestly i'm curious where in the book you see an example of a term or notion that isn't defined in situ? as usual (with all of these things) mathematical maturity is what's required rather than familiarity with the material. what this means is a sense for why definitions are written in the way that they are, which hypotheses in theorems capture the phenomenon and which are technical, which lemmata can be ignored on first reading, etc. this is a very hard thing to communicate, especially in text, but this book does do its best to make that not-overwhelming as possible with ample restatements of definitions and assumptions and diagrams.

Buzzwords are popular words. You put category theory on your resume it's not gonna get you anything. It's obscure.

Look the point isn't the python, the point is, the design pattern can be applied to many places and in some contexts it's faster in other contexts it is not, but the design pattern exists. My intent was to convey understanding of the pattern at a very general level. Not to argue about the validity of the python implementation.

Started reading this and was disappointed to find the same disingenuous claims about strong static type systems.

I say disingenuous because the people that espouse these beliefs seem to have a minimum modicum of intelligence and do or would certainly (after a moment of reflection) certainly realize their fallacy:

> The only serious argument I hear against strong static type check- ing is that it might eliminate some programs that are semantically cor- rect. In practice, this happens extremely rarely and, in any case, every language provides some kind of a backdoor to bypass the type sys- tem when that’s really necessary.

This is patently false. Port a correct dynamically typed program to Haskell and it will certainly fail until you satisfy the type checker through no small extraneous effort. And this is not a theoretical matter; it is an enormous cost to the programmer that is not there in weaker or non- typed systems.

It is a certainty that type systems ask for far more than is needed to produce correctness. Anyone who tries to dodge this obvious and fundamental truth is operating off of a religious not rational commitment to defending their type system. Note that I am not saying the type system doesn't give you something back but it certainly comes with a inherent cost over alternatives.

> Another argument I hear a lot is that dealing with types imposes too much burden on the programmer. I could sympathize with this sen- timent after having to write a few declarations of iterators in C++ my- self, except that there is a technology called type inference that lets the compiler deduce most of the types

This is the most heinous and sad lie. Type inference changes nothing. The types are there even if you don't have to type them in and they are significantly constraining your set of accepted programs.

I've heard this response before from seemingly smart static typers. I just can't believe a smart person would not see the obvious emptiness of this claim. There is no way anyone would think that having to type characters is the exclusive cost of static typing that inference suddenly whisks away.

I want to buy into the strong static typist's promise of utopia but I have yet to meet a static typist enthusiast that doesn't parlay in these lies, wittingly or unwittingly.

Because of this I have a serious suspicion that there is nothing else to stand on and that strong static typing is simply a case of the Emperor's New Clothes. Prove me wrong.

I timed it -- 2 orders of magnitude slower across the board.

    In [19]: short, middle, long = [{2*i+1:2*i+2 for i in range(n)} for n in [2, 2**8, 2**16]]
    In [20]: timeit  [x for kv in d.items() for x in short]
    812 ns ± 6.86 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
    In [21]: timeit  [x for kv in d.items() for x in middle]
    30.1 µs ± 1.87 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
    In [22]: timeit  [x for kv in d.items() for x in long]
    9.77 ms ± 1.19 ms per loop (mean ± std. dev. of 7 runs, 100 loops each)
    In [24]: timeit  eval(str(short).replace('{','[').replace('}',']').replace(':',', '))
    10.4 µs ± 240 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
    In [25]: timeit  eval(str(middle).replace('{','[').replace('}',']').replace(':',', '))
    592 µs ± 23.8 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
    In [26]: timeit  eval(str(long).replace('{','[').replace('}',']').replace(':',', '))
    264 ms ± 3.22 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

Python dictionaries are ordered, and iterate in order (since 3.6, as guaranteed property since 3.7). In older versions of python where they are not ordered, str also does not preserve the order in the literal (except for one of all possible orderings).

   Python 3.7.2 
   Type "help", "copyright", "credits" or "license" for more information.
   >>> str({5:6, 4:5, 3:2})
   '{5: 6, 4: 5, 3: 2}'

   Python 2.7.15
   >>> str({5:6, 4:5, 3:2})
   '{3: 2, 4: 5, 5: 6}'

You might consider what I wrote offensive, but maybe you can still take the above as evidence that there are areas where your mental model is imperfect. I have the impression there is a puzzlingly common class of CS engineering failures stemming from misguided abstraction attempts because people are either unable or just unpredisposed to making extremely back of the envelope task breakdown of the most direct implementation in terms of primitive, costed operations. I also see this happen to rather smart but inexperienced engineers. Since you are not inexperienced my advice is unlikely to be helpful.

I'm totally new to the community! So I have no idea about almost anything I didn't link to or isn't linked here, ha.

That is a freakin' awesome link, thank you so much! Though, it'll probably mean yet another rewrite of my record layer :) (at learning is fun)