

Does a new or emerging programming language really need practical libraries? - berlinbrown

Using a factor or forth, Arc or whatever as an example (note: factor is a bad example because it has a large set of practical libraries). Lets say you are considering using a programming language. Does having a large set of practical libraries matter? If your language is well designed, then it would be easy to create a 'string' library or a 'date' library. Maybe even a web framework?<p>I mention this, because when a language emerges, it seems that someone brings up 'practical libraries'.
======
mooism2
By the time I've written a string library, a date library, a cgi library,
sqlite bindings, a templating library, and a graphics library, I could have
written my application in Blub.

A lot of these sorts of libraries contain an essential amount of cruft, either
because they deal with crufty human things, or because they implement crufty
standards.

------
triplefox
If you're talking about more than trivial applications(examples: computational
geometry, statistics, parsing and saving common formats) libraries become
important as a means of offloading effort. They can be abused, for sure, and
by being overly general purpose they can often cause no end of trouble, but
using a few good libraries appropriate to the domain may result in 1000x less
time to get productive results, even if the language sucks. So you've just
gotta have libraries. The problem a lot of new languages face is that they
aren't different enough to necessitate building out a new set of libraries.
Bindings to C are an ugly 80% solution, good enough for most cases, and they
have the nasty result of making C even more all-consuming as the source of all
library code.

haXe and Factor are both good examples of languages that have a basis with
which to grow their libraries. haXe is getting uptake from a variety of angles
but the emphasis is clear the everyone involved wants to minimize the costs of
multiple-language incompatibilities, and that is resulting in powerful
libraries across multiple domains. I don't know the details of Factor's
growth, but I suspect that it is doing so on its strengths as a "next-gen"
concatenation language in a field with little comparable competitors. Both
languages have C bindings available, but haXe in particular has strong reasons
to create native libraries.

------
Todd
Only if you want it to thrive. There are a number of interesting backwater
languages that never get more than passing interest. Even the motivated
developers that experiment with languages move on after a time if they can't
do anything more than write Fib() with it.

Take the case of Lua. A compelling small language if ever there was one. It
has many great things going for it: simple syntax, elegant grammar, small and
efficient VM. Even after 15 years it has only gotten traction among game
developers and as an embedded language. The obvious reason why is that their
standard library is very small (for important reasons).

------
makecheck
"If your language is well designed, then it would be easy to create a 'string'
library or a 'date' library."

It may be easy to create such things with a new language, but you shouldn't
have to.

I consider it good enough if established libraries can be linked to new
languages (e.g. via C). That way, the unique features of the language can be
more readily tested in existing tools. For example, I may have a program with
a critical algorithm, that _might_ be faster in a new language; if the
language simply links to C, I can easily test _that algorithm_ in the new
language, without having to replace the rest of the program and the libraries
it uses.

Note that I'm not saying it's bad for new languages to be _capable_ of
implementing something like a 'string' or 'date' in a simple way. In fact,
such practical examples may help when learning the new language. It's just a
question of whether or not that is mandatory before anything useful can be
done with the new language.

------
jimbokun
One trick is to build on a virtual machine or other platform that already has
a bunch of libraries. This is why there are a lot of languages for the JVM and
CLR. Objective C and C++ got all of the C libraries by being supersets of C.

------
lacker
It doesn't matter how well your language is designed - it is _not_ easy to
write libraries from scratch for regular expressions, HTTP serving, or
emitting json. All things that are pretty handy for hacking together a
website.

