5 ms·

> I'm not saying you're lying but maybe they misspoke or you misremembered. No, that dev never did any serious image editing. He was just full of himself and o

> I'm not saying you're lying but maybe they misspoke or you misremembered. No, that dev never did any serious image editing. He was just full of himself and of the "superior UNIX philosophy", the thought that there might be domains where that doesn't apply just never crossed his mind (image/audio/video editing being a major one)

kragen 7y ago
Vim does not use the Unix philosophy. It is an Amiga program ported to Unix, designed along the lines of Emacs, which also does not use the Unix philosophy. You would think he would have noticed that his text editor was a domain where he wasn't applying the superior Unix philosophy. I'm not convinced that the Unix philosophy doesn't apply to image and video editing, but certainly we haven't seen an example (aside from filters, which work well in things like netpbm and Khoros, but I mean for actual interactive drawing and editing.) And certainly the performance cost of the Unix approach was infeasible in 1988, when Thomas Knoll wrote Photoshop. Still, the tree-structured pipeline structure of CAD models in FreeCAD, SolidWorks, and CATIA suggests that it might be a productive approach with enough work. We have seen the Vim philosophy applied to video editing, with great success; that's Blender.
- investinme 7y ago
  I was talking more about the GUI/command line divide. SolidWorks/Blender are fundamentally GUI apps, even if they do contain some programmatic features (like parametric filters/models/...). Also, all media software have something like "Unix tools who do one thing well" - plugins, filters, ..., but you compose them using the GUI.
  - kragen 7y ago
    It sounds like you're being confused by the surface appearance of things, rather than paying attention to their fundamental nature. Maybe that's why you weren't able to understand the arrogant Vim guy's utterance and wrote him off as delusional instead of figuring out in what sense he might be saying something true. It's good that you did figure it out eventually even if you couldn't hear it from him. Unix wasn't distinguished from other contemporary systems by not using a GUI. With a few visionary exceptions like NLS/Augment, SKETCHPAD, Spacewar!, and GENESYS, computers didn't have GUIs when Unix was born. The Unix philosophy wasn't about using textual commands. Every computer used textual commands except desk calculators. It was about a uniform interface that permits unrestricted composition of orthogonal software components, easy and expressive automation of routine tasks, and prioritizing usability over absolute computational efficiency. These are not, to put it mildly, Photoshop’s strong points.
    - investinme 7y ago
      I understand your point about Vim not following Unix philosophy, also the way Vim and Blender are similar. I disagree that the GUI/command line divide is a "surface appearance". I'm not talking about Vim/VS Code kind of thing, where one is implemented in the command line, the other in the GUI, but are basically the same. I'm talking about apps which fundamentally require a pointing device. In Photoshop you point at a pixel and say "do something here", in command line ImageMagick you say "x=100 y=200". This is not a trivial difference to me, it changes everything and generates different usage scenarios.
      - kragen 7y ago
        Vim is not a command-line program. It's a screen editor. The command-line equivalents are Perl, ex, and sed. I agree that writing +100+200x17x25 is a terrible UI design for drawing. But you’ll notice that Vim doesn't use such an interaction design for text; and typing the 100 and 200 into the properties box of a Quartz Composer processing node doesn't make it any better. So it sounds like you're attacking a straw man, maybe unintentionally.
        investinme 7y ago
        I'm not sure what I'm attacking, certainly not Vim. I'm just saying that you can perfectly use Vim without a mouse, in fact most guides recommend you to disable mouse (and cursor) support. But you can't use Photoshop or Blender without a mouse. Sure, you technically can, in a limited way, you can for example crop images or apply global filters in PS with just the keyboard, the same in Blender, but certain core manipulations are impossible in both without a mouse. I would argue that it's because of the much higher resolution of images/3d data. 80x50 with a 100 character alphabet versus 2000x2000 with a 16.7 mil alphabet. In Vim you say "move the cursor after 'func'". How would that work in Photoshop? "move the cursor after RGB(25, 15, 9) RGB(98, 126, 22)?" You can't even see the pixels in PS, let alone guess their values. There are pixel art editors which are completely usable with just the keyboard, but they are used for images smaller than 256x256.
        7y ago
- Aloha 7y ago
  How is vim significantly less unix like than vi? The user interfaces are near identical and vi is very unix in philosophy and originated on unix.
  - kragen 7y ago
    EMACS was the extensible, customizable, self-documenting display editor, that did hairy things like turn your compiler error messages into hypertext and syntax-highlight your code—a massive amount of functionality tied up in a single garbage-collected process with an embedded scripting language, with potentially hundreds of files open at once. It came from ITS and Multics, where it provided not only an IDE but windows, on text terminals. It inhabited Unix systems uneasily, like the giant flying saucer in Independence Day, provoking complaints from co-workers that you were hogging megabytes of memory and making the VAX slow. vi, by contrast, was just a display editor. If you wanted to refill a paragraph in your email, you typed !}fmt to pipe it to fmt, an external process. To reformat a block of C, you could use !%indent. (And you could map a key to this as a keyboard macro.) If you wanted to script some editing, you might emit an ex or ed script, probably from a shell script. If you wanted to concurrently edit a second file, you would start a separate vi process. You could run it on a PDP-11, where no process could exceed 64K. Unix philosophy: tiny tools, loosely coupled—though vi was a bit on the fat side in order to get WYSIWYG instantly responsive editing like Bravo, Smalltalk, or EMACS. Vim is an extensible, customizable, self-documenting display editor, that does hairy things like turning your compiler error messages into hypertext and syntax-highlighting your code—a massive amount of functionality tied up in a single garbage-collected process with many embedded scripting languages, with potentially hundreds of files open at once, using megabytes of memory. If you want to refill a paragraph in Vim, you probably type gq}, which invokes Vim’s internal paragraph-filling code, not an external process. It uses the vi command set, with enhancements, but not the vi design. Not that that's a bad thing. I greatly prefer Vim to vi. I've been using EMACS since 1990 or so and vi and Vim since 1996—I couldn't afford to wait 30 seconds for EMACS to load over NFS on my SPARC 5 every time I wanted to reply to a mail.

kragen 7y ago

Vim does not use the Unix philosophy. It is an Amiga program ported to Unix, designed along the lines of Emacs, which also does not use the Unix philosophy. You would think he would have noticed that his text editor was a domain where he wasn't applying the superior Unix philosophy. I'm not convinced that the Unix philosophy doesn't apply to image and video editing, but certainly we haven't seen an example (aside from filters, which work well in things like netpbm and Khoros, but I mean for actual interactive drawing and editing.) And certainly the performance cost of the Unix approach was infeasible in 1988, when Thomas Knoll wrote Photoshop. Still, the tree-structured pipeline structure of CAD models in FreeCAD, SolidWorks, and CATIA suggests that it might be a productive approach with enough work. We have seen the Vim philosophy applied to video editing, with great success; that's Blender.

investinme 7y ago
I was talking more about the GUI/command line divide. SolidWorks/Blender are fundamentally GUI apps, even if they do contain some programmatic features (like parametric filters/models/...). Also, all media software have something like "Unix tools who do one thing well" - plugins, filters, ..., but you compose them using the GUI.
- kragen 7y ago
  It sounds like you're being confused by the surface appearance of things, rather than paying attention to their fundamental nature. Maybe that's why you weren't able to understand the arrogant Vim guy's utterance and wrote him off as delusional instead of figuring out in what sense he might be saying something true. It's good that you did figure it out eventually even if you couldn't hear it from him. Unix wasn't distinguished from other contemporary systems by not using a GUI. With a few visionary exceptions like NLS/Augment, SKETCHPAD, Spacewar!, and GENESYS, computers didn't have GUIs when Unix was born. The Unix philosophy wasn't about using textual commands. Every computer used textual commands except desk calculators. It was about a uniform interface that permits unrestricted composition of orthogonal software components, easy and expressive automation of routine tasks, and prioritizing usability over absolute computational efficiency. These are not, to put it mildly, Photoshop’s strong points.
  - investinme 7y ago
    I understand your point about Vim not following Unix philosophy, also the way Vim and Blender are similar. I disagree that the GUI/command line divide is a "surface appearance". I'm not talking about Vim/VS Code kind of thing, where one is implemented in the command line, the other in the GUI, but are basically the same. I'm talking about apps which fundamentally require a pointing device. In Photoshop you point at a pixel and say "do something here", in command line ImageMagick you say "x=100 y=200". This is not a trivial difference to me, it changes everything and generates different usage scenarios.
    - kragen 7y ago
      Vim is not a command-line program. It's a screen editor. The command-line equivalents are Perl, ex, and sed. I agree that writing +100+200x17x25 is a terrible UI design for drawing. But you’ll notice that Vim doesn't use such an interaction design for text; and typing the 100 and 200 into the properties box of a Quartz Composer processing node doesn't make it any better. So it sounds like you're attacking a straw man, maybe unintentionally.
      - investinme 7y ago
        I'm not sure what I'm attacking, certainly not Vim. I'm just saying that you can perfectly use Vim without a mouse, in fact most guides recommend you to disable mouse (and cursor) support. But you can't use Photoshop or Blender without a mouse. Sure, you technically can, in a limited way, you can for example crop images or apply global filters in PS with just the keyboard, the same in Blender, but certain core manipulations are impossible in both without a mouse. I would argue that it's because of the much higher resolution of images/3d data. 80x50 with a 100 character alphabet versus 2000x2000 with a 16.7 mil alphabet. In Vim you say "move the cursor after 'func'". How would that work in Photoshop? "move the cursor after RGB(25, 15, 9) RGB(98, 126, 22)?" You can't even see the pixels in PS, let alone guess their values. There are pixel art editors which are completely usable with just the keyboard, but they are used for images smaller than 256x256.
        7y ago
Aloha 7y ago
How is vim significantly less unix like than vi? The user interfaces are near identical and vi is very unix in philosophy and originated on unix.
- kragen 7y ago
  EMACS was the extensible, customizable, self-documenting display editor, that did hairy things like turn your compiler error messages into hypertext and syntax-highlight your code—a massive amount of functionality tied up in a single garbage-collected process with an embedded scripting language, with potentially hundreds of files open at once. It came from ITS and Multics, where it provided not only an IDE but windows, on text terminals. It inhabited Unix systems uneasily, like the giant flying saucer in Independence Day, provoking complaints from co-workers that you were hogging megabytes of memory and making the VAX slow. vi, by contrast, was just a display editor. If you wanted to refill a paragraph in your email, you typed !}fmt to pipe it to fmt, an external process. To reformat a block of C, you could use !%indent. (And you could map a key to this as a keyboard macro.) If you wanted to script some editing, you might emit an ex or ed script, probably from a shell script. If you wanted to concurrently edit a second file, you would start a separate vi process. You could run it on a PDP-11, where no process could exceed 64K. Unix philosophy: tiny tools, loosely coupled—though vi was a bit on the fat side in order to get WYSIWYG instantly responsive editing like Bravo, Smalltalk, or EMACS. Vim is an extensible, customizable, self-documenting display editor, that does hairy things like turning your compiler error messages into hypertext and syntax-highlighting your code—a massive amount of functionality tied up in a single garbage-collected process with many embedded scripting languages, with potentially hundreds of files open at once, using megabytes of memory. If you want to refill a paragraph in Vim, you probably type gq}, which invokes Vim’s internal paragraph-filling code, not an external process. It uses the vi command set, with enhancements, but not the vi design. Not that that's a bad thing. I greatly prefer Vim to vi. I've been using EMACS since 1990 or so and vi and Vim since 1996—I couldn't afford to wait 30 seconds for EMACS to load over NFS on my SPARC 5 every time I wanted to reply to a mail.