[jblow]

No, you clearly didn't understand my point. I am talking about maximizing the rate of successful features implemented. Programming things in assembly language is obviously not going to do that.

I don't know, man. I have 31 years of programming experience. I am not detecting from your argument that you have anywhere near this level of experience, so I am inclined not to get into this discussion. But I will say that your code example at the end of your comment is exactly what I am talking about. It happens all the time that I want to put something in front of 'return b' (or, in fact, I just want to put a breakpoint on that line in the debugger! Not going to happen in your second example...)

[georgeorwell]

I'm not even clear that it's clear I didn't understand your point. I guess I have trouble communicating effectively. I thought your point was that flexible control flow structures like if-else allow you to change code quickly and more easily in the future. Wasn't that the point?

Assuming I have understood your preference for flexible code, I am simply stating my belief that it is useful to balance this with rigid code. Sometimes the flexible code is simpler, easier to read and write, and more maintainable, sometimes the rigid code is simpler, easier to read and write, and more maintainable. It depends on what you are trying to do. In this particular case I prefer the ?:.

The assembly argument was based on a notion I had that any time you use something more complicated than test and branch for control flow you are introducing rigidity into your code. Often this lets you be productive too; switch statements are a good example.

And lastly, let's assume I am 14 years old. Is that really the way a wise teacher talks to the young and inexperienced? My favorite teachers ask questions to check and help deepen my understanding, and sometimes it's revealed that they're learning something too.

[jblow]

Sometimes rigid code is simpler, sure. But what I am arguing is that it is almost never more debuggable / maintainable.

What I am saying is not specific to test and branch, though test and branch is great because it gives you these big code blocks into which you can insert more code and it's clear where that code lives and under what circumstances it runs. Which is something you don't get in assembly language, which is part of why the assembly language reply is a goofy straw-man argument.

Yes, my reply was a bit irritable; I would definitely prefer to have a reasonable discussion, but the assembly-language thing was the first volley in being unreasonable. Putting up a straw man like that is an attempt to win the argument, not an attempt to understand the other person's position. I detected this and decided, well, if that's the position, then it is useless trying to make further / deeper rational arguments, so I am just going to say, this comes from a lot of experience, so take it or leave it.

As fatbird replied, "This is shitty." (I can't reply to his reply yet because of the timed reply thing, so I am including it here.) Maybe it is shitty, I don't know, but it's true and sometimes you just have to say the true thing to be expedient and get on with life.

I don't have time to teach people on the internet how to program. I work my ass off for 4 years at a time to build and ship games that are critically acclaimed and played by millions of people. These are the kinds of things most programmers wish they had the opportunity to work on, and wish that they knew how to build. (Often programmers think they know how to build these things, and then they go try, and they fail. It is a lot harder than one thinks). I am not saying this to brag, because I honestly don't feel braggy about it right now. It's just fact. I am pretty good at programming (probably not as good as Carmack) and I have worked really hard for a long time to be as good as I am. Meanwhile I am also trying to be pretty good at game design, and oh yeah, running a software company.

So when I give advice like this, and someone retorts, and it seems to be coming from a place of lesser experience, it is not really worth my time to get into a serious argument. I am not going to learn anything. I have been in the place where I had that kind of opinion, many years ago, and then I learned more. Fine. I can either be polite and quiet about it, or say something a little bit blunt and rude, in the hope that the other person (and maybe any bystanders to the conversation) will seriously re-consider what was said in light of the new information that it comes from someone who is maybe not a joker. I can't spend a lot more time than that teaching everyone in the internet how to program, because it takes almost all the energy I can muster just to build software. (Though occasionally I do write up stuff about how to program, and give lectures bearing on that subject, like this one: http://the-witness.net/news/2011/06/how-to-program-independe...).

Of course this don't-get-into-the-argument strategy of mine has at least partially failed, since here I am typing out this really long reply. I don't know.

[georgeorwell]

I used the word extreme in the assembly language argument to indicate that I understood you weren't actually advocating people program in assembly. So I don't consider it a straw man. Rather, it was an example of extremely flexible control flow. Sometimes this is what you need. Sometimes you need to modify the stack so that a function is called in a different way. Sometimes gotos can provide significantly more efficient code. Sometimes vtables are too expensive. Rails is at the opposite end of the spectrum, it is very rigid. As a refutation to your argument against rigid code, a lot of people consider Rails code to be debuggable and maintainable. Personally, I like a middle ground and try to be aware of the costs and benefits of making and using cookie cutters, an example of which is chained ?:.

I was not asking questions to "destroy your argument", I was trying to establish different contributors to rigidity / flexibility. It seemed to me that in your argument you were dismissing rigidity - certainly you weren't praising it - and I wanted to point out that in the use of any control flow more complicated than test and branch you are in fact relying on rigidity. If this is a "straw man" in your eyes, then so be it. Having functions introduces rigidity! Even if-else enforces some things. If anything, I was just actually interested in the topic, because I hadn't really thought much about the tradeoffs of rigid vs. flexible in those specific terms and I wanted to explore them a bit.

What if I revealed myself to you, and then you were like, oh shit, I better take what he says a little bit more seriously, wouldn't that just be embarrassing? I don't want to do that to you.

[jblow]

Creepy reply is creepy.

About this:

"Plus, I mean, what if I revealed myself to you, and then you were like, oh shit, I better take what he says a little bit more seriously, wouldn't that just be embarrassing? I don't want to do that to you."

No, by all means, go ahead. I am interested in having a productive discussion about programming, so if you can share your experience in a way that convinces me, I am totally open to it. If it turns out I am wrong, I won't be embarrassed, I will just change my opinion so that I am not wrong any more. This is how one becomes a good programmer in the first place: by paying attention to what is empirically true, rather than what one is originally taught or what seems exciting or what is in theory better.

[eru]

John Hughes makes a good argument in favour of rigidity in "Why Functional Programming matter" (e.g. http://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pd...)

[georgeorwell]

I cut out the creepy parts, I agree that they were. I can't reveal my experience without breaking anonymity. If you need to know about my experience for my examples and arguments to hold water, then my points aren't very good anyway, which is why I prefer to stay anonymous. Good luck with The Witness and I'm sorry that this was painful. Symbolism and meaning in games are important and I appreciate what you are doing.

[neumann_alfred]

It depends on what you are trying to do.

Which you can't know in advance, which is the point. Since you don't know what you might want to do with stuff down the road, you end up writing code in a style that is less concise but more "putty-like". I am an amateur programmer with derpy years of experience, but I found myself often taking "shortcuts" out after a while, because they made working with the code harder.. just like the poster said, I realize that trying to be super clever all the time isn't that helpful. I guess you could say in places that are subject to constant change or lots of copy and paste, I trade screen space for putty-ness, and when something turns out to not really change anymore, or generally gets in they way of more interesting things, I compact it a bit.

[fatbird]

I have 31 years of programming experience. I am not detecting from your argument that you have anywhere near this level of experience, so I am inclined not to get into this discussion.

This is shitty.

[Cushman]

Not to repeat myself, but:

    if (a) 
      printf("returning b");
    return a ? b : c;

...makes it easy to modify the side effects of the return without muddying the semantics.

[to3m]

Now, let us suppose that expression a has side-effects...

"But that's just stupid!"

Yes. Now, given that a has side-effects...

[georgeorwell]

Assuming a has type int:

  int a_val = a;
  if (a_val)
    printf ("returning b");
  return a_val ? b : c;

Anyway, it's not useful for complicated code that needs to do lots of stuff. It's useful for simple code that ends up being more verbose with if-else. It's also useful for enforcing behaviour.

[Cushman]

Suppose I want to `printf("Returning. A: %i", a)`. Same answer.