Hacker News Search

stcredzero 19y ago

The semantics of that are no different than a case statement. (Unless this is in a performace-critical loop, and you'd gain something though a compiler optimization of the case statement.) You're equating using case statement syntax to good programming? That's the best example you have of a "mess?" That makes me suspect that you don't think about programming at a very high level and that you like making largely arbitrary changes to code for (unacknowledged) ego-driven reasons.

edw519 19y ago
"You're equating using case statement syntax to good programming?" No. I'd prefer something a little closer to: Months = ['January','February','March','April','May','June','July','August','September','October','November','December']; MonthDesc = Months[MonthNbr - 1]; "That's the best example you have of a mess?" No. Just what came to mind. "That makes me suspect that you don't think about programming at a very high level" You suspect wrong. Don't suspect. Ask and find out. "you like making largely arbitrary changes to code for (unacknowledged) ego-driven reasons" If only I had the time, that would be my dream come true!
- stcredzero 19y ago
  Array indexing is just another way of getting it done. Often a case statement is going to be faster. 90% of the time, it just doesn't matter. If you're getting paid for doing such useless code changes, you might as well get paid for surfing Y Combinator news. Perhaps that's why the original programmer is a successful founder, and you're fixing the code. > You suspect wrong. Don't suspect. Ask and find out. Don't have to ask. You actually think minutiae at this level is interesting discussion. That's evidence against you.
  - brlewis 19y ago
    I actually think cutting 12 lines of code down to 2 is worthwhile. He could have posted an example of 600 lines of code that should have been 50, but I'm glad he didn't.
  - edw519 19y ago
    Do you really think "faster" is what's most important? In any of these cases, we're in core, where measurements are made in nanoseconds. So it just doesn't matter. Anyone trying to squeeze a few nanoseconds out of anything is wasting their time. Now let me tell you what DOES matter. Ready? My back of the envelope solution is 15% as much code as the original. To do the same thing. THAT is a big frickin' deal. If you've ever spent time building, deploying, enhancing, and maintaining anything of substance, then you already know that, right? Never said the original programmer was a successful founder. I said he was a retired millionaire. Not hard to do after 40 years in this industry. Or in his case, 1 year's experience 40 times. I'm fixing bad code because there is a stunning demand to do so now. Because of guys like the original programmer. Which is great. Because it demonstrates the demand for the startup I'm developing. By the way, I don't decide what is interesting discussion here. The whole group does. Apparently, someone other than you thinks that what I have to say is interesting.
    - stcredzero 19y ago
      > Do you really think "faster" is what's most important? As I said before in the thread, over 90% of the time, no. Actually, more like 98%, no, so we are in agreement about nanoseconds. I only included the quip about performance for completeness. True, the array indexing code is much shorter. That can be worthwhile. If your project has gotten to the point that these sorts of things are actually worth your time pursuing, then you're doing very well. But that would mean that all your bugs are fixed, there are no more pressing architectural issues, and there are no highly demanded bits of new functionality to implement. In other words, your project would be practically dead. Reducing a 600 line subsystem to 100 lines would be a big deal. Reducing 12 lines to 2? Nope. It runs. Reducing 12 lines to 2 in 500 different spots around your codebase? Well, if that's the case then I'm sorry that you have to put up with that all over the place, but at least it's correct. Again, if your highest priority is cleaning up stuff like that, then you probably have it easy. Too easy.
      - edw519 19y ago
        I realize we're beating this to death, but so what. It's never my priority, it's always my customers' priority. Here's my life right now: Customer is opening new warehouse in 2 weeks and calls me to change whatever software needs changed to split orders to print in the appropriate warehouse. I agree because I'm a masochist. I find 15,000 lines of code to do what I (and you too, probably) could have done in less than 1000. Most of it was clearly written by someone who had no idea what they were doing, much of it is never accessed, much of it has never run properly, and I have to do something. I rewrite what, in my professional opinion, must be rewritten. I workaround what I can, and I add what I need. I want it to work right the first time and I never want to come back (until new business requirements come along). I am usually very successful doing this, making changes during unit and system testing and finishing in a day or two. I use to be bitter about cleaning up other peoples' mess because they were too lazy, stupid, rushed for time, or whatever. But no more. I've turned around my thinking to use all of this as a motivator to build solid business apps where no one ever has to go though this again. <closing loop...> THAT'S what has motivated me to do my start-up. I threw out my original example because it's a classic, it came to mind quickly, and most readers here, even the juniors, could understand it. I had no idea it would spawn such discussion. Nice talking to you.