What Makes A Programming Language Good

Brad brad.lanam.comp_nospam at nospam_gmail.com
Thu Jan 20 01:13:38 PST 2011


In digitalmars.D, you wrote:
> The two most frustrating aspects were documentation and deployment.
> The documents were sparse and useless and deployment was the
> hugest headache I've ever experienced, in great part due to Rubygems
> not working properly!
>
> They've probably improved it a lot since then, but it reinforced
> my long-standing belief that third party libraries are, more often
> than not, more trouble than they're worth anyway.

I only poked into RubyGems briefly and I had the same impression
at the time.  Perl's CPAN is much more mature.

Much of the time, I feel as you do about 3rd party libraries.  They
try to do too much, are inflexible and not customizable.  But many
of the perl packages on CPAN are written to address a single task,
are flexible and easy to use.
I use several and have my favorites.  Others are not worth the trouble.

But this problem is going to happen to any system.
Some of the packages are simply useless, poorly
designed, too specific, not supported, out of date, etc.

But other packages are well designed, well supported, work great.
Some haven't changed in ages and work well.

I think counters can help -- how many downloads, indicating popularity.
How many _recent_ downloads, or a histogram of downloads by month
so the user can tell if the package is out of date.

Don't like the rating systems much, but that's also a possibility.

An integrated bug database and forums similar to sourceforge would be very
useful.   You can check activity and see if the author of the package
is active and keeps on top of problems.

--
  Brad


More information about the Digitalmars-d mailing list