Become Shell Literate • Hacker News Board

Re: Become Shell Literate

#131

Post by wott » Sat, Dec 12, 2020, 8:09 PM UTC

spijdar wrote: post #88

CodeAndCuffs wrote: post #83

Earlier quoted context omitted.

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.

Emotionally, I actually agree with this. I'd love for at least a basic understanding of computers down to boolean logic and the very basics of semiconductors up to the OS level and beyond to be "widely known" by programmers and "computer literate". At the same time, I know that's extremely unreasonable to expect. I guess for the shell and editor, you can argue you ought to understand it stripped of abstractions, sinc…

> At the same time, I know that's extremely unreasonable to expect.

However, that's exactly the path every Electrical & Electronics Engineer classically took.

Re: Become Shell Literate

#132

Post by chaganated » Sat, Dec 12, 2020, 8:15 PM UTC

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…

Sounds like a reinforcement of Drew's point to me. Using the IDE to jump all over the place, and blast changes over several files at once, suggests severe and unnecessary non-localities and tight couplings in the code.

Maybe without the IDE, the code would have ended up a little cleaner.

Re: Become Shell Literate

#133

Post by tracyhenry » Sat, Dec 12, 2020, 8:15 PM UTC

memetomancer wrote: post #122

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…

This speaks more to the narrowness of your view than it does about shell. Example: I work with parallel filesystems quite a lot. Often I will need to parse through GB of logs spread across a cluster to track down a particular sequence of events for troubleshooting. I could load up a fancy IDE with all the bells and whistles, one that instantly refactors all my 'foo', and still spend a (very) non-trivial amount of tim…

> "parse through GB of logs spread across a cluster" Why would you do that with IDE?

The OP is comparing IDE v.s. shell in terms of "exploring" and "editing" the code. In that case IDE is a powerful nail gun and championing it isn't wrong.

Re: Become Shell Literate

#134

Post by chubot » Sat, Dec 12, 2020, 8:17 PM UTC

akkartik wrote: post #16

tutfbhuf wrote: post #4

I wish that shell would be more sane. I don't think that a shell should be a complete programming language. If you need a programming language, then better use one. There is xonsh if you are looking for something like this. I think there should be a better bash with an very clean and consistent interface. Some of the most commonly used utils like awk '{ print $2}', sed, grep, sort, ... should be included out of the b…

I've been trying to build a computer with a single principled HLL included that can also double as a shell. There's also http://www.oilshell.org which _also_ tries to be compatible with existing shell. It also tries to include features from awk and sed: https://www.oilshell.org/blog/2016/11/13.html If these design points turn out to be over-constrained and have to make major compromises, yes the next thing I would tr…

BTW I think the general idea of Oil's syntax is working out: start in "command mode", and then when you see the RHS of =, changing modes to Python-/JS- like expressions. There a few other cases where you switch to expression mode, like proc p(a, b) [1]

So far nobody has complained about any of this, I'm guessing because it looks very familiar, and that was intentional. Oil takes some pains to literally look like shell + Python syntactically, with better semantics.

I noticed that a few other shells are having problems with this command/expression distinction, and I discussed it like 3-4 years ago with Ilya Sher (of NGS) and a few other people. They were also having the same problem.

For example, does / mean a path separator or the division operator? Does * mean a glob or a multiplication? In Oil, this is no problem. It's obvious depending on the context.

Though I'm interested in more feedback on this, and the latest release is available to try as always :) https://www.oilshell.org/release/latest/

---

The awk and make integration is still doable but not done. Awk might require a notion of "lazy expressions" or "lazy arg lists", which would be shared with dplyr-like functionality. Oil's Zulip is open for discussion on these ideas :)

[1] https://www.oilshell.org/release/0.8.5/doc/command-vs-expres...

Re: Become Shell Literate

#135

Post by tracyhenry » Sat, Dec 12, 2020, 8:18 PM UTC

morelisp wrote: post #99

bentcorner wrote: post #44

Earlier quoted context omitted.

I do like my IDE but my one complaint with leaning on it a lot is that it lets you write code that is harder to understand if you don't have that IDE readily available. For example, if you name a member "flag" and you have several types with the same member, your IDE can tell you where this flag is used, so it's not a big deal if you wanted to refactor or are trying to track down a bug. But god help you if you're loo…

A better example might be perpetuating typos (and other less obviously wrong bad names), the number of times I've seen some variant of "setIntercetpor" or "closeDataSteam" or... anything that gets actually typed as "most of the first word plus completion."

Your example sounded like results produced with editors that do not understand the underlying language. A proper IDE would not prompt you with closeDataSteam if it's not a member function of the object to which you want to close the data stream.

Re: Become Shell Literate

#136

Post by oblio » Sat, Dec 12, 2020, 8:20 PM UTC

dbalatero wrote: post #126

oblio wrote: post #109

Earlier quoted context omitted.

How do you refactor, say, Java or C# or Typescript with Vim?

These days, language servers and wiring up one of the clients in Vim.

Have you used them? Are they reliable/stable/fast? Easy to configure?

Re: Become Shell Literate

#137

Post by jariel » Sat, Dec 12, 2020, 8:21 PM UTC

I think we need a visual shell. Git should literally show you a tree, then an animation of what's happening because there's a lot going on and I was shocked at my ignorance once I did see something.

Mac Finder is my goto a lot because it's just powerful to see the tree. Could we blend the command line there?

And finally - for expert users this is not a problem, for for medium users, the fact that many of the commands have different flags in different orders is a pain. A brand new set of integrated commands - where everything followed a predictable standard would be great.

Re: Become Shell Literate

#138

Post by larkinrichards » Sat, Dec 12, 2020, 8:21 PM UTC

I spend many hours of each day ~programming~ wrangling text files and I use macos + zsh + textmate2 for my daily drivers. I see shell as an important proficiency because it helps maintain a lower-level understanding of how the "magical" GUI "works," which often helps in debugging obtuse errors, and I'm sad to encounter more engineers who are completely unfamiliar with it.

When it comes to examples like that posted by the OP, I like the combination of piping/pasting to mate and multi-caret editing for most scenarios where others would reach for awk/xargs.

Here's me following the same example scenario but with multi-caret editing (slowed down slightly):

https://user-images.githubusercontent.com/226503/101993951-6...

Step by step:

  1. git status -s | mate
  2. select " D" with arrow keys + shift
  3. command-E macos default for "use selection to find"
  4. option-command-F to find all (multi-caret editing starts)
  5. type "git checkout" to replace " D"
  6. command-left to move cursor to start of line, then shift-command-right to select to end of line.
  7. copy
  8. select all + delete (clear document)
  9. paste, 
  10. press return to insert newlines
  11. select all + copy
  12. switch back to terminal
  13. paste

To me, this is many small steps, but each step is more mechanical and flows naturally, and the general flexibility of multi-caret editing means it is applicable more often in my daily work.

Re: Become Shell Literate

#139

Post by combatentropy » Sat, Dec 12, 2020, 8:22 PM UTC

ddevault wrote: post #80

combatentropy wrote: post #63

Earlier quoted context omitted.

You're right. I often think the man page should begin with a few examples, then launch into the neverending list of options. That is no way to learn. In foreign language 101, they start you off with a small group of examples. "Como estas?" "Muy bien. Y tu?" Afterward, they explain the rules of the language (this is a noun, this is a verb, this is how you conjugate for first-person singular, etc.). In fact, this is ho…

>The Linux man pages are upside down. Examples don't come till the very end, if at all. You only learn the tool once. Every subsequent time you visit the man page, the information you're probably looking for is frontloaded. Just scroll to the bottom if you want examples?

Fair points. After all, I know the keyboard shortcut to jump to the bottom (Ctrl-G).

Re: Become Shell Literate

#140

Post by tracyhenry » Sat, Dec 12, 2020, 8:22 PM UTC

teeray wrote: post #105

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…

> 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. I do this in stock vim using ctags files. You can generate them with anything, though “exuberant ctags” is very popular. Ctrl+] when over an identifier jumps to its definition, and there’s a tag stack to jump backwards similarly (you can…

The point of IDE is that there is almost 0 configuration. You get everything by just clicking "install". Y you can configure vim or emacs to be as expressive as IntelliJ. But the time it takes is much larger than 0. And when you switch to another language you'll probably need to repeat many steps.