| |||||||||||||
GNOME and high-level languagesGNOME and high-level languagesPosted May 12, 2005 7:21 UTC (Thu) by socket (guest, #43)In reply to: GNOME and high-level languages by dhess Parent article: A new Harmony Project I think this is a hard problem for us. Sun effectively controls Java. Microsoft's history makes many free software developers wary of anything they "give away," including C#, and in my opinion, rightly so. But I realize others feel differently, and I fully expect that someone will correct me by pointing out that Microsoft doesn't really control C#. That's a debate for another time. Being language-agnostic is a wonderful goal, and I'm an active follower of Parrot's development, but despite its power, there's still a relatively small number of useful languages supported. In the meantime, it means that we're just stuck with putting SWIG wrappers around each required C library, for each language, and then eventually rewriting stuff that's commonly used in C and adding more bindings. Being able to call Perl libraries from Ruby or Python just isn't possible until we have good implementations of each on Parrot. Choosing one of Perl, Python, Ruby, OCaml, Lisp, Standard ML, Modula-3, Forth, Postscript, or anyone else's favorite scripting language leads us down another path: we choose favorites. But honestly, I've come to have several favorite languages, and would be disappointed if I couldn't use whatever I'm happiest with at that moment on my weekend project to make a better recipe manager. So here we are. I don't want my software dependent on libraries or tools controlled by Sun or Microsoft. I'm sure many of us don't want to spend our time scratching our heads at some obtuse bit of Perl from CPAN if it made up part of a core library we had to call in to. I'm sure we also grit our teeth and wish Python were more like Ruby, or the other way around. And others can't get past the parentheses of Lisp. And we all want more libraries, and desktop systems, to have support for our favorite language. It's a hard problem. I just to emphasize the point that we don't force ourselves down paths we can't backtrack from. I want us all to think about what it would really mean to say, "For this desktop environment, your development language is really just $LANG. The others will kinda sorta work, but they're not supported anywhere near as well." Our strength comes with and partly because of a diversity of ideologies related to programming languages. Let's not be so quick to throw that away.
(Log in to post comments)
GNOME and high-level languages Posted May 12, 2005 14:37 UTC (Thu) by ncm (subscriber, #165) [Link] "Our strength comes with and partly because of a diversity of ideologies related to programming languages."Really? From here it looks as if each of these ideologies saps our strength. Whether it's built-in garbage collection, or object orientation, "there's more than one way to do it", "lambda the ultimate, or "builds and does", we are the poorer for being locked into it, even if only in a single project. The best that might be said about a diversity of them is that it may undermine allegiance to any one of them. Even then, we are led to believe that anything common to all the languages we know is god-given. We are better off with pragmatic languages. Survey the programs on your favorite distribution, and you'll find (in order) C, C++, a few in Perl, fewer in Python. Java is largely confined to programs for people who are already obliged (by corporate diktat?) to use it, or write it. These languages rule not because they're especially good at anything particular, but because they don't pretend to know better than we do what we're trying to do: C, because it doesn't pretend to know much of anything; C++, because it is happy to get out of the way; Perl, because it's all over the place.
GNOME and high-level languages Posted May 12, 2005 16:02 UTC (Thu) by shahms (subscriber, #8877) [Link] Um, I think you'll find the actual order (at least for FC4) is going to be:C, C++, Python, Perl. Almost all of the Fedora GUI system tools are Python. There are very, very few progams that are built using Perl. automake and autoconf are the biggest ones. foomatic also uses perl and I think libtool.
Don't get me wrong, there are a lot of packages that require perl, but most of these are perl modules and not applications.
GNOME and high-level languages Posted May 12, 2005 17:20 UTC (Thu) by ncm (subscriber, #165) [Link] That was what I expected to find, but it wasn't what I found. Your mileage may vary. I didn't look at a Red Hat system, which undoubtedly has lots of Python programs not found on other distros. Python is another pragmatic language, anyway, that "plays well with others".
GNOME and high-level languages Posted May 12, 2005 23:05 UTC (Thu) by bk (guest, #25617) [Link] automake/autoconf uses m4, or am I missing something obvious?
GNOME and high-level languages Posted May 13, 2005 9:36 UTC (Fri) by wilck (subscriber, #29844) [Link] autoconf: m4automake: perl
That's what it used to be.
GNOME and high-level languages Posted May 13, 2005 4:11 UTC (Fri) by green (guest, #29086) [Link] For Fedora Core 4 the order will be C, C++, Java, Lisp/Scheme, Perl, Ada, Python, Assembly (ignoring shell scripts, most of which are auto* files anyways).
Here's the data to back this up:
AG
As I said Posted May 13, 2005 6:08 UTC (Fri) by ncm (subscriber, #165) [Link] "Java is largely confined to programs for people who are already obliged (by corporate diktat?) to use it, or write it."
Eclipse 1310322 How many of these are useful to somebody not already obliged to run Java, for being obliged to write it? Sure, Sun shoehorned the stuff into OO.o, but that's corporate diktat too.
GNOME and high-level languages Posted May 14, 2005 14:58 UTC (Sat) by ohanssen (subscriber, #2761) [Link] Well. I have seen examples of the opposite. People want to use Java, but are not allowed to (by some "corporate diktat"), because somebody strongly belives that dot net and C# is the right choice. And in another case, because of ideological reasons ("Java is not free software", etc. etc.).
|
|||||||||||||