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

From novice to master, and back again (2013)

blog.djmnet.org

Post reply on HN
Print view View original

91–100 of 150 posts

Re: From novice to master, and back again (2013)

#91

Post by nice2meetu »

layer8 wrote: post #85
elteto wrote: post #72

Earlier quoted context omitted.

What finally got the `ln` argument order engraved in my mind was learning that you can skip the destination argument: ln -s /foo/bar/baz will create a soft link in the CWD named baz, pointing to /foo/bar/baz. So you see, if you know that you can always skip the destination, then, logically, the source must be the first one!

> logically, the source must be the first one! You mean the target, but that isn’t a logically necessary consequence at all. Conceivably, `ln` could support the following two syntaxes: ln [options] target ln [options] link_name target The way I remember the correct parameter order is that I remember it’s the non-intuitive one.

Ah, I remember it is the non-intuitive one, but then when I use it a while, I keep double-guessing which one is the intuitive one.

Kind of like when my wife tells me I'm doing something wrong and she wants it to be the other way.. I know she thinks this thing is important, but can't work out which way she wants it done.

Re: From novice to master, and back again (2013)

#92

Post by layer8 »

jesterpm wrote: post #61
icambron wrote: post #27

Earlier quoted context omitted.

I use the `ln` command a lot. I use the `man ln` command _almost_ as much.

I generally only need `ln -s `. I know the -s means symbolic link, but in my head I read it as "source", since that's how I remembered the order long ago.

This is confusing, because when you picture the link as an arrow (as in `ls` output), the link name is the source and the link target is the destination.

Re: From novice to master, and back again (2013)

#93

Post by layer8 »

hvs wrote: post #44
MobiusHorizons wrote: post #31

Earlier quoted context omitted.

I think what a lot of people don’t get about the Unix command line is that learning to use the tool is part of the experience. Sure I forget the precise flags to get various tools doing what I need, but browsing the man page and rediscovering the breadth of the tool is half the beauty.

The only feeling I've gotten looking at a man page is, "well, I don't have to time to dig through all of this. Guess I'll just look at stack overflow which will have my exact use case and required parameters."

In my opinion, the EXAMPLES section should be near the top of the man page and include the most common usages.

Re: From novice to master, and back again (2013)

#94

Post by shriek »

Underphil wrote: post #62
dmd wrote: post #52

Twice in the last decade I've been completely stuck on something, googled extensively, finally found the answer ... which I wrote, on Usenet, 25 years ago.

Worse : You Google a question and realise you yourself asked it many moons ago and it never got answered.

Oh man this happened to me last month. I was even wondering how this guy had the exact same issue that I was having and only realized after a while that it was literally me who posted it. I eventually found an answer and decided to post an answer in case future me forgets it again.

Re: From novice to master, and back again (2013)

#96

Post by layer8 »

nice2meetu wrote: post #91
layer8 wrote: post #85

Earlier quoted context omitted.

> logically, the source must be the first one! You mean the target, but that isn’t a logically necessary consequence at all. Conceivably, `ln` could support the following two syntaxes: ln [options] target ln [options] link_name target The way I remember the correct parameter order is that I remember it’s the non-intuitive one.

Ah, I remember it is the non-intuitive one, but then when I use it a while, I keep double-guessing which one is the intuitive one. Kind of like when my wife tells me I'm doing something wrong and she wants it to be the other way.. I know she thinks this thing is important, but can't work out which way she wants it done.

The intuitive one is the order in which `ls` displays it, or assignment order (a := b). That’s how I remember what the intuitive order is. ;)

Re: From novice to master, and back again (2013)

#97

Post by scruple »

belval wrote: post #35
focusedone wrote: post #16

Wow, epic! The most depressing thing is being presented with an issue and finding my name attached to a closed ticket from years before with no explanation of how I fixed it. Guess what, current me, you're going to learn this again from scratch because past me was in a hurry and couldn't be bothered to type out what he did. BSG - this has all happened before, and it will all happen again.

I go through the same thing but with a few "popular" GitHub issues. Every time I encounter those bugs I Google it and the first result in my comment on the issue that explains the workaround I used. That's probably how early Alzheimer feels.

I sometimes have to go back to GitHub issues I created, that I bookmarked for this specific reason.

I think that the Internet has modified how our brains retain information. I don't think this is an original idea, but I've observed that I'm real good at indexing where I saw some piece of information and very poor at storing the actual piece of information. I have to physically write things down to commit them to recallable memory.

Re: From novice to master, and back again (2013)

#98

Post by cestith »

lazide wrote: post #22
100011_100001 wrote: post #10

I find my personal memory is very ephemeral, without repetition, things get quickly forgotten. In a long enough timeline, about 1-3 year, I start to fail recognizing my own code. Since I have trained most Jr Devs I work with they all have similar coding patterns as me, which makes it even harder. Granted, I have specific code tells, which helps, but like the article mentions I have forgotten the why or the bug that I…

That feeling when you go on a rant about how something was done in a super confusing way, so you do a ‘git blame’ or equivalent - and it’s all your fault. Oops.

This is why there's a "from:" line in the standard commit message template I introduced for my group of teams. If there's a ticket, bug report, user story, specification change, or standards reason for the commit I want to know that later. Sometimes that makes it into the code comments, and sometimes into the docs. It's always in the commit.

Re: From novice to master, and back again (2013)

#99

Post by cestith »

Banana699 wrote: post #82
bcrosby95 wrote: post #23

Earlier quoted context omitted.

My biggest problem with regex is each language/program/whatever has their own take on it. You don't have to learn it over and over, you have to learn multiple slightly different versions of it over and over.

I don't mind the slightly different versions, that's what documentation and SO is for. I mind the language being a garbage kludge of organically-grown syntax and semantics, with not the slightest hint of a single principle or a unifying idea. And I mind that the vast majority of interfaces to it from a general purpose PL is fucking around with strings like a caveman, instead of a typed, IDE-assisted, first-class repr…

From this description, you may enjoy Raku.
Post reply on HN