Eli Mellen07/08/2023, 10:58 PM
Eli Mellen07/08/2023, 11:08 PM
(aka, never a tab, a million windows)A, a citizen of Siracusa county :)
Eli Mellen07/08/2023, 11:10 PM
Joshua Horowitz07/09/2023, 1:05 AM
David Alan Hjelle07/09/2023, 1:50 AM
Eli Mellen07/09/2023, 1:53 AM
Grant Forrest07/09/2023, 2:04 AM
David Alan Hjelle07/09/2023, 2:21 AM
Andrew F07/09/2023, 2:53 AM
Maybe linking the visual design to semantic meaning would help the idea fit better into the mental model of coding.I quite like this thought from @Grant Forrest. This is one of the big critiques of node-wire visual programming — it's "visual" in only the shallowest sense, because the visual design is half-devoid of semantics. The spatial arrangement of nodes has meaning to the human programmer, but not to the computer. It would be nice to play with a visual programming system that allowed for both.
For instance, indicate a function declaration by the name of the function being on its own line in larger, bolder text.This comment from @David Alan Hjelle makes me think of literate programming. I'd love to try writing in a literate language that expected rich text. I'm sure such a thing exists, I've just never used one.
Gregg Irwin07/09/2023, 4:31 AM
I started using a couple functions named
TBD: FIX: ...
for this purpose. Tooling can find them, but their argument can be anything.
, of course, is almost always an inline example, but may refer to a file, url, or hashtag. While it may make sense to change how things look, I imagine many of us remember the early days of desktop publishing, 3D borders in GUIs, circus-inspired web pages, etc. The goal is to communicate meaning and intent clearly, in context, but also let people find more information as needed or desired. So, rather than text size, what if this content became links, maybe with a preview popup? Things can be smaller, but still a paragraph long, which makes them either hard to read or take up so much space that you lose more active content. What I try to do is minimize the size of the comment content, though sometimes I still do entire paras and have 5:1 comments to code by line.
Why shouldn’t my code look as good as a professionally typeset manuscript?A good experiment would be to take a non-tiny piece of software and do this. It's largely aligned with Literate Programming, so yes it's been done. Why didn't LP win? Many reasons and mine would only be anecdotal. I love the idea in theory but, having tech edited and co-authored books, I'm much happier writing code. I'm also a lot better at it. There are two different skills at play. Another pretty easy experiment is to take a codebase and simply write a ToC and index for it, like a book would have. Consider, also, that formatting is intended to aid the reader. This is what we should all do. Who us our reader? It's not a novel, or a play, or a textbook, or a newspaper. But if we take those as examples, how much variety is there in typography? Not much. Mostly it's about structure.
Why shouldn’t my code look as good as a professionally typeset manuscript?Why should code look like manuscript? The use case and needs are very different. Code is fundamentally non-linear. I mean, to the extent that we have zero typography in code, sure, anything would be an improvement. But I think it would quickly hit diminishing returns. It would be a strategic dead end. The typographic needs of code need to be rethought from scratch.
Makes me wonder about other ways that being able to choose the size of representation in a program — independently from typical size units of code (ie: lines) — could be useful.One place I would have loved this is when I was trying to grok Lisp interpreters. The classic Lisp interpreter looks something like this:
Basically you have a large number of branches, and each of them has some complicated expression that passes
def eval(form, env): case ... -> eval(..., env) ... -> eval(..., env) ... end end
around. For more real-world codebases (like https://github.com/arclanguage/anarki or http://www.paulgraham.com/bel.html) each case might be complex enough to require a helper. In which case you now have a maze of mutually recursive calls. And often the case that actually uses
is just one line deep inside one of the helpers. All the other mentions of
exist just to plumb it through to that one line. It would be great to typeset all the mentions of
in small font size, but magnify the font size of
in that one line. And this is just one argument. If you look at Bel's source code, there's a half dozen such arguments being plumbed through in a similar pattern that would benefit from this sort of visual salience management.
Beni Cherniavsky-Paskin07/09/2023, 9:30 AM
a little pocketbook tucked into the back flap of a function?Reminds me of some paper I've seen attaching hand-written ink annotations to code. don't remember the specific paper, but found now several on Beryl Plimmer's publications, sounds like a good starting point... (I have to question the long-term accuracy of anything you can't grep, but actually handwriting recognition might mean you can, and anyway there is interesting value in enabling the kind illustrations we tend to draw on whiteboards but rarely commit.) Varying font size go nicely with zooming! Code Canvas tried quite a lot of that. Imperfect aesthetics, but some interesting gradual-reveal functionality 👍 https://eaglemode.sourceforge.net/ file manager does quite unusual UI tricks with zooming and font sizes – e.g. instead of tooltips, UI elements (buttons etc) documentation is engraved right on them in tiny font. See "project philosophy" there. And https://museapp.com/. Prototyping tips: (1) Emacs supports varying fonts. The poster child is latex but you can apply it to any kind of syntax-highlight. Plus various support for folding. (2) on the web, CodeMirror.
Joakim Ahnfelt-Rønne07/09/2023, 12:58 PM
David Alan Hjelle07/09/2023, 8:18 PM
having tech edited and co-authored books, I'm much happier writing code. I'm also a lot better at it. There are two different skills at play.I definitely think there is an element to this. I am certainly more verbose than most of my co-workers — well, oddly, maybe more verbose in issues and merge requests, and perhaps more terse in code. That said — I'm personally thinking less of literate programming and more of fancy syntax highlighting.
Mostly it's about structure.Yes, exactly! What ways can we devise to communicate that structure more effectively to our brains?
What ways can we devise to communicate that structure more effectively to our brains?Size, shape, space, similarity, sequence, segment, sound… .…smell, saturation, story, sitar, situation… …sauté, Solar, seat, seal, satire, superspirituality…
Gregg Irwin07/10/2023, 1:17 AM
Jason Morris07/10/2023, 6:57 PM
Grant Forrest07/12/2023, 3:47 PM
Grant Forrest07/12/2023, 3:49 PM
Eli Mellen07/12/2023, 4:03 PM
Grant Forrest07/12/2023, 4:12 PM
Beni Cherniavsky-Paskin07/12/2023, 4:18 PM
Andrew F07/12/2023, 4:27 PM
Eli Mellen07/12/2023, 4:28 PM
Beni Cherniavsky-Paskin07/12/2023, 4:31 PM
what if the future of coding is the friends we made on the way?I twitted that out for tools for thought. But that one works better because of the double entendre. I do think the culture is a huge part of the FOC mentality. It's why I'm personally not interested in just being a press release venue for startups building tools. We have to take a wholistic view of the way technology relates to all the aspects of the world and our life. We have to think about the ways in which the technology we makes impact people. When building new technology, it is less interesting to me what "problem it solves" and more interesting what it says. What's its viewpoint? How does it change the way people approach life and tech? That's why I'm interested in reading the papers we read. These are people thinking about this stuff, thinking about what we ought to make, and what it means. Not simply building a tool so a VC can get a bigger return on investment. We already have lots of talk about those companies and what they are doing, let's do something different.
Eli Mellen07/12/2023, 4:43 PM
Grant Forrest07/12/2023, 5:03 PM
Florian Schulz07/21/2023, 7:54 AM