5 ms·

> it works out of the box with no configuration (batteries included). You don't really believe that, do you? Competent users tend to have preferences. There's

> it works out of the box with no configuration (batteries included). You don't really believe that, do you? Competent users tend to have preferences. There's no need to worry about installing plugins if you have to have a .vimrc to begin with, just have the .vimrc do the installing as well.

Mashimo 8y ago
I have not tried amp yet, but just as an example why I switched shell. I use fish shell because of the sane defaults. I don't want to be bothered with setting up code completion and history size. Just install it and use it. Works. I like projects that provide similar experience.
- wasted_intel 8y ago
  Yes, fish shell is a beautiful example of that philosophy! Its design documentation[0] reflects a lot of the values that drove me to create Amp. [0] https://fishshell.com/docs/current/design.html https://fishshell.com/docs/current/design.html
  - tbrock 8y ago
    Also see: Ruby on Rails
    - wasted_intel 8y ago
      Yep, another great example. :)
wasted_intel 8y ago
Amp, and convention over configuration in general, don't prevent configuration, they just try to avoid it. There are a bunch of things you can configure in Amp, if you'd like: https://amp.rs/docs/#configuration https://amp.rs/docs/#configuration
- phlyingpenguin 8y ago
  That's not really what I was doubting (I could see that). I just doubt that it's likely to not need a configuration file if I were to replace vim with it. In GP's assertion that this is the best reason to use Amp over vim, that's not really a huge benefit in the end. A config is a config is a config, or something to that effect.
  - wasted_intel 8y ago
    Unfortunately, configuring Vim is rarely just pulling a config file. Pathogen and Vundle have made installing/tracking plug-ins easier, but unless things have changed, those tools required their own bootstrapping outside of simply being referenced in the config. And that's just for Vimscript plug-ins. There are several situations (e.g. fuzzy file finders) where external binaries are preferable, for performance reasons. The idea is to include those directly in Amp, so that it's _only_ a configuration file that's needed, if at all.
    - phlyingpenguin 8y ago
      All depends on your taste. My .vimrc handles ensuring that I have a plugin manager installed and that it installs those plugins on my behalf if they aren't there. And I do all of that in ~10 lines of vimL config. It's totally reasonable to have your plugin/config ensure the external binaries exist as well. The popular golang plugin has a command for that.
      - wasted_intel 8y ago
        It ensures you have a plug-in manager installed, but it won't install it for you, right? I know that might seem like a minor nit, but if package management is considered an essential part of Vim, I'm of the mindset that it should work out of the box. That said, Amp doesn't have plug-in support at the moment, so it's a little unfair for me to judge Vim on that front. But if it did, the package management portion would be baked in so that you'd only need to pull your configuration file and Amp would handle the rest. :)
oblio 8y ago
Fragmentation also hurts the ecosystem. Just look at Linux distributions or desktop environments to see the effects. The best thing is to provide some sensible overridable defaults and basic functionality expected these days from a programmer's editor, such as simple project management: index files, fuzzy file finder, etc. Vim and Emacs are a pain in the butt for precisely this reason: they don't take ANY decision, they just throw the entire burden on the user. They're forgiven because they're classics, but any kind of editor launched in 2018 would be utterly ignored if it didn't have these features.
- wiz21c 8y ago
  >> Fragmentation also hurts the ecosystem. Just look at Linux distributions or desktop environments to see the effects. I don't think so. I've never felt that having 10 linux distributions was a problem, I just can pick between at least two super robust choices : Debain, RedHat. I can even choose between inkscape, krita, gimp. Or KDE and Gnome... You can argue that progress would be faster if we have less choices but more choices also means more developpers...
  - oblio 8y ago
    It definitely hurts mainstream adoption. And it also kills distribution of most commercial desktop applications.
  - PurpleRamen 8y ago
    Choice is a process which can hurt when it takes too long or when you lack the ability to execute the process itself or in a good manner. See https://en.wikipedia.org/wiki/Overchoice https://en.wikipedia.org/wiki/Overchoice and https://en.wikipedia.org/wiki/Analysis_paralysis https://en.wikipedia.org/wiki/Analysis_paralysis This is BTW no limited to OSS but AFAIK it comes from sales-research. People confronted with to many products of similar type can end in a deadlock, avoiding those products or even start to avoid the whole category. > You can argue that progress would be faster if we have less choices but more choices also means more developpers... More developers reinventing the wheel doesn't automatically make the wheels faster. It can mean healthy competition, but it also can mean wasted ressources. It's case by case.
ronjouch 8y ago
Sure, but "Competent users tend to have preferences" doesn't exclude slow evolution of sane-by-default preferences for programs part of a same class. A newcomer text editor, say, comes in town, settles its default configuration as the sanest of previous generations, while existing programs of the same class are (reasonably!) stuck due to compatibility. Which means newcomer text editors need less configuration, and users generally staying closer to the default stable, tested configuration. You can argue that you're part of a margin needing XYZ specific setting, or that new programs don't necessarily make good default config choices. To me it feels generally reasonable to believe so. Case in point, with text editors / light IDEs. I did Sublime Text -> Atom -> VSCode. At each step, the size of my config size decreased. Of course I still have a VSCode settings.json, but it's twenty lines. My sublime prefs are ~100 lines, my .vimrc is hundreds :)
- phlyingpenguin 8y ago
  The plugins you need to make Atom/VSCode great (no experience with modern Sublime) definitely count as configuration in my book, and often come with their own configuration load. If I sit down at a new machine, they won't be there. Most of my .vimrc is a couple of lines per plugin configuring the plugins, for example.
  - wasted_intel 8y ago
    You're going to get a fuzzy file finder, Git integration, syntax highlighting, symbol navigation, and and a package manager immediately available to you in those editors. None of those are available in Vim by default; that's the inspiration for Amp. There are additional perks to including things by default, too. Jump mode is a good example of that: it's integrated with its select mode. You can start a selection and then switch to jump mode to move the cursor to complete the selection. Lastly, there's simplicity in including things rather than asking new users to pick from a dizzying array of plug-in options. Rails is a good example of this: there's a lot of functionality that could have been left to 3rd-party gems, but having the framework include them by default means they'll work out of the box, and there's a single canonical solution to [sessions, templates, ORM, routing, etc].
tbrock 8y ago
Yes I do. Ever use textmate or Atom? Sure you can configure a bunch of keys if you want to change them but nobody ever does.
sfifs 8y ago
This discussion reminds me of the classic "standards" xkcd https://xkcd.com/927/ https://xkcd.com/927/

Mashimo 8y ago

I have not tried amp yet, but just as an example why I switched shell. I use fish shell because of the sane defaults. I don't want to be bothered with setting up code completion and history size. Just install it and use it. Works. I like projects that provide similar experience.

wasted_intel 8y ago
Yes, fish shell is a beautiful example of that philosophy! Its design documentation[0] reflects a lot of the values that drove me to create Amp. [0] https://fishshell.com/docs/current/design.html https://fishshell.com/docs/current/design.html
- tbrock 8y ago
  Also see: Ruby on Rails
  - wasted_intel 8y ago
    Yep, another great example. :)

wasted_intel 8y ago

Amp, and convention over configuration in general, don't prevent configuration, they just try to avoid it. There are a bunch of things you can configure in Amp, if you'd like: https://amp.rs/docs/#configuration https://amp.rs/docs/#configuration

phlyingpenguin 8y ago
That's not really what I was doubting (I could see that). I just doubt that it's likely to not need a configuration file if I were to replace vim with it. In GP's assertion that this is the best reason to use Amp over vim, that's not really a huge benefit in the end. A config is a config is a config, or something to that effect.
- wasted_intel 8y ago
  Unfortunately, configuring Vim is rarely just pulling a config file. Pathogen and Vundle have made installing/tracking plug-ins easier, but unless things have changed, those tools required their own bootstrapping outside of simply being referenced in the config. And that's just for Vimscript plug-ins. There are several situations (e.g. fuzzy file finders) where external binaries are preferable, for performance reasons. The idea is to include those directly in Amp, so that it's _only_ a configuration file that's needed, if at all.
  - phlyingpenguin 8y ago
    All depends on your taste. My .vimrc handles ensuring that I have a plugin manager installed and that it installs those plugins on my behalf if they aren't there. And I do all of that in ~10 lines of vimL config. It's totally reasonable to have your plugin/config ensure the external binaries exist as well. The popular golang plugin has a command for that.
    - wasted_intel 8y ago
      It ensures you have a plug-in manager installed, but it won't install it for you, right? I know that might seem like a minor nit, but if package management is considered an essential part of Vim, I'm of the mindset that it should work out of the box. That said, Amp doesn't have plug-in support at the moment, so it's a little unfair for me to judge Vim on that front. But if it did, the package management portion would be baked in so that you'd only need to pull your configuration file and Amp would handle the rest. :)

oblio 8y ago

Fragmentation also hurts the ecosystem. Just look at Linux distributions or desktop environments to see the effects. The best thing is to provide some sensible overridable defaults and basic functionality expected these days from a programmer's editor, such as simple project management: index files, fuzzy file finder, etc. Vim and Emacs are a pain in the butt for precisely this reason: they don't take ANY decision, they just throw the entire burden on the user. They're forgiven because they're classics, but any kind of editor launched in 2018 would be utterly ignored if it didn't have these features.

wiz21c 8y ago
>> Fragmentation also hurts the ecosystem. Just look at Linux distributions or desktop environments to see the effects. I don't think so. I've never felt that having 10 linux distributions was a problem, I just can pick between at least two super robust choices : Debain, RedHat. I can even choose between inkscape, krita, gimp. Or KDE and Gnome... You can argue that progress would be faster if we have less choices but more choices also means more developpers...
- oblio 8y ago
  It definitely hurts mainstream adoption. And it also kills distribution of most commercial desktop applications.
- PurpleRamen 8y ago
  Choice is a process which can hurt when it takes too long or when you lack the ability to execute the process itself or in a good manner. See https://en.wikipedia.org/wiki/Overchoice https://en.wikipedia.org/wiki/Overchoice and https://en.wikipedia.org/wiki/Analysis_paralysis https://en.wikipedia.org/wiki/Analysis_paralysis This is BTW no limited to OSS but AFAIK it comes from sales-research. People confronted with to many products of similar type can end in a deadlock, avoiding those products or even start to avoid the whole category. > You can argue that progress would be faster if we have less choices but more choices also means more developpers... More developers reinventing the wheel doesn't automatically make the wheels faster. It can mean healthy competition, but it also can mean wasted ressources. It's case by case.

ronjouch 8y ago

Sure, but "Competent users tend to have preferences" doesn't exclude slow evolution of sane-by-default preferences for programs part of a same class. A newcomer text editor, say, comes in town, settles its default configuration as the sanest of previous generations, while existing programs of the same class are (reasonably!) stuck due to compatibility. Which means newcomer text editors need less configuration, and users generally staying closer to the default stable, tested configuration. You can argue that you're part of a margin needing XYZ specific setting, or that new programs don't necessarily make good default config choices. To me it feels generally reasonable to believe so. Case in point, with text editors / light IDEs. I did Sublime Text -> Atom -> VSCode. At each step, the size of my config size decreased. Of course I still have a VSCode settings.json, but it's twenty lines. My sublime prefs are ~100 lines, my .vimrc is hundreds :)

phlyingpenguin 8y ago
The plugins you need to make Atom/VSCode great (no experience with modern Sublime) definitely count as configuration in my book, and often come with their own configuration load. If I sit down at a new machine, they won't be there. Most of my .vimrc is a couple of lines per plugin configuring the plugins, for example.
- wasted_intel 8y ago
  You're going to get a fuzzy file finder, Git integration, syntax highlighting, symbol navigation, and and a package manager immediately available to you in those editors. None of those are available in Vim by default; that's the inspiration for Amp. There are additional perks to including things by default, too. Jump mode is a good example of that: it's integrated with its select mode. You can start a selection and then switch to jump mode to move the cursor to complete the selection. Lastly, there's simplicity in including things rather than asking new users to pick from a dizzying array of plug-in options. Rails is a good example of this: there's a lot of functionality that could have been left to 3rd-party gems, but having the framework include them by default means they'll work out of the box, and there's a single canonical solution to [sessions, templates, ORM, routing, etc].

tbrock 8y ago

Yes I do. Ever use textmate or Atom? Sure you can configure a bunch of keys if you want to change them but nobody ever does.

sfifs 8y ago

This discussion reminds me of the classic "standards" xkcd https://xkcd.com/927/ https://xkcd.com/927/