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

What most young programmers need to learn

joostdevblog.blogspot.com

Post reply on HN
Print view View original

81–90 of 108 posts

Re: What most young programmers need to learn

#81

Post by loqi »

eric_h wrote: post #48
vog wrote: post #3

> Code in comments [...] When asked applicants are usually well aware that commented-out-code is confusing, but somehow they almost always have it in their code. To my experience this is a common symptom of not using a version control system. You change a line of code, but you want to be able to undo if it doesn't work, possiblay half an hour later when you changed other places of your code (so your editor's undo is…

We have a saying over here - TWGIF[1]. Any time someone checks in commented out code, they get chastised. 1: TWGIF - That's what git is for

I've gotten in the habit of adding trailing whitespace when I comment out code or do any printf debugging. It's still quick, but then git yells at me if I try and commit it.

Re: What most young programmers need to learn

#82

Post by npsimons »

jimmaswell wrote: post #61
vog wrote: post #3

> Code in comments [...] When asked applicants are usually well aware that commented-out-code is confusing, but somehow they almost always have it in their code. To my experience this is a common symptom of not using a version control system. You change a line of code, but you want to be able to undo if it doesn't work, possiblay half an hour later when you changed other places of your code (so your editor's undo is…

Maybe for just a small code segment, a comment is a lot more convenient than going all the way through git for it? What if there's some functionality in a method you're not sure you want to take out or change or not, but you've also added to the rest of the file, so you commit it with a small code segment commented out and a short explanation? That's not hurting anything and it'd be a PITA and overkill to put it in a…

Maybe for just a small code segment, a comment is a lot more convenient than going all the way through git for it?

I don't get this; stashing changes, branching, even just copying and pasting something from history in git, are all very fast for me (using git in emacs with egg). Granted, I can comment-dwim with M-;, and I've conditioned myself against "just" commenting out code, but still.

Re: What most young programmers need to learn

#83

Post by mkehrt »

dschiptsov wrote: post #10

Scheme. As still the best "small" language to teach fundamental principles (everything is a first-class value, symbols are references to values - naming, procedure composition and nesting as the basic building block, ADTs, immutability of the data, evaluation strategies - eager and lazy, and what is meant by "mostly functional language", etc.) and shapes of data structures (list, three, table). It will pay back with…

Disagree about monads. What you mean is that IO actions are an awkward way to ensure evaluation order in a lazy language. In Haskell, IO actions form a monad, but this is only reasonable because so many other things form a monad that the language has special support for them.

Monads are great in that disparate things like lists, sets, IO, control flow, state, optional values, and even functions are all instances of a single ADT which is useful enough that one can write reasonable code abstracted over it, and Haskell provides the mechanisms to do so.

Re: What most young programmers need to learn

#85

Post by UrMomReadsHN »

gknoy wrote: post #70
UrMomReadsHN wrote: post #46

Earlier quoted context omitted.

No... you are making your code hard to understand to others by doing that. Thats if you check it in like that. Nothing wrong with leaving it there during development.

I disagree. If I see 25-40 lines of something that LOOKS like it should be simple, it's tempting to replace it with the four line version. A comment which says, "You might think this would be better as {{4 lines}}, but it is too slow... because this/that/etc" can be VERY helpful, so that one doesn't reproduce the problems (and the time fixing) that caused the initial un-simplification in the first place.

Thats totally different than just leaving it there without any context at all. Which is what i was referring to.

An actual comment is of course helpful, but when people check in code that has been commented out it usually has no explanation at all. Thats the confusion part.

I'm talking stuff like this...(and I believe so was the author)...

//int foo = 10;

int foo = 20;

if (bar)

//if (foo > 0)

{

foo++;

}

//else

//{

//foo--;

bar = false;

//}

Re: What most young programmers need to learn

#86

Post by dschiptsov »

mkehrt wrote: post #83
dschiptsov wrote: post #10

Scheme. As still the best "small" language to teach fundamental principles (everything is a first-class value, symbols are references to values - naming, procedure composition and nesting as the basic building block, ADTs, immutability of the data, evaluation strategies - eager and lazy, and what is meant by "mostly functional language", etc.) and shapes of data structures (list, three, table). It will pay back with…

Disagree about monads. What you mean is that IO actions are an awkward way to ensure evaluation order in a lazy language. In Haskell, IO actions form a monad, but this is only reasonable because so many other things form a monad that the language has special support for them. Monads are great in that disparate things like lists, sets, IO, control flow, state, optional values, and even functions are all instances of a…

> one can write reasonable code abstracted over it

Don't you think that at least in a strict language, this would be rather over-abstraction or abstracting for the sake of abstraction?

Re: What most young programmers need to learn

#87

Post by mkehrt »

dschiptsov wrote: post #86
mkehrt wrote: post #83

Earlier quoted context omitted.

Disagree about monads. What you mean is that IO actions are an awkward way to ensure evaluation order in a lazy language. In Haskell, IO actions form a monad, but this is only reasonable because so many other things form a monad that the language has special support for them. Monads are great in that disparate things like lists, sets, IO, control flow, state, optional values, and even functions are all instances of a…

> one can write reasonable code abstracted over it Don't you think that at least in a strict language, this would be rather over-abstraction or abstracting for the sake of abstraction?

Not really. I think you're confusing Haskell's purity, which makes it necessary to write monadic code, with its monad syntax, which makes it easy.

Re: What most young programmers need to learn

#88

Post by sanderjd »

sophacles wrote: post #77
justifier wrote: post #63

Earlier quoted context omitted.

what i understood as the author's issue with copy paste was the knowledge that changes are expected if you copy: do_something(); do_another_thing(); another_call(); a few times in your codebase, but decide that you want to alter that a bit: do_something(); perform_new_feature(); do_another_thing(); another_call(); you can hurt yourself by forgetting that that alteration needed to be done to each instance just easy to…

Yes in that case it's a win, but it becomes an anti pattern when you sometimes want to perform_new_feature() and sometimes you don't. I've seen it happen where you end up with many functions like: def a_and_b_and_c() {...} def a_and_b_and_c_error_checked_internally() {...} def a_and_new_and_b_and_c {...} def a_and_new_and_b_and_c_error_checked_internally() {...} def a2_and_b_and_c And so on. Basically you are just pu…

This is a great discussion! I've always thought that after the basic "how do I even do this at all?" concepts of programming, the next most important concept to learn how to wield and to perpetually sharpen is the "don't repeat yourself" principle. Huge swaths of software engineering literature is dedicated (explicitly or implicitly) to when and when not to apply that principle.

Your parent's comment addresses by far the best argument for the principle, which is that any time something is likely to change in a snippet, copy-pasting should be undertaken rarely and thoughtfully. With the recognition that nearly any given snippet is likely to change in some way, we can conclude that nearly any copy-paste is "bad".

Your comment is then a great argument against the thoughtless application of the principle, recognizing that yes, granted, nearly any snippet will change, but the required changes may well not be uniform.

Personally, I think it still makes sense to pull out shared behavior for the period of time in which it is shared. During that period of time, all you have is a guess that the code might eventually diverge. If there comes a point in time when you do want the code to diverge, it is straightforward to copy-paste it back out, if branching or creating a similar method with the differences is a worse option. On the flip side, if you haven't pulled out the shared behavior, and you discover that you want to change it everywhere in the same way, it is far less straightforward to go find all those places, or even be aware that you need to do so.

Another point is naming by purpose rather than behavior. To continue your example, it makes sense to ask why one method checks internally and the other externally? What different purposes do the different checking styles have? If there are good answers to questions like that, the methods can be named better, and it becomes less about memorizing name than understanding when to use which.

Of course none of this is at all black and white, and I think you're spot on that this is one of those craft bits, and among the most important!

Re: What most young programmers need to learn

#89

Post by dllthomas »

vog wrote: post #3

> Code in comments [...] When asked applicants are usually well aware that commented-out-code is confusing, but somehow they almost always have it in their code. To my experience this is a common symptom of not using a version control system. You change a line of code, but you want to be able to undo if it doesn't work, possiblay half an hour later when you changed other places of your code (so your editor's undo is…

Code should exist in comments when it's going to be uncommented shortly. This, because 1) reaching into the VCS is extra work compared to uncommenting something already present (think cache vs disk), and 2) more importantly, it is code that anyone making changes nearby should be aware of.

Code in comments may also occur as a symptom of poor VCS habits, but that's not always the case.

Re: What most young programmers need to learn

#90

Post by _asummers »

sonny9 wrote: post #15

I keep hunting for such a post specifically for an iOS Developer.. to get beyond the initial frameworks and learn processes and flows

Check http://www.objc.io/ for good pointers for iOS and Objective-C related things. I haven't done iOS for a year/year and a half, and I still read their posts.
Post reply on HN