As someone who very occasionally types a line or two of Haskell, but never committed any of the basic types to memory, I have to say that ironically I couldn’t remember what a functor actually was until this bit:
The best (but still extremely bad) alternative name to Functor is Mappable.
This is anecdotal and subjective and all, but the name
Mappable is just so much more obvious to me. The point of “well what about cartography” also seems to be contradicted by a previous point
Reliability is also subjective. It all depends on context and familiarity.
In context, there is no confusion between printed on paper maps and the type. “Mappable is a type that can be mapped over” is much more consistent than “Functor is a type that can be mapped over”, and should be clear to most developers. Yes, beginners will still need to learn the meaning of “mapping over”, but once they do, why not give them a memorable (if imprecise) name instead of another conceptual pointer they need to keep in their heads.
I understand the desire for precise, unambiguous language by Haskell folks, but it really just doesn’t resonate well with me. I’d much rather optimize for readability and ergonomics.
why not give them a memorable (if imprecise) name instead of another conceptual pointer they need to keep in their heads.
I don’t think the name should be changed, because functor is a perfectly good word with plenty of relevant educational material pointing to it. It’s more precise than “mappable”, because functors actually go further than the concept of mapping functions over containers.
However, the analogy of mapping functions over containers is useful, because it allows the student to actually get to work with this algebra rather than navel-gaze on the meanings and origins of names.
Mappable is good, but I think Functor is better still because we can recall the “functor laws” from category theory (functors preserve identity and composition). These laws aren’t just abstract curiosities—they are actually useful for reasoning about programs. Mappable doesn’t really convey the fact that these laws should hold.
I’m not sure most programmers can recall the functor laws from category theory. I certainly never heard of it.
To me, the key detail is: when you hear the word “functor” for the first time, you aren’t led into a false sense of familiarity. If it’s a new word to you, you can Google it and learn about the functor laws. But if we just called it “mappable”, you might think “ok I know what this is doing” and never learn the proper definition. And if you already know what functors are, you can immediately start using them without having to learn a “friendlier” neologism when learning a new language.
Not most programmers, but most people who learn a language which explicitly uses those abstractions.
Anything noteworthy to call out with this release? Perhaps the site hasn’t been updated, but it seems like a pretty minor version bump.
For more information about this release, see the etc/NEWS file, which you can view from Emacs with `C-h n’.
The link to the file is here.
Those are the only changes I’ve noticed, it says it’s a maintenance release, so probably not a lot of new features.
** New option 'help-enable-completion-auto-load'. This allows disabling the new feature introduced in Emacs 26.1 which loads files during completion of 'C-h f' and 'C-h v' according to 'definition-prefixes'. ** Emacs now supports the new Japanese Era name. The newly assigned codepoint U+32FF was added to the Unicode Character Database compiled into Emacs.
This is great! I really like this style of explaining how the pieces fit together from the ground up. Every time I’ve tried to start a project in Phoenix (or Rails, or Django, …) in the past, I’ve been pretty overwhelmed by the sheer number of different moving parts that are simply scaffolded in.
Agreed, this was super well written and easy to follow. I love the idea that each section links to a commit. I might steal that for my blog :)
Thanks! I’ve got a whole pipeline that transforms a
git log into an article formatted to work with my static site generator. I’m a big fan of the format!
As someone else who recently generated a new scaffolded project with Phoenix (just to have a play around, I don’t know much elixir) and felt overwhelmed by all the moving parts, I wanted to chime in too and say I found this post very handy. Thanks :)
That’s interesting! I wonder if there could be a place for a tool that does database query and schema linting. That way these issues could be programmatically caught, as opposed to requiring users to memorize all the preferred syntax / types.
I built something similar to what you described a couple months back, but didn’t spend too much time fleshing out the rules. This list would actually be a fantastic addition to the tool.
maybe https://github.com/jfcoz/postgresqltuner could be extended
Another good one is
Just found out about this one recently from a coworker. It opens up
$EDITOR for writing commands. I’ve been using it to edit stuff with a bunch of arguments so I can spread them across multiple lines and rearrange things more easily.
This is the greatest think I’ve learned in … a while. I don’t write a lot of one-off scripts and tend to just have a bunch of commands joined on one line with semicolons. This will help a bunch.
Thanks, so much!
Wow, this is wild. I was just getting ready to release my own webextension later this week that does almost exactly the same thing. You definitely beat me to the punch :)
There’s a definite need, so I was shocked to find nothing in the Web Store was solving the issue!
Yours is much more complex and walks the DOM to collect data and completely reformats the recipe contents. Mine is [on purpose] much simpler and just clones the recipe into a modal so that its appearance is still in line with the site itself and I let some styling leak onto the elements I add as well so it feels at home on the page.
I think with yours it would be easier to go the extra mile and start linking to places to purchase ingredients, do nutritional breakdowns, etc.
I started a side project called SimpleBlog. The idea was to auto publish Google Docs as blog posts with one click. I figured there were enough people who didn’t care at all about dealing with arcane web editors with too much configuration and not enough features in their word editor. For example, Substack is all the rage right now, and it still doesn’t have inline code blocks.
I made about a third of an MVP and got lazy and convinced myself no one would use it.
Hah, I had the same idea, and also abandoned it after building an MVP. I never had intentions of monetizing / publicizing, so for me the motivation was having a reasonable offline mobile editor (the Google Docs app) available to write trip journal entries while out in the wilderness.
I dropped the project after I realized I don’t write this kind of content generally, and it’s not due to a lack of software.
If anyone’s interested in a more complete implementation of this idea, Blot may fit the description.