4 ms·

Did anyone ever think that maybe the problem is the FILES? Let me ask that one more time. Would people be ranting like this if there were NO FILES? I still b

Did anyone ever think that maybe the problem is the FILES? Let me ask that one more time. Would people be ranting like this if there were NO FILES? I still believe the "future of programming" is where your code objects are not arbitrarily mapped onto files in the file system, you just manipulate them directly! A few Smalltalks and Lisps out there do this using image-based development. This is where it's at. If you can't use a image-based Smalltalk or Lisp to get your work done, then use a JetBrains/Eclipse IDE. They're generally modeled off of the Smalltalk IDE and are the next best thing if you're forced to use a broken file-based language. If you just take "files" for granted and think that the UNIX design philosophy is the best thing ever, then accept your fate and stop bitching.

duck 17y ago
Not exactly no files, but I think the bubble concept could solve this too. http://www.cs.brown.edu/people/acb/codebubbles_site.htm http://www.cs.brown.edu/people/acb/codebubbles_site.htm http://news.ycombinator.com/item?id=1181742 http://news.ycombinator.com/item?id=1181742
plinkplonk 17y ago
" If you can't use a image-based Smalltalk or Lisp to get your work done, then use a JetBrains/Eclipse IDE. They're generally modeled off of the Smalltalk IDE and are the next best thing if you're forced to use a broken file-based language." I've worked in smalltalk, and yes it is an interesting way to work but images had almost as many problems as hey solved. primarily version controlling and syncing code were terrible (yes there were some tools, and yes they all broke on weird edge cases). If forced to choose these days, I'd rather use files + git + (+ emacs + grep + ... ) than images, Images are nice as an additional dev time artifact, but I believe files are more natural than images for source code. "If you just take "files" for granted and think that the UNIX design philosophy is the best thing ever, then accept your fate and stop bitching." This is provocative nonsense. smalltalk, while hugely influential and innovative is hardly the ultimate superior dev env that some old geezers make it out to be. I think it is mostly "the lost cause" style romanticism.
- blasdel 17y ago
  That's just the thing, git doesn't give a shit about files internally, it tracks the content instead and uses heuristics to figure out the file metadata. Files and their artifacts do show up everywhere in git's UIs, because noone's found a better model yet of exposing the content to the user.
MartinCron 17y ago
Related: Using Visual Studio + ReSharper, I can just press CTRL + N and start typing the name of the type I want to go to. CTRL + ALT + SHIFT + N (seriously) and I can start typing the name of the method, variable, whatever. With both of these, you can use wildcards or PascalCase caps, it's really, really fast. I hardly ever use the solution explorer anymore. The fact that the types I'm working in exist in files is something I barely pay attention to.
- futuremint 17y ago
  This is similar to the "browse implementor" or "find senders" in smalltalk, or "Find Usages" and "Browse Implementation" in IntelliJ (I use RubyMine). You navigate the code, not the files. I've found I can concentrate on the design of the software a lot better when I'm not also worrying which subdirs certain files are in.
pshc 17y ago
I agree with your post. That said, maybe the problem is the text. There are many artificial problems we create for ourselves by using strings for everything. Programming languages in particular have upper limits on expressiveness due to syntax issues. We can't easily annotate expressions or types with extra details without filling the screen with symbols; characters don't scale. Keying every resource with a unique human-readable string causes import conflicts, broken backwards compatibility, and hundred-line diffs - all in the name of renaming one function. Mistakes like ambiguous identifier-scope lookups, block structure/indentation mismatches, and operator precedence issues eat up valuable programmer hours repeatedly, in exactly the same way each time. We've designed better languages to mitigate these effects, but we can only do so much. We can do static analysis to catch common errors and incremental compilation in the editor itself, but the heuristics can only work in a fraction of innumerable cases. Even simple syntax highlighting is intractable in many cases. If we programmed in structure with an AST-aware editor, whole classes of artificial problems would vanish in an instant. (To be replaced by the UI issues of a whole different paradigm in editors...) Well, there are plenty of people working toward this, myself included. We'll see.

duck 17y ago

Not exactly no files, but I think the bubble concept could solve this too. http://www.cs.brown.edu/people/acb/codebubbles_site.htm http://www.cs.brown.edu/people/acb/codebubbles_site.htm http://news.ycombinator.com/item?id=1181742 http://news.ycombinator.com/item?id=1181742

plinkplonk 17y ago

" If you can't use a image-based Smalltalk or Lisp to get your work done, then use a JetBrains/Eclipse IDE. They're generally modeled off of the Smalltalk IDE and are the next best thing if you're forced to use a broken file-based language." I've worked in smalltalk, and yes it is an interesting way to work but images had almost as many problems as hey solved. primarily version controlling and syncing code were terrible (yes there were some tools, and yes they all broke on weird edge cases). If forced to choose these days, I'd rather use files + git + (+ emacs + grep + ... ) than images, Images are nice as an additional dev time artifact, but I believe files are more natural than images for source code. "If you just take "files" for granted and think that the UNIX design philosophy is the best thing ever, then accept your fate and stop bitching." This is provocative nonsense. smalltalk, while hugely influential and innovative is hardly the ultimate superior dev env that some old geezers make it out to be. I think it is mostly "the lost cause" style romanticism.

blasdel 17y ago
That's just the thing, git doesn't give a shit about files internally, it tracks the content instead and uses heuristics to figure out the file metadata. Files and their artifacts do show up everywhere in git's UIs, because noone's found a better model yet of exposing the content to the user.

MartinCron 17y ago

Related: Using Visual Studio + ReSharper, I can just press CTRL + N and start typing the name of the type I want to go to. CTRL + ALT + SHIFT + N (seriously) and I can start typing the name of the method, variable, whatever. With both of these, you can use wildcards or PascalCase caps, it's really, really fast. I hardly ever use the solution explorer anymore. The fact that the types I'm working in exist in files is something I barely pay attention to.

futuremint 17y ago
This is similar to the "browse implementor" or "find senders" in smalltalk, or "Find Usages" and "Browse Implementation" in IntelliJ (I use RubyMine). You navigate the code, not the files. I've found I can concentrate on the design of the software a lot better when I'm not also worrying which subdirs certain files are in.

pshc 17y ago

I agree with your post. That said, maybe the problem is the text. There are many artificial problems we create for ourselves by using strings for everything. Programming languages in particular have upper limits on expressiveness due to syntax issues. We can't easily annotate expressions or types with extra details without filling the screen with symbols; characters don't scale. Keying every resource with a unique human-readable string causes import conflicts, broken backwards compatibility, and hundred-line diffs - all in the name of renaming one function. Mistakes like ambiguous identifier-scope lookups, block structure/indentation mismatches, and operator precedence issues eat up valuable programmer hours repeatedly, in exactly the same way each time. We've designed better languages to mitigate these effects, but we can only do so much. We can do static analysis to catch common errors and incremental compilation in the editor itself, but the heuristics can only work in a fraction of innumerable cases. Even simple syntax highlighting is intractable in many cases. If we programmed in structure with an AST-aware editor, whole classes of artificial problems would vanish in an instant. (To be replaced by the UI issues of a whole different paradigm in editors...) Well, there are plenty of people working toward this, myself included. We'll see.