4 ms·

No it's not. If you're a dev/SWE you should be able to grok a semi-complex CLI API to control software... but the further the world gets into "everything as UI

No it's not. If you're a dev/SWE you should be able to grok a semi-complex CLI API to control software... but the further the world gets into "everything as UIX" and "everything has to be 'easy'" the more we stray from incredibly powerful, immediately available CLI tooling. I know of too many highly-paid people who literally refuse to learn the CLI `git` or `docker` and limit themselves/skillsets by doing everything through the comfort of a UI. To me, it's a mark of laziness. Git isn't "too hard"... it solves an incredibly complex problem. It has a lot of capability and complexity under the hood to deal with all of the craziness of distributed development paradigm.

SpeckOfDust 6y ago
It's probably laziness. Is that such a bad thing though? I think its ok to expect tooling to be easy so we can spend our times on actually writing code. To me it's the same thing as expecting auto completion and line by line debugging from our IDEs.
- folkhack 6y ago
  > It's probably laziness. Is that such a bad thing though? Yes. > I think its ok to expect tooling to be easy so we can spend our times on actually writing code. I have never seen someone use a git GUI alternative as quickly and effectively as a competent CLI user. Especially if you're dealing with anything of reasonable complexity, but still, even for simple stuff. I can hit F1 for my quake-like terminal and type out `git add . && git commit -m 'Adds [...]'`, or a `git stash`, etc. faster than someone can reach over to the mouse and even open the GUI (let alone actually committing). That's not to say that I don't use Sublime Merge but it's only for complex visualization situations of weird branching etc. But... it's worth noting that most of the time I can get that hammered out on my GitLab instance. So, if you're looking for efficiency and want to "spend time actually writing code" I attest your argument that a GUI would speed anything up only if you refuse to learn the CLI. > To me it's the same thing as expecting auto completion and line by line debugging from our IDEs I work in Sublime all day long and actually actively turn features like this off because they slow me down. Also this is not to say I don't often jump into Intellij for heavier IDE stuff (step-through debugging) but that's like 1-2 times a week max. Otherwise, get out of my way and just let me get the code onto the page, I know 100% what I'm doing/writing and my docs are immaculate and accurate. --- Overall we probably work in very different ways, with very different development philosophies - which is 100% fine =)
  - SpeckOfDust 6y ago
    Yes. We clearly do. Appreciate your input though. It's always interesting to understand different perspectives. Cheers!
tweetle_beetle 6y ago
The whole point of the article is that not everyone is a [professional] "dev/SWE", or in other words: > ...a bunch of people who are already really comfortable with their terminals, and they’re reading the email from mailing lists in their terminals already, and unpacking patches by typing out a tar command in a single go. But even if you consider the case of "lazy" devs, I think the conclusion holds true: > I guess this short TL;DR version would be I feel that version control systems (the next version of them) should not be something that was specifically made for the Linux Kernel community. It should be something that was specifically designed to be used by the wider community. It has become the de facto distributed version-control system for the world, but if even people who are "highly paid" professionals struggle with the CLI, what hope for everyone else? It might only be "semi-complex" to you, but there are dozens of GUIs listed on official site[0], dozens of books teaching it and an official manual which is still a "work in progress"[1] 15 years after it was released suggesting a different view in the wider community. Imagine if git was lost and it had to be recreated, would it make sense to rebuild it exactly as it is now? It's an amazing tool and has stretched far beyond it's original use case, but surely we can all agree that there is room for improvement in its design? [0] https://git-scm.com/downloads/guis https://git-scm.com/downloads/guis [1] https://git.github.io/htmldocs/user-manual.html#todo-list https://git.github.io/htmldocs/user-manual.html#todo-list
- folkhack 6y ago
  > Imagine if git was lost and it had to be recreated, would it make sense to rebuild it exactly as it is now? I find your argument to be "if things were different, wouldn't they be different?" which I don't find to be of much substance... but let me fancy your thought experiment: Assuming the remembrance of the features/API was not lost there would be a worldwide effort to recreate it as soon as humanly possible due to the problems it solves better than any other SCM on the market. It's critical for global software engineering productivity. I have no doubt that a similar (if not exact copy) of git would be produced in very short time. Let's take another piece of Torvald's software and ask the same question: if Linux disappeared overnight would things be done different? Well, yes... sure. but would things also be re-created near 1:1 due to the known success of the Kernel? Also yes, and as fast as humanly possible.
at_a_remove 6y ago
Git can still solve an incredibly complex problem, have a lot of capability and complexity, etc, and still have lousy porcelain. It's awful. The porcelain is awful. Git solves problems and it has awful porcelain. Git is very useful and it has awful porcelain. Everyone would benefit from learning the basic model of git and ... it has awful porcelain.

SpeckOfDust 6y ago

It's probably laziness. Is that such a bad thing though? I think its ok to expect tooling to be easy so we can spend our times on actually writing code. To me it's the same thing as expecting auto completion and line by line debugging from our IDEs.

folkhack 6y ago
> It's probably laziness. Is that such a bad thing though? Yes. > I think its ok to expect tooling to be easy so we can spend our times on actually writing code. I have never seen someone use a git GUI alternative as quickly and effectively as a competent CLI user. Especially if you're dealing with anything of reasonable complexity, but still, even for simple stuff. I can hit F1 for my quake-like terminal and type out `git add . && git commit -m 'Adds [...]'`, or a `git stash`, etc. faster than someone can reach over to the mouse and even open the GUI (let alone actually committing). That's not to say that I don't use Sublime Merge but it's only for complex visualization situations of weird branching etc. But... it's worth noting that most of the time I can get that hammered out on my GitLab instance. So, if you're looking for efficiency and want to "spend time actually writing code" I attest your argument that a GUI would speed anything up only if you refuse to learn the CLI. > To me it's the same thing as expecting auto completion and line by line debugging from our IDEs I work in Sublime all day long and actually actively turn features like this off because they slow me down. Also this is not to say I don't often jump into Intellij for heavier IDE stuff (step-through debugging) but that's like 1-2 times a week max. Otherwise, get out of my way and just let me get the code onto the page, I know 100% what I'm doing/writing and my docs are immaculate and accurate. --- Overall we probably work in very different ways, with very different development philosophies - which is 100% fine =)
- SpeckOfDust 6y ago
  Yes. We clearly do. Appreciate your input though. It's always interesting to understand different perspectives. Cheers!

tweetle_beetle 6y ago

The whole point of the article is that not everyone is a [professional] "dev/SWE", or in other words: > ...a bunch of people who are already really comfortable with their terminals, and they’re reading the email from mailing lists in their terminals already, and unpacking patches by typing out a tar command in a single go. But even if you consider the case of "lazy" devs, I think the conclusion holds true: > I guess this short TL;DR version would be I feel that version control systems (the next version of them) should not be something that was specifically made for the Linux Kernel community. It should be something that was specifically designed to be used by the wider community. It has become the de facto distributed version-control system for the world, but if even people who are "highly paid" professionals struggle with the CLI, what hope for everyone else? It might only be "semi-complex" to you, but there are dozens of GUIs listed on official site[0], dozens of books teaching it and an official manual which is still a "work in progress"[1] 15 years after it was released suggesting a different view in the wider community. Imagine if git was lost and it had to be recreated, would it make sense to rebuild it exactly as it is now? It's an amazing tool and has stretched far beyond it's original use case, but surely we can all agree that there is room for improvement in its design? [0] https://git-scm.com/downloads/guis https://git-scm.com/downloads/guis [1] https://git.github.io/htmldocs/user-manual.html#todo-list https://git.github.io/htmldocs/user-manual.html#todo-list

folkhack 6y ago
> Imagine if git was lost and it had to be recreated, would it make sense to rebuild it exactly as it is now? I find your argument to be "if things were different, wouldn't they be different?" which I don't find to be of much substance... but let me fancy your thought experiment: Assuming the remembrance of the features/API was not lost there would be a worldwide effort to recreate it as soon as humanly possible due to the problems it solves better than any other SCM on the market. It's critical for global software engineering productivity. I have no doubt that a similar (if not exact copy) of git would be produced in very short time. Let's take another piece of Torvald's software and ask the same question: if Linux disappeared overnight would things be done different? Well, yes... sure. but would things also be re-created near 1:1 due to the known success of the Kernel? Also yes, and as fast as humanly possible.

at_a_remove 6y ago

Git can still solve an incredibly complex problem, have a lot of capability and complexity, etc, and still have lousy porcelain. It's awful. The porcelain is awful. Git solves problems and it has awful porcelain. Git is very useful and it has awful porcelain. Everyone would benefit from learning the basic model of git and ... it has awful porcelain.