I remember when I was 18, when I went to sofTV, knowing a lot about C but little about Windows and C++. The first summer was tough as the managers had scheduled everyone at 200% time (seriously). But because I was keen, I memorized MSDN and Stroustrup quickly. Then I switched to Java at OTI, which was not very successful since I spent most of my time dealing with OTI's politics rather than Eclipse/SWT. Then at BitFlash? I switched back to C, but for Palm, RIM, WinCE, and Symbian, using CodeWarrior? instead of VC++6 as well as the W3C XML standard set. And then ASP during the campaign, but I had real politics to do then, of course, so I didn't really care. Now, I am shoveling LAMP into my skull.
Through this entire exercise, the one thing I've learnt is that a platform is defined by its players, personalities, politics, and primary opportunity. You should choose your platform based on the people you want to be around and the business you want to be in, rather than a particular feature set, since every platform eventually gains the right features. Conversely, if you want to create your own platform, you need to focus mostly on collecting the right people, and aligning them around the same primary opportunity. CommunityOverContent.
That being said, what I like the most about systems programming in C is that there are very few people to negotiate with. It comes down to you and the hardware, which is a very rewarding experience. Feedback is constant, predictable, and reasonable. Every keystroke can be progress. However, I don't think I would have gotten into C programming if it hadn't been for the Fidonet C_ECHO that taught me what good development was. I also don't think I would have become a strong object-oriented programmer without WikiWikiWeb.
OpenSource development models like the CathedralAndTheBazaar? speak volumes about the personality types of those projects. The Linux kernel itself is a cathedral, with Linus Torvalds and Alan Cox presiding. However, the platform as a whole is a bazaar, with anyone contributing anything. Perl's CPAN is similar. A bazaar leads to an explosion of creativity. However, it also means it is very expensive to develop against. You need experts who can navigate the pitfalls. For instance, trying to parse CSV files using CPAN modules is so complicated there are two modules, Text::CSV and Text::CSV_XS. As it turns out Text::CSV_XS is the one that works, and it doesn't parse high 8-bit characters correctly without setting a flag. This kind of complexity is absurd given how simple CSV files are to create and parse.
Because CPAN modules and Linux applications are owned by their respective creators, there is no stable negotiation process that allows others to make necessary modifications. Instead, the best you can do is create a new project to compete with ones you disagree with. Hence the need for FreshMeat? to keep track of what's going on in this world. Compared to paying Microsoft for developer tools that are stable and well-documented, and subscribing to MSDN's many articles describing how to use it, plus 10 times as many developers on the Internet discussing how to work against the same platform, I truly wonder what is more expensive. I guess FreeMarket? true believers would conclude developing for Microsoft is cheaper.
An ideal OpenSource project would, I believe, allow anyone to do anything, but have a coherent negotiation process to stabilize changes into a common core. For instance, because language libraries need to be StableBases, a rigorous standardization process exists to migrate new ideas from the experimental periphery to the mainstream core (e.g. C++'s Standard Template Library). I gather that the Gnome and KDE projects were meant to do this for Linux, but I guess the truth is that the people who are attracted to Linux are more libertarian (to each his or her own) than liberalist (stable processes to achieve a common, SuperordinateGoal), so this process has been like herding cats. -- SunirShah
I believe the two are not in conflict; as long as you have a few "centralizing" groups providing "a rigorous standardization process exists to migrate new ideas from the experimental periphery to the mainstream core", everyone can do what they want, and the community can still end up with navigable libraries.
What I think we lack today is sufficient organizational structures for scalable centralizing groups (and maybe, admittedly. sufficient manpower for those groups). I think that the centralizing process itself needs to be more decentralized (bazaar-like) in order to make it scalable.
For example, you just gave us valuable information on the choice between Text::CSV and Text::CSV_XS. However, as far as I know, there is no formal way for your observation to begin percolating up the chain of command with the goal of eventually marking one of these libraries as "the standard one" (well, Perl seems to lack even a formal method of choosing a standard subset of libraries; but in other languages that do, such as Python, it seems to me that which libraries get in depends on a certain group of core developers. That's fine, but if those folks don't have time to focus on a particular type of functionality yet, there is no way for others to aid in winnowing the field of choices in the meantime).
But I've heard that the Java world is farther along at attacking this problem than others, that the Java Community Process leads to the creation and standardization of all sorts of APIs and presumably libraries. Yet you feel that there is too much politics in Java. Care to comment?
-- BayleShanks
I'm not sure if Java itself has a lot of politics from the point of view of Cuppa Joe Hacker. Certainly it does, but it's obviously a working system, or else Java would have never have grown to be a serious competitor to Microsoft. OTI, where I worked, had a lot of internal issues related to the late release of Eclipse and the meritocratic environment that is OTI ("Can't speak until you ship!"). I actually like the Java Community Process a lot, from what I know of it (not being a Java developer yet).
What I really want is to take the wiki model of content creation and apply it to software development. One of my end goals for InfiniteMonkey/Typewriter is to build a WikiAsSourceControlRepository, even if that means simply wikifying an existing source-control repository like svn. Now, I'm sure to get the same arguments again... no, that won't work. People will add bad code and make everything crash. People will add viruses. Someone needs to be in control. But I think those arguments have proven to be bogus. All you need is a process to integrate ideas (and associated code) in a coherent way. As long as FactBasedArgument? prevails, then it's easy to resolve competing ideas, even if it is merely by employing EnlargeSpace.
The intermediate design of InfiniteTypewriter has Meatball hosting a central NetworkRepository against which people can build client applications on their own servers. However, my goal is that good ideas can migrate into the core as long as those who rely on the central repository (after all, it must be a StableBase for everyone) agree to incorporate it. Building central repository becomes the CommonContext and SuperordinateGoal--the BarnRaising--to draw in many hands.
The reason I want to do this in code, beyond the need for a truly PublicScript, is that writing the script is a GodKing power, and my sole reason to be the GodKing of Meatball is to increasingly DevolvePower away from myself--in a coherent way, of course. I strongly believe in that. -- SunirShah