151–160 of 178 posts
Earlier quoted context omitted.
> 11. Never use early exits. As a general piece of advice, this is flat out wrong. Or, to put it more correctly, this is only valid advice when using certain languages and only under certain conditions. Just because it is sound advice in languages with C/C++ derived syntax doesn't mean it should be presented as good advice in general.
Huh? You _want_ early exits in c code how else will the compiler optimize?
Earlier quoted context omitted.
You just asked a non-sequitur question. Patrick said, "consider carefully what you mean by success; one measure is geek status ranking, another is financial success". You responded by saying "show me your code" --- in other words, by implying that there is only geek status ranking, which makes no sense as a response. When you grok what Patrick is doing, the programming angle on it makes more sense. On HN, he's best k…
It is not, of course, about github. It is much simpler. When some scientist met, say, mathematicians, it is very normal to ask - show me what you have done. Or the same thing with writers - Oh, you're writer? What did you wrote. This thread was about programming, and the given comment was mere a self-assertion. So, it is OK to assert oneself if one wants to. But, show us, then, what you have done.
How to be an Excellent Programmer for Many Years (Excellent==Successful. Money & fame are more difficult to control.) 1. Choose a small subset of available technology, learn it intimately, and embrace it. Then evolve that subset. 2. Understand the pros and cons of various data structures, both in memory and on disk. 3. Understand the pros and cons of various algorithms. 4. Understand your domain. Get away from your c…
"Never use early exits" is tantamount to saying "never study programming languages deeply enough to understand control-flow graphs". That's not simply a good rule of thumb, it's a terrifying omission. I would suggest that early exists are simply a matter of taste and never using them is the crutch that keeps junior developers junior. Data are on my side here: a quick perusal of the Quake 3, the Linux kernel, the Cloj…
Earlier quoted context omitted.
I don't post this with any sarcasm or to draw any inferences about your intended meaning, but just to bring to your attention that the point you've now raised struck me independently upon reading: > A successful programmer is not just a programmer, he is also a personal representative, a salesman and a contract negotiator.
Yes, fair enough -- in that case, I had to either choose a gender for one word or go with one of those malaprops like "they".
Earlier quoted context omitted.
> 11. Never use early exits. As a general piece of advice, this is flat out wrong. Or, to put it more correctly, this is only valid advice when using certain languages and only under certain conditions. Just because it is sound advice in languages with C/C++ derived syntax doesn't mean it should be presented as good advice in general.
Huh? You _want_ early exits in c code how else will the compiler optimize?
Earlier quoted context omitted.
While loops are the exact same thing as GOTOs. It equals to: start: if(!p) goto end ... goto start; end: It should help people figure out why it's bad - in 99.99% of the cases ;)
A loop is based on a conditional jump (aka. a flow control statement in imperative langs) which makes all the difference. The problem with jumps (is usually called a jump, purely arbitrary jump) is that they are arbitrary: http://news.ycombinator.com/item?id=4627730
Earlier quoted context omitted.
When you advise against naming a variable a subset of another variable, are you talking about confusing names, or practices like breaking off a chunk of array to process instead of finding a smarter way to step through it like mapping or in-place logic?
No, just variable naming. As we speak, I'm maintaining some old code with the following variables names: - CommandRec - Command - Comm - Com along with the fact that some of these are reused for different purposes and all are global. I'm having a hell of a time finding all instances to rename them properly. I understand that some programmer interfaces are better than others hanlding this, but that belies my main poin…
Cmnd
Cmd
Command
RecCommand
Command
(Couldn't resist that last one)
Earlier quoted context omitted.
Naming a project "A/Bingo" and hosting it on his own site is "grey hat"?
Naming it "A/Bingo" and hosting it on his own site? Nah. Naming it "A/Bingo" and hosting it on his own site for the intent of garnering linkjuice while at the same time presenting the name choice as simply a guileless, clever pun (as he does in his announcement of the project [1]) and within the context of his normal policy of broad disclosure? A little bit. Perhaps "grey hat" is too strong a word. Swap in "a little…
Please name a salesperson more open and honest than Patrick. Tell us who he should emulate. If people don't emulate Patrick's style, maybe they should follow Marc Pincus or Coffeefool instead?
There are no really successful programmers. In a general sense: There are no really successful wage-earners. The only really successful people are business-people. That applies to just about every industry. No one is going to give you a billion dollars (or even a million) to sit at home or in an office and write code. No matter how beautiful and optimised and whatever other qualities you think code should have. Unles…