Pineapple - A juicy-sweet D library
Pineapple, a D implementation of the Foundation framework by Apple , or, it will be. If you were attracted by what I said about D and have started using it as a programming language you may have heard of Tango.
Tango is a cross-platform open-source software library, written in the D programming language for D programmers. It is structured as a cohesive and comprehensive library for general purpose usage, and is supported by a growing number of recognized D enthusiasts.
Tango is a replacement for Phobos, the general purpose library that comes with D. I have not used D much and have looked very little at Tango. I cannot tell you which one is better, Tango or Phobos but, I can tell you that you won’t have to worry about that sort of thing for long.
Pineapple, like I said, will be a D implementation of Apple’s Foundation framework. I could add everything to Pineapple that Foundation has, all the convenience functions of the classes, but, I will choose not to. I will be selective about what I add to Pineapple and I have a few features in mind that Foundation does not possess.
I began a couple days ago creating Pineapple and everything was going fine. Then I realized I could base my code off Tango or Phobos. This would greatly reduce the development time because most of the code, if not all, would already have been written for me. I was encouraged by this thought and downloaded the Tango source. Sadly, like most large projects, it is confusing and messy. Some of the confusion, by confusion I mean code that is hard to follow, is from the number of features and classes. For example, the FileConduit class inherits from DeviceConduit which in turn inherits from Conduit which implements the IConduit and ISelectable interfaces. Too much inheritance can be a bad thing.
I have come to the conclusion that I will use the Tango code but by the time I am done with it it will not look much like Tango.
I will try to post the interesting things I come across as I develop Pineapple. If you want the code or to file a bug report visit the Pineapple site hosted at dsource.org.
Filed under: Programming on December 26th, 2007
“Confusing and messy”? Because you can’t understand it at first glance? Hmm… I wonder how you would design something so that it wouldn’t be “confusing and messy”?
Ari,
One easy way to design something to prevent it from being “confusing and messy” is to Keep it Simple. When projects get big, the code, consequently, also gets harder to read. However, if you have been working on the project from the beginning then you probably can find your way around the code. But, it will take longer because there is more code.
I will always favor simple over versatile code.
I think you’re underestimating how much coding and designing is required to produce even the most basic functionality of something like the Foundation framework. The KISS principle is a great thing to swear by, but you seem to be expecting to be able to completely understand and start coding for something after an unrealistically short period of time.
Have you ever tried to figure out what even a fairly complicated single-file program does? Well if you haven’t, I’ll tell you that it’s not easy. In something like the thing you’re trying to write, you’ll inevitably wind up with many large source files which are interconnected in very complicated ways. Of course, this only makes things harder to understand. Each project is going to have developed its own unique architecture and idioms, and every time you come across one you’re going to have to go look in some other file to find out what it does.
I believe that the author of a library has an obligation to provide good documentation for the user of that library. However, unless a large amount of prospective developers are chomping at the bit for some sort of English-language guide to hacking the internals of the library, nobody’s going to write it. The best documentation is the source code. If you’re not willing to get your hands dirty and spend a significant amount of time figuring out the general architecture and how things work, it doesn’t seem to me that you should really be doing any hacking at all.
You might say “well commented code should be easy to understand”, but comments can only take you so far. I think it’s generally agreed that comments should be used to annotate particularly confusing bits of code, provide general notes about the code, say what functions do, etc. They should NOT be used to document each and every line - that sort of hand-holding ends when you stop reading the sample code from your programming book and start looking at some real-world programs.
Ari,
I think you underestimate me. I have done a lot of programming and have been using the Cocoa frameworks (which Foundation is one of) for several years.
I have rewritten one program from scratch as well as refactored another, both of which were capable OS X GUI programs. I am not a newbie, I know what I am doing.
Have you ever read the book ‘Code Complete’? If you haven’t, I highly recommend doing so. In there you will find the author talking about things such as ‘loose coupling.’ He says that no two classes should be too heavily interwoven and that if they are you should redesign them.
Not all projects end up with closely knit classes, I don’t allow that in my code, I take the time to redesign them so they don’t have a choke hold on the other.