Slashdot Mirror
Open Source Project Management Lessons
cpfeifer writes "Paul Baranowski takes a moment to reflect on Open Source Project Management in his blog. His reflections are based on the first two years of the Peek-a-booty project." Interesting comments on media coverage, choice of programming language, when to release a project, and more.
Story was just released to subscribers and already it's loading slow so here's the article text for when the inevitable /. effect comes:
Peekabooty - Lessons Learned
By Paul Baranowski (paul@paulbaranowski.org)
July 1st 2003
Here is a review of the first two years of the Peekabooty Project. Over that time I have had to re-evaluate many of the things I learned in university and in the working world - many of the engineering lessons that I had been taught turned out not to work so well. The project management of an open source project is very different from old-school engineering project management, so I had to learn a lot about how open source project management works.
All of these problems have been seen before - by no means do I see these as unique. They are simply more data points on the "How To Do Open Source Development" graph.
What did I learn from the first version of Peekabooty?
Open-Source Project Management Lessons
Don't release before it does something useful.
This lesson is recounted in Open Sources: Voices from the Open Source Revolution as well as other places. I had even read about this rule before we released, but I had to learn it for myself. If you release too soon, you spend a lot of your time answering emails instead of developing.
The press is a tool - more like a hammer than a Swiss army knife.
The press is like a hammer - it can help you or hurt you, depending on how you use it. But like a hammer, it can't do everything, like cut a tree in half. It has limited capabilities and you cannot expect too much from it.
How the Press has Helped
The press has helped to bring awareness to key people that have the ability to help the project grow.
Press will get you more downloads. Whether this is good or bad depends on lesson #1.
Press will not get you more developers unless #1 is in place. The fastest way to get more developers is to network with other developers.
How the Press Has Hurt
The press loves infighting because it's a good story. However, the infighting story is bad for a project that is trying to get funding. This creates an air of instability. People only like to fund things they feel will have a high chance of success, and instability erodes that confidence.
95-5 Rule
Usually it's the 80-20 rule, but in open source projects it's more like the 95-5 rule. Open source projects are usually run by one or two people doing most of the work. If you decide to lead an open source project, you must be willing and ready to accept this. If you want to lead an open-source project, it helps to be independently wealthy. This allows you to forget about things like a job and work on the project you want to work on. In hindsight, wouldn't it have been better to take a really long vacation instead? Doh!
Engineering Lessons
C/C++ is no longer a viable development language
This may seem obvious to some people, and other people may recoil in shock. In college/grad school we were taught to believe that C/C++/Java, etc are the best languages in the world, so it was a very difficult transformation to accept that these languages are not viable development languages for application level work.
C++ is seen to be great for execution speed, static binding, object orientation, templates, and more. However, it is absolutely lousy for development time. Here's why:
It requires compilation - as your code grows larger, the wait time to see if your code works increases. This delay directly affects how fast your code is developed.
It's really, really, really hard for people to learn it, and this directly impacts the number of developers you will have on an open-source project.
It uses static binding (Isn't that supposed to be a good thing?)
There are no standard libraries for C++, so there's a lot of reinventing the wheel. (Yeah, there's the STL and ot
I have often regretted my speech, never my silence.
-Xenocrates
Just a suggestion.
The peek-a-booty project is a lot less interesting than I would imagine...
This is a rule in "traditional" project management too.
and the other lessons read just like Project Management 101 too. I would have loved to have seen something insightful or interesting about how open source changes the development environment or the management environment from single location to distributed, but no such luck.
Food not Bombs is a nice platitude but it breaks down when you notice that the Bombees are usually well fed
Personally, I dig Common Lisp.
I first heard about this project from a BBC Article where they describe it as a "browser free from censorship or outmoded intellectual property laws," which is something I think we can all get behind! However, they made the point that the project could have been better named.
It seems the author has picked up on that now, too. I think most telling is this passage from the author's blog (weblog):
Hopefully, he'll take these insights to heart!
Consensual sex is boring.
It requires compilation - as your code grows larger, the wait time to see if your code works increases. This delay directly affects how fast your code is developed.
It's really, really, really hard for people to learn it, and this directly impacts the number of developers you will have on an open-source project.
It uses static binding (Isn't that supposed to be a good thing?)
There are no standard libraries for C++, so there's a lot of reinventing the wheel. (Yeah, there's the STL and others, but each one has a huge learning curve associated with it).
So, basically, it has to be compiled (duh). It's hard to learn (no, it's hard to use correctly) and it has no libraries... eh?
I'm sorry, but this guy is not a software developer. The usual comments about "X is the One True Language" notwithstanding, I can't follow that because he thinks it's "too hard" and he thinks it's "not viable" and decides that it simply isn't a good fit for his project, then LanguageX must be dead. Perhaps he'd like to share with us which language his OS is written in. Maybe it's Forth or Scheme. Use the right language/runtime/lib/technology for the job and refrain from saying "X sucks because I don't like it".
Other than the dubious "this is how you do open source" slant I can't see how this article is even worthy of news.
Often time this principle applies to people on the project, not just the software being developed. I've learned from experience that really sharp people with a broken user interface can destroy a project!! You have to try to minimize interaction points with folks like that and find where they can excel and use their talents without creating problems for the others on the team. A difficult nut to crack at times and a far more critical factor to project success that the programming language, source management tools, etc...
Everyone knows that once your code compiles, it will work!
There are no standard libraries for C++, so there?s a lot of reinventing the wheel. (Yeah, there?s the STL and others, but each one has a huge learning curve associated with it).
This is a huge error that casts doubt on the author's credibility. What is commonly known as the STL is the C++ standard library, and it has been since C++ became an ISO standard in 1998. Doubters may consult books like the clearly-named "The C++ Standard Library" (Josuttis, 1999) to get themselves up-to-date.
Maybe that's just another drawback of C++... a lot of people don't know what the hell they are talking about and thus repeat misinformation?
Not mentioned is the final langauge they used. Is the code in C/C++?
I do agree with the binary protocols vs. text protocols, but I'm not sure that is a recent revelation. Most of the Internet protocols use text based protocols.
June 14, 2003
Dear diary,
I have decided to record my thoughts on managing the project "peek-a-booty". The most important lesson I've learned is not to use booty in a project name!
Sure, it was funny two years ago after a few beers, but I swear the next person that makes a "booty" joke will die. I'm serious. "Dude, is it for peeking up skirts?" "Hey, if you integrate telephony you can call it 'peek-a-booty-call'"
In other news, I'm starting a new project to manipulate network traffic, this time using Java. I'm thinking of calling it 'jAck Off'. I like the sound of that. It will be good to get that whole 'booty' thing behind me...
C and C++ are most certainly viable development languages. Let's see now: Linux, BSD, GNOME, KDE, Apache, Mozilla. Even Perl, Python and Ruby are written in C or C++. But maybe the author is saying those projects aren't viable...
Use the right language for the job. If all you're doing is interfacing to a database, then a scripting language may be the most appropriate. But if you're writing system software, then by all means stick with C and C++ with some shell glue.
Compiled languages are damned convenient to the user. "Here's an executable, just run it", versus, "here's a script, go download compile and install the interpreter first, making sure it's the correct version, set up your environment variables correctly, then run the script."
A Government Is a Body of People, Usually Notably Ungoverned
C/C++ is no longer a viable development language
... Ever heard of protocol layering or data marshalling ?
Sure, in the scope of this particular project and in the context of their skillset and development practices.
Don't Use Binary Protocols for Application Development
Bah, I'm speachless. Yeah, right. Better yet convert data to PNG images and pass those along - it will allow you to debug networking layer with a web browser
With all due respect, it looks like Mr.Baranowski either learnt wrong lessons or likes to summarize things beyond reasonable limits.
3.243F6A8885A308D313
It sounds like he busted his ass on a project no one appreciates because it is generally useless.
they would just call them facts.
"C/C++ is no longer a viable development language..."
"not viable development languages for application level work."
"...It's really, really, really hard for people to learn it."
"...There are no standard libraries for C++, so there's a lot of reinventing the wheel. (Yeah, there's the STL and others, but each one has a huge learning curve associated with it)."
So in otherwords it's shocking that the programmer has to know something about the tool, platform, domain, etc. to be able to code? G~A~S~P!!!
What's the number one complaint of almost all end users to a product? Code bloat and speed . Sorry to tell you this but if your complaining about compile times then you don't have much of an option when it comes to execution speed of the same said program being compiled.
BSD is designed. Linux is grown. C++ libs
There is, indeed, a standard library for C++, one which is widely supported - STL.
I don't think that's what he meant by a "standard library". He's thinking along the lines of Java's standard library -- a standard library that gives you graphics classes, networking classes, XML parser classes, GUI classes, etc. You know, the kind of stuff that would be convenient to have bundled with a language. STL is a standard library full of basic data types like linked lists and hash tables. Big whoop.
So, after two years he still hasn't realized the importance of documentation?
"Document it and they will come."
A good project is nothing without it...
I am not a very active coder, nor will I ever be. Coding is just something that does not come naturally to me. However, I thought that for the most part, C/C++/Java were still the big "players" in the application development world (scripting's a different story). So I would like to know what this fellow suggests for a good language to start projects in?
"Hell hath no fury like a woman scorned for SEGA. ..."
http://goatee.net/2003/07#_02we-a
Design By Committee: "...Yes, you understand me correctly, I'm more worried about the size and character of the community than the actual technical issue."
Compiled languages are damned convenient to the user. "Here's an executable, just run it", versus, "here's a script, go download compile and install the interpreter first, making sure it's the correct version, set up your environment variables correctly, then run the script."
Amen. When I'm trying to solve a problem, I like using high-level languages like Perl or Python. But when I need to write an application that I want ordinary users to be able to download and _just use_, I don't have a choice - I have to write it in C or C++.
Luckily, thanks to faster processors (shorter compile times) and tools like valgrind to detect memory errors, programming in C and C++ isn't nearly as bad as it used to be.
This really has nothing to do with MySQL. It due to the crappy database access interface in PHP and developer laziness/ignorance.
--
"What do you want me to do? Whack a guy? Off a guy? Whack off a guy? Cause I'm married."
no, I don't think bundling that is particularly convienient... indeed, I think that it's more convienient to have a choice and not have things like that tied tightly to the language.
Right now there are well established libraries in C++ for anything you get from standard libraries that are tightly integrated... just with multiple competing established libraries. A wealth of choices.
There is no standard GUI library that ships with all compilers. That will come, but not before it's time. Java gives such a library... too bad it sucks.
-pyrrho
So it's either C, or Java (lately). Anything else is considered as scripting (Perl, Shell, SQL).
As much respect as I have for the project and its developers, his broad, sweeping statement to the effect of C/C++ is no longer a viable language is really telling of his ignorance and lack of perspective. Which is too bad, since there are other points he makes that are useful lessons.
To claim the fundamental implementations of all modern OSes (Windows, almost every single UNIX, Linux, and the plethora of other OSes) to be "no longer viable" is way beyond reproach: it's just plain idiotic, and does significant damage to the credibility of his other points.
Unfortunately, my that-was-ridiculously-stupid meter flew off the scale when I read that point, so I stopped reading right there.
As an interface designer and technical writer, this has always been my personal mantra. It's finally nice to see that at least one engineer finally actually gets it!
;~)
You probably won't believe how many MMI designers and technical writers are feeling totally vindicated at this point.
Really, it's not often one sees history in the making.
Words to men, as air to birds.
Actualy, if you are about to set out on a new project, its probably best to tell yourself that you are NOT willing and ready to accept this.
6 years ago I started a project called GeoTools and it was, for the main part, excactly that - two people doing most of the work. This was fine for a few years but over time the user/developer ratio got out of hand.
Eventualy it became all but impossible for the two lead developers to support 300+ users and although other developers wanted to contribute it became dificult to 'train' new developers as the knowledge of how things worked existed mainly in the heads of only two individuals who had done 95% of the work.
Two years ago we took the descision to re-design the toolkit from the ground up with as much input from as many people as possible. Since that time we have strived to make sure that as many people as possible have an input into the design process and we keep that process as open as possible by pubishing the IRC sessions in which discussions take place.
The project now has 9 very active developers who are members of a Project Management Committe and a number of other active contributers as well. The end result is that quiries to mailing lists get responded to far more quickly.
Getting other people to work on your project is often - TO START WITH - more effort than just doing the work yourself, but the pay off is HUGE, as you then have someone else who can explain things to others.
If you ever have a contributor who gets stuck or confused and you find yourself thinking 'oh, it will be quicker/easier for me to do this part myself' STOP. Spend the time, help them work out how to do the modification even if it takes a few hours when you could have done it yourself in minutes becuase after you have invested the time in them, they will be able to add things in minutes too, and they can teach others as well.
If you work on a tight, well defined, non-evolving project then most of my ramblings are probably irelelevent if not they they may be of use. The only danger is in investing time in helping developers who then wander off - it happens, but I tend to find that the more you invest in them, the less likely they are to loose intrest.
Spell checker (c) creative spelling inc. (aka my dyslexic brain)
Okay , you
dont't
have to
like using whitespace
so
others can actually
read your code, but
I like the
way
Python lets me
do the
right
thing.
How many political dissidents are in US prisons? I mean besides the people who are there because they ingested drugs or because they don't have the huge sum of money to pay bail even 'tho it's a good chance they are innocent. I mean actual dissidents - like someone who goes online at a widely read journal and calls the president a parasite.
Russia's only non-government controlled TV network has been dissolved by order of that government. In fact, Putin would like to have the head of the network "putin" jail despite the fact another court (outtside the jurisdiction of the kremlin) found he had commited no actual crime.
The other states are no longer part of the FSU, of course, but in other now "democratic" countries (like Ukraine) criticizng the government in the press may not even get you due process - instead you may be found hanging like a side of rotting beef. Or maybe even beaten to death in the street.
It's getting bad... but it's not nearly as bad here as it could get.
You over simplified. As he said, static bindings are both a blessing and a curse.
...X, with or without Altivec), N *nix bases (Sun, HP, IBM, Linux*M, BSD*3)*(2+ GCC versions) = well over 10 popular platforms], you either have to manage binary chaos or you have to start distributing your code as source.
...) is usually harder than installing Java.
For example: Oops, sorry. Mozilla on Linux is now being compiled with gcc3.2 so you'll have to get the source and recompile to run on that older (gcc2) system... Also, your old plugins will need to be recompiled before you can use them with Mozilla on the new system - if you can find the source.
Compare and contrast:
Java - install the compatibility VM; use the same binary on all platforms
C - no VM; compile and distribute different binaries for each platform
As the number of platforms increases [3+ Windows code bases (9x, NT, newer), 3+ Mac bases (system
But wait! Distributing code as source requires the end user to install the compiler, and this (setting up environment variables, binary compatibility, support libraries,
So, we're back to square 1.
Lose a turn; don't pass "Go".
So much of what is said about C++ here on slashdot looks to me to be fear, uncertainty and doubt I find it ironic.
The complaints about C++ are the kind of complaints users make about linux when comparing it to Windows. "It's much easier to click on a big E than to learn another icon..."
And clearly he's talking about GUI libraries... instead of multiple good C++ and C based multi-platform GUI libraries, he prefers another model, more like javas, where you get one crappy library and save yourself a lot of thinking!
If anyone cares about the quality of the software (more than their experience developing), they'll learn to use a good compiled language, period. If you can cut corners on quality, if you buy the idea that CPU cycles are here to waste, then use something lesser (I do in that case). However, I think we are wasting cycles, and there are some amazing things our software is not doing that it could. Moore's Software Law is that every 18 months software gets twice as inefficient doing the same thing.
-pyrrho
None of the lessons learned and reported here are directly related to Project Management per se. They are all by and large implementation issues.
There is also nothing new here. This does not advance the state of the art. History does not advance by people relearning the same lessons again and again. Just because they have been reported here does not make this article special in any way. This article could have been written in any of the decades of 70s, 80s, 90s (substituting en vogue languages for C++/Java) and still make sense.
In order to truly advance the state of the art, we have to think in far more advanced ways about project management and software development. True Software Practice and Experience requires much more planning and critical thinking than evident here.
If Open Source is to provide a useful and stable platform on which to build, then we certainly need a better vision of how to build software. Otherwise, we will be doomed to repeat history by implementing old things in different ways and not really gaining any control over complexity.
In summary, we still have a software crisis; Open Source will not change that; and summaries of software development experience that just say "I made the same mistakes as other people did" are not very helpful.
"Document it and they will come."
A good project is nothing without it...
Good point; somebody should document this.
Java is the blue pill
Choose the red pill
His point that this is not unique to OSS Projects is a good one. While OSS development has unique constraints most are around people and personality. In an office we all have to get along or get fired, in OSS it can sometimes be worse.
...The program should be fun to work with. There should be buttons and things that blink. The interface should be the first thing you do. The interface serves as inspiration and motivation and helps you to learn how the final product should look. Yes, it's going to change a lot. Yes, it's going to have to be rewritten multiple times. Yes, it will never be good enough...But when someone downloads your program they will have something to do. No one likes to look at command lines.
For example:
The press loves infighting because it's a good story. However, the infighting story is bad for a project that is trying to get funding. This creates an air of instability. People only like to fund things they feel will have a high chance of success, and instability erodes that confidence.
It is too bad on so many mailing lists ego/attitude/personality or just plain rudeness show up. Things you would never say to a coworker, make it onto a mailing list for eternity, or at least what looks like one. I hope people take this point to heart before posting.
95-5 Rule
Usually it's the 80-20 rule, but in open source projects it's more like the 95-5 rule. Open source projects are usually run by one or two people doing most of the work. If you decide to lead an open source project, you must be willing and ready to accept this.
Looking at sourceforge I see this lesson again and again. The idea that if I create it they will come, and build. Forgotten, or unknown, is that nearly all had a real need to be built first. I needed application ZAFDE so I built it. I then released it and people thought they could build on it, and so on.
I wanted to learn C++ or JAVA or XYZ is the reason we have 2,134,931 notepad applications, not OpenOffice.
C/C++ is no longer a viable development language
I knew we would see a flamewar as soon as I read it. My thoughts:
- Both are still viable. Much like his hammer analogy, they are not good for everything.
- What makes them "bad" for development, makes them "good" after they are developed.
Does it matter to the user that it took 81 minutes to compile? Nope, they have the binaries or compile it once and run it for years.
Every language has a shortage of people who know it. Or specifically a shortage of the people who know it and are willing to work on OSS project PDQ.
Static binding is good/bad/sometimes both. Yes it is.
All the negatives he spoke of are positives after it is developed. Which we hope is long compared to the time spent developing it.
If there is one thing projects should take away, it is probably this:
Interface is Everything
I like command lines. I use them, but I understand they are power tools. Most people do not like/use them and consider them an indicator of a poor product. Even while it may not be technically true, perception is reality in this.
Well, seems to me that SMTP, NNTP, HTTP, etc are easier to develop for because they are textual.
HTTP may be just about the ideal balance: use text for things which tend to be small, but capable of sending a large payload (e.g. a PNG image which the protocol just needs to wrap, not do anything with) in binary.
The thing about protocol layering and/or marshalling is: do you have good debugging tools (at a minimum, log what is going across the wire and be able to interactively enter data and see results)? For binary protocols like TCP and IP, largely yes ("telnet" client in the case of TCP; tcpdump for both TCP and IP). And maybe some RPC packages have these kinds of thing (I haven't used them enough to know). But an app which rolls their own binary format generally doesn't.
C is a must when performance is of big importance. If the program structure and APIs within the program modules are designed properly and in a clean way, I don't think it is much more difficult to maintain and improve on the code.
A "mixed" C/C++ approach is probably worthwhile using when the program has extensive GUI requirements and performance is still top requirement. Use C++ for the GUI (qt, wxWindows or whatever gui library you like) but for the performance critical parts and the algorithms that are in the heart of the program just use plain C under simple C++ class wrappers if at all (no abstract classes, overloading, etc.). Personally, I have found this approach quite useful.
However, designing things in C++ and doing it properly is damn tough; many designs may seem easy to begin with, but then run into trouble with things like multiple inheritance from related parents, or simply that encapsulation is difficult because of the need for exposing the inner workings of classes... STL fixes some of this at the expense of code bloat -- it is easy to produce executables tens of megabytes in size.
Another problem with C++ which has been bothering me, and I would presume, the developers of Peekabooty, is the tendency towards static compilation and inclusion of everything. I looked at the source files here, and the sheer number of include-files compared to source files indicate that this probably does not compile quickly.
There is a way around this, if the application can be divided into several major and fairly independent components which then are compiled and linked as a number of dynamical libraries (.DLLs on Windows, .so on Linux and Unix). Now, with proper design, recompiling the whole lot is not necessary for smaller changes within one of the parts where no changes in this part has taken place. The trick here is encapsulation: do not let code in any one part know about any of the internal structure of code in any other part.
SIGBUS @ NO-07.308
OK, enough language advocacy ;-)
I couldn't agree more with you. Once you have experienced a dynamic language, there's no looking back. It just feels like you have finally found an environment that tries to actively support you, adapting to your style of working, rather than to impose arbitrary restrictions from the world of punch-card batch processing on you.
In static languages, you write C or C++ or Ada or Java. In a dynamic language, you write solutions for the problem at hand.
Programming can be fun again. Film at 11.
I'll go off on a different track than the other responses I've seen...
:-/
Wouldn't python suffer from roughly the same problem as Java with the JRE? I mean, unless it's compiled (and I'll admit right now, I don't follow python closely enough to know if it has a "compiler" yet), users are going to need to find and download a Python runtime environment of some sort. The latest I've found at python's web site is around 9M. While that's still about 1/3 what a JRE is, it's still either going to be a separate install, or a lot of additional weight to package up with whatever you're distributing.
It would seem that anything interpretted is going to suffer the "separate download" problem... Ease of learning would also be debatable for probably every language out there. I know folks who are wizards with C/C++/Java/perl/$language1 who could couldn't get a working "Hello, world." out of $language2, while at the same time I know others with the skills in $language2 who couldn't do anything in $language1.
It's a shame the linked article's author didn't address what WOULD be an ideal language to use, and enumerate why, but it's probably because any language he did pick would end up sharing criteria with his "these make C/C++/Java bad" statements.
"The urge to save humanity is almost always a false front for the urge to rule." --H.L. Mencken
He disparages both C++ and Java as open source development languages, and I agree with his comments on those.
I don't -- at least not his comments concerning Java.
At one time (before they were bundled) people had to download a web browser if they wanted to view a website. I don't recall any webmasters who felt that they shouldn't work in HTML because people had to go and download a browser in order to view it.
Every software project has prerequisites. Some projects require external libraries, others require external runtime environments. If you code an Open Source project is Perl, I'm not going to be able to run it on my OS/2 systems without downloading the Perl runtimes, for example. The only way to avoid this is to statically compile everything you need into a native executable which, once again, isn't going to work for people running on a different platform(s) than what you're building for. Now they have to go through the pain of installing (and possibly paying for...) a compiler, and then modifying the code to make it compile on their platform of choice.
If your application does something useful that people can't otherwise do, they'll take the one-time hit and download the Java Runtime (or any other project prerequisite).
I think this is a non-issue. As the administrator of a Java-based Open Source project that targets client-side Java (The jSyncManager Project), I can say that using Java hasn't inhibited the growth of my project significantly, as it provides value that people can't get elsewhere (namely, a single application and plug-in architecture that can run on any Java-enabled system, which allows organizations in heterogeneous environments to run the same application on all their platforms, reducing maintenence costs). As such, people who need this sort of value have no problem taking the one-time hit in installing the proper prerequisites.
Yaz.
Actually, he mentions the STL by name.
Jesus saves and takes half damage.
Java - install the compatibility VM; use the same binary on all platforms
.NET...
I'm laughing so hard Dr. Pepper is spewing out my nose! Let me wipe off my screen...
Trying to get Java applications to work on my Solaris workstation is a nightmare. I can't understand it because the company that makes Java makes Solaris. I try to figure out what the problem is, and hidden way deep in the README is this thing that says I need to install a different version than what Sun provided with Solaris. I fix that and it still doesn't work. Looking deeper into the problem, I see that I need a couple of other components that didn't come with the application. After about two hours of searching for the "myleetclasses.jar" and "ubercoolstuff.jar" files, I put them in a directory, fiddle with the CLASSPATH variable, and finally get the program up and running. And then it crashes five seconds later.
you either have to manage binary chaos or you have to start distributing your code as source.
Binary chaos is a pain. A royal pain. So I distribute my code as source instead. Easy. Painless. Users that don't want to compile can grab a prebuilt package from their distro or another repository.
Of course, I'm writing Open Source, and not cheesy shareware. Perhaps that's the true niche for Java and
A Government Is a Body of People, Usually Notably Ungoverned
-
Existing C++ code in Oracle products has already raised serious portability issues.
-
Oracle RDBMS is one of the first products to be ported to a new platform, often before the official release of the new platform. At the time of porting, a C compiler will be available, but a C++ compiler may not be.
-
C compilers for 64-bit platforms are far ahead of their C++ counterparts.
-
C++ compilers on some platforms are immature. It's far easier to write incompatible C++ code (than C).
<disclaimer> My views; not those of Oracle. </disclaimer>The Mozilla C++ Portability Guide also restricts use of some key C++ features (rtti, exceptions, templates (which rules out the STL by the way!)).
Think about it - an open-source project of any large size requires more than a handful of developers. There are only a finite number of developers on the planet, and only a subset of those are willing to work on open-source projects. Now, of those, how many do you think have a) free time to devote to an open source project (which also may mean that they aren't contributing to other projects), and b) can work in the language being used, or pick it up quickly?
I can guarantee you that subset is rather small, perhaps in some cases non-existant, because many programmers with a good skillset like that (that is, they are C++ programmers for a long while and know their shit, or can pick up C++ rapidly) want to be *paid* for their work - thus those who just want to help out are few and far between.
Now, what if the project was developed in something much easier to pick up - or was more widely known? You would instantly have more developers willing to help out, simply because of the numbers knowing the language. Plus, ordinary users could easily pick up the language and help out, possibly fixing the bugs that bother them (and bugs which bother one user may not bother developers, but they probably bother a ton of other users).
Unfortunately, C++ is not the language that most people know. Java comes close, but it still is difficult for a lot of people to grasp. What most people *can* grasp (though it may not be best for application development, however, in most projects it won't matter if done right) is a language which has a much more "english-like" syntax, and can be programmed as a "functional language" (as opposed to requiring OOP, like Java). What does that leave most users with? That's right - VB. Is it any wonder that many (understatement - an absolute TON would be better) internal (and more than a few external) applications for businesses (that is, applications developed by businesses for business - whether it is for internal use or external sale) have been written in VB? Is it any wonder that Windows holds the desktop in businesses - wonder why? VB. Whether it is a real VB solution (ie, VB executable, etc) or an "Office" integrated solution (VB for Applications) - in the end, it comes down to VB, and users being able to quickly come up to speed on it.
Personally, I think this is one of the things holding back development by businesses on Linux (esp on the desktop) - the lack of such a tool. The closest I have seen has been Python with some windowing toolkit (to interface with X) tacked on, plus a gui designer to create the fancy forms - but none of this is as integrated as VB's IDE is, and while Python is a nice looking language (I can't really tell how good it is at things - I have never used it - currently playing and learning about Perl and PHP), it isn't BASIC.
I have never understood why there is such derision regarding BASIC - because that is the problem, it seems. At one time, BASIC was looked upon as a satisfactory language for a lot of projects - whether hobbiest or business. Even today, in business, you still have people creating large business application (think vertical markets) in what amounts to BASIC. Why is it that Parallax's microcontrollers became so popular so quickly? BASIC!
I think if inroads are to be made in the business realm on the desktop by Linux (and maybe even *nix distros in general), there needs to be a form of BASIC for users to create custom applications with. I am not saying that we should have it like Microsoft's vision (what with Outlook being able to willy-nilly run VBA scripts and such) - but a BASIC with perhaps sandbox capabilities for security, plus the ability be plugged into a variety of office applications, and a tight, clean IDE/debugger - that would help propel Linux onto the desktop in business.
Finally, let me say this - I am not saying BASIC (or VB) is the tool for every job - it isn't. But it is a nice general purpose tool which can help solve many problems in business, and it provides rapid turnaround for projects. If such a language or development environment were created for Linux, it would be a boon for both businesses and open source projects/developers.
Reason is the Path to God - Anon
I'm working on a project for central user management on a popular network appliance. At present there's only one commercial solution (that I could find/google) available that lets you manage n+1 of these appliances at once.
I initially looked at the problem and figured, heck I can do it easily with expect and ssh, but then I started thinking about how my employers & co-workers would use it (I contract), and realised a command-line application wouldn't suffice.
So I started pondering how I could integrate a fairly simple backend (that could be implemented by scripting languages) with a portable interface.
I could either:
I eventually chose the tcl/tk option, because of the following reasons:
So I ended up choosing a well-documented language for implementation, which has the benefits of being portable, interepeted (no compiling), and easily updateable (email the latest script). Sure it isn't the sexiest solution, but it works and is easy for new developers (the project will be open-sourced when ready) to pick up on where its at.
Man watching 6 MSCE's around a sun box, looks alot like the opening scene's of 2001:space odyssey...
Eiffel is, or are you concerned about possible IP problems with the language spec per se?
take the best aspects of java, objective-c, eiffel and maybe some smalltalk like elements and roll them up into one language.
The D programming language looks somehow interesting...
You are almost a text book example on how to do things right.
See my journal, I write things there
-I dont agree with his language critique. I think the advantages of static typing far outweigh any time it takes to (as he describes) figure what type to declare a variable. Have you ever tried to debug a large project written in a dynamically typed language? It can be a fucking bitch.
-He also says it is really, really hard to learn C, C++, and Java. He says this cuts down on your developer base. Any developer who doesn't have the capacity to pick up those three languages, I just do not want on my project.
With regard to the first: consider learning thee build tools part of the cost of learning a static compiled language. It is not optional.
With regard to the second: If you have so many cross-dependicies, you will run into problems in any language as the project grow. A bug solved in one module may cause new bugs to appear in any other module.
In general, Based on many years experience with C++ and Lisp, I'd recommend compiled and statically typed languages for large projects, because of the discpline they encourage. Interpreted and run-time typed languages are usually superior for small projects.