Using Python's built-in defaultdict we can easily define a tree data structure:
def tree(): return defaultdict(tree)
That's it!
Using Python's built-in defaultdict we can easily define a tree data structure:
def tree(): return defaultdict(tree)
That's it!
JavaScript █████████████████░░░ なかなか Pretty Good | |
HTML ███████████░░░░░░░░░ まあまあ Not Bad | |
CSS █████████████░░░░░░░ そこそこ Alright | |
Vue.js ███████████████░░░░░ それなり Good | |
Muscle ██░░░░░░░░░░░░░░░░░░ よわよわ Weak | |
Guitar ███████████████████░ つよつよ Strong |
Monads and delimited control are very closely related, so it isn’t too hard to understand them in terms of one another. From a monadic point of view, the big idea is that if you have the computation m >>= f
, then f
is m
’s continuation. It’s the function that is called with m
’s result to continue execution after m
returns.
If you have a long chain of binds, the continuation is just the composition of all of them. So, for example, if you have
m >>= f >>= g >>= h
then the continuation of m
is f >=> g >=> h
. Likewise, the continuation of m >>= f
is g >=> h
.
%% Copyright 2020 Alexander Yakushev | |
% | |
% This work may be distributed and/or modified under the | |
% conditions of the LaTeX Project Public License, either version 1.3 | |
% of this license or (at your option) any later version. | |
% The latest version of this license is in | |
% http://www.latex-project.org/lppl.txt | |
% and version 1.3 or later is part of all distributions of LaTeX | |
% version 2005/12/01 or later. | |
% |
Here's a rundown of definitions in my .jprofile.ijs
, which get loaded in all J sessions.
Some of these are so simple they don't need names, but sometimes I just put things in here so I don't forget how to spell them.
Not all the functions are the most efficient, they're just there for playing with data. Often in a script, I will copy a function in, or re-write one that is more specific to the given problem domain.
% \documentclass[9pt,a4paper,twocolumn,landscape,oneside]{amsart} | |
\documentclass[9pt,a4paper,landscape,oneside]{amsart} | |
\usepackage{amsmath, amsthm, amssymb, amsfonts} | |
\usepackage[T1]{fontenc} | |
\usepackage[utf8]{inputenc} | |
\usepackage{booktabs} | |
\usepackage{fancyhdr} | |
\usepackage{float} | |
\usepackage{fullpage} | |
%\usepackage{geometry} |
blah blah blah more things here
From my experience fundraising in Haskell, companies who use it all seem to have suffered from the same two flavors of problem:
A rockstar comes in, dumps mindblowing code everywhere that dazzles the rest of the team and fools the product leads with pseudo-productivity until the rockstar leaves or finally wakes up. Cue the rest of the team death-marching for the next year or few years as the team attempts to juggle feature additions with excising or unraveling the impenetrable yarn-tangle of semantic misdirection.
An especially productive senior or team lead spends their time on refactoring and generally spinning their wheels with respect to product delivery, and then fails to deliver on time, or at all. Cue the rest of the team struggling to keep up with the refactors. The team's knowledge of the state of the product suffers, confusion about goals sets in, the senior/lead effectively becomes an anti-team player, throwing curveballs at the rest o