Slashdot Mirror

If the project is small enough that one person can do it, and also could have written the code you submitted for themselves had they thought of that and liked the idea, they would. OTOH, larger projects which need a team of people thrive on contributions. I think we're simply going to see some both, and probably a lot more of the smaller personal projects that indeed do scratch an itch. I know I'm doing a few of the latter myself, although a coming one is destined to be much larger than I can alone ultimately handle, so I will have to decide how to deal with that when the time comes.

As for good clean code, opinions do differ. I've debated with a programmer who persistently releases code without comments that I find hard to read, and he was of the strong belief that his style was the very best. To him, comments just got in the way of seeing what the real code really does. While I still personally insist on good comments that explain and add to the code (as opposed to redundant comments, which are evil), his arguments have made me at least be careful about overcommenting. The point is, what constitutes good code, and good programming, and good design, is in fact something so many of us all have different opinions about. These differences are one of the factors that causes more than one project with the same apparent end goal (not to be confused with different virtual requirements, e.g. KDE vs Gnome).

If you want to tell me your opinion of my coding/programming style, one sample is here. If you disagree with my style, then I'm almost sure to disagree with yours. But isn't that the way it's supposed to be :-)

I sure hope tux2 is capable of at least 2^31 or 2^32 * blocksize. I don't see why it wouldn't be. OTOH, if it's cleanly enough written, you should be able to redefine a few macros and have a version capable of 2^63 or 2^64 * blocksize, and with larger blocks, too.

Other limitations on size, such as limiting a single file to 2GB tend to be more a problem with API's trying to conform to standards (you have to be able to address a location in a file via the API to the byte level, including negative values for relative seeking), and using the variable type called off_t, which probably could not have been equated to the type long long (though the new C99 now makes that a standard one).

From what I recall, ext, which came before ext2, meant "extended", and probably refers to going upwards from the rather limited minix. The filesystem in use by BSD may have at that time still been a licensing issue.

If by your remark you intended to imply and mean that programming in C (as opposed to C++) is insane, then fine, I am Happily insane.

I learned C programming not from the books (though I had both K&R and H&S handy as references to look up stuff) but from actually diving in and doing it. Having started in 1982, I've had quite a bit of time to progress to the point I am today with C programming skills. I also had the foundation of several years of assembly programming before then.

I did not learn C from the books. I didn't read them. They didn't make sense the way they were written. Obviously they were not written for me, a very experienced programmer from the mainframe legacy with already several languages of experience. Those books appeared to be written for someone somewhere between "newbie" and "academic". They were not written for a working programmer.

I have yet to find any programming book for any programming language which is written for an audience with specific experiences to draw on, and specific questions that need to be answered about the new language. I was lucky with C because it became quite clear with a few experiments with pointers, and dumping the generated assembly code, and testing out some kernel calls (in TOPS-20 at the time), that C was just "portable assembly code". Neither K&R nor H&S explained things that way. Nor has any other book explained the basis and concepts of their language in terms all experienced programmers could catch on to quicky.

Learning a new language by the book is for newbies only!

Now how does this affect C++? Unlike my relation between assembly and C, C++ has no already existant basis to learn it from. While I do object oriented design and then code it in assembly (did that even before I learned C) and in C, I do not comprehend that way C++ has approached the OO principles in its language design. I have tried languages like CLU (from back in the early 1980's) and Java, but they were too slow to commit to and I soon abandoned them because by projects were real, not abstract. None of the C++ books I have looked at are oriented to explaining C++'s particular OO language philosophy. Even Stroustrup's own book didn't cover it the way I needed it.

While these books probably would work fine for a "newbie" who can spend the next couple years trying, failing, and learning from failure, they do no good for me. I cannot just stop all programming and spend the time as a "newbie" to learn something new. Every time I might even think of something I could do in C++ (or some other language I might learn) it is so temping to go do it in C because I can whip it right out faster than in the new language, debug it quickly, and have it totally kick ass on the computer.

While I do know of some specific shortcomings of C++ and could use those to say that C++ is not the best choice of language, I also know that shortcomings exist in C as well. But I have worked around them. Specific shortcomings aren't the point, anyway. If you want to know why it is so many people have not transitioned from C to C++, might I suggest surveying C++ programmers and ask them how many years experience they have had programming in C, and compare that with the results of a similar survey of C programmers. You can start with my 18 years experience programming in C.

If you still want to convert C programmers to use C++ then I suggest writing a book ... a short one, that explains every concept in C++ ... not just language syntax, but practical concepts ... clearly and concisely. Don't drag it out for newbies; focus on experienced C programmers. Explain how it is that C++ takes basic OO design concepts and puts them into a programming language. Explain how C++ behaves with each concept at higher abstract as well as lower real levels. Include a full reference section. And make sure there are examples of whole programs, not just snippets everywhere. Maybe then you might see more converts. But until someone does this, I doubt you will see very many.

Now if you do want to see an example of how I program in C, visit http://phil.ipal.org/freeware/avlmap/ and take a look. I suppose this merits my "insane" label.

Vast amounts of things out there that work are hacks. Sure it's a hack. Animation is a hack, too, but it's extremely popular. Sure, it's inefficient, but people often don't care about that if it gives them what they want.

As for meeting the standard, in the GIF89A standard, there is a clause that reads "A Local Color Table is always associated with the graphic that immediately follows it". The rotating pallettes which were popular back when PCs had 256 color video, violated this part of the standard because they were applying the local color table to image blocks that had been previously rendered. Were you complaining about that back then?

I use NON-compressed GIF now to avoid the licensing issues. PNG doesn't work on my browser because no one implemented a plug-in for it (Netscape 3) for Linux to support PNG in-line. Netscape 4 was way too buggy (and still is at 4.72 even though there is finally PNG support) to even use. Maybe ... maybe ... Mozilla/Netscape 6 will change that. It remains to be seen (i.e. hasn't, yet).

Sadly, PNG was a great idea gone bad because it just wasn't promoted well enough. That, and the lack of animation in the original version, effectively killed it.

The examples are here . And, yes, the file sizes, especially when not compressed due to no LZW, get huge. This is not the best way to do true-color imaging, but if it needs to be done, it can be.

No, it does not restrict you to 256 colors. That limit came about back when the best graphical displays were 256 colors and indexed, and happened to match up exactly with the number of colors GIF could encode in a single image block. So the practice came about to use exactly one image block for a whole GIF image. There is nothing preventing you from using multiple image blocks (without the animation extension which isn't part of the official GIF standard). IE 3-5, NS 3-4, Opera, and Mozilla all display things correctly (IE fails to print correctly).

There are plenty of reasons not to use GIF, but a limit of 256 colors is not one of them. Such limits exist only in those programs (the majority, unfortunately) that implemented GIF by reusing tired old code over and over from the 256 color display days (e.g. 1989).

You can see non-compressed and true-color GIFs here and get free GPL non-LZW code to produce your own here.

No, it does not restrict you to 256 colors. That limit came about back when the best graphical displays were 256 colors and indexed, and happened to match up exactly with the number of colors GIF could encode in a single image block. So the practice came about to use exactly one image block for a whole GIF image. There is nothing preventing you from using multiple image blocks (without the animation extension which isn't part of the official GIF standard). IE 3-5, NS 3-4, Opera, and Mozilla all display things correctly (IE fails to print correctly).

There are plenty of reasons not to use GIF, but a limit of 256 colors is not one of them. Such limits exist only in those programs (the majority, unfortunately) that implemented GIF by reusing tired old code over and over from the 256 color display days (e.g. 1989).

You can see non-compressed and true-color GIFs here and get free GPL non-LZW code to produce your own here.

IANAL += 1; /* :-) */

I choose to release my library code under the LGPL because it is my intent to allow others to integrate my library code (such as my recently released AVLMAP library) into applications that are distributed in binary-only form. When the application is not intended as a resource of code for developers I see no reason that the code has to be found there. I do not see the distribution of an application as a means to get the library source into the hands of developers. This is especially so when the purpose of the library isn't really related to the purpose of the application. My AVLMAP library could be used in just about any kind of application. I'd much rather have the source downloaded from my web site or one of the mirrors, or found on sites like Freshmeat where they can be exposed to the vastness of open source free software of all kinds.

The LGPL was changed from Library to Lesser because, I believe, RMS wanted to promote having more libraries released as just GPL , as opposed to making a different license available for other programs. You can read about that here . I just happen to not totally agree with RMS on this. But there is a difference and you should read both carefully and decide for yourself which you want to use.

IANAL += 1; /* :-) */

I choose to release my library code under the LGPL because it is my intent to allow others to integrate my library code (such as my recently released AVLMAP library) into applications that are distributed in binary-only form. When the application is not intended as a resource of code for developers I see no reason that the code has to be found there. I do not see the distribution of an application as a means to get the library source into the hands of developers. This is especially so when the purpose of the library isn't really related to the purpose of the application. My AVLMAP library could be used in just about any kind of application. I'd much rather have the source downloaded from my web site or one of the mirrors, or found on sites like Freshmeat where they can be exposed to the vastness of open source free software of all kinds.

The LGPL was changed from Library to Lesser because, I believe, RMS wanted to promote having more libraries released as just GPL , as opposed to making a different license available for other programs. You can read about that here . I just happen to not totally agree with RMS on this. But there is a difference and you should read both carefully and decide for yourself which you want to use.

Since the code was a TWO BYTE code, and the browser displayed it as ONE question mark, then the browser knew how to convert UTF-8 encoding into a raw numeric code. It just didn't have a glyph to render it with, so it substituted the question mark.

That may NOT be the standard, but it is also the case that many standards groups are spending (wasting?) too much time with making things like XML more complicated than they need to be, and not keeping all aspects of standards up to date (like officially supporting UTF-8 encoded UNICODE, which is trivial to implement in validators ... for those who use such things).

It is already common for standards to be extended and the extensions to be accepted. Netscape added animation to GIF, and while there were some purists crying foul, others just got on with making things better, leaving standards group to eat their dust. I extended GIF to support true-color images and browsers support that, too (Netscape, Explorer, and Opera, that I have tested). People did bitch and whine about it because it wasn't described in the standard for GIF, but it did work, it did not conflict with the literal standard, and it was the only way to get true-color into web pages until PNG came along (which admittedly was slowed due to browser makers dragging their feet).

So I suspect as soon as you have full UNICODE support in X windows and/or the font server, with proper fonts, it will work fine (despite what some useless validator says).