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

What's wrong with this code, really?

cvmountain.com

Post reply on HN
Print view View original

121–130 of 217 posts

Re: What's wrong with this code, really?

#121

Post by WildUtah »

JoachimSchipper wrote: post #88
morsch wrote: post #62

Earlier quoted context omitted.

Depends on what you want to accomplish and what your container and iterators support. If your Iterator offers a delete method, I think it's a very elegant and clear way to filter a container. for (Iterator it = container.iterator(); it.hasNext(); ) if (!predicate(it.next())( it.remove(); It's more ugly and error prone if you've got to juggle an index, though.

Even with plain C, you can just iterate backwards: for (i = ctr_size(container); i > 0; i--) if (!predicate(container, i - 1)) ctr_remove(container, i - 1);

Use the goes-to-zero operator.

  for (i = container.size; i-->0;)
    if(deletep(container, i))
      container.remove(i);

Re: What's wrong with this code, really?

#122

Post by sanderjd »

boredguy8 wrote: post #101
jcromartie wrote: post #58

Earlier quoted context omitted.

I think there's a fundamental concept that isn't taught very well, and that concept is: Computers only ever do (for something like 99.999999999% of instructions) exactly what they are told to do. They don't have a mind of their own, and programming isn't magic. Opaque languages, libraries and APIs don't help the situation either. I wonder how many programmers start out under the assumption that computers are more-or-…

Physical objects only ever do exactly what they're 'told' to do, period. Rocks don't have a mind of their own, and physics isn't magic. Yet I don't want to live in a world where we don't spend time twiddling with dials and poking around.

I agree with the thrust of your statement, but it's worth keeping in mind that while physics isn't magic it is not deterministic either, once you start working with really small things.

Re: What's wrong with this code, really?

#123

Post by sanderjd »

outworlder wrote: post #73
jcromartie wrote: post #58

Earlier quoted context omitted.

I think there's a fundamental concept that isn't taught very well, and that concept is: Computers only ever do (for something like 99.999999999% of instructions) exactly what they are told to do. They don't have a mind of their own, and programming isn't magic. Opaque languages, libraries and APIs don't help the situation either. I wonder how many programmers start out under the assumption that computers are more-or-…

I've noticed this "magic" thing too, among the most clueless members of our profession. Even if they have no idea how bad they are, which they usually don't.

You see this a lot (even on this forum) with people referring to Rails "magic", when it can't possibly be anything but a bunch of lines of code being executed according to the rules of a certain interpreter.

Re: What's wrong with this code, really?

#124

Post by jcrites »

MortenK wrote: post #27

About the McConnell quote: "Inefficient programmers tend to experiment randomly until they find a combination that seems to work." The essence of this quote is being passed around quite often these days. When you first start programming, you generally have no idea what the hell you are doing. You learn all these strange, abstract concepts best, by experimenting. It's easy to dismiss people "jiggling things around unt…

> It's easy to dismiss people "jiggling things around until they work", as lesser, more inefficient or just plain bad programmers. Just remember that you were once like that too.

Sure. But you're not ready for much more than an internship in the software industry (if even that), if that's the phase of programming you're at. The point is that you aren't yet ready to write production code if that's your approach.

Re: What's wrong with this code, really?

#125

Post by sanderjd »

simonsarris wrote: post #94
thaumaturgy wrote: post #78

Earlier quoted context omitted.

Yikes. That's quite a difference in performance ... what I still don't understand though is, why? I've done a little bit of searching and I can't find anything so far on how JS arrays are implemented. Since JS arrays are objects and inherently support things like out-of-order indexes, non-integer indexes and that kind of thing, maybe we can assume it's some kind of hash map? A tree would make sense too, for faster ac…

Most of the time it is simply because a shift operation has to re-address each element in the array (if it is implemented like a ho-hum, classic array) and a pop operation does not have to do this.

I think the assumption was that even arrays indexed by integers are stored as JS Objects, which are basically a hashmap style structure, and so they wouldn't be implemented like a ho-hum, classic array. I'm not sure if that assumption is right, but if it is, there would be no need to re-address each element.

Re: What's wrong with this code, really?

#126

Post by drv »

jeffesp wrote: post #10
wccrawford wrote: post #2

Like the blog author, I thought it was obvious what the problem was: Every time I read that, I'm going to have to figure out what it means. Any time there's a problem or change to code in that area, I have to stop and understand what it's doing. To clean it up, I'd do 1 of 2 things: Either write a .clear() function, or rewrite it to start at the end and clear the items in reverse. With the .clear() function, I can at…

Besides a .Clear(), wouldn't the second most obvious be to have a count variable external to the loop that is initialized to the number of tabs before entering the loop? Then you still count up, and are able to reach the end of the list. Either way, we have just come up with 3 much clearer solutions in what I would guess is at most 5 minutes between us. I would guess we have the luxury of it not being 9pm at night an…

This is broken in a different way (assuming you mean something like the following):

  int c = this.MyControl.TabPages.Count;
  for ( int i=0; i
Let's say you have 4 items. That'll go something like this:

  Original list: (0,1,2,3)
  Remove 0    Item 0 removed, items (1,2,3) become (0,1,2)
  Remove 1    Item 1 (originally 2) removed, items (0,2) become (0,1)
  Remove 2    Only two elements left in the list (0 and 1), so there is no index 2 anymore...

Re: What's wrong with this code, really?

#127

Post by sanderjd »

[deleted] wrote: post #108
microtonal wrote: post #47

Earlier quoted context omitted.

But we are talking about tabs here. Premature optimization is the root of all evil (to throw another cliché).

[deleted]

I really like your insight about the accumulation of decisions over the course of a project - I've never thought about it in quite that way, that by having one default decision or the other, your project's destiny is completely different. Picking a sane default answer to that question for a project should be thought of as one of the (many) important jobs of its creator.

edit: I really don't understand why the parent comment was downvoted and then deleted.

Re: What's wrong with this code, really?

#128

Post by rtperson »

sid0 wrote: post #118
hxa7241 wrote: post #112

Earlier quoted context omitted.

for (i = ctr_size(container); i--; ) if (!predicate(container, i)) ctr_remove(container, i);

filter predicate xs :)

Haskell, I assume. Two things really make Haskell shine when it comes to problems like this: 1) higher-order list operations -- you're not iterating through indices, so there is no possibility for off-by-one errors, and 2) immutability -- your code takes a new list with the undesirable elements removed; you can't remove elements of a structure at the same time you're iterating through it.

I always love the problems on SPOJ where they give you the number of cases up front, because in Haskell you can almost always throw out that value. Your map function knows when the list is out of elements.

Re: What's wrong with this code, really?

#129

Post by sid0 »

rtperson wrote: post #128
sid0 wrote: post #118

Earlier quoted context omitted.

filter predicate xs :)

Haskell, I assume. Two things really make Haskell shine when it comes to problems like this: 1) higher-order list operations -- you're not iterating through indices, so there is no possibility for off-by-one errors, and 2) immutability -- your code takes a new list with the undesirable elements removed; you can't remove elements of a structure at the same time you're iterating through it. I always love the problems o…

Yeah, I was thinking Haskell, but any functional language will do. Problems like the one in the blog post really make you appreciate them.

Re: What's wrong with this code, really?

#130

Post by g0su »

It's bad because you have to write a long blog post about it explaining all the pitfalls, compare good to bad programers, talk about maintenance cost, etc etc.

This code:

for i in 1.100: print i

There's nothing to talk about, it's crystal clear.

Post reply on HN