[OT] Was: totally satisfied :D

[H. S. Teoh]

On Sat, Sep 22, 2012 at 03:48:49AM -0400, Nick Sabalausky wrote:
> On Fri, 21 Sep 2012 15:37:46 -0700
> "H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote:
> > 
> > The sad part is that so many of the commenters have no idea that
> > adjacent C literals are concatenated at compile-time. It's a very
> > nice way to put long strings in code and have it nicely indented,
> > something that is sorely lacking in most languages. But regardless,
> > why are they posting if they clearly don't know C that well?!
> > 
> 
> Heh, actually I didn't even know about it until I learned it from D
> and then learned that D got it from C (does D still do it, or is that
> one of those "to be deprecated" things?)

Heh. I suppose in any language complex enough to be interesting there
are always some things that you don't know about until a long time
later. :) So maybe I was a bit harsh on the commenters. But still, they
should've checked before they posted (but then I'm guilty of that one
too).


> But then dealing with strings is something I generally tried to avoid
> in C anyway ;)

Yeah... D is just so much more comfortable to write when dealing with
strings. With std.regex in Phobos now, writing string-processing code in
D is almost as comfortable as Perl, and probably performs better too.


> > > Note also that the "' ...code here" and "' ...more code here"
> > > sections were typically HUGE.
> > 
> > Speaking of 1000-line functions... yeah I routinely work with those
> > monsters.
> 
> *cough* DMD's main() *cough*  ;)
> 
> Although it's actually, surprisingly, not too bad in DMD's case, all
> things considered. Took me by surprise at first though, I really
> wasn't expecting it.

I haven't followed this rule to the letter all the time, but usually I
consider that if a function doesn't read like pseudo-code, then you're
doing something wrong. What I mean is, it should read like steps of an
algorithm that makes sense when you read it, for example, "initialize
data structure X to empty, loop over input items, transform data and
store in X, return result" should map to something like:

	Result func(Input input) {
		auto result = X();
		foreach (item; input) {
			auto x = transform(item);
			result.add(x);
		}
		return result;
	}

That is, the detailed steps in transform() shouldn't pollute the main
code in func(), but should remain as a separate function. Ditto with
X.add(), which may involve a complicated series of steps.

As soon as you start having a whole bunch of code at different levels of
abstraction mixed together, you know it's time to split them up into
separate functions, 'cos chances are you'll need to use each piece
independently one day.


[...]
> > I have seen code whose function names are along the lines of
> > "do_it()" and "do_everything()". As well as "do_main()" and
> > "${program_name}_main()" in addition to "main()".
> > 
> 
> What really gets me is that these are the sorts of things that are
> harped on in chapter 1 of just about any decent "intro to programming"
> book. So where did these people even learn to code in the first place?

Probably from a youtube video on how to write your own lame Flash game.
:-P  OK, I'm being a bit harsh. But it's hard not to be cynical when
you've seen the kind of code that passes for "enterprise software" these
days.


> Heck, back in college, I used to be a CS tutor for first semester
> programming students. Even *they* wrote better code, no exaggeration.

Totally. I've been a teaching assistant before, and we made sure to
drill sound programming practices into the students early, and often.
Makes me wonder where all these students went after they graduated, 'cos
the people writing code in the workforce don't seem to be the same
people who attended these courses. Strange.


> (Well, except for the handful of students, and I could always tell
> which ones they were, who were from the class of Mrs. "Let's Teach OOP
> *Before* Basic Flow Of Execution". Those poor students couldn't write
> *any* code, let alone good or bad code. I felt bad for them.) 

Speaking of students who couldn't code...  I used to give out "sympathy
marks" for struggling students. Y'know, their code was so bad, like code
that obviously didn't compile or work, or code with comments written in
a way that suggested the student thought that if they pleaded hard
enough verbally the computer might *just* do what they wanted it to do
-- they had to get a failing mark, but I tried to find excuses to not
give them an outright zero. But one time, after marking a bunch of 15-20
page assignments (complete with intro, description, code, test results,
etc.), I came across a submission consisting of a single sheet of paper
*hand-written* on a single side.  I was boggled for a good moment.  It
was like... I was trying not to give anyone an outright zero but she
gave me no choice, y'know?  What was the point of handing that piece of
paper if she wasn't even going to make the effort of using the lab
*printer*, for crying out loud.

What's scary is that sometimes I wonder if that girl would've done a
better job at the kind of "enterprise" code I see every now and then.
At least her inability to code (or use a computer, for that matter)
would be obvious, instead of the kind of garbage that passes for code,
compiles, and apparently works (and somehow passes code review) but has
so many things wrong with it that it makes you face-palm, many, many
times.


> > > I've been sticking to contract stuff now, largely because I really
> > > just can't take that sort of insanity anymore (not that I ever
> > > could). If I ever needed to go back to 9-5 code, or cubicles, or
> > > open-floorplan warrooms, I'd *really* be in trouble.
> > 
> > I really should start doing contract work. Being stuck with the same
> > project and dealing with the same stupid code that never gets fixed
> > is just very taxing on the nerves.
> > 
> 
> Yea, contract has it's upsides, although naturally it has it's own
> perils too. Making a living at it is *damn* hard (either that or I'm
> just REALLY bad at self-employment...but it's probably both), and
> frankly I'm still trying to figure out how to do it.
[...]

True. I suppose you just have to do what's most popular out there right
now. I know someone who does Java stuff, and he's never short on
contracts. In fact, he gets to choose his vacations 'cos he has enough
options in terms of which contracts he chooses to bid on.


T

-- 
"Maybe" is a strange word.  When mom or dad says it it means "yes", but
when my big brothers say it it means "no"! -- PJ jr.