Notation as a Tool of Thought (1979)
jsoftware.com
jsoftware.com
For example the dy/dx notation in calculus naturally leads to inquisitive thinking. Can you multiply by dx? It looks like a division but it isnt, really, except that a soon as you get past Calc 101 you are spraying dys and dxs all over. the notation is just incredibly suggestive.
Another example is exponents where m^n is introduced naively for natural n but instantly prompts the question around non integer n.
i think that having a notation that is suggestive and can be creatively broken to use in new ways is v important
Maybe. But can you multiply by ∂x?
∂x would have a problematic definition, as it would require selecting from its components based on information not supplied. E.g., let x = y+z. Then dx = dy + dz. But ∂x (by extension) = ∂y + ∂z, but at least one of these terms on the right is identically zero, depending on whether y or z is held constant. So ∂x doesn't have a meaning.
Like, I get “dx”, but I cannot put my finger to it!!! This might be because the Precise Definition of the Limit phrases it as “x approaches a”; it is as though we are “sent” to the land of dx, but not told what it is as an atomic concept!
Sure it does. There is no need to know about smooth manifolds or differential forms to understand the differential of a function of one variable at a point and the meaning of dy = f’(x)dx.
dy = f'(x)dx is just a definition for notional convenience, primarily employed when doing u or u-v substitution. My point is that dx in single variable calculus is notation. It is not an intrinsic object. dx is an intrinsic object as a differential form on a smooth manifold. Of course, the real line R is a 1-manifold, so dx does have that meaning, but you need to understand what a differential form is to know that.
One doesn't necessarily need the full generality of smooth manifolds though. Harold Edwards' Advanced Calculus: A Differential Forms Approach and Advanced Calculus: A Geometric View teach differential forms for Euclidean manifolds.
1) The differential of a function (at a point), dy, is not notation, it is a concept.
2) The differential of the function y = x, dx, is not, then, a notation, either; and, since the derivative is 1, dx = 1 Δx = Δx = x - x0.
3) You can argue, of course, that using dx instead of Δx in dy = f'(x)dx is "notation," but I think the above shows that it is more than that.
However, and this is very amusing to me, it turns out that the process of automatic differentiation (see https://en.wikipedia.org/wiki/Automatic_differentiation, the section on dual numbers) works in exactly the same way. Just replace all of the primed symbols (u', v', etc.) with du, dv, etc. and dual numbers are isomorphic to infinitesimals (if I'm using that term correctly.)
Creative breakage is a bug which tells you to think harder about what you're doing.
https://news.ycombinator.com/item?id=32173840
I started down the APL/J path last week after watching this APL study group with Jeremy Howard of fast.ai:
The bit on "avoid ambiguity, or introduce useful ambiguity" is especially fascinating.
And yet I miss many things about APL when coding in modern functional languages. Specifically, having the shapes of arrays being a concept that's distinct from both their types and from their values is something that I can't reproduce in Haskell.
Compactness is great for things that are true and work, but when there's a bug in there somewhere, terse code requires a lot of scribbling on paper.
Many programmers instead see self-documenting code as the ideal outcome: maybe not very compact, but virtually free of comments (and with documentation at least partially autogenerated).
In reality, successful open-source projects tend to have many comments in the source code. Often not one-liners, but detailed descriptions of functions, their arguments and algorithms, motivation for the choice of the implementation and so on.
From https://github.com/tlack/b-decoded
Arthur is famous for his very dense programming style. Most C programmers would scream when seeing this code.
In his view (and others in the terse scene), it is much better to have everything in your application readable on the screen at once than to have great names for things or a lot of white space to comfort the first timer reader.
To them, once you've sufficiently studied that screen or two of code, you can understand all of it at the same time. If it's spread out over thousands of files, it's very difficult to understand all of it, which leads to bugs, unnecessary abstraction, and the need for advanced tooling just to work with your own project's code.
He wants to see the code "all at once" so he can understand all of its behavior without paging around and shifting his focus to another tab, window, etc. To get there he makes a lot of tradeoffs in terms of the code formatting and naming conventions. He also, in b, creates a dense set of interlocking macros and abstractions that can make the code very hard to follow.
Critics and the uninitiated say that his code is like old school modem line noise: random punctuation intermixed with bits of understandable code. I would suggest that he's actually quite careful with the abstractions he chooses and they are actually not always the most dense, highly compressed code structures available to him. He chooses wisely and his code rewards deep study.
Interview with Arthur Whitney: https://queue.acm.org/detail.cfm?id=1531242
The key point is this; once you've sufficiently studied that screen or two of code, you can understand all of it at the same time. If it's spread out over thousands of files, it's very difficult to understand all of it,
Because there are so many interlocking concepts in code you have to keep as much as possible in your head to build up the entire picture. This is where concise, terse and direct-to-the-point code shines; nothing gets in the way of putting all the pieces of the jigsaw puzzle in front of you so you can "get" everything at a glance. A good example is K&R C style espoused in their book which i used to find difficult in the beginning but now understand. Always put as much of relevant code as possible into one screenful.
The thing is, notation is always a tool of thought. No exceptions.
Take two matrices A and B. The notation AB for the matrix product is a great thinking tool. The matrix product is so strange when first seen, but the fact that it is introduced as a product, with the same notation as the product notation for scalars, makes it so much easier to grok. Imagine that we'd had used A@B, like in Python (numpy).
> Boolean: ∨ ⍱ ~ (and, or, not-and, not-or, not)
In some places in the pdf the notation looks sketchy. But this line demonstrates beyond any doubt that the pdf is missing chars.
> In Appendix A, the list of boolean functions should be ∧ ∨ ⍲ ⍱ ~ instead of ∨ ⍱ ~
I don't mean this to be terribly dismissive: I've always been "tangentially fascinated", like I think a lot of people are, by APL and Forth. But I've never properly used it because ultimately it's in conflict with how I think programs should be written: with types, abstraction, a focus on readability etc.
Now that the ACM has made them free to access, papers from the APL conference are a good place to look to get a sense for this; APL79 was the first really huge one: https://aplwiki.com/wiki/APL_conference#1979
There was a time when APL was taught in universities, and some computers came with APL-specialized keyboards. That time came and went because the bulk of mainstream software development went in a wildly different direction.
I know you're not trying to flame, but what you've given us so far is a false claim that nobody writes code in APL, and a bare assertion that APL is a bad way to program. On that note, you're trying to say a language you've never used doesn't allow for "abstraction" or "a focus on readability", which I think is dead wrong. All of which is at best tangentially relevant to Iverson's claim in the paper (not APL's founding document, by the way; that would be A Programming Language) that APL's notation is a way to enhance your thinking. APL has good and bad aspects, and there's a lot to discuss, but can it please be a discussion instead of these careless remarks?
What helped me understand and become productive in forth was that you had the normal commands which manipulated values and are in every language, and a meta-language for manipulating the stacks. Once I made the stacks dance forth became just another language.
I don't make my way to that list as often as I'd like, but I have found plane trips and other similar times are great for when I want to do something like that. Sitting down with a longer blog post and taking notes on a 5 hour flight is oddly relaxing. So yes, to answer your question, I do get around to it eventually when the post is worthwhile.
Every once and a while I go through some[1] of it and ask myself "Will I ever actually look at this"? Sometimes there's a clear answer, but more often it stays in the list because it still looks interesting and I only consume maybe 5-10% of what I saved. There's got to be some term for this. Digital hording? It makes me anxious to have it and anxious to just delete it. There are plenty of times I do remember something I saw and wish I could find it again, but I lean too hard into "maybe I'll think about this again and want it".
[1]: It's so long I generally lose the will to even evaluate the items after a while.
(This perhaps a bit of an ADHD-specific tactic)
Ps YMMV a lot based on figures code snippets and anything illustrated so not for all content including the featured article
This also is my answer to OP. I save these articles to VDR. And when I have time to read or listen to something, I open the app. It helps that VDR shows me the length of each document in terms of reading time. When you ask me how long a particular book was, I’ll say “It’s a 12 hour book”. Really helps to put things in perspective.
I always save the HN thread when applicable rather than the link, because it gives me short hand notation and normalization for writing with a pen. Now in a paper notebook I have a few pages where each line is a theme, a word etc. Next to it write the HN ids (can as well save a comment thread; superbly useful) to reference under that theme. Done. If particularly useful I can write few words in small print over the id detailing more the subject of a link.
This is however done for a set purpose, as reference material for writing speculative and science fiction (HN is great for ideas and research) and also articles. When and whether I finally visit a link is staked on a piece and theme ever getting picked by me for writing; I find this is a great compromise and more realistic than simply hoarding.
If you want to try it for yourself id be happy to give you beta access. I'm still experimenting for the best UX.