17 ms·

Perhaps this project shows that file vs image is, in fact, a false dichotomy. Instead of replacing our current file-based workflows with a monolithic image, thi

by ths 14y ago

Perhaps this project shows that file vs image is, in fact, a false dichotomy. Instead of replacing our current file-based workflows with a monolithic image, this kind of tool could provide all the image functionality on top of the file structure. This model is no more difficult for large teams than the file-based one, since in that respect the database/query engine/tools they describe have the same essential ingredients for this as Git has, and one could envision a similar toolchain (push/pull/Github etc. for the database instead of the Git repo) emerging for a system like this. Best of both worlds? In many ways, it feels like the next step for the ideas that make Git great: why not add language semantics and query capabilities and take things to the next level?

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 ths 14y ago

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).