6 ms·

The Smalltalk model (simplifying horribly as storing functions/code units instead of files) has significant and obvious advantages, and it's been around for 30

The Smalltalk model (simplifying horribly as storing functions/code units instead of files) has significant and obvious advantages, and it's been around for 30 years. The fact that the file model continues to dominate suggests to me that there may be significant drawbacks as well. Possibilities: * Losing the ability to use file-based tools costs too much. This is less that the function model is bad and more that existing tools happen to be file-based * The model will eventually win, it's just taking a really long time for thoughts/tools to catch up. * The model is better, but has not caught on for reason unrelated to its utility. The model is Betamax. * The file-based model is better

qznc 14y ago
I think the Smalltalk problem is that it is too different. You cannot integrate its features one by one into your workflow, but you basically have to change everything. Porting the features one by one takes a long time and sometimes the benefit seems to be low, because it only provides synergistic effects together with other features. Another example is Plan9. Some of its innovations were ported (/proc, utf8, ...), but some things probably never will (everything is a file).
wmf 14y ago
The difference is that Codeq appears to be an index, while the storage of record is still a file-based git repo. Eventually you could probably work in either representation if there's reliable round-tripping.
ken 14y ago
Garbage collection took around 40 years to become mainstream. There are lots of important concepts that the industry still ignores. I don't think that 'computer science being ignored by industry programmers for decades' is evidence of anything except the industry's own technical apathy. Personally, I think the image model is a huge win for a single programmer, while the file model makes it easier to integrate changes from a big team. (There's not really a "DVCS for images" yet.) When I look around, I see that tools that have won tend to support big teams of less-efficient programmers. So it's not really surprising to me that, by numbers, the file model dominates. That's not an indictment of the image model. What do you mean by "better"? There are more Corollas than BMW 5's on the streets here, but does that mean they're better, or worse, or better for a particular use case? I'll take the image model for building a fast prototype any day, even if I have to hand it over to a big team writing C or Java for the final product.
- gfunk911 14y ago
  You state that the image model is good for a single programmer, but not large teams. How much of this do you feel is due to the lack of tools (VCS, IDEs, etc) equipped to deal with the image model, and how much is inherent to the models?
  - ken 14y ago
    I was careful to say that the image model is great for a single programmer, but not that at was bad for large teams -- simply that large teams are a (current) strength of the file model. Large teams are built of individuals, after all, and there's no reason they can't use images on their own. There's just not much in the way of tooling (yet) to support integration at the image level. Is this limitation inherent? I think that's impossible to say. How many people accurately predicted the importance of a DVCS, before ever seeing one built? Or for that matter, a garbage collector? In cases where it's not obvious, the tools drive our understanding. I don't see anything inherent in image models that would prevent this, though languages don't seem designed in a way that would make this particularly easy. For example, right now we're collaboratively editing a (very simple) shared image (HN).
- rprospero 14y ago
  Where do you see the advantages of the image model for a single programmer? I ask because, when I've played around with image based languages, I hated them. However, I've encountered programmers vastly wiser than myself who seem to love it, so I suspect that I'm missing something important.
jcromartie 14y ago
I think that Lisp actually strikes a great balance here. The data structures that represent programs are simple and unambiguous, and they serialize to text files absolutely trivially. We should be able to work with code-as-data while making use of text-based persistence and versioning.
- jimbokun 14y ago
  Maybe if someone invented a "new" programming language where programs were valid JSON, without mentioning the obvious connection to Lisp, programmers could be tricked into using it. Programmers seem to love adopting the features of Lisp, as long as they can re-assure themselves they are not actually programming in Lisp.
  - maaku 14y ago
    MISC might be of relevance here: http://lambda-the-ultimate.org/node/2887 http://lambda-the-ultimate.org/node/2887 EDIT: And for the record, I actually think it's a brilliant idea.
  - tomjakubowski 14y ago
    Srikumar K.S's jexpr is an experimental (and it seems abandoned) attempt at doing just this: http://srikumarks.github.com/jexpr/ http://srikumarks.github.com/jexpr/ {do: [ {fetchURL: "http://some.data.source/", timeout: 30.0, onfail: {raiseError: "URL not reachable"}}, {fork: [ {displayInElement: "element_id"}, {cacheInLocalStorage: "prefix"} ]}]} more here: http://srikumarks.github.com/gyan/2012/04/15/j-expressions/ http://srikumarks.github.com/gyan/2012/04/15/j-expressions/ http://srikumarks.github.com/gyan/2012/04/14/creating-dsls-in-javascript-using-j-expressions/ http://srikumarks.github.com/gyan/2012/04/14/creating-dsls-i...
    - darkxanthos 14y ago
      Wow this is pretty great! Never knew about this and might play with it some. Thanks!
deleted 14y ago
[deleted]
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.
jeremyjh 14y ago
Maybe I misunderstand, but I thought Codeq is more of an analysis tool. Your code would still be files in a git repo.
- snprbob86 14y ago
  "The resulting database is highly programmable, and can serve as infrastructure for editors, IDEs, code browsing, analysis and documentation tools." The mere mention of editors and IDEs suggests to me that they envision analysis as the gateway drug.
pshc 14y ago
The structured model will win. It only needs a real high-quality editor. Not a hokey drag-and-drop toy, but a tool that scales to real-world problems and addresses the way code evolves through time.
tamasnet 14y ago
I think your first possibility is most likely (which implies that the fourth is too, de facto). When I started coding professionally I used IBM's VisualAge for Java (which was actually a multi-language tool based on Smalltalk) and it did exactly that: all Java classes were managed as code artefacts held in the IDE's internal repository. You had to export from the IDE if you wanted your standard files-in-directores source/objects. It worked very naturally and when IBM moved to Eclipse instead I found it to be quite a step backwards in terms of working with my code. But the drawback was was you could do exactly what the VisualAge IDE supported and not much more. The file-based model gives a level of low-cost interoperability that's pretty hard to beat.

qznc 14y ago

I think the Smalltalk problem is that it is too different. You cannot integrate its features one by one into your workflow, but you basically have to change everything. Porting the features one by one takes a long time and sometimes the benefit seems to be low, because it only provides synergistic effects together with other features. Another example is Plan9. Some of its innovations were ported (/proc, utf8, ...), but some things probably never will (everything is a file).

wmf 14y ago

The difference is that Codeq appears to be an index, while the storage of record is still a file-based git repo. Eventually you could probably work in either representation if there's reliable round-tripping.

ken 14y ago

Garbage collection took around 40 years to become mainstream. There are lots of important concepts that the industry still ignores. I don't think that 'computer science being ignored by industry programmers for decades' is evidence of anything except the industry's own technical apathy. Personally, I think the image model is a huge win for a single programmer, while the file model makes it easier to integrate changes from a big team. (There's not really a "DVCS for images" yet.) When I look around, I see that tools that have won tend to support big teams of less-efficient programmers. So it's not really surprising to me that, by numbers, the file model dominates. That's not an indictment of the image model. What do you mean by "better"? There are more Corollas than BMW 5's on the streets here, but does that mean they're better, or worse, or better for a particular use case? I'll take the image model for building a fast prototype any day, even if I have to hand it over to a big team writing C or Java for the final product.

gfunk911 14y ago
You state that the image model is good for a single programmer, but not large teams. How much of this do you feel is due to the lack of tools (VCS, IDEs, etc) equipped to deal with the image model, and how much is inherent to the models?
- ken 14y ago
  I was careful to say that the image model is great for a single programmer, but not that at was bad for large teams -- simply that large teams are a (current) strength of the file model. Large teams are built of individuals, after all, and there's no reason they can't use images on their own. There's just not much in the way of tooling (yet) to support integration at the image level. Is this limitation inherent? I think that's impossible to say. How many people accurately predicted the importance of a DVCS, before ever seeing one built? Or for that matter, a garbage collector? In cases where it's not obvious, the tools drive our understanding. I don't see anything inherent in image models that would prevent this, though languages don't seem designed in a way that would make this particularly easy. For example, right now we're collaboratively editing a (very simple) shared image (HN).
rprospero 14y ago
Where do you see the advantages of the image model for a single programmer? I ask because, when I've played around with image based languages, I hated them. However, I've encountered programmers vastly wiser than myself who seem to love it, so I suspect that I'm missing something important.

jcromartie 14y ago

I think that Lisp actually strikes a great balance here. The data structures that represent programs are simple and unambiguous, and they serialize to text files absolutely trivially. We should be able to work with code-as-data while making use of text-based persistence and versioning.

jimbokun 14y ago
Maybe if someone invented a "new" programming language where programs were valid JSON, without mentioning the obvious connection to Lisp, programmers could be tricked into using it. Programmers seem to love adopting the features of Lisp, as long as they can re-assure themselves they are not actually programming in Lisp.
- maaku 14y ago
  MISC might be of relevance here: http://lambda-the-ultimate.org/node/2887 http://lambda-the-ultimate.org/node/2887 EDIT: And for the record, I actually think it's a brilliant idea.
- tomjakubowski 14y ago
  Srikumar K.S's jexpr is an experimental (and it seems abandoned) attempt at doing just this: http://srikumarks.github.com/jexpr/ http://srikumarks.github.com/jexpr/ {do: [ {fetchURL: "http://some.data.source/", timeout: 30.0, onfail: {raiseError: "URL not reachable"}}, {fork: [ {displayInElement: "element_id"}, {cacheInLocalStorage: "prefix"} ]}]} more here: http://srikumarks.github.com/gyan/2012/04/15/j-expressions/ http://srikumarks.github.com/gyan/2012/04/15/j-expressions/ http://srikumarks.github.com/gyan/2012/04/14/creating-dsls-in-javascript-using-j-expressions/ http://srikumarks.github.com/gyan/2012/04/14/creating-dsls-i...
  - darkxanthos 14y ago
    Wow this is pretty great! Never knew about this and might play with it some. Thanks!

deleted 14y ago

[deleted]

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.

jeremyjh 14y ago

Maybe I misunderstand, but I thought Codeq is more of an analysis tool. Your code would still be files in a git repo.

snprbob86 14y ago
"The resulting database is highly programmable, and can serve as infrastructure for editors, IDEs, code browsing, analysis and documentation tools." The mere mention of editors and IDEs suggests to me that they envision analysis as the gateway drug.

pshc 14y ago

The structured model will win. It only needs a real high-quality editor. Not a hokey drag-and-drop toy, but a tool that scales to real-world problems and addresses the way code evolves through time.

tamasnet 14y ago

I think your first possibility is most likely (which implies that the fourth is too, de facto). When I started coding professionally I used IBM's VisualAge for Java (which was actually a multi-language tool based on Smalltalk) and it did exactly that: all Java classes were managed as code artefacts held in the IDE's internal repository. You had to export from the IDE if you wanted your standard files-in-directores source/objects. It worked very naturally and when IBM moved to Eclipse instead I found it to be quite a step backwards in terms of working with my code. But the drawback was was you could do exactly what the VisualAge IDE supported and not much more. The file-based model gives a level of low-cost interoperability that's pretty hard to beat.