The fact that the maintainer of Fedora packages is ready to pass them off does not mean the software in question is neglected/ignored. One of the listed packages is audacity.
It just means one individual doesn't have time to maintain Fedora packages anymore.
It’s a shame these advanced languages don’t get more attention, since they are clearly better languages than the ones most programmers use day to day, and would solve their problems if only they tried them.
Or, maybe programmers aren't as dumb as some people think and there's more to making a language productive than optimizing for 10 line examples?
Which of those languages are you claiming is optimized for 10-line examples? If it had been one if the "scripting" languages (Ruby/Python/Perl), I might at least see some relevance since those were the initial use cases. But none of these are like that, and in fact most of them have trouble showing their benefits in toy examples.
If anything I'd like to see fewer packages provided as part of the distros and a cleaner system for installing them separately. I practically never use any of the installed versions of languages in Ubuntu. They're usually out of date, broken down into too many sub-packages, over-specified on dependencies, and unable to play nicely with packages you install yourself via gems/easy_install/whatever.
They are usually not installed by default (unless something pulls them as a dependency - can happen for perl or python, but definitely not lisp/erlang/forth... by default) and they are installed separately. The situation is exactly what you ask for - they are available for separate install, right there in distribution repository.
You can also choose - either too many subpackages, or overspecified on dependencies. You can not have both, for obvious reasons.
Wrt gems/easy_install/whatever, do you realize that these language specific systems are broken by design and interoperating with them is not exactly easy?
Wrt gems/easy_install/whatever, do you realize that these language specific systems are broken by design and interoperating with them is not exactly easy?
Yet I deploy a wide range of services into production with them every day.
Do you have some more information about why they are broken? I'm not trying to call you out, I'm just curious and don't know much about these systems, or and couldn't find anything when I went looking for criticisms.
The Ruby community is probably not interested in dealing with distro packages. I.e. having to get people in their forums asking about some ancient Debian stable version that's no longer supported.
".tar.gz is the most widely used archive format on Linux. Using other formats (.tar.bz2, for example) is discouraged, as it requires additional steps for the packager."
-- so fix the bleeping package system to support bzip2.
I note, too, that Fedora has rubygem packages, which provide Ruby gems directly. Is there something rpm does better than dpkg here?
(Not that I give a flip about Ruby; it's a terrible language. I spent about 6 months building an app in Rails; it took about 3 months to go from "this is easy!" to "but it won't let me do anything hard!".)
> ".tar.gz is the most widely used archive format on Linux. Using other formats (.tar.bz2, for example) is discouraged, as it requires additional steps for the packager."
> -- so fix the bleeping package system to support bzip2.
Here you have a point. That's a fairly silly requirement. However, the rest of the recommendations in the second link are pretty solid.
> I note, too, that Fedora has rubygem packages, which provide Ruby gems directly. Is there something rpm does better than dpkg here?
No, it's a policy/politics thing. Gems break the FHS, so Debian pretends they don't exist. Not knowing it intimately, I don't know Fedora's approach precisely, but presumably they're either allowing FHS breakage, or patching the gems to bring them into line.
Patching them is a non-small job; the number of badly-written gems out there is astounding. I say this as someone peripherally involved with patching them to make them conform to Debian's standards.
> (Not that I give a flip about Ruby; it's a terrible language. I spent about 6 months building an app in Rails; it took about 3 months to go from "this is easy!" to "but it won't let me do anything hard!".)
That's a shame - the limitations of Rails are not an accurate representation of the limitations of the language.
But it’s even more of a shame if people won’t even be able to try these languages because we lose them from Fedora entirely.
That's really overstating the problem. I've worked with several of these languages, one of them for quite a large project - and I've never relied on anything but the language's official site to get the necessary tools. A lack of maintenance from Fedora isn't going to kill anything.
Consider this: many compilers are written in the language they compile, hence they require some sort of bootstrapping. The popular Common Lisp implementation SBCL for example is written in Common Lisp. Bootstrapping compilers is bit of a hassle and not a very newbie-friendly process. I'm quite sure that the lack of prepackaged versions of these languages in Fedora would seriously affect the usage of these languages in Fedora.
True, but the number of developers who expect batteries to be included is not small. And those are the people who "* for dummies" markets to. And when your manager goes to Barnes and Noble and sees an entire wall of "* in 3 days", guess what language he is going to pick for his next project?
More serious: Batteries included make it easier to get up to speed. It's also easier to use synaptic as an "AppStore" instead of hunting for everything out in the web.
Though for languages that I am more familiar with, e.g. Haskell, I am more open to hunt myself (or install custom package managers like Haskell's cabal).
It just means one individual doesn't have time to maintain Fedora packages anymore.