|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| News | Programming style | Recommended Links | Books | The Elements of Programming Style | Programming Abilities |
| C Programming Style | Perl Style | C Humor | SE quotes | Humor | Etc |
Programming is an art. So much depends on the level of programming talent you have. But emulation of great authors might help.
Another good source of insight into good style is to read the postings by Guido and other Python masters at http://www.findmail.ocm/list/python-list. Search for postings by Tim Peters and you will find a very enjoyable series of postings on topic of programming. Tim once worked on compiler optimization at Cray.
I don't know of any online tutorials that are that are that great, but Steve Summit's 'C Programming FAQ' is excellent.
-spc (I'd review some of these, but some of them are just too hard to find 8-(
I've always thought that Michael Abrash was a Good resource for Graphics and
Performance Code writing.. of Course most of his stuff is from an MSDOS
standpoint, but its still C and the "Techniques" are very portable.
Look at:
Michael Abrash's Graphics Programming Black Book
(There's even sections about how parts of Quake were done)
JWitt
Algorithms are the most important part of programming.
One doesn't need "real code" to learn or use them. A mistake made by many
people. A good designer understands how to program without tricks; a good
implementor knows how to weld them like a sword. A good programmer is both.
This book is out of print, but it's included on the CD that comes with 'Michael Abrash's Graphics Programming Black Book'.
Another very good book is Large Scale C++ Software Design by Lacos. It did teach the importance of dependencies and tools to handle dependencies correctly. Certainly recommended.
(nice tool to avoid cyclic dependencies is to assign a number to modules.
Independent module (or module that depends only on external modules) is level 0,
module that depends on level <=N module is level N+1.. => avoids cyclic
dependency as on a cycle you cannot find correct level number for them..)
The idea of scripts and tools
Having to write in several languages in the course of my schoolwork I find
a need to break applications up into two major parts, scripts and tools.
Scripts are a straight sequence of events. They should have for while's or for's,
and if's should be kept to a minimum. They are strictly for the uninitiated to
follow the sequence of events.
Tools are where the actual work of a processing is done. Tools make descisions,
branch into subroutines, tranform data, etc.
The best programs I've reversed engineered have used this dichotomy well. Tools
are kept seperate from scripts, and scripts are a one-shot sequence of events.
Best both in performance, AND legibility.
For a convoluted block of code is as confusing to the computer as it is to the
developer.
Abelson (head of the MAC group at the MIT AI Lab) and Sussman (one of the creators of Scheme, early AI Lab hacker) are in the process of putting their 'Structure and Interpretation of Computer Programs' on-line (I believe the first chapter is currently on-line, and there are some technical problems with the Tex->HTML conversion with the rest). It's the authoritative tutorial on Scheme programming, and the associated way of thinking. I'd still recommend buying the hard-copy, though.
I've always found the GNU libc to be an great example of good code. Each function is fairly simple & strait forward - clear yet with uncompromised speed.
This book has been mentioned here, but not in such a way that you could find it. Abelson & Sussman's "Structure and Interpretation of Computer Programs" is a book that can change your way of thinking. Really. It has lots of code (downloadable, by the way, from the book's site, but without comments). The code is in Scheme (I think everyone who knows Scheme knows this book, this comment is for those who may want to see what is beautiful about it).
I'd like to second the suggestion of Squeak (and, similarly, of the Smalltalk-80 Class Library in general). It is some of the most beautifully organized programming I've ever seen -- particularly at the core of the object and class system, and the introspection that makes it possible.
The entire system is designed with a great deal of effort towards an aesthetic/intuitive appeal. It is extremely well factored, and needs very little commenting because of its clear style.
The writers of Squeak, in particular, are some of the original authors of Smalltalk, and I think the system benefits from being yet another rewrite of the system.
The core authors include Alan Kay (inventor of the windowing metaphor, among other things), Dan Ingales (who I believe was also involved in the early PARC/Xerox research), the creator of the Morphic system from SELF (John Maloney? I'm afraid I'm getting names mixed up), and many others.
----
I disagree. Good code (written in a language which makes good code possible) should be self-contained. Comments become stale. They leave out details. Except for some summaries (when you don't care how the code does it, just what the code does), comments are, IMHO, a sign that the code isn't written as well as it could be.
Apache is a great work in my opinion. Anybody trying to write great software should check it out.
First off, the subject is an excellent one. Those that claim design is more
important that coding and commenting style are correct to a point. Both are
important to *great* works of code.
There are differences in individual coding styles, and with as many contributors
as the Linux kernel has, some of it can be rather dramatic. You can see were a
specific driver design is a hack, as well as those that are works of beauty.
Some lack critical comments that would keep others from "fixing" things that
look broken, but are only work-arounds for broken hardware. Others include very
descriptive and often brutal but funny commentary that explain exactly why
they've had to butcher their code in a certain manner.
By contrast, the Samba code seems to lack any sort of "design" at all. It
functions, but it is rather unfriendly to wade through. A project as critical to
the Unix world as Samba is should have far more coders working full time on it
than Samba does now. That is because one can't get a quick grasp on what is
going on in the code.
Samba has a relatively flat directory structure and no clearly defined API.
Samba does not bother to have any libraries that can be linked to other
programs, so adding SMB functionality to the desktop becomes far more difficult
than it should be. Instead, the only SMB clients are the ones that either
contain part of the Samba code base as their own (pam_ntdom) or are a part of
the Samba base itself (smbclient).
Because adding SMB support to other apps is os difficult, you end up seeing
things like tar file support in the Samba source tree. Samba doesn't need to
know how to create or extract tar files! That's for gnu-tar to do. The proper
thing to do would be to teach gnu-tar about SMB shares. But this is just not
possible with the current Samba code.
[Kernel coders know not to try that sort of thing with the Linux kernel. Those
that do get a few stern words from Linus himself. There is a clear understanding
as to what does and does not belong in the kernel.]
It is here that one realizes the importance of design... I have yet to mention
coding style in my description of Samba, because it does not matter. One must
have a good design before coding style is of concern.
Good code is kinda like a good book. If it's got a good plot, it doesn't
matter so much that the writer lacks a bit of style. On the other hand,
good writing style can never cover up for a bad plot. The great books
combine great plot with an equal amount of writing style.
[I don't mean to offend anyone with this post, especially those on the Samba
team. The Samba code does (IMHO) need shared libraries and a public API. That in
itself would help make Samba an easier project to work with or on. The server
software works and works well. But I do find the code rather difficult to
follow.]
The code that might be considered terrible form for a text editor might be
excellent for games, you really have to consider the application you're
writing...
Comments are certainly necessary, but I think not what you're saying for
here. I have come across several areas that I've needed documentation:
1. When a library I'm not familiar with is used (it is inappropriate for
comments here);
2. When structures I'm not familiar with are used (the comments should be where
the struct or class or union or what-have-you is prototyped);
3. When another function within the same program is called (and here, the
comments should be at the definition of the function); 4. When a large
(generally more than 10 lines) code block is used -- at this point, a comment
detailing the relevance of any out-of-the-ordinary for() loops, the purpose of
the code, etc. us relevant.
I really can't think of anywhere else that comments are necessary... do you have
some ideas?
First, to qualify my remarks, I must state that I have never looked at the
Sambe source code.
However, I have used the Samba server quite extensively over the past couple of
years, with no problems relating to the software.
I agree that the Samba project needs shared libs; it would make the addition of
"Network Neighborhood" functionality trivial for GNOME and KDE filemanagers--and
I think SMB Browse List functionality would greatly help Linux become a
popularized desktop OS.
But let's not forget how they are trying to keep up with MS's protocol, which
has had its own quirks and nuances from one version of NT to the next. I imagine
that has quite a lot to do with the (reportedly) unstructured nature of the
code.
I just thought that last Samba remark was a little harsh, considering the luck
I've had with the software...
If you look at event-based programs with explicit continuations you will have
a hard time to maintain your dichotomy. Look for example at the source of the
web cache Squid.
I'm still waiting for programming language concepts (other than threads) that
can represent event-based programs in a more readable way...
Carlos
I'm taking a wild stab here (because I admittedly haven't looked at the code
directly), but the "ACE" (Adaptive Communication Environment), written by Doug
Schmidt & his collegues at Washington U is a full fledged communications
framework - open source, and free.
I say it probably would be good C++ reading because the whole project was based
on using "design patterns" frequently found in communications software. It takes
the best of everything, and makes it whole. There are a lot of patterns that
they invented from their own communications experiences.
Literate Programming is one of Knuth's most interesting ideas. The deep insight is that you might want to present a program's structure in a non-linear way -- perhaps showing the very highest level, then going over the lowest-level primitives, then explaining the middle level of operations which requires that you know about the top and bottom. You use whatever order is clearest for explaining the structure.
But... I've never come across a really good implementation of the concept. I've tried to write literate C programs using tools such as CWEB and FunnelWeb, and found myself trying to maintain two parallel sequences. One is the order of explanation -- the prose side of things. The other is the ordering of C programs; you must have #include stdio.h before doing printf() calls, struct A must be defined before any functions which use it, and so forth. This effort was painful, and it led to useless sections of text like:
Section 4.5: Include the C headers.
#include "header1.h"
#include "header2.h"
#include "header3.h"
...
There's little of interest that you can say about the above section of the code, but you have to have it.
Perhaps you'd need a smarter tool which knew more about C semantics, and automatically included unistd.h when it saw you using open(), but that means you lose language independence--you can't write literate Smalltalk or Lisp or Python or Octave--and it starts to seem like an IDE where you have no clue what's happening to your source.
I strongly agree with the people recommending The Elements of Programming Style; the languages used may be mostly obsolete, but the principles aren't. My favorite quotation from it:
Some compilers allow a check during execution that subscripts do not exceed array dimensions. This is a help, but not sufficient. First, many programmers do not use such compilers because "They're not efficient." (Presumably, this means that it is vital to get the wrong answers quickly.)
I recommend "Patterns of Software" by Richard Gabriel, one of the founding
fathers of the Patterns movement. His opinion? Patterns don't gain you
anything, unless you're one of the snake-oil salesmen who's profitting from
selling the idea. Gabriel has turned his back on the whole idea and has come
down to earth.
As for the larger question in this thread, for me I think my strength as a
programmer boils down to mechanical aptitude. I see programs as big Rube
Goldberg contraptions and there's no silver bullet to deal with them, you just
have to role up your sleeves and wrestle the complexity and get the job done.
Simplify as much as possible with elegant algorithms and clever mnemonics, but
don't waste your time on OO ideology.
Kludgy code can make good products, just because the code has lots of voodoo doesn't mean that the finished product is bad, if you ever try compiling Mozilla there are bazillions of warnings, and some of the code is a mess (it actually scares me :)), but the product is quite nice and reasonably stable.
Patterns of Software/Richard Gabriel
by Hugh Johnson ([email protected])
on Saturday July 18, @09:31PM
(User Info)http://www.semplicesoft.com
This is my book recommendation. Misleading title; it's actually a revolt
against the "patterns" movement. No code to speak of. It's intended to be
understandable to the layman, but I doubt if just anyone could read it.
Ultimately, the book simply makes the point that there are no shortcuts to
creating beauty, no magic formula, no silver bullet.
You wanna write good code? Just DO IT!
I absolutely agree that the Samba source code is hard to follow. I'm probably fairly well qualified to comment on it as I'm the original author of Samba.
I thought I'd post a bit of an explanation as I'm actually quite interested in good coding practices an some of the "why" behind the bad style may interest other people.
First off, you should take a quick look at the history file that comes with the source code. There you'll notice a few things:
1) Samba was my first unix application
2) it was my first networking application (I learnt socket programming by writing
Samba)
3) I was a physicist by training, only switching to computer science later
4) I didn't even know the name of the protocol I was implementing till 2 years
after I released the first version.
The last point is probably the most important. Samba was written by staring at packet dumps in Emacs and guessing what all the bytes might mean. If you have never tried this then you may not realise how hard it is to have a really good coding structure when you have no idea what a bit of code you are writing is really for!
Now, of course, we have specs on most of the protocol and a better design would be much easier. I have in fact rewritten large parts of Samba over the years with the aim of making it more understandable (and smaller). I've only been partly successful.
In particular I (and others in the team) have written a SMB library which is aimed at producing SMB-enabled code without having to reinvent everything all the time. This code is used in things like pam_smb and pam_ntdom. It still isn't a really clean library like you find in the graphics world, but at least it is a start.
I'm actually been wanting to produce a SMB enabled GNU tar, and writing the SMB library was a step in that direction.
One thing that many people have asked me is why I don't use sructures to hold the standard SMB headers and other protocol structures. Doing so would make the code _much_ easier to understand as it would remove all those large slabs of code that effective piece together the structures. The reason is that although these structures appear to be uniform if you read a spec, it is quite deceptive. There are places where bugs in MS code have left us with extra pad bytes in the middle of structures or where some structures have the wrong byte or word order. This makes writing a general SMB parser quite difficult. The solution we use in Samba is all those ugly SVAL() macros.
So what lessons can we learn from this? The most obvious one is that writing well structured code without a spec is quite difficult. That doesn't mean it shouldn't be done, it just means that you end up with something that isn't a joy to behold.
Finally, I would really welcome it if someone wanted to write a new open source SMB server from scratch, learning from the mistakes in Samba. It is really a pity that the success of Samba has prevented this from happening up till now. Samba is quite unusual in the open source world because it is a "one of a kind". It doesn't have any competition. That is bad. Imagine if emacs was the only choice for editing, or GTK was the only graphics library, or even if Linux was the only open source kernel. They would be much worse than they are now because there would be less pressure on them and really new ideas wouldn't have a chance.
So I suppose this is an invitation for someone to write a new open source SMB server. If you do, then please look at the Samba source code, but don't be tempted to copy large chunks of it or you'll end up with a Samba clone, rather than something completely new. Some competition would do us good!
- Tridge
Re: Literate Programming
by Nicholas Riley ([email protected])
on Saturday July 18, @10:26PM
(User
Info)
Let's try this again, with an actual link to the page...
Have you tried LEO?
It's not "true" literate programming at least according to the author, but it's been sufficiently functional (and prints really nicely!) that I've started to use it for some of my programming projects.
A book that I have had on my shelf since 1989 that is my "inspiration" is Programmers At Work published by Microsoft Press. It has interviews from many famous software developers like the late Gary Kildall, Bob Carr (framework), Andy Hertzfeld (MacOS) and others. Guaranteed you'll take something away from reading this book everytime you do.
Machine Beauty - David Gelernter
Patterns of Software - Richard P. Gabriel
I highly recommend the above books as sources very concerned with the aesthetics
of software. Each is a quick non-technical read, should be read more then once,
and will send you down the right path.
"Thinking Forth" by Leo Brodie
by dean ([email protected])
on Saturday July 18, @11:11PM
(User Info)
This is a good book about what I think is one of the hardest tasks in
programming: decomposition or factoring of the problem into managable pieces (ie:
interfaces, classes, modules, whatever).
Many good programmers contribute anecdotes to the book. Brodie pulls it all
together with a very readable style and with some great diagrams and cartoons.
Although the language focused on is Forth, most of the problems are not
discussed specifically in terms of Forth - enough explanation is given at the
beginning to cope with the examples.
It was published by Prentice Hall, Computer Literacy has it as out of print,
which is a shame.
Pong!
by Trepidity
([email protected]) on Saturday
July 18, @11:11PM
(User Info)
Well, Pong is a great example of programming. A great game, playable for
hours on end, and in mere bytes of code, compared to the 10MB+ crap that you
find today.
Knuth
by Christopher Craig
([email protected]) on Saturday July 18, @11:18PM
(User
Info)
If you've gotten this far then you obviously have a great deal of patience, in which case you should at least look at "The Art of Computer Programming" by Donald E. Knuth. It currently has three volumes, "Fundamental Algorithms", "semi-Numerical Algorithms", and "Sorting and Searching" and is a challenging read (Ok, I admit it I haven't finished the first one yet) But it is a very good look at intelligent programming.
Re: Great writers first need to know HOW to write.
by Benjamin Strautin ([email protected])
on Saturday July 18, @11:30PM
(User
Info)
I could not agree more..
Personally, I know all too many people who have
the syntax down pat, but have not a clue as to
how they can actually accomplish what they want
to do.
Figure out how to solve the problem first, then
write the appropriate code.
Re: The Python language source code
by Neil Schemenauer
([email protected]) on Saturday July 18,
@11:37PM
(User
Info)http://www.ucalgary.ca/~nascheme/
I totally agree. In my years of using Python, I have yet to find a bug in the
interpeter. If you look at the ChangeLog, the number of bugs fixes made to the
interpeter is amazingly small. The source code is very straight forward.
Optimization tricks are only used where absolutely necessary (and are usually
well commented). The whole thing is portable as hell (Unix, Windows, DOS, VMS,
Mac, Windows CE, Pilot :)
tim-writes-cool-code-too
Re: Programming Styles
by Anonymous Coward
([email protected]) on
Saturday July 18, @11:37PM
(User
Info)
I don't think there are enough "good examples" to actually follow. And those
few that may exist are almost certainly the result of a fluke than anything
else. [There may be exceptions to this, of course -- perhaps some of them have
even been suggested].
For this reason I think the question can't be answered as posed. Instead, I feel
it is more instructive to ask which projects are the *absolute worst*, elucidate
why [usually rather easy], and then issue a Directive From On High: "Thou shalt
never do that".
Unfortunately, the worst are likely in the commercial realm and won't see the
light of day for the obvious reasons.
Naturally, that shouldn't prevent us from speculating. For example, I feel such
a list would almost certainly not be complete without entries for Win32, MFC,
ODBC, and perhaps just about every piece of crap that has spewed out of the Anus
of Bill. [Commonly known as Microsoft.]
The purple book
by TedC ([email protected])
on Saturday July 18, @11:41PM
(User Info)
I had that book as a text for two classes, but I never really did get along with Lisp/Scheme very well. It seems the more you know about procedural programming going in, the harder it is. The book does have a lot of useful insights that I haven't seen anywhere else, tho.
Do you know of any other good books along the same line?
Appropriateness of comments
by Scott Wood
([email protected]) on Sunday July 19, @12:12AM
(User Info)http://www.pitt.edu/~sawst46
I disagree that large blocks of code necessitate comments. Comments should be used if there is anything non-obvious about the code, but length has relatively little to do with it.
Code written to be readable should not need comments, however, and code *should* be written to be readable, barring necessary performance hacks which may obfuscate the code somewhat (in which case a quick comment is fine). I find that it just clutters things up; I have to search for the actual code among the highly verbose comments.
I do agree, though, that data structures should be commented with their fields explained, and non-trivial functions labelled with usage information. But that's another matter entirely..
Footnote your Code!
by SEGV ([email protected])
on Sunday July 19, @12:41AM
(User Info)http://www.cgocable.net
Since I've started writing more code (as opposed to merely porting and bug
fixing), I've begun to footnote my code.
Example: I might add a comment saying "See More Effective C++ Item 5 for why I
didn't provide user-defined conversions operators for this class..."
I've seen too much code that did things one way instead of another, and without
such comments I find it hard to believe the author didn't just flip a coin. At
least maintainers of my code will appreciate that I knew what I was doing!
No Subject Given
by programming style ([email protected])
on Sunday July 19, @01:02AM
(User
Info)
I think a lot of people are missing the point. K&R and "writing solid code"
are good books, but they are mostly about writing functions. you won't much
about program design from them.
"design patterns" is a fantastic book about program design. people complain that
it doesn't have good examples. that's what I thought the first time I saw it.
usually I just read the examples with a programming book. but "design patterns"
is about writing apps, or even families of apps with common code. it's not about
functions.
but that doesn't answer the question - what's a well-designed app that a person
could learn from? I'd like to know.
Re: Take it easy on Samba...
by Dom Mitchell ([email protected])
on Sunday July 19, @02:14PM
(User Info)
Just because a product works well, doesn't mean to say that the code is good. Procmail is a perennial favoroutie here. I love procmail and wouldn't be without it, but the code is abysmal.
Don't forget the Makefiles
by Dom Mitchell ([email protected])
on Sunday July 19, @02:16PM
(User Info)
There's more to coding than just the language you're coding in; I found this paper to be a very good read on a useful surrounding subject: Recursive Make Considered harmful.
Re: Pong!
by Mattias Engdeg�rd
([email protected]) on Sunday July 19, @02:20PM
(User
Info)
Pong was actually not "programmed" as we know it, but in fact directly implemented in logic. There was no CPU, no memory, no EPROM, which is why you won't see pong emulated in MAME or the like.
While I agree with Trepidity's opinion in principle, I'll rather have a "10MB+ crap" (which can be ported, emulated, hacked, cracked, expanded, improved, copied, compiled, decompiled, FTP:ed etc) than a hardwired solution like Pong.
But it was the game that started it all. And if I recall correctly, a demented Brit even wrote a simulation of it (that is, it simulated the actual hardware inside it -- quite a hack!)
Re: Patterns of Software/Richard Gabriel
by Chris Parrinello ([email protected])
on Sunday July 19, @02:30PM
(User
Info)http://www.chrispy.net
Of course there is no silver bullet but that doesn't mean that Patterns
aren't helpful. They're ways of describing class hierarchy and collaboration
structures in OO. It's exactly like taking common algorithms and giving them
names but I'm sure nobody considers the Art of Computer Programming a silver
bullet.
How can comments ever be a bad thing?
It seems to me that the more context from the programmer's mind gets embedded in
the source, the better a chance you have at understanding what was going on and
why things were done in that particular fashion.
-Mars
Re: Comments
by mgix ([email protected])
on Sunday July 19, @03:21PM
(User Info)
There are many ways a comment can be a bad thing:
1. Too many of them make the code cluttered
and actually less readable
2. Comments have to be maintained and kept synchronized with the the code and
that it an extra burden. Once too often have I come across comments that were
plain old lies, become the code had evolved and nobody had bothered updating
them.
An element of a great programmer
by Allen Buck ([email protected])
on Sunday July 19, @03:28PM
(User Info)
There are a lots of parts that go together to make a great programmer. Coding style is just one of them.
My advice on style is to read and modify code. The more the merrier. There is tons of code on the net, even without commercial code. It comes from many different environments and with different criteria (speed, ease of maint, speed of delivery).
Great writers read all the time. And not just great works of literature. Develop a broad experience, then apply it.
Re: Programming Pearls
by Tal Cohen ([email protected])
on Sunday July 19, @03:35PM
(User Info)http://www.forum2.org/tal/
Jon Bently's "Programming Pearls" and "More Programming Pearls: Confessions of a Coder", published by Addison-Wesley, on 1986 and 1988. Based on a column in Communications of the ACM. Highly recommended, for programming style and many other reasons.
* For reviews of other CS books, check this out.
goto
by Scott Wood
([email protected]) on Sunday July 19, @10:36PM
(User Info)http://www.pitt.edu/~sawst46/
While it is generally something to be avoided, it is rather useful when you need to clean up at the end of a function, no matter how it exits. Without it, you end up with the cleanup code repeated every time there's an if that leads to an abnormal exit.
Re: NeWS
by toby thain ([email protected])
on Sunday July 19, @11:02PM
(User Info)http://www.telegraphics.com.au/
doesn't NeWS live on as the "X11/NeWS merge" in OpenWindows? The other day I was able to run a number of NeWS applications/demos under OpenWindows. Gosling himself was touting this evolution of NeWS in Sydney, Australia, at AUUG '89.
Re: Pattern Schmatterns
by Stu Charlton ([email protected])
on Sunday July 19, @11:25PM
(User Info)
Pattens codify experience. They're not about OO, or the latest fad. They're
tools of communication & learning.
I don't understand how some people don't want to *learn*. Pattens, OO ones too,
can teach many things about good software architecture.
Re: Great writers first need to know HOW to write.
by Stu Charlton ([email protected])
on Sunday July 19, @11:31PM
(User Info)
I definitely agree. This is why I think that college/university education
that focuses on 'foundations' will churn out the best students (if they realize
that what they're learning is foundations... I bet all too often they complain
why they're learning Pascal & not C.. like people did in my class)
There are *some* benefits to looking at code though: gaining design &
architecture ideas. Sometimes, this is the only choice you have since diagrams
aren't available. Clean code really can communicate a "vision".
Jesus.. what an argumentative jerk.
by anti () on Monday July 20,
@12:09AM
(User Info)
I don't disagree with many of the points you brought up in your rant.. but I
do think it's completely off topic. You say we shouldn't look at someone else's
code to "follow their style". Not many would disagree with this, and it's only
vaguely close to the question posed to the group. We are not proposing students
read code as their entire cirriculum. It's been proposed that if it were *added*
to the cirriculum, who would be good to study?
Writing students don't read Shakespeare, and then rewrite MacBeth. Still, there
is much to be gained from reading MacBeth from a writer's standpoint. The same
is true for programming. There is quite a bit to be gained from finding out how
*others* have solved problems , come up with implementations, etc. Of course you
still need to learn to program on your own. That's a given.
It's my impression that you look for reasons to rant.. I believe you saw the
topic of this discussion, and immediately thought "ooh! ooh! here's my chance to
bitch about things only remotely related to the current discussion!" Go to #c
and #java and kick off a few "lamahs". Impress them with your vast knowledge of
the /dev directory. I have a feeling that we just don't want to hear it.
Re: C++, Anyone?
by ewjc ([email protected])
on Monday July 20, @12:51AM
(User Info)
I don't know. I never got thru the Booch books because I have been bored to death by the writing style. The C/C++ languages are really write-only languages (still better than Perl) that lack the fundamental beauty of Algol-like styles. The Pascal-like original Sedgewick book was good; the C++ version is just a direct translaton: it's neither Pascal nor C++. Honestly, I don't even believe Sedgewick is reputed to be good at programming.
Re: Great writers first need to know HOW to write.
by ewjc ([email protected])
on Monday July 20, @12:58AM
(User Info)
There is a good book on how you develop Unix-like small utilities from
fundamental ideas and good writings:
Software Tools, by Kernigphan and Plauger.
Yes, it's an old book but it's the best "programming book" I've read. Looks like
Kernighan has a real talent in writing programming books in rich yet concise
way.
Programming Style
by Chris Hanson ([email protected])
on Monday July 20, @01:10AM
(User Info)http://www-swiss.ai.mit.edu/~cph/
As several other people have already commented, programming is more than just
style. Understanding the semantics of programming is very important, and that
isn't likely to be picked up by reading code.
However, style is also very important if you think of programming as an art
form, as I and apparently many other slashdot readers do.
Different stylistic conventions can be learned by reading the code of others.
However, don't just copy someone else's style; think about what you like and
dislike about it, and adopt the things you like into your own style. Keep in
mind that your own style should be a dynamic thing -- keep trying to improve it,
making your code more elegant and readable. Even after you think that it's as
good as it will get, you'll always learn something new over time.
Furthermore, don't let others tell you what good style is. It's currently
popular to define "standard" styles for writing programs. The people who are
doing this seem to think that programming is like writing a business letter. If
you think that programming is art, then "standard" styles are a load of crap.
Make your own style and to hell with the conformists.
Virus code.
by Jesper Juhl ([email protected])
on Monday July 20, @01:49AM
(User Info)http://serpent.dk/
If you want to look at some beautifull assembly code, then go study som virus code.
Many viruses contain extremely efficient code and I myself have learned a great deal about constructing very optimized (and thereby fast) functions, from reading some of the very small viruses (100 - 200 bytes of code).
/Jesper
PHP3
by Tobago ([email protected])
on Monday July 20, @02:05AM
(User Info)
Ok, you are all cracks.
But where I can find good programmed PHP3-Code?
I am searching for an example of a *WOW*-implementation with PHP3.
Who can help me?
Look at Doom and Wolfenstein
by Jens Ch. Restemeier () on
Monday July 20, @03:58AM
(User
Info)
Hi !
You can always look at the source of ID's Castle Wolfenstein and Doom
sourcecodes, available from their homepage. I wouldn't call them beautifull
programmed, but J.C. is definitely a great programmer.
Jens Ch. Restemeier
Good one!
by Pete Bevin ([email protected])
on Monday July 20, @07:02AM
(User Info)http://www.bestiary.com/moose/
Plus, it's much more useful to the reader if you say "Balanced tree search and insertion, see Knuth, section 6.2.3, algorithm A" than to describe in detail what's going on in the code.
Model Software
by Matthew Hoskins
([email protected]) on Monday July 20, @08:03AM
(User
Info)
Hmmm,
Less, ncftp, grep, perl, tar, cpio, bash, lynx, dd, telnet, kermit, ftp, And
many more.
Put em in a Pipe, use em' direct, they do EXACTLY as instructed. well documented
and very reliable.
-Matt
Re: Free, on-line programming texts?
by Chad Fowler ([email protected])
on Monday July 20, @08:12AM
(User Info)http://pootybbs.ml.org
Try Bruce Eckel's Pages. He has some great OO information, including the entire text of his book, Thinking in Java. I consider this to be one of the best general programming books I've ever read.
Re: Linux Kernel and Samba - applause
by Per "Hacky" Hammer
([email protected]) on Monday July 20, @08:18AM
(User
Info)
And that, in essence, is the very core of Linux' success. And hopefully
Mozilla. And others.
A finer example of "ego-less" programming can hardly be found.
I applaud you, tridge.
=Per
Programming Pearls
by Bill Rugolsky ([email protected])
on Monday July 20, @08:32AM
(User Info)
Anything written by Jon Bentley. See Programming Pearls and Confessions of a Coder. When I was just a kid in NYC, I used to go listen to Jon speak at places like the NY Academy of Sciences, and it was pure pleasure. If you use symbol tables in your code, check out his recent work with Robert Sedgewick on Ternary Search Trees
Re: Beauty
by Alastair Burt ([email protected])
on Monday July 20, @08:35AM
(User Info)
I think Gelernter's book is actually called "The Aesthetics of Computing". The basic tenet is that students learning programming should not only look at the beautiful code of the greats but also study Matisse and Degas.
Re: Kernighan & Ritchie
by Dan Kirkpatrick
([email protected]) on Monday July 20, @08:57AM
(User
Info)
I second this one. This is perhaps the single best piece of technical writing to come from a couple of programmers. It may be short, but it is also complete. The only reference to C I have ever owned, or will ever own. I have 4 copies (one at home, one at work, one in the laptop bag for consulting, and a virgin hardback 1st release first printing--a true collector's item).
Don't Read Code...
by Stephen Darlington
([email protected]) on Monday July 20,
@09:01AM
(User
Info)http://public.logica.com/~darlings/tps
I can't believe that no one else has recommended this so far: read 'Code Complete' by Steve McConnell. This is essential reading for any programmer.
It goes through many aspects of good coding and tells you why they're good. You don't get that reading through thousands of lines of other peoples code.
Re: GAlib
by Cory ([email protected])
on Monday July 20, @09:09AM
(User Info)
I've glanced at the code and documentation, and by inspection, GAlib is the
most well designed, complete, well documented OO (written in C++) library I've
ever seen. GAlib is a library for designing and implementing genetic algorithms.
The source code is free for non-commercial use, well structured, and well
commented. The documentation (in PS and PDF) is beyond complete. It's definitely
worth the time to give it a look.
GAlib: Matthew's Genetic Algorithms Library -
http://lancet.mit.edu/ga/
Re: LEO
by A.M. Kuchling
([email protected]) on Monday July 20,
@09:17AM
(User Info)http://www.triode.net.au/~skaller/interscript/iscr
LEO looks very interesting; thanks for the reference. Unfortunately it's Mac-only, so I can't actually run it, but I wonder if it would be possible to construct something similar in Emacs, using its outline handling together with the existing language modes.
I also just saw a posting about InterScript, another new literate programming tool that I'll have to look at.
Re: Apache
by Zachary Amsden ([email protected])
on Monday July 20, @09:23AM
(User
Info)
Apache is a very great work of art. It is a bit difficult to jump into at
first, but the module system and interactions are well structured. One thing I
liked in particular was the use of memory pools to help prevent memory leaks.
Can't study it...
by Chuck Shotton ([email protected])
on Monday July 20, @09:24AM
(User Info)http://www.shotton.com/chuck/
Asking people to comment on programs that they think are "great" simply based
on their outward observations is not a valid way to determine the "greatness" of
its inner workings. There is rarely a correlation between the outward appearance
of an application and the quality or elegance of its innards. Some of the most
beautiful examples of software engineering I've seen are applications that have
no user interface at all and no way to measure the "greatness" other than by the
fact that it works at all.
To study the works of a "great" work of software, you really have to study the
original requirements, design documents, implementation rationale, the
trade-offs that were made, and then you can study the actual code. But examining
a great work of software simply by observing its outward appearance or a cursory
examination of the code itself is a superficial examination at best. You'd learn
very little as far as being able to repeat the process yourself.
Re: The Python language source code, and Tim Peter
by A.M. Kuchling
([email protected]) on Monday July 20,
@09:24AM
(User Info)http://starship.skyport.net/crew/amk/quotations/py
Agreed about the Python source code. While there are design problems that bug
some people -- using refcounts for garbage collection, for example --
everything (at least in the core) is well-organized and reasonably simple to
understand.
Also, someday I'll tattoo my body with every posting that Tim Peters has ever
made.
He's very clever, with a cutting wit, and has
done a *lot* of things in his career. See the link above for a collection of
quotations from comp.lang.python and elsewhere; Tim is most strongly
represented.
Re: Elements of Programming Style
by Andy Dingley
([email protected]) on Monday July 20, @09:33AM
(User Info)
I'd _not_ recommend K&R as the greatest style guide, simply because K&P did
that "learn by example" genre so much better in the very similar "Elements of
Programming Style".
I don't have the PL/1 copy, but I do have the Fortran and Pascal flavours. It's
a fascinating read to compare and contrast all 3 versions, and see just how much
"good programming" style really is language independent, even when the raw tools
are as unpromising as Fortran (speaking of a veteran of a 100K line RATFOR
program, that leant heavily on their techniques)
I don't know Knuth's Tex work, but his earlier 3 books are written around a
virtual machine that's maybe just too low-level to make a good style guide.
To throw another recommendation in, try Bertrand Meyer's Eiffel books. I first
read this after about 3 years of OOP development, and I alternated between
kicking myself for not having read it sooner, and congratulating myself for
having worked out the same techniques (but doing it the hard way)
If you're a grunt Microserf with work to get through today, go out and buy
anything by Steve McConnell. They're hardly going to set the theoretical CompSci
world alight, but they'll save you money.
Great discussion!
by Chris Lee () on Monday
July 20, @09:35AM
(User Info)http://www.cs.cmu.edu/~chrislee
What an excellent discussion. I think it might be good to add a pointer to this somewhat related article which relates to learning from reading the code of a "Real Programmer" (who writes in straight machine code because assembly is for wusses).
Re: Comments
by Cheesus ([email protected])
on Monday July 20, @09:39AM
(User Info)
> 2. Comments have to be maintained and kept synchronized with the the code
and that it an extra burden.
Programmer laziness does not make comments a Bad Thing. Taking the time to
update a comment should not be considered extraneous or unrelated - it's part
of the job. In my experience, I've wasted more time trying to figure how
code works than it would have taken the original programmer to document it.
-Chris
Re: Kernighan & Ritchie
by Rick Mangi ([email protected])
on Monday July 20, @09:40AM
(User Info)http://www.tgix.com
As opposed to the book by Bjarne Straustrup (sp?) the author of C++ who manages to obfuscate C++ enough to scare off even the most driven sophmore CS student...
Re: Different apps, different styles
by Andy Dingley
([email protected]) on Monday July 20, @09:40AM
(User Info)
> Document all your work, using REM [...]
> whichever the language supports
I hate this approach. Most of my days are spent reworking old client-server
code, sometimes even nasty old dogs in C*B*L. Everything I work on has
bucketfuls of those old-style boxed comments on every function header. Is it
readable ? Like hell it is....
Stating the obvious is no substitute for clarity of thought in the first place.
Use consistent and meaningful names for the variables and you don't _need_ the
explanatory comment alongside. Use an algorithm, not a kludge-with-warts-on, and
you won't have to explain it to every reader.
I pride myself on the clarity and robustness of my own code (meeting deadlines
and execution speed are another matter ! 8-) )
I don't do it by sticking in spadefuls of comments though, but by striving for
underlying elegance.
Perl Source
by Rick Mangi ([email protected])
on Monday July 20, @09:45AM
(User Info)http://www.tgix.com
Not necessarily for the programming style (although it is good, I'm not a C
fan...). But as a Tolkien reader, you need to read the comments!!
Not that they have much to do with the code specifically, more with the overall
package's purpose.
Software is more than coding
by Andy Dingley
([email protected]) on Monday July 20, @09:45AM
(User Info)
There's more to it than just lines of source.
If we look at the bigger picture of design, then try Papanek's "Design for the
Real World". It's a good argument against the Office '97 bloatware approach.
Lions Commentary on Unix Version 6
by Mark Leighton Fisher ([email protected])
on Monday July 20, @10:01AM
(User
Info)
Reading "Lions' Commentary on Unix : With Source Code" (ISBN 1573980137, Peer Communications) back in 1979 or thereabouts marked a major advance in my understanding of programming. The combination of the clear programming style of Ritchie, Thompson, et. al. and Lions' commentary was unbeatable -- it really helped me understand OS kernels. As this was out of print for many years (and only directly available to those with Unix source licenses before then), we are lucky that Peer Communications has reprinted it. (Amazon will ship it in 2-3 days, which means it is a reasonably popular title.)
QuickDraw
by Nathan Tennies
([email protected]) on Monday July 20, @10:02AM
(User
Info)
As a young programmer, I had the good fortune to work on the pre-release Mac
in late 1983. Bill Atkinson's QuickDraw - the graphics engine for the Mac - was
powerful, fast, and versatile. OK, I didn't get to read the source, but I
learned a huge amount about good design by simply working with one of the
simplest, most consistent APIs I've ever run across.
I'm definitely a believer that reading other programmers' code is indeed a
critical step in becoming a professional programmer. My first summer job was
porting existing Applesoft BASIC code to the brand new IBM PC, and I learned a
lot about both good and bad programming style. Not long after, I read The
Psychology of Computer Programming, which also emphasizes the importance of
reading code.
BTW, I think it is interesting although not surprising that most programmer's
I've met who have read a lot of code are the same ones who are sticklers for
making code easy to read.
mIRC design
by Stonebreaker
([email protected]) on Monday July 20,
@10:50AM
(User Info)http://shaft.arizona.edu/~maynard/
mIRC is a great IRC client, well designed, with a wonderful interface. I would definitely put this on my study list, but since it isn't open source study would be limited to the interface only (which is admittedly great).
Re: Free, on-line programming texts?
by Peter Lisherness ([email protected])
on Monday July 20, @10:56AM
(User
Info)
developer.com has a free online reference library, which contains full texts of a number of books. you can check it out at http://www.developer.com/reference/r_library.html. There are books on C and PERL, with a couple non programming books on Linux and Unix (although those books are suprisingly rather poorly written). While the books are very simple, they are good at teaching non-technical persons (ie. parents, children, household pets) the fundamentals of programming. They certainly aren't near as good as stuff like Knuth's works, but they're free...so don't complain (athough $50 for The Art of Computer Programming is money well spent).
Comments and arbitrary metrics...
by Gaurdian ([email protected])
on Monday July 20, @11:06AM
(User Info)
I was once given a programming assignment (back in college) to write a heater
control program in assembly. We were told that the grade would depend on several
factors, such as how close it kept the temperature, how quickly it responded to
changes in temp, etc. as well as certain metrics run against the source code.
One of them was a 'percent comments' metric. Heheheh... I think I ended up with
50% comments (1st place on that metric)... Each function or procedure got a
short description of parameters and return values. Each line of code got a
comment, even if it was 'go to the next row' as well. This was an assembly
language project...
Silly? Yes, most definitely.
Would I ever do that for 'production' code?
Possibly. For perl code, I probably would, since I am one of the few people at
the company who understand perl. Most of the time, though, the 'comment every
line and procedure' is overkill.
Definitely comment on the non-obvious lines, and on choices made for
implementation.
Re: Kernighan & Ritchie
by Kip Lubliner (ude.uhj.sc@pik)
on Monday July 20, @11:48AM
(User Info)http://www.ugrad.cs.jhu.edu/~kip
yup, K&R is da bomb! This is the book that taught me about the elegance of C.
The programs in this book remind me of a quote (I can't remember who said it, or
the exact words) "You are finished when there is nothing to add, and nothing to
take away."
Re: Literate Programming
by Pradeep () on Monday July
20, @11:54AM
(User Info)
I think LEO is probably the best and
the most practical tool I have found
that actually helps you write literate
code.
Too Bad
by Waldo ([email protected])
on Monday July 20, @12:14PM
(User Info)
Too bad that Judge Gwin isn't a /. reader.
POV documentation
by chris prince
([email protected]) on Monday July 20,
@12:16PM
(User Info)http://www.povray.org
I can't say too much about the source of the program, but the documentation is certainly the finest for any program I've seen, commercial or otherwise. Anyone looking to provide documentary support for a program should look at it; it's made my experience using povray much more enjoyable.
Re: Beauty
by Richard Turner () on
Monday July 20, @12:37PM
(User
Info)
" The basic tenet is that students learning programming should not only look at the beautiful code of the greats but also study Matisse and Degas. "
Hmmm... Perhaps I should pick up a copy for my wife who is currently a contract programmer but has a degree in Fine Arts.
Re: Jesus.. what an argumentative jerk.
by Dana M. Epp ([email protected])
on Monday July 20, @12:44PM
(User Info)http://www.netmaster.ca
I don't think its off topic at all. I would have rather taken this privately,
however, you cowardly forgot to leave your email address.
I believe the question brought forth was, and I quote...
"My question, then, is this: What do Slashdot readers consider to be the great
works of programming literature? Programs that made you think, "Wow! This is
beautifully designed!", programs worthy of study."
From that, my impression was that the reader wanted to more study code to
increase their knowledge of (a) Programming dynamics or (b) how to better code
or (c) Learn new algorithms that are interesting.
I could be totally off on a tangent, however, my "rant" as you like to call it
is nothing more than a explaination that a STRONG foundation in programming will
better suit the need of, and I quote... "the works of great programmers."
Your impression is just that, yours. How you perceived my comment was
unfortunate, but your response was pretty entertaining. Perhaps next time before
you post, you would consider the fact perhaps the comment was made with a
foundation towards showing alternatives to the question, rather than a "rant".
Re: The purple book
by Bdale Garbee ([email protected])
on Monday July 20, @01:08PM
(User Info)
I ocnsider "Thinking Forth" by Leo Brodie, reprinted by and available through
the Forth Interest Group, as being in the same class as SICP. It's a bit dated
now, but there are powerful ideas lurking there. I don't often write in either
Scheme or Forth, but the ideas represented in those books and those languages
show up over and over in my own work...
The art of programming is as much the process of thinking about problems and
architecting good solutions as it is writing good code. Get the former right,
and you can cheat on the latter if you need to.
Envy 2.2 source code is IMHO crystal clear
by Vasco Costa
([email protected]) on Monday July 20,
@01:37PM
(User Info)
In my view the cleanest MUD and for that matter any source code i've ever
seen is that from the Envy 2.2 coders. This code is beatifully hand formatted,
you have to see it to believe.
It compiles on nearly anything with an ANSI-C compiler and BSD sockets. Even on
Win32!
Get the source from
and see what i mean. Of course, nothing beats K&R for coding style, though i
disagree a bit with their code formatting style. The GNU coding style is much
worser though :-)
A Bunch of Reaffirmations, and A New Open Source C
by Tom Morrisette ([email protected])
on Monday July 20, @01:39PM
(User
Info)
I strongly agree with these previously mentioned sources:
For collections of articles ranging from theory to code implementations to clever hacks, see the Graphic Gems series publshed by Academic Press.
Meyer, Reuseable Software: The Base Object Orinted Com//www.amazon.component Libraries is a collection of over 140 soon to be officially released (but downloadable now open source classes.
Re: Comments and arbitrary metrics...
by David Jacoby ([email protected])
on Monday July 20, @01:50PM
(User Info)http://harbor.ecn.purdue.edu/~jacoby/
as well as certain metrics run against the source code. One of them was a 'percent comments' metric. Heheheh... I think I ended up with 50% comments (1st place on that metric)... Each function or procedure got a short description of parameters and return values. Each line of code got a comment, even if it was 'go to the next row' as well. This was an assembly language project...
It could just be me, but I find assembly almost unworkable without copious comments. That is, if you ever want to go back and debug.
Everyone in the local shop programs perl, so I don't comment much. I should do that more, but I try to avoid weird constructions and choose the most understandable way to do it.
Happy C programmer
by Ambrose Li ([email protected])
on Monday July 20, @02:21PM
(User Info)
Well, you are a happy C (or C++, Java, LISP, Ada, etc.) programmer. That's good for you. But you have to realize that some languages puts a heavy limit on name lengths. The language I use at work (dBASE derivatives) limit me to 10 characters; assembly used 6; some early Microsoft BASIC's, 2. With such languages you really have to put a lot of comments in your code.
6th Edition Unix Source Code
by Jay Ts ([email protected])
on Monday July 20, @02:37PM
(User Info)http://www.kachina.net/~jay
I agree absolutely. The source code to the 6th edition Unix kernel, including
the device drivers
for the ttys and one hard disk, amount to just under 10,000 lines of classic
"K&R" C, plus a little MACRO-11 assembler that bind it to the hardware.
The combination of the simple and sensible PDP-11 hardware and early UNIX
implementation, plus John Lions' concise but clear commentary make the book a
highly valuable teaching and learning resource.
Lions' wrote the book as a text for the class he taught on operating system
design, so it was intended to be used for exactly that purpose.
It's possible to read quickly through the book and get a very good idea of how
the UNIX system functions as a whole, and how the parts fit together. Then, with
more study, the cleverness of the details can be discerned understood, and
appreciated.
Code Complete/McConnell
by Karsten Self ([email protected])
on Monday July 20, @03:20PM
(User Info)
A very strong second. My only complaint is that Steve wrote the book backwards -- though he has a reasonable defense. I'd recommend starting with Chapter 31, which summarizes methods and philosophy, then his sections on style, before reading the rest of the book.
Code Complete is one of the timeless books of software construction. Its examples and implementations may seem somewhat quaint in another ten or twenty years, but they will be completely valid so long as procedural software is written. Many of the methods McConnell suggests are already ten or twenty years old. They're just good, and proven.
McConnell also has an interesting website with more writings, his commercial venture, and personal information
Adevnture (was Re: Good code)
by Eric Smith ([email protected])
on Monday July 20, @03:25PM
(User Info)http://www.brouhaha.com/
No, Adventure was in fact originally written in Fortran. And not Fortran-77 or Fortran-90 either; it didn't have the type of 'IF' statement structure you show. It was also not very portable; it depended on stuffing five ASCII characters into an integer, since it ran on the 36-bit DECsystem-10.
There were many conversions of the Fortran code to run on other systems; usually they changed all the string handling, and often changed or omitted Wizard mode. There were also multiple independent conversions to C and other languages. One of my friends even translated it to RPG for an IBM System/34!
I was involved in making the "original" Crowther & Woods 350 point Adventure Fortran sources available in the Interactive Fiction Archive at ftp.gmd.de.
I'm pretty sure the original version was written in MUMPS, which was a version of LISP that the MIT AI Lab hackers cooked up. The FORTRAN code read like readable LISP code.
You may be thinking of Zork (AKA Dungeon), which was written in MDL (pronounced "Muddle") at MIT. Zork was in fact translated into Fortran for the PDP-11, which was then translated into C (as "cdungeon"). However, the commercial Zork games continued to be developed in ZIL (Zork Implementation Language), a subset of MDL.
MUMPS is something else entirely. AFAIK, no widely available adventure games were ever developed with MUMPS.
IMHO, the Adventure code in Fortran looked very little like LISP. It would be difficult to write LISP-like Fortran code, but if you did it, it wouldn't look much like the Adventure code.
Re: Linux kernel
by David Bonn ([email protected])
on Monday July 20, @05:10PM
(User Info)http://www.watchguard.com/~david
I can think of only a handful of places I like to see comments:
The risk you run with anything more detailed is two-fold. At some point the probability of the comments and code being out of sync approach unity, and at that point figuring out what is going on is harder than with no comments at all. The other (subtly related) problem is that over-detailed comments can actually delude an otherwise clueless maintainer into thinking they understand more than they do.
I know for a fact that I pay a lot more attention to what I'm dorking with if the code has no comments at all.
Re: Code Complete book club
by Richard Freytag ([email protected])
on Monday July 20, @05:36PM
(User
Info)
I'm setting up a site that will discuss Steve Maguire's book: Code Complete.
It'll allow
readers to pose and reply to each other's questions. We'll step through the book
chapter-
by-chapter. Send me your email address if you wat me to tell you when the site
is up.
Cheers,
Richard Freytag
Re: goto
by Harry Heymann
([email protected]) on Monday July 20, @05:56PM
(User Info)
startup_code()
do {
code();
if(error)
break;
more_code();
if(error)
break;
} while(false);
cleanup(code)
Re: Lions Commentary on Unix Version 6
by Gary Capell ([email protected])
on Monday July 20, @07:21PM
(User Info)http://www.cs.usyd.edu.au/~gary/
For more modern work by Thompson, Pike et al. you might want to shell out for the Plan 9 CD, with full source. Very nice design and code, and also a nice OS to live in.
Incidentally, I agree with most of the points made. For example, reading bad
code can
be helpful. As part of my job, I have to
revise some extremely ugly, nearly unmainatainable
programs. Once you go through such an ordeal,
you tend to code with future programmers (yourself included) in mind.
And of course, there is no substitute for coding,
just as there is no substitute for writing. Still, I think it helps to read as
well as write.
Again, thanks!
Re: Comments and arbitrary metrics...
by Gaurdian ([email protected])
on Tuesday July 21, @08:57AM
(User Info)
It could just be me, but I find assembly almost unworkable without copious
comments. That is, if you ever want to go back and debug.
Yeah, but I knew I'd never be touching that code again. I haven't even looked at
it in almost 6 years. I'm trying to remember what other 'metrics' they used. I
think one was code size, and another was number of 'functions' used. You've
convinced me to go back and look.
This was also the class where they claimed to have a 'theorem prover' program to
detect cheating.
-- G
Re: Free, on-line programming texts?
by Immo H�neke ([email protected])
on Tuesday July 21, @09:57AM
(User Info)http://public.logica.com/~hunekei/
I have found two on-line texts that I refer to often. They are the Perl reference (lots of mirrors, but try http://language.perl.com/info/documentation.html) and the Javascript reference at http://developer.netscape.com/docs/manuals/communicator/jsref/index.htm. I won't say they're brilliant, but they contain lots of well structured examples and they get the job done. Usually :-)
Programmers at Work book
by John Foster
([email protected]) on Tuesday July 21, @11:19AM
(User Info)
Microsoft Press published a book in the late 80's called "Programmers at Work." It was interviews with the "superstar" programmers of the time. What was different about the book was discussions on where coding took place and how problems got solved. It's worth a read if you can find it.
No Subject Given
by Prashanth Kuchibhotla ()
on Tuesday July 21, @05:12PM
(User
Info)
Read the works for good programmers... this was first suggested in Gerald Weinberg's The Psychology of Programming. A very old book, but IMO is a must read for any professional. Truly a classic.
Re: flabbergasted at notion of "no comments"
by steve harley ([email protected])
on Thursday July 23, @11:43AM
(User Info)
comments are how i program. part of it is working out ideas; class diagrams
in OO design are essentially an advanced form of comments. i find that i can
approach coding as a craft if i work at making comments as clear as possible.
part of it is purely the joy of process. my comments are a form of journal, and
looking back on old comments helps me realize what i have since learned and that
i'm on a continuous journey.
part of it is communicating to other programmers. often my comments are helping
the future programmer deal with difficult concepts (which i had to deal with
myself). there are a lot of inexperienced or poorly educated programmers who
come across real OO in database code and need some help. i have needed such
help.
in this case, the comment can also protect the code from a well-intentioned
ignoramus, who might otherwise mangle the code. if you say no well-intentioned
ignoramus should touch the code you're not living in the real world.
still another part of it is that some languages are inherently obtuse, and thus
much code simply cannot be written in a self-obvious style. SQL is a prime
example.
sure, keeping comments up-to-date requires discipline, but it's a haughty
proposition that comments are unnecessary: "if you don't understand it you are
not worthy." programmers should strive to be generalists and communicators, not
just technical experts.
James Baldwin said that Nazism thrived not because most Germans were evil but because most were spineless. One cowardly compromise after another, succumbing to the bluster of bullies, quickly created a climate in which the rare act of courage, however splendid, became futile. Cowardice proved infectious, contagious. Taking a stand against the dark storm, individuals might have redeemed themselves, but their nobility disappeared with barely a trace; the Nazi anti-culture created a kind of collective immunity to anything redemptive. Only rampant destruction and total collapse would finally cleanse that corrosive atmosphere, so that new beginnings could be made and genuine values could again take root.
Is that what is happening to us? Perhaps.
Or let's just say my fillings itch when a television network takes orders from a political party: a TV miniseries, probably as second-rate as most, canceled out of fear. Fear of what? Of nothing specific. Yet of something pervasive. That's the nature of the disease.
CBS canceled The Reagans because of an unspecific fear of a pervasive meanness, a nastiness, a mercilessness toward anything that contradicts one faction's image of itself. It is not enough anymore for the far-right Republican Party to be in power; now they demand the right to control how others see them. The CBS answer could have been: Abraham Lincoln, Teddy Roosevelt, FDR, Truman, Ike, the Kennedys, Lyndon Johnson, Richard Nixon, and even George W. Bush have been depicted, flatteringly and unflatteringly, in many TV and feature films; what makes Ronald Reagan so special? But the far right has sanctified Reagan, and will not have his sainthood questioned. Intolerance is the right's mode of operation, rage is its engine, fear is its weapon -- a weapon that only works on cowards. What fundamental insecurity, what virulent anxiety, what holy terror, makes rightists such braying bullies? Cowards don't ask such questions.
Especially cowards in high places. CBS Chairman Les Moonves made the decision to pull The Reagans. Moonves is in charge not only of the network's entertainment division, but of CBS News, CBS Sports, UPN, King World syndications (which distributes Oprah), and the 39 TV stations owned by Viacom (CBS's parent company). That seems a lot of power. Yet Moonves couldn't say No to the Republican Party. That is an enormous political and cultural fact.
Political: Off-the-record comments indicate Viacom didn't want to jeopardize relations with state and federal lawmakers, from whom Viacom constantly seeks favors; so, contrary to the notion of corporate-run politics, the Republicans now have a major corporation running scared.
Cultural: We may be entering an era in which mass culture is directly the servant of politics -- a first for the United States.
Put the two together: What happens if corporations, in order to achieve their agenda of profit and dominance, take on the cultural agenda of the far right in order to please Republicans? Until now only Rupert Murdoch's Fox empire has openly taken sides in our culture wars. If this becomes standard corporate practice ("the price of doing business," as they say) our atmosphere could resemble Germany's in the early 1930s, when, one by one, the major cultural venues gradually kowtowed to the Nazi Party, allowing no other visions to reach mass circulation. Then think of the far right's cultural agenda: a fundamentalist Christian state; the rights of women, gays, and nonwhites severely curtailed and controlled; creationism taught as fact in public schools; history, science, and art subject to ideological whims. What if that also becomes the corporate agenda? Most people in America, after all, work directly or indirectly for corporations that demand economic obedience; what happens if they begin also to demand right-wing ideological purity, in order to curry favor with the dominant party?
Nothing less is at stake when, for the first time, a political party is allowed to dictate what may be broadcast on the public airwaves.
The Reagans was first commissioned by ABC. ABC let it go because, they said, "It was very soft, not controversial in the least." CBS picked it up. Anybody who's worked in television knows that not a single script gets the green light until it's been pawed over by a coven of executives, network censors, and sponsors' reps. CBS Chairman Les Moonves is a micromanager famous for reading every script for show under his command, though he now claims to have known nothing of the production that was to have been his sweeps-month centerpiece. No one in the industry believes him. Thus The Reagans went through the usual exhaustive TV vetting process, and was deemed ready and fit for public consumption. Then The New York Times ran a piece that focused on the show's portrayal of Nancy as a control freak and Ronald as an aging president showing the first symptoms of Alzheimer's. Republican flacks on talk radio and Rupert Murdoch's Fox News banshees took to the warpath -- though not a single one of them has, as of this writing, seen the film or read a complete script. Their uproar made its way to the desk of Les Moonves. Calling the film "unbalanced" -- as opposed to all the "balanced" material on CBS -- he canceled the broadcast. Yet in his official statement of cancellation Moonves admitted that "the producers have sources to verify each scene in the script."
Pause at that. History is, in essence, an evaluation of sources. As any shelf of history books easily proves, the same sources can lead to different conclusions from different historians. There is never "the" truth; there is always "a" truth, a conclusion drawn from sources. It is precisely this eternal condition that the far right abhors. They insist that their conclusions are "the" truth, and there is room for no other. (The far left is guilty of the same syndrome, but, not being in power, they're not worth an argument. Anyway, they're so happy to argue with one another, it would be bad manners to interrupt.) Be that as it may, according to Moonves, his decision to cancel "was based solely on our reaction to seeing the final film, not the controversy that erupted around a draft of the script." But no network has ever canceled a sweeps-month centerpiece two weeks before airtime for any reason, so no one in the industry takes Moonves at his word. He chickened.
Good news: The right has proved that these so-called Chairmen of Everything soil their drawers when faced with human beings who are willing to go the distance for their beliefs. Progressives need to remember that.
Bad news: You can't improve on William Butler Yeats' "The best lack all conviction, while the worst are filled with passionate intensity." Passionate intensity is wonderful in love and art, and disastrous in politics. Politics at its best is the cool art of compromise -- "the art of the possible." The right's passionate political intensity is matched on the left by Ralph Nader and his Greens, who have endangered the welfare of millions of powerless people by an abhorrence of compromise that is a mirror image of the far right's (as Nader's petulant inflexibility mirrors that of Bush). Going the distance for your beliefs doesn't have to mean intolerance for the beliefs of others. If it does, democracy is doomed.
Those who pay for Showtime (another Viacom subsidiary) can see a version of The Reagans early in 2004. Robert Greenblatt, Showtime honcho, promises the version he broadcasts "will contain the essence of [the filmmakers'] vision." Anyone who's worked in film and TV knows those are fighting words. In movie-talk, Greenblatt is promising that he will define "the essence" and edit accordingly.
Put plainly: The Reagans has effectively been banned by the far right
-- a victory that has rightists salivating for their next fight, to see just how
much mass culture the Republican Party can directly control. That is very
different from conservative artists making conservative art, as
they have every right to do, be it pop or highbrow. We're seeing with The
Reagans the first round of the fight for and against politically
controlled culture. It's going to be quite a fight, and, if intolerance
wins, then, as Clint Eastwood gets to say in Don Siegel's Coogan's Bluff,
"You won't believe what happens next, even while it's happening."
.
From a foreword by Cynthia Martin (Associate Professor of Russian, Maryland), who surely bears no blame for the travesty of the book itself:
To understand the appropriateness of the word samizdat in the title of this paper, a brief discussion about the word's meaning and its significance in Soviet history is in order.
Russian culture has always recognized the power of the word, spoken and especially written. In contrast to a democratic tradition predicated upon the notion that protecting free speech is necessary to foster the open exchange of ideas, a monolithic world-view, be it tsarist, monarchy, or Communist totalitarianism, cannot tolerate the potential for alternative positions or systems of government gaining broad support. The written word, as the bearer of such alternative ideas, is viewed as quite powerful, and hence, it is not surprising that official control over all forms of publication has been exercised throughout Russian history, especially during the Soviet period.
State-sponsored censorship developed during the pre-1917 tsarist period, and subsequently found its full elaboration in the Soviet Union. Samizdat was a response to the attempt by the Russian government to control access to all publications and publication outlets. Samizdat referred to the practice of "self-publishing" by dissident thinkers in a variety of areas, including political thinkers, academics and scholars, scientists, and literary and artistic figures in the Soviet Union. [...]
The punishment for producing samizdat or even possessing such self-published literature could be harsh, resulting in prison sentences or worse. To prevent unauthorized publishing, state control of the printing apparatus was so meticulous, that over long holiday weekends, for example, publishing offices containing typewriters and other forms of copying technologies were literally locked and their doors were sealed. The particular keystrokes of all typewriters were registered with the authorities so that illegally typed works might be traced to those responsible.
One of the most famous cases of a dissident writer whose works, political and literary, were published via samizdat is the case of Alexander Solzhenitsyn. His personal fate is evidence of how much Soviet Russia feared the bearer of alternative ideas, and how total the attempt was to control the dissemination of texts that offered alternative views. Solzhenitsyn came to be seen as more of a threat inside Russia, where he could still spread his anti-Soviet views, than outside, and therefore he was stripped of his Soviet citizenship and expelled from Russia in February 1974.
What a noble enterprise! The goals of samizdat publishers are those which I think many open source contributors would admire: speaking truth, sharing information and ideas, and doing it using their own tools even when it inconveniences or annoys the regime.
Brown slanders the open source and Unix community in the body of the book. But at least in the choice of his title, he is far too kind. The comparison to samizdat publishers is inspiring and flattering, but eventually an exageration: few of us run the risk of the gulag to publish our code, and though the cause of free software is worthy it is not so grand as the liberation of a country from totalitarianism. I do my bit, but I am no Solzhenitsyn.
The rest of the book is truly awful. Were it a university paper, every page would have red ink... at least until halfway through, when I think any marker would give up and just write FAIL.
If there is one worthwhile thing that AdTI ever said, it is this: even our enemies see Linux as being like dissidents under communism.
Recently, our readers may have likely heard about a nebulous study from the Alexis de Tocqueville Institute on open source-- and as has been more mentioned particularly, although I'd like to stress that it's important not to miss the point by focusing on a single point, the allegation that Linux is legally a derivative of Minix. We were able to obtain a review copy of the forthcoming paper and I will be able to report on the merits of the points brought up by it. I also understand that my editor will be posting an opinion article on it soon.
By the way, there have been allegations of sneaky fingers-in-pies style manipulation between AdTI and Microsoft in regards to this paper. After reading it myself I found that this is not very likely. The most possible linkage that I could ever estimate is that somehow it was Microsoft funding or Microsoft's prominence in the market that lead to the inspiration for this paper. But that is of course contrived. In any case I would tend to take Brown's statement in other press recently that what he wrote were his own thoughts basically at face value.
However, I'd like to note that the behaviour of the Institute in regards to pre-release press is somewhat shameful, inasmuch as the scandalising headlines: "Torvalds claim to 'invent' Linux probably false, says new study." On the contrary, though this is a claim of the paper, it is not a central thesis and I can only imagine that it was spun up this way to attract media attention (which it certainly has).
This is part one in a series of articles to appear on Cynicism Personified on the Samizdat study.
The Samizdat paper opens with some interesting parables and a foreword about the era of Samizdat, the paper's namesake period in Russian history in the Soviet era when freedom fighters would copy and distribute dissident materials against the will of the state censorship apparatus. It's an interesting analogy that gains relevance. In the first place the paper opens up discussing the idea of three spheres of source code control: Proprietary, True Open Source, and Hybrid. Brown classes academic style licenses like the Apache and BSD licenses as truly open, while suggesting that GPL style licenses which have the very interesting Pandora's box property of allowing derivatives but placing restrictions (compare to the truly open that flatly allow derivatives, and to the proprietary which flatly deny the right to create them) are "Hybrid" licenses.
Continue reading "Samizdat study questions open source"
This seems a reasonable term. It goes on to define it economically. This is the very thesis of the paper, the economic impact of open source. Brown states, "Mandated openness ends an individual�s ability to leverage its scarcity. Simply put, mandated openness, eliminates value because in essence everybody can have it." This is the fundamental basis of the paper and to understand it you must understand this.
Brown's specific idea and problem with Hybrid License is that it does mandate openness, wanted or not, and causes any contributed code to be 'valueless.' This is the foundation for which the work is based on and I am sorry to report that the foundation is rotten. It's a good point that Hybrid prevents commercial exploitation of software that is Hybrid licensed, after all this is precisely the point and idea.
Suppose you write a program and want to make it open for anyone to enjoy. If you use a traditional open license, you may worry that a company will appear, take your hard work that you intended to be useful for everyone, and then sell it and make money off of it. However if you place your code under the GPL you prevent this, legally enforcing your standard academic atmosphere of any new discoveries and developments on the program being contributed back to the public. This seems reasonable.
The thesis of this paper however is that the problem is that this prevents the great economic benefit of commercial exploitation of the source code and software under Hybrid licensing, and effectively destroys value that was there before. The problem is in the assumptions. In the first place, Hybrid based commercial software has been a proven business, as Brown notes in a different context for such companies as Redhat. Therefore there isn't a real world basis for the idea that Hybrid licensed code cannot be used for commercial exploitation.
More fundamentally, much stock is placed in the idea of fundamental value of the source. If anyone can have it, then it is worthless because it is not scarce. But this is flawed thinking based on material economics where scarcity can never be escaped. On the contrary, there can still be much value. Suppose I build an open source car, called the Pinto. It's magickal, so I can make it replicate itself infinitely. It is not scarce. And I license it legally so that no one can ever remove the magick from it, allowing them to modify it and then sell it copy by copy.
In this world no one could profit from selling Pintos. But many people could benefit from using it. Because it is not scarce so to speak, there is not value in selling Linux, as is. But even so, even if it were only distributed completely freely, it would still create value in the economy. Just ask anyone that is using Linux as an operating system and saving money by lessening security and other problems as well as initial purchase cost, and increasing configurability, among other alleged benefits of Linux. Brown completely forgets that source code is not just property, chunks of things that have some sort of inherent value.
If there is a value it is because there is a utility, and the highest value of software is found not in the money that is transferred away and lost by consumers, personal and corporate, that drains the public treasuries and the company accounts destined for the ledgers of the hard-working software houses. Cars are not valuable because Detroit makes money off of them. Cars are valuable because they take us places. Our economy is helped by the impetus that the automobile industry gives us, but to put it above the very source and reason for value in a product is folly and sadly the Samizdat commits this folly. You don't buy junk. If software has value it is not because someone can charge you for it. It is because people find it very useful and need it. The problem is that once your basic thesis is flawed, not many good points can be salvaged from the rest. That said, the paper contains many interesting and provocative thoughts and pieces of research which we'll examine in our next article.
In the meantime, read the upcoming opinion piece by our editor, which being such I expect to be fairly opinionated.
, 2004 09:14 AM
Cynicism
Personified Samizdat study questions open source
As you've probably already read, the CP consortium has recently gotten a hold of the draft of the Alex de Tocqueville Institute's new Samizdat paper. Although it purports to focus on the economic implications of open source and so-called "hybrid source," a large part of the paper focuses on the creation of Linux, and whether it was done legitimately.
The paper suggests that writing Linux in such a short time was a fantastic feat, since only magickal code wizards can write OSes in such a short time - after all, look how long it takes Microsoft to release new version of Windows!. The catch: Linux isn't an OS. That's right, as you probably knew already, Linus didn't write a full-blown OS in 6 months. He wrote a kernel, in fact a hardly working one as of its first release, which was later combined with the GNU tools that already existed. It took years to get it up to par with Minix and Unix. So it wasn't really THAT amazing that Linus made the kernel at the speed he did. By contrast, Microsoft churns out new tools, interfaces, filesystems, web browsers, media players, drivers, and other bloated features with every release of Windows these days.
As one of its main arguments, the paper brings up the fact that Linux was written out of modified Minix code - something which has been said by Eric S. Raymond, among others, as how it was made. However, it is accepted that there is no Minix code left in Linux. Since it was based on Minix, it's a derivative work, says the paper. Well, obviously the author of the paper isn't really aware of the meaning of the term 'derivative work.'
A derivative work is "A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship...." according to 17 USC 101.
Is Linux a REVISION of Minix? No, clearly they are different products.
Consider the following.
I want to build my own car. Luckily I already have a Ford Taurus, although it is a Ford that I've leased, and as such I can't use Ford's special parts to make my own car (a derivative work, so to speak) due to the leasing agreement, which seeks to protect Ford's unique way of making car parts. So I start by replacing the engine. Then I replace the frame. Gradually I remove all the Ford parts from my car, replacing them, until all the Ford parts are gone. In fact, I even take the "special" Ford parts and reassemble them so that I now have two cars, and I return the original car so I can end my lease. The Ford reps never know that I used the car part "code" if you will to make another car.
Is my new car a Ford too?
Does Ford own my car? Can they sue me for making a derivative work of their car, thus violating my leasing agreement? What if I used the Ford parts as a framework for a giant bowl of cheese ravioli, replacing the engine with a block of mozzarella cheese, the frame with pasta, and the leather of the inside with tomato sauce, until there are no more Ford parts? Does Ford own the rights to my ravioli? When I go to enter my bowl of ravioli into the Guiness Book of World Records, whose record is it - mine or Ford's? If I decide to mass produce Giant Cheese Ravioli Bowls and sell them, does Ford get a cut of my profits?
Did I create my bowl of cheese ravioli, or is it just a derivative work of the Ford Taurus?
Did Linus Torvalds create Linux, or is it just a derivative work of Minix?
Recently, our readers may have likely heard about a nebulous study from the Alexis de Tocqueville Institute on open source-- and as has been more mentioned particularly, although I'd like to stress that it's important not to miss the point by focusing on a single point, the allegation that Linux is legally a derivative of Minix. We were able to obtain a review copy of the forthcoming paper and I will be able to report on the merits of the points brought up by it. I also understand that my editor will be posting an opinion article on it soon.
By the way, there have been allegations of sneaky fingers-in-pies style manipulation between AdTI and Microsoft in regards to this paper. After reading it myself I found that this is not very likely. The most possible linkage that I could ever estimate is that somehow it was Microsoft funding or Microsoft's prominence in the market that lead to the inspiration for this paper. But that is of course contrived. In any case I would tend to take Brown's statement in other press recently that what he wrote were his own thoughts basically at face value.
However, I'd like to note that the behaviour of the Institute in regards to pre-release press is somewhat shameful, inasmuch as the scandalising headlines: "Torvalds claim to 'invent' Linux probably false, says new study." On the contrary, though this is a claim of the paper, it is not a central thesis and I can only imagine that it was spun up this way to attract media attention (which it certainly has).
This is part one in a series of articles to appear on Cynicism Personified on the Samizdat study.
The Samizdat paper opens with some interesting parables and a foreword about the era of Samizdat, the paper's namesake period in Russian history in the Soviet era when freedom fighters would copy and distribute dissident materials against the will of the state censorship apparatus. It's an interesting analogy that gains relevance. In the first place the paper opens up discussing the idea of three spheres of source code control: Proprietary, True Open Source, and Hybrid. Brown classes academic style licenses like the Apache and BSD licenses as truly open, while suggesting that GPL style licenses which have the very interesting Pandora's box property of allowing derivatives but placing restrictions (compare to the truly open that flatly allow derivatives, and to the proprietary which flatly deny the right to create them) are "Hybrid" licenses.
This seems a reasonable term. It goes on to define it economically. This is the very thesis of the paper, the economic impact of open source. Brown states, "Mandated openness ends an individual�s ability to leverage its scarcity. Simply put, mandated openness, eliminates value because in essence everybody can have it." This is the fundamental basis of the paper and to understand it you must understand this.
Brown's specific idea and problem with Hybrid License is that it does mandate openness, wanted or not, and causes any contributed code to be 'valueless.' This is the foundation for which the work is based on and I am sorry to report that the foundation is rotten. It's a good point that Hybrid prevents commercial exploitation of software that is Hybrid licensed, after all this is precisely the point and idea.
Suppose you write a program and want to make it open for anyone to enjoy. If you use a traditional open license, you may worry that a company will appear, take your hard work that you intended to be useful for everyone, and then sell it and make money off of it. However if you place your code under the GPL you prevent this, legally enforcing your standard academic atmosphere of any new discoveries and developments on the program being contributed back to the public. This seems reasonable.
The thesis of this paper however is that the problem is that this prevents the great economic benefit of commercial exploitation of the source code and software under Hybrid licensing, and effectively destroys value that was there before. The problem is in the assumptions. In the first place, Hybrid based commercial software has been a proven business, as Brown notes in a different context for such companies as Redhat. Therefore there isn't a real world basis for the idea that Hybrid licensed code cannot be used for commercial exploitation.
More fundamentally, much stock is placed in the idea of fundamental value of the source. If anyone can have it, then it is worthless because it is not scarce. But this is flawed thinking based on material economics where scarcity can never be escaped. On the contrary, there can still be much value. Suppose I build an open source car, called the Pinto. It's magickal, so I can make it replicate itself infinitely. It is not scarce. And I license it legally so that no one can ever remove the magick from it, allowing them to modify it and then sell it copy by copy.
In this world no one could profit from selling Pintos. But many people could benefit from using it. Because it is not scarce so to speak, there is not value in selling Linux, as is. But even so, even if it were only distributed completely freely, it would still create value in the economy. Just ask anyone that is using Linux as an operating system and saving money by lessening security and other problems as well as initial purchase cost, and increasing configurability, among other alleged benefits of Linux. Brown completely forgets that source code is not just property, chunks of things that have some sort of inherent value.
If there is a value it is because there is a utility, and the highest value of software is found not in the money that is transferred away and lost by consumers, personal and corporate, that drains the public treasuries and the company accounts destined for the ledgers of the hard-working software houses. Cars are not valuable because Detroit makes money off of them. Cars are valuable because they take us places. Our economy is helped by the impetus that the automobile industry gives us, but to put it above the very source and reason for value in a product is folly and sadly the Samizdat commits this folly. You don't buy junk. If software has value it is not because someone can charge you for it. It is because people find it very useful and need it. The problem is that once your basic thesis is flawed, not many good points can be salvaged from the rest. That said, the paper contains many interesting and provocative thoughts and pieces of research which we'll examine in our next article.
In the meantime, read the upcoming opinion piece by our editor, which being such I expect to be fairly opinionated.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
Google matched content |
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater�s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright � 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: August 30, 2019
