Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Become Shell Literate

drewdevault.com

Post reply on HN
Print view View original

181–190 of 341 posts

Re: Become Shell Literate

#181

Post by enriquto »

Jasper_ wrote: post #97
turbinerneiter wrote: post #47

Earlier quoted context omitted.

Cool. Still, a lot of people start out programming with complex IDEs and end up being unable to run their code without the "play" button of their IDE. Starting out, or only ever leaning an IDE is also hiding a lot of things from you. For me, knowing the shell isn't about IDE vs. shell tooling, it's about, whatever you use, be aware and knowledgeable about the foundation and being able to do stuff even if there is no…

Still, a lot of people start out programming with complex compilers and end up being unable to hand-write their assembly code in pure HEX without the "help" of their compiler. Starting out, or only ever leaning a compiler is also hiding a lot of things from you. Now, I am familiar with assembly, I live and breathe it honestly, but I don't gatekeep and say "you're not a real programmer unless you've written your own a…

> Still, a lot of people start out programming with complex compilers and end up being unable to hand-write their assembly code in pure HEX without the "help" of their compiler.

I will reply with a car analogy. You can be a professional driver even if you don't know how to write the chemical formula for the combustion in your motor. You can not be a good professional driver if you don't know how to change a flat tyre or check your oil. No matter how good your driving is, if you cannot change the oil you are an incompetent driver. Maybe in the future, cars will not need oil. So good, but today they do and you need to deal with it.

Likewise, today's computer systems rely on the shell. If you are shell-illiterate, you are an incompetent programmer, no matter how good your programs are.

Re: Become Shell Literate

#182

Post by vvanders »

pessimizer wrote: post #172
vvanders wrote: post #120

Earlier quoted context omitted.

By framing the IDE as a crutch, that's very much in the gatekeeping category.

Is "gatekeeping" now just another word for making people feel bad? Like "pretentious" or "elitist" has become? Nobody is saying that people with crutches shouldn't be allowed to walk. edit: It's so strange to not only demand the right to not know how to do something without a complicated tool (a right which is inalienable and not threatened), but to also demand that people who do know how to do that thing not think t…

I mean shouldn't you feel bad if you're trying to discourage active engagement in a topic if one doesn't do it in a specific "correct" way?

Personally I've found a diverse set of viewpoints to be incredibly valuable on the teams I've been a part of. I have my own biases on testing, stability, performance and seeing how others approach it has broadened my understanding of how to build software.

To put it another way, the parent could have said "IDEs are awesome and I've found when you combine that with an understanding of the CLI you have an awesome set of tools at your disposal that are greater than the sum of their parts" instead of making it an exclusive trade off or implying that IDEs are limiting.

Re: Become Shell Literate

#184

Post by hiq »

mrkeen wrote: post #147
gfxgirl wrote: post #29

Someone should write "become IDE literate" as a response to opening of using vim with no extensions and using grep a lot. I've been using editors that are language aware since at least the late 90s. Depending on the language they'll show me all references, take me to the definition or declaration, stack those jumps so as I follow the links I can pop back a level to where I was. All of this is instant. 1000x faster th…

1) I'm not going to teach Jenkins to use IntelliJ. I want my build step (whether gradlew or make) to be runnable in the same way as it runs in scripts. I get to set (and read!) env vars when they're right there in front of me, not hidden away behind dialog boxes. > 1000x faster than opening a shell Don't close the shell. > trying to grep all the project files for word phrases which, not being language aware, can't te…

Regarding Intellij and looking for classes / running test: I think this mostly depends on whether you're casually browsing some random project, or if you're gonna work on the same project for several weeks.

It's fine to try to open the random project in your favorite IDE and see if it just works. If it doesn't, and you just need to figure out what the code does, fix a few lines of code, going back to a text editor, grepping and trusting the CI to run the tests itself is just less overhead.

If you work on the same project for a longer period of time, you can easily justify the upfront cost of configuring your environment properly (and have your class searches and 'Run all tests' running).

Re: Become Shell Literate

#185

Post by demosito666 »

gfxgirl wrote: post #29

Someone should write "become IDE literate" as a response to opening of using vim with no extensions and using grep a lot. I've been using editors that are language aware since at least the late 90s. Depending on the language they'll show me all references, take me to the definition or declaration, stack those jumps so as I follow the links I can pop back a level to where I was. All of this is instant. 1000x faster th…

> Depending on the language they'll show me all references, take me to the definition or declaration, stack those jumps so as I follow the links I can pop back a level to where I was. All of this is instant.

Vim can do this too and (rip)grepping the code is only needed if you're looking for, you know, text. I have 'gd' mapped to "go to declaration" and 'gr' to "find references". Works across dozens of languages, can be further scripted upon. Basic refactoring (renaming class method in several files) should also work, but I use it so rarely that actually can't testify about it (I use rope bindings for python refactoring but it's usually limited to a single file).

It's not as honed as purposely built 5GB IDE of course. But having one editor for all languages and syntaxes is really nice. Things like VSCode have this one too, but I wouldn't call them and IDE either.

I haven't been using IDEs any meaningful amount of time as I'm not a developer, but if the things you mentioned (go to definition, changing names) are the main reasons for an IDE, one could argue that terminal workflow has substantial benefits, like better understanding of the toolchain, simpler integration with ci/cd tools, endless customization, single tool across languages and other standard cons of CLI tools.

I do, however, find vim without extensions useless for editing code as well.

Re: Become Shell Literate

#186

Post by pessimizer »

CodeAndCuffs wrote: post #83
turbinerneiter wrote: post #47

Earlier quoted context omitted.

Cool. Still, a lot of people start out programming with complex IDEs and end up being unable to run their code without the "play" button of their IDE. Starting out, or only ever leaning an IDE is also hiding a lot of things from you. For me, knowing the shell isn't about IDE vs. shell tooling, it's about, whatever you use, be aware and knowledgeable about the foundation and being able to do stuff even if there is no…

Cant we make this argument for any level of abstraction? A lot of people start out with shells and end up being unable to understand how to construct a switch or adder in logic gates. A shell is a great tool but shouldn't be a crutch.

> Cant we make this argument for any level of abstraction?

We could also make the opposite argument for any level of abstraction: can you really say that someone who buys apps for their iPhone and runs them is less of a programmer than someone who actually programs? If programming is just getting a job done, and being a good programmer is just picking the right tool to get the job done...

The real question is pragmatic, not theoretical. Does your dependence on a tool sometimes make easy things impossible or encourage misunderstandings about lower level processes that lead to bugs or inefficiencies? Is it simply too big or expensive to run in all of the places you might want to program? Does the tool make up for that lack of flexibility with increased productivity? Those are real questions that you can ask about any specific tool (including the shell.) It doesn't mean anything to ask them about tools in general, and the idea that sacrifices and benefits must all come out even in the end is just the law of averages.

Re: Become Shell Literate

#187

Post by demosito666 »

j1elo wrote: post #104
gfxgirl wrote: post #29

Someone should write "become IDE literate" as a response to opening of using vim with no extensions and using grep a lot. I've been using editors that are language aware since at least the late 90s. Depending on the language they'll show me all references, take me to the definition or declaration, stack those jumps so as I follow the links I can pop back a level to where I was. All of this is instant. 1000x faster th…

> take me to the definition or declaration, stack those jumps so as I follow the links I can pop back a level to where I was. Know any C/C++ IDE that would do this? I transitioned from Qt Creator to VSCode and none of those have helped me with this cool nicety you mention. EDIT: I should add that for me, exploring foreign code bases has been hugely improved since I discovered Sourcetrail, so I'd suggest having a look…

vim can definitely do it with CoC

Re: Become Shell Literate

#188

Post by yowlingcat »

vvanders wrote: post #182
pessimizer wrote: post #172

Earlier quoted context omitted.

Is "gatekeeping" now just another word for making people feel bad? Like "pretentious" or "elitist" has become? Nobody is saying that people with crutches shouldn't be allowed to walk. edit: It's so strange to not only demand the right to not know how to do something without a complicated tool (a right which is inalienable and not threatened), but to also demand that people who do know how to do that thing not think t…

I mean shouldn't you feel bad if you're trying to discourage active engagement in a topic if one doesn't do it in a specific "correct" way? Personally I've found a diverse set of viewpoints to be incredibly valuable on the teams I've been a part of. I have my own biases on testing, stability, performance and seeing how others approach it has broadened my understanding of how to build software. To put it another way,…

> instead of making it an exclusive trade off or implying that IDEs are limiting.

But that would be a completely different argument. Their whole point is that there /is/ an exclusive trade-off, which is different from what they're trying to say.

If you want my opinion, they both piss me off, just in different ways. The IDE requires me to use my mouse, even with the best Vim impersonation plugins. I hate that, but I put up with it because the autocomplete, syntax completion and indexing just works so much better than the Vim equivalents which fall apart under heavily load. And conversely, trying to edit remotely complex projects is a nightmare with Vim, no matter which distributions I use.

Which maybe is a different tone of saying exactly what you are saying.

Re: Become Shell Literate

#189

Post by tommd »

And for goodness sakes, use ShellCheck! It can be easy (i.e. there are CI services that will run shellcheck automatically on your PRs and comment bugs).

Re: Become Shell Literate

#190

Post by hiq »

kaszanka wrote: post #167

That pipeline sure does look convenient. Let's see how it will handle a path with spaces. $ git status -s | grep '^ D' | awk '{ print $2 }' | xargs git checkout -- xargs: unmatched double quote; by default quotes are special to xargs unless you use the -0 option $ git status -s D "g h i" I'd be lying if I said I was surprised, to be honest.

I think people who routinely write this kind of commands in an interactive shell are well aware of the shortcomings, they just deal with it when they need to and not before. One example is that people very rarely handle '\n' or spaces in filenames (e.g. using the -0 option from `xargs`). Whatever works is fine as long as one knows the risks.

For a one-off thing like the one mentioned in the article I'd say it's almost ok, although I'd put `git checkout --` in the category of risky commands if you don't have any backup.

Post reply on HN