3 ms·

Ah, just saw your edit. I'm not sure what you mean by 'temporary', but there's two axes here: a) Is the formatting saved across restarts? b) Is the formatting

Ah, just saw your edit. I'm not sure what you mean by 'temporary', but there's two axes here: a) Is the formatting saved across restarts? b) Is the formatting customized for tiny parts of a file? What I'm looking for is 'temporary' for b) but 'permanent' for a). > This also brings me to my observation that there's literally zero tools out there for _reading_ code. Something I'd love to change, and I keep gathering ideas, but I sadly lack time ATM to make even a proof-of-concept. That is very close to my heart, though my theory is that reading code only becomes easier when the very representation of software projects undergoes a sea change: http://akkartik.name/about http://akkartik.name/about. I'd love to hear your thoughts!

akkartik 10y ago
As an example of persistent-but-customized, check out this plugin of mine (in an inferior editor, sadly ;) which lets me highlight specific words in a random but persistent color: https://www.reddit.com/r/programming/comments/1w76um/coding_in_color/cezpios https://www.reddit.com/r/programming/comments/1w76um/coding_.... When I'm reading a strange codebase, finding a couple of key variables to colorize immediately causes the data flow of a function to "pop out" to my eyes.
- TeMPOraL 10y ago
  Nice work on a plugin. I still have that experimental buffer opened, so I used the features for highlighting I described to highlight words "let", "buffer" and "create" with highlight-symbol-at-point, and the lines containing word "foo" with highlight-line-matching-regexp: http://i.imgur.com/ubXumzK.png http://i.imgur.com/ubXumzK.png The last four lines were generated by calling M-x hi-lock-write-interactive-patterns. If you save them in the file, Emacs can reload and reapply those highlights in the future. I use it mostly when browsing log files, though the feature is useful for code too. Since I'm addicted to traditional syntax highlighting, I prefer the background change when highlighting code.
  - akkartik 10y ago
    Yeah, I think what you showed is exactly what my plugin was going for. To get more fine-grained than that we'd need a smarter editor that understands markup. Fun conversation! I just shot you an email.
TeMPOraL 10y ago
Re a) and b), I replied below your comment about your Vim plugin. > That is very close to my heart, though my theory is that reading code only becomes easier when the very representation of software projects undergoes a sea change: http://akkartik.name/about http://akkartik.name/about. I'd love to hear your thoughts! I read the page you linked (though I didn't browse the other parts it links to - I'll have to leave that for later). Quite a lot of interesting ideas you have there. I've added the Mu project to check out later. It seems we have similar general goals in mind, but different ideas of making it happen. You seem to be focusing on how to change the programming practice to facilitate understanding of large codebases. I am thinking more along the lines of tools that would help one explore and get the picture of existing codebases in current languages. So far, I've briefly explored areas like: - software for generating diagrams of the code - software for generating runtime diagrams - time travelling debuggers - printing out code on paper (per edw519's advice) and annotating it - annotating code in PDF readers and word processors I think what resonates with me most in the text you linked is "Deemphasize abstractions in favor of traces". I actually went into the first three bullet points of mine because I had to refactor some code that I couldn't figure out the exact flow of. What I wanted was exactly the "trace" of execution I could inspect. Unfortunately, the time travelling debuggers I tested are too heavy for the task, and don't present the trace itself in any way, they just allow you to navigate it. A dream tool I'd love to have would be a "read-only" IDE for code, that would let me quickly move around the project with semantic commands ("jump to definition", etc.) and annotate stuff. I want to take notes, highlight stuff in colors, even draw on the code. Kind of a combination of a good IDE and annotation facilities of a PDF reader. I have a lot of thoughts on the subject; I guess I should publish them somewhere at some point :).
- akkartik 10y ago
  We certainly should continue chatting :) "A dream tool I'd love to have would be a "read-only" IDE for code, that would let me quickly move around the project with semantic commands ("jump to definition", etc.) and annotate stuff. I want to take notes, highlight stuff in colors, even draw on the code. Kind of a combination of a good IDE and annotation facilities of a PDF reader." Yeah, I spent a few years thinking about a "wikipedia for code" which is almost exactly what you describe. But I eventually gave up on it for 2 reasons: a) I started learning about the benefits of tests, and I noticed that this idea doesn't really have a good answer to how to make use of tests for reading. b) I started noticing that in large teams and over time a good tool contains within it the seeds of its own demise. It's a little like creating roads to relieve traffic: for a while things are good, but then people start buying more cars (at least in the US), and eventually traffic is as bad as it used to be. In software, for example, high-level languages make it easier to declare function arguments (compared to say Basic's GOSUB), but now programmers start creating functions with 20 arguments, and that is as bad if not worse than GOSUB. Inheritance makes some kinds of control flow easier but also causes new kinds of spaghetti code. And so on and on.. These are the reasons why I stopped thinking in terms of just a tool. A tool helps existing habits, but loses control of new habits created around the tool. Changing practice, on the other hand, would affect both sides of the feedback loop. Instead of a vicious cycle of new abstractions (language features or tools) that hide details from the user and cause users to abuse them, I'd like to trigger a virtuous cycle where using a tool gradually makes you more likely to understand its internals. Lisp macros have that property: after using them for a few months I was surprised to find when I built a lisp interpreter how easy implementing macroexpansion was. It was as if macros were a (benign) virus that planted themselves in my brain as I used them. I'd like to create more such viruses :) It's a slower approach to changing things than creating a tool, it's true. But I think there's a lot more upside in the long run.

akkartik 10y ago

As an example of persistent-but-customized, check out this plugin of mine (in an inferior editor, sadly ;) which lets me highlight specific words in a random but persistent color: https://www.reddit.com/r/programming/comments/1w76um/coding_in_color/cezpios https://www.reddit.com/r/programming/comments/1w76um/coding_.... When I'm reading a strange codebase, finding a couple of key variables to colorize immediately causes the data flow of a function to "pop out" to my eyes.

TeMPOraL 10y ago
Nice work on a plugin. I still have that experimental buffer opened, so I used the features for highlighting I described to highlight words "let", "buffer" and "create" with highlight-symbol-at-point, and the lines containing word "foo" with highlight-line-matching-regexp: http://i.imgur.com/ubXumzK.png http://i.imgur.com/ubXumzK.png The last four lines were generated by calling M-x hi-lock-write-interactive-patterns. If you save them in the file, Emacs can reload and reapply those highlights in the future. I use it mostly when browsing log files, though the feature is useful for code too. Since I'm addicted to traditional syntax highlighting, I prefer the background change when highlighting code.
- akkartik 10y ago
  Yeah, I think what you showed is exactly what my plugin was going for. To get more fine-grained than that we'd need a smarter editor that understands markup. Fun conversation! I just shot you an email.

TeMPOraL 10y ago

Re a) and b), I replied below your comment about your Vim plugin. > That is very close to my heart, though my theory is that reading code only becomes easier when the very representation of software projects undergoes a sea change: http://akkartik.name/about http://akkartik.name/about. I'd love to hear your thoughts! I read the page you linked (though I didn't browse the other parts it links to - I'll have to leave that for later). Quite a lot of interesting ideas you have there. I've added the Mu project to check out later. It seems we have similar general goals in mind, but different ideas of making it happen. You seem to be focusing on how to change the programming practice to facilitate understanding of large codebases. I am thinking more along the lines of tools that would help one explore and get the picture of existing codebases in current languages. So far, I've briefly explored areas like: - software for generating diagrams of the code - software for generating runtime diagrams - time travelling debuggers - printing out code on paper (per edw519's advice) and annotating it - annotating code in PDF readers and word processors I think what resonates with me most in the text you linked is "Deemphasize abstractions in favor of traces". I actually went into the first three bullet points of mine because I had to refactor some code that I couldn't figure out the exact flow of. What I wanted was exactly the "trace" of execution I could inspect. Unfortunately, the time travelling debuggers I tested are too heavy for the task, and don't present the trace itself in any way, they just allow you to navigate it. A dream tool I'd love to have would be a "read-only" IDE for code, that would let me quickly move around the project with semantic commands ("jump to definition", etc.) and annotate stuff. I want to take notes, highlight stuff in colors, even draw on the code. Kind of a combination of a good IDE and annotation facilities of a PDF reader. I have a lot of thoughts on the subject; I guess I should publish them somewhere at some point :).

akkartik 10y ago
We certainly should continue chatting :) "A dream tool I'd love to have would be a "read-only" IDE for code, that would let me quickly move around the project with semantic commands ("jump to definition", etc.) and annotate stuff. I want to take notes, highlight stuff in colors, even draw on the code. Kind of a combination of a good IDE and annotation facilities of a PDF reader." Yeah, I spent a few years thinking about a "wikipedia for code" which is almost exactly what you describe. But I eventually gave up on it for 2 reasons: a) I started learning about the benefits of tests, and I noticed that this idea doesn't really have a good answer to how to make use of tests for reading. b) I started noticing that in large teams and over time a good tool contains within it the seeds of its own demise. It's a little like creating roads to relieve traffic: for a while things are good, but then people start buying more cars (at least in the US), and eventually traffic is as bad as it used to be. In software, for example, high-level languages make it easier to declare function arguments (compared to say Basic's GOSUB), but now programmers start creating functions with 20 arguments, and that is as bad if not worse than GOSUB. Inheritance makes some kinds of control flow easier but also causes new kinds of spaghetti code. And so on and on.. These are the reasons why I stopped thinking in terms of just a tool. A tool helps existing habits, but loses control of new habits created around the tool. Changing practice, on the other hand, would affect both sides of the feedback loop. Instead of a vicious cycle of new abstractions (language features or tools) that hide details from the user and cause users to abuse them, I'd like to trigger a virtuous cycle where using a tool gradually makes you more likely to understand its internals. Lisp macros have that property: after using them for a few months I was surprised to find when I built a lisp interpreter how easy implementing macroexpansion was. It was as if macros were a (benign) virus that planted themselves in my brain as I used them. I'd like to create more such viruses :) It's a slower approach to changing things than creating a tool, it's true. But I think there's a lot more upside in the long run.