231–240 of 334 posts
Earlier quoted context omitted.
> I'm frequently stumped by man pages, and end up having to hunt down an example of how to use a particular command line application on Stack Overflow. If you're not aware of tldr [0], I highly recommend it. [0] https://tldr.sh/
man(1) pages on linux are almost all terrible. Unworthy of inclusion in any manual. Proper manuals have examples of use. Many linux man pages don't even discuss (or list, even!) return codes or failure modes.
Earlier quoted context omitted.
man(1) pages on linux are almost all terrible. Unworthy of inclusion in any manual. Proper manuals have examples of use. Many linux man pages don't even discuss (or list, even!) return codes or failure modes.
Some of the manpages for utillinux (e.g., chsh, useradd) are pretty barebones and don't include examples, but off the top of my head I can't think of a major GNU utility that doesn't have EXAMPLES sections in its manpages. GNU coreutils, find, sed, and grep all have such a section in their manuals. What are you thinking of that is example-less?
All in all, I find that manpages on Linux are usually pretty good, particularly compared to systems like MacOS where many daemons and utilities seem to have no manpage at all. People are far too quick to slag manpages, which probably has something to do with the `man` utility itself being a bit archaic. Common Linux desktops could probably do a better job of advertising GUI-based manpage readers like khelpcenter.
As for markdown I showed it to my girlfriend and this is now what she uses for everything. She is a designer and loves that here she does not have to bother with design, just with markup. She hates Microsoft Word with a passion. People who used formatting in any 2000s internet forum know in principle how to use markdown. That aside, I see it as a problem that tech people fail to anticipate the needs of their peers. I…
This isn't a programming problem, or exclusive to our field. Go talk to any expert in their field about something in that field, and have the same reaction. I tried my hand at blacksmithing, and had to learn (what seemed like) a lot of metallurgy before half of what my mentors were saying made any sense at all. Sometimes it's on the expert to make it clear to the non-expert. Other times it's on the newbie to learn th…
I think most of the times it is on the expert to be clear, because as an expert you should know what complexity your experise involves, while this cannot be expected of the non-expert. That being said, it is totally okay as an expert to answer in the sense of "that involves a lot of things that you need to know beforehand" and then give them a hint where they can learn those things and ask them to come back when they did their homework.
What does not help anyone is if you just answer the question without giving context. Great, technically you were right, but you are also the only person who can tell it was.
Communicating clearly is a separate skill. Not every expert has that skill. But every expert could potentially profit from having that skill. If you have that skill it does not mean you now need to put in a lot of work in explaining things to everybody – but it means you can explain things if it is needed. People are surprisingly happy if someone manages to clear things up for them without looking down on them or going into teacher/preacher mode.
The problem is mainly one of discoverability. The non-programmer in the examples says "simple" when they mean "discoverable". The programmer says "simple" when they mean "not much code complexity". Of course you disagree. All the examples - installing and using a package manager, running a command line program - are "simple" from a software point of view, but they're not at all "discoverable". To understand the steps…
There should be a library that makes it easy for developers to include a basic GUI with a CLI
Literally everything I write is in Markdown because it’s so simple to me. I use it for blogposts, presentations, documentation, todos, internet comments. But this article doesn’t strike a chord with me. The author fails to understand that it seems easy to us because we’re familiar with it. Of course we know how to transform it into PDF or HTML. But this knowledge isn’t basic, and it’s understandable that people want…
Not contradicting you. Just adding this famous case of using Excel. > the median Excel user probably completes this task quicker and better than the median pandas user Some might complete it with catastrophic effects. > A million-row limit on Microsoft's Excel spreadsheet software may have led to Public Health England misplacing nearly 16,000 Covid test [1] [1] https://www.bbc.com/news/technology-54423988
For example, there was one office where the engineers were affectionately known as "swine". (I'm not sure how that came to be.) If an engineer did some particularly clever piece of engineering, the ultimate compliment was to call it "swinish".
To an outsider, this made no sense at all, but it worked for us.
The problem is mainly one of discoverability. The non-programmer in the examples says "simple" when they mean "discoverable". The programmer says "simple" when they mean "not much code complexity". Of course you disagree. All the examples - installing and using a package manager, running a command line program - are "simple" from a software point of view, but they're not at all "discoverable". To understand the steps…
I wish CLIs had better discoverability. That's one of the first principles of UX. There should be a library that makes it easy for developers to include a basic GUI with a CLI
I didn't see a need to add a GUI as a web browser will do nicely.
Earlier quoted context omitted.
Building the long-term solution first is often wrong even when you need one. I use the quick and dirty method until I know I'll do that task more regularly and I know enough about the problem so I don't need to make wild guesses about the design.
> I use the quick and dirty method until I use it until I realize it’s not quick after all. Now I default to writing one off scripts.
For something like this, the first thing I'd do is extract the first row manually in Vim, recording my actions as a macro, then use that macro to extract the rest. That would take a few minutes tops, depending on the structure of the data it might take seconds or there might be a bit more massaging necessary, but no more than about 5 minutes for this step. I have a keybinding that maps execution of the macro in the q register to the spacebar to streamline this process; I double-tap q to start recording, press q again to stop recording, and press/hold the spacebar to execute that q macro. In my experience, 2 or 3 passes are usually enough to cleanly extract a table of data from some random HTML page.
If the job was a once-and-done, then I'm already done. If I am meant to be creating something that can be re-used later, then I still do the above anyway and now I have the result with which to test whatever more permanent solution I'm writing.
The difference being most software/tech workers largely make their salary from non-tech savvy consumers so I don’t know, maybe some more perspective is needed in dealing with “normal people”.
But also helping out with printers and stuff is lame, as mentioned I understand where author is coming from.
Edit: I guess my point is - rants are totally fine if labeled as such but this doesn’t seem very constructive to me. Hopefully us tech savvy individuals can help level up everyone else
Earlier quoted context omitted.
Some of the manpages for utillinux (e.g., chsh, useradd) are pretty barebones and don't include examples, but off the top of my head I can't think of a major GNU utility that doesn't have EXAMPLES sections in its manpages. GNU coreutils, find, sed, and grep all have such a section in their manuals. What are you thinking of that is example-less?
GNU ls's manpage has no examples, but it's also a thousand words long so it hardly seems fair to characterize it as bare-bones. All in all, I find that manpages on Linux are usually pretty good, particularly compared to systems like MacOS where many daemons and utilities seem to have no manpage at all. People are far too quick to slag manpages, which probably has something to do with the `man` utility itself being a…