Re: 4 beginner's questions on the PL Ada

[Emanuel Berg <embe8573@student.uu.se>]

Shark8 <onewingedshark@gmail.com> writes:

> There's a *huge* problem with this: superficial understanding.
> This problem can lead to extremely bad code adopted as "best
> practice"/"standard practice".

There is nothing superficial about code. Code *is* programming!

And code can have a "maturing" side just as reading a book:
re-reading it two years later, and basically reading a new book
(and not because the book has changed by even a single letter).

Can you honestly say you understood semaphores, pipes, etc., the
first time you used them? For one, I admit I didn't. But now I do,
because I wrote that code, and invoked those commands, so many
times.

And all the while, I *did* something that made my system better,
more user-friendly, and/or more fun.

I could have read that chapter in "Big Book of Unix IPC" (a couple
of times), and that would have given me - the same understanding?
Perhaps, but not for sure (actually, I doubt it). The same
experience? No. Not typing, not managing a project, not compiling,
nothing like that at all. All the million "side-effects" to doing
stuff: self-confidence, creativity, etc.?  None. And all the
improvements to my system - all the .profile, .rc, .emacs,
.Xresources, all that stuff? (Now I move away from the IPC
example, but the principle holds.) Nothing. Just a very impressive
bookshelf!

But, that being said, books are *great*. If they weren't so
expensive, I would own a lot more of them. References are great,
as well. But I like mine offline (i.e., on paper).

I don't like Googling - it disturbs my workflow, and hearts my
eyes (I exclusively work in Emacs, in a Linux VT - see the
screenshots [1] - it is the best configuration - faces, the font,
etc. - that I spent years configuring, to counteract tired/dry
eyes).

Googling also reduces the mental-physical presence: relying on it
will reduce your attention span - in the room, in time - giving
you "short thoughts" instead of "long".

This may seem monkish, and it is. I like Lisp, C, LaTeX, that
stuff. I don't like Python, Java, PHP (or any web programming). I
don't like GUIs (except for very specific applications, e.g., GIS
and the like; and then I accept them for *others* to use). I don't
like IM but love mails, which I send from rmail. I don't like the
SX sites, but Usenet, for which I use Gnus. I see a pattern in
this, and I hope you do, too. (And not be offended if *you* happen
to like Java.) So you see, you can, as I, prefer code to
documentation, and there is nothing superficial about it.

> An excellent example: PHP's official site.  They go to the code
> side even in the documentation, to the point where the mb/forum
> attached to the particular function is oft littered with code
> examples... and usually bad ones once you gain a deeper
> understanding of what's going on.

That's not an excellent example. If the code is *bad*, all bets
are off... (Well, not quite, because I can learn a thing or two
from that code, and then re-write it the way I think it should be
done.) It's like me picking up the worst documentation ever
written, saying it exemplifies why documentation shouldn't be
studied.

> Then you're a step ahead of the cut-n-past script monkeys that
> the "code snipet" style seems to generate -- not to say that
> code isn't useful but, again, it seems to encourage a lazy
> psudeo-understanding.

This is 100% incorrect. I'm not going to argue with you if this is
your base, because it is not productive one bit.

-- 
Emanuel Berg - programmer (hire me! CV below)
computer projects: http://user.it.uu.se/~embe8573
internet activity: http://home.student.uu.se/embe8573