From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: Emanuel Berg Newsgroups: comp.lang.ada Subject: Re: 4 beginner's questions on the PL Ada Date: Sat, 10 Aug 2013 19:43:11 +0200 Organization: Aioe.org NNTP Server Message-ID: <87eha1787k.fsf@VLAN-3434.student.uu.se> References: <87ob96ajv6.fsf@VLAN-3434.student.uu.se> <877gfucton.fsf@VLAN-3434.student.uu.se> <87pptmb4p9.fsf@VLAN-3434.student.uu.se> <88cb99c6-df8b-49f8-ac53-54b737a02c34@googlegroups.com> NNTP-Posting-Host: SWN/nubmpQxYKwY7hPy4YA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) X-Notice: Filtered by postfilter v. 0.8.2 Cancel-Lock: sha1:ISSTj+ONQfUrDD9Kg0bXvVPfIVo= Xref: news.eternal-september.org comp.lang.ada:16785 Date: 2013-08-10T19:43:11+02:00 List-Id: Shark8 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