5 ms·

As a happy user of vim + fugitive¹, git² serves as a bold abstraction of my code in exactly this fashion. I do not think of files as anything but eponymous cont

by guns 14y ago

As a happy user of vim + fugitive¹, git² serves as a bold abstraction of my code in exactly this fashion. I do not think of files as anything but eponymous containers of namespaces. Git blame, for instance, allows tracking lines across file renames, and tpope's wonderful vim interface actually makes this easy to use. I enjoy git on the command line, but _tight_ integration with the editor is an almost sublime experience. So git's well-defined data structure already enables quite a bit of editor magic, but Codeq's extra layer of abstraction is very intriguing. Also, the fact that you can query the engine and get back simple data compares favorably to the mishmash of shelling out and git object parsing done by many tools today. WRT Smalltalk's image, code management is only one of its marquee features, so I think Smalltalkers would object to calling image vs files a false dichotomy. The image is more akin to a versioned virtual machine than an SCM. I've never known the magic of the image (or a Lisp machine), so I lack an opinion on which is superior. ¹ Drew Neil's excellent video introductions to fugitive: http://vimcasts.org/episodes/archive http://vimcasts.org/episodes/archive (April/May 2011) ² and other _content_ tracking DVCSs

ths 14y ago
WRT Smalltalk's image, code management is only one of its marquee features, so I think Smalltalkers would object to calling image vs files a false dichotomy. Yeah, I agree. That was inaccurate on my part. What I said really only applies to the code management side.
sedachv 14y ago
> I've never known the magic of the image (or a Lisp machine), so I lack an opinion on which is superior. None of the Lisp machines really had image-based development. The MIT ones all had an Emacs that worked on text source files. You'd boot into a system image, but that was more like a kernel binary, than the Smalltalk image with a class browser. Interlisp had a structured editor that worked on s-expressions in memory, kind of like the Smalltalk class browser, but these were saved to files (the system would automatically track which definitions were saved in which files, and could tell you about changes: http://larry.masinter.net/interlisp-ieee.pdf http://larry.masinter.net/interlisp-ieee.pdf).

by guns 14y ago

ths 14y ago

WRT Smalltalk's image, code management is only one of its marquee features, so I think Smalltalkers would object to calling image vs files a false dichotomy. Yeah, I agree. That was inaccurate on my part. What I said really only applies to the code management side.

sedachv 14y ago

> I've never known the magic of the image (or a Lisp machine), so I lack an opinion on which is superior. None of the Lisp machines really had image-based development. The MIT ones all had an Emacs that worked on text source files. You'd boot into a system image, but that was more like a kernel binary, than the Smalltalk image with a class browser. Interlisp had a structured editor that worked on s-expressions in memory, kind of like the Smalltalk class browser, but these were saved to files (the system would automatically track which definitions were saved in which files, and could tell you about changes: http://larry.masinter.net/interlisp-ieee.pdf http://larry.masinter.net/interlisp-ieee.pdf).