Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Sixteen Years Later: GNU Still Needs An Extension Language

Unknown Lamer posted more than 2 years ago | from the one-of-us-one-of-us dept.

GNU is Not Unix 425

Fresh from the 2011 GNU Hackers Meeting, Andy Wingo has written a long piece on the status of Guile Scheme, the woefully underutilized official user extension language of GNU. Wingo argues that Guile is the best choice for extension in GNU given the ability of Scheme to adapt to change over time. Presented with using e.g. Javascript instead of Scheme for its popularity: 'We should also consider the costs of using hastily designed languages. JavaScript has some crazy bad stuff, like with, var hoisting, a poor numeric model, dynamic this scoping, lack of modularity regarding binding lookup ... Finally, we have the lifespan issue. If GNU had chosen Tcl because it was popular, we would have a mass of dead code' (it should be noted that Guile does partially support Javascript syntax). With the proliferation of Firefox extensions, Greasemonkey, etc. it is clear there is a large set of power users who want to modify the programs they use without spending years becoming skilled programmers. Perhaps after Emacs has been ported to Guile the philosophy of user extensibility will spread to other parts of the GNU system.

Sorry! There are no comments related to the filter you selected.

Guiwhat? (-1)

Anonymous Coward | more than 2 years ago | (#37264914)

Something is wrong if no one knows about it.

Maybe releasing it under a truly free license instead of locked-down copyleft-GPL then maybe people would notice it.

Guile is LGPL (1)

tepples (727027) | more than 2 years ago | (#37265086)

Guile is LGPL [gnu.org] . It's no more "locked down" than any of the other LGPL libraries that proprietary software uses, such as glibc or Gtk+ or SDL.

Re:Guiwhat? (1)

Anrego (830717) | more than 2 years ago | (#37265120)

I'm not a fan of the GPL either, but I think licensing has little to do with it.

Extension languages fill a small void. People who are tech savy enough to want to make changes to the way their programs work and have basic programming ability, but arn't skilled enough or don't have the time/interest to make a full blown patch.

I think they've got it all backwards here. You don't ignore popularity and pick an extension language based on it's language features .. you pick a language based purely on it's popularity and ignore language features. Using some obscure (even if well suited) language just narrows that void even more to people who can't be bothered to write a patch, but can be bothered to learn a whole new language.

ECMAScript (2)

tepples (727027) | more than 2 years ago | (#37265286)

Using some obscure (even if well suited) language just narrows that void even more

If you don't like the parenthesized S-expression syntax commonly associated with Guile, use M-expressions. Guile supports a curly-bracket syntax called ECMAScript, as the summary points out. You already have thousands of web developers using JavaScript and ActionScript, both of which are based on ECMAScript.

Re:ECMAScript (2)

Anrego (830717) | more than 2 years ago | (#37265506)

Here's the problem.

If you don't like the parenthesized S-expression syntax commonly associated with Guile, use M-expressions. Guile supports a curly-bracket syntax called ECMAScript

In the time it takes someone to interpret what that even means.. they've lost interest in using it. Like I said.. the niche of people who would use an extension language is pretty small. The fact that they have to learn something new makes it even smaller. This is why using actual javascript vice something that is based off the same thing would make more sense. Most geeks have at least a basic understanding of it.. and could start using it right away.

I'd also like to add that their basic argument of "lets not use something popular that could go out of style, but instead use something that has never been in style at all!" seems a bit odd.

Re:ECMAScript (0)

Anonymous Coward | more than 2 years ago | (#37265860)

This is why using actual javascript vice something that is based off the same thing would make more sense.

You have no idea of what you're talking about. Please google ECMAScript and come back here.

Re:Guiwhat? (1)

maxwell demon (590494) | more than 2 years ago | (#37265352)

Alternatively you can make the language popular. Get GUILE into HTML5, and its popularity will rise. :-)
(Or maybe the popularity of HTML5 will go down instead ;-))

Re:Guiwhat? (2)

Anrego (830717) | more than 2 years ago | (#37265520)

I generally subscribe to the idea that if something is good, it will become popular all on it's own.

16 years later and no one has heard of it.. not good.

There are of of course exceptions, where something is so far ahead of its time that no one appreciates it, or where something is never given a fair shake ... but I think guile falls under neither group. It was a nice idea, but let it die and use javascript/lua/python/whatever ..

Re:Guiwhat? (2)

fuzzyfuzzyfungus (1223518) | more than 2 years ago | (#37265362)

In the rather unixy context in which GNU software tends to operate(historically, yes, there is the strong lisp-derived strain; most prominently holding out in Emacs; but today's incarnations generally show up as the userland tools of a unix or unixlike system) the niche for extension languages is arguably even a bit narrower:

They have to address problems of interest to people technical enough to write them; but not technical or interested enough to modify the program(as you note); but they also have to address problems in programs that are sufficiently monolithic that you would use the program's internal extension language, rather than hacking together a bash script that stitches together a bunch of common utility programs. In a context where command line users are largely an afterthought, or a workflow situation that makes heavy use of big, monolithic, programs with minimally useful command line invocations, extension languages are the 'glue logic' you get(observe your local Office guru's bludgeoning about of VBscript, or some photo-pro's slightly alarming Photoshop batch processing abilities); but the unix 'flavor' has historically been that the shell, rather than the program extension language, has been the tool of choice for bodging jobs too big to tackle manually but to small to be worth delving into the guts of the programs themselves.

No one seems to care (-1)

Anonymous Coward | more than 2 years ago | (#37264940)

The lack of comments indicates that no one cares about this.

Languages are tools not religions.

Re:No one seems to care (0)

Anonymous Coward | more than 2 years ago | (#37265348)

Also, religions are tools and not languages.

Python ka-SLAM! Python ka-Pow! (0)

Anonymous Coward | more than 2 years ago | (#37264988)

from the article:

"Guile supports POSIX threads, with no global interpreter lock. "

Ouch...

Re:Python ka-SLAM! Python ka-Pow! (1)

rubycodez (864176) | more than 2 years ago | (#37265516)

that's a silly argument against Python, a particular Python implementation can be made without global lock. Jython and IronPython don't have one.

People hate paren languanges (1, Insightful)

Anonymous Coward | more than 2 years ago | (#37264994)

(Besides a few hardcore geeks, (people (hate (shit that (looks) like ((this))))))

Re:People hate paren languanges (3, Informative)

mmcuh (1088773) | more than 2 years ago | (#37265196)

Why would anyone write it like that? You use line breaks and indentation to convey structure, just like you do when you write in any other language.

Re:People hate paren languanges (0, Troll)

rubycodez (864176) | more than 2 years ago | (#37265280)

do all that and it still looks like ass and is a PITA. I did LISP professionally for years. yes, it's the queen of the languages and can do everything and anything any other language can do, and it can compile to native code even when modifying the language itself......but I'm glad I can do the same jobs in easier to read and debug languages

Re:People hate paren languanges (2)

siride (974284) | more than 2 years ago | (#37265314)

It's still a lot harder to read something like (plus 7 (minus 4 5) (some-function (* my-var 3))) than to read 7 + (4 - 5) + some_function(3 * my_var). It's also easier to read while(x 3) than it is to read the crazy Lisp syntax for do-loops, which appears to be a list of a variety of values, variables, conditions, all compacted into one statement, with no differentiation, syntactically, between the different arguments to the loop structure. Indentation and line breaks only help so much. Having actual syntax helps a lot more.

Re:People hate paren languanges (1)

Paradigma11 (645246) | more than 2 years ago | (#37265804)

It's still a lot harder to read something like (plus 7 (minus 4 5) (some-function (* my-var 3))) than to read 7 + (4 - 5) + some_function(3 * my_var)...

especially if the lisp code is not a well formed expression.

Easier to read, harder to get right. (0)

Anonymous Coward | more than 2 years ago | (#37265808)

Why else do we have BODMAS in our maths class?

Re:People hate paren languanges (1)

snowgirl (978879) | more than 2 years ago | (#37265862)

(plus 7 (minus 4 5) (some-function ( * my-var 3))) is more difficult to read for the same reason that typing in all caps without spaces is more difficult to read: we don't have a lot of practice at it.

That said, my go-to one-liner evaluation language is a lisp-like language without parentheses*, and while I'm getting pretty good at typing out expressions in a prefix notation, the line "/ + * 3 + * 5 2 * 4 4 + * 5 2 * 4 3 + * 6 3 5..." still isn't easier to really read than the equivalent infix version of: "(3 * (5 * 2 + 4 * 4) + (5 * 2 + 4 * 3)) / (6 * 3 + 5)"

*: How can a lisp-like language work without parentheses? It's a context-sensitive language that assumes a default number of arguments to functions, which can either be extended by using "," or truncated/terminated by using "."

Re:People hate paren languanges (0)

Waffle Iron (339739) | more than 2 years ago | (#37265488)

(even
    (when)
    (it looks (like this))
        (everyone (still)
        (hates (it))))))))))))))))))))))

Seriously, who needs first class continuations and hygienic macros in an application script? IMO, the only thing that Lisp and its offspring are good for is implementing other languages. If the data and algorithms in your problem don't map directly onto a tree made of singly linked lists visited with recursion, Lisp's idiosyncrasies just get in the way of what you're trying to do.

And all the powerful features that let you redefine language constructs make it like talking to a stoned hippie:
"What do these one-off custom control structures actually do?"
"Whatever you want them to do, man..."

I once tried to use guile in the Gimp to do a few simple filters. Between the abysmal documentation and the clumsy syntax, I gave up in disgust after a couple of hours, and installed the Python Image Library instead. My sanity was saved.

Re:People hate paren languanges (1)

mukund (163654) | more than 2 years ago | (#37265702)

I once tried to use guile in the Gimp to do a few simple filters. Between the abysmal documentation and the clumsy syntax, I gave up in disgust after a couple of hours, and installed the Python Image Library instead. My sanity was saved.

GIMP doesn't use Guile. It currently uses an embedded fork of Tinyscheme, which is somewhere between R4RS and R5RS compliant, and somewhat not.

Some people like Scheme (it is well suited to represent order of graphics operations), and some hate it. That's why GIMP supports Python and C too for extending.

I guess that sums up what other apps can do. You don't have to stick with "an" extension language when you can support many.

Yes, but it's clean and elegant (1)

Anonymous Coward | more than 2 years ago | (#37265518)

From the Guile webpage:

Guile is an interpreter and compiler for the Scheme programming language, a clean and elegant dialect of Lisp.

OK, if I see a bunch of Lisps walking down the street, I'll be able the recognize Guile as the one wearing spats and carrying a walking stick.

Would somebody please tell me why we keep resorting to these ridiculously nondescript descriptions.

Re:People hate paren languanges (3, Insightful)

nschubach (922175) | more than 2 years ago | (#37265262)

function Besides() { a(); few(); hardcore(); function geeks() {people(function hate(){shit(); that(looks()); like ((this();));})}}

I think that's harder to read.

Re:People hate paren languanges (1)

siride (974284) | more than 2 years ago | (#37265602)

Nobody writes JS like that.

Re:People hate paren languanges (2)

JonySuede (1908576) | more than 2 years ago | (#37265420)

you have the wrong form, your parenthesization is all wrong and you have two useless conjunction:

(Beside
            (few (hardcore geek))
            (hate people (look shit (like this)))
)

Re:People hate paren languanges (2)

siride (974284) | more than 2 years ago | (#37265546)

Yes, that's MUCH better /sarcasm.

Re:People hate paren languanges (1)

JonySuede (1908576) | more than 2 years ago | (#37265788)

Please excuse the misfiring of my single humour neuron, I try recruit more neurons into this network by exercising that part of my brain but to this day only my retarded cell enrolled.

It's not just the paren, it's the order (1)

Anonymous Coward | more than 2 years ago | (#37265478)

It's not just the parens, it's the order. Prefix order is only natural sometimes. Take (loop (print (eval (read)))) for example.

This is just a small example so the parens aren't a bother. What does bother you is that when you think, "how do I implement a REPL?" you don't think of the print before the read or eval. You think of the reading first. In a small example like this it isn't too hard to slow down and see what's happening.

In larger functions, it's a problem. Finding the "starting point in the maze" becomes a gruesome chore of navigating down a parse tree of parens. It isn't the parens causing the problem though. You'd have the same problem if this were done using some other syntax for a parse tree.

There are two big patterns in programming: hierarchy and sequence. IMHO, Lisp does a fantastic job representing hierarchy, but a lousy job with sequence.

Re:People hate paren languanges (0)

Anonymous Coward | more than 2 years ago | (#37265642)

People hate trees? Hug a tree! It won't kill you, unless a parenthesized coconut drops in your head while performing the said hugging. That's deadly. I hate parenthesized coconuts.

Re:People hate paren languanges (1)

coaxial (28297) | more than 2 years ago | (#37265880)

Besides a few hardcore geeks, no one bothers to even look at the code.

And seriously. Like @#$%t78rRuby or $!^&$Perl is better.

Lua? (2)

batrick (1274632) | more than 2 years ago | (#37265006)

Why isn't Lua considered? Everytime I see Guile brought up as a possible extension language, the project in question always settles on Lua or Python. (Python being the poorer choice because it is not designed to be an extension (scripting) language.)

Re:Lua? (1)

fusiongyro (55524) | more than 2 years ago | (#37265076)

Guile is working on Lua support.

Re:Lua? (3, Funny)

jockm (233372) | more than 2 years ago | (#37265136)

Working on being the core term. Not have, not encouraging people to use, not bragging about compatibility, but working on. Wake me when it is ready, like their JavaScript support. It will make a nice break from waiting on Hurd.

Re:Lua? (4, Insightful)

SerpentMage (13390) | more than 2 years ago | (#37265768)

Here is an idea instead of adding Lua support, I don't know, USE LUA... Wow what a concept!

This is what gets me with the GNU team. Instead of actually reusing what other people develop they rather stick to their own little ivory tower and get very little done. I am being serious here.

I appreciate the work that the original GNU people did about two decades ago. It was needed. But for crying out loud these people remind of an older generation that does certain things because well that is how they did it two decades ago. And if it was good enough then, then gosh darn it, it's good enough today...

Re:Lua? (2)

GuldKalle (1065310) | more than 2 years ago | (#37265532)

(Not trying to flame or confront, just curious)
What about Python makes it unsuitable as an extension language?

Lisp? (1)

Hatta (162192) | more than 2 years ago | (#37265026)

Why not?

Re:Lisp? (2)

royallthefourth (1564389) | more than 2 years ago | (#37265070)

Because Scheme is already a Lisp.

Re:Lisp? (1)

Hatta (162192) | more than 2 years ago | (#37265160)

Oh, I didn't know that. Is it very different from emacs lisp? It would make sense to stick with one extension language.

Re:Lisp? (1)

CarsonChittom (2025388) | more than 2 years ago | (#37265442)

What I don't understand—admittedly, as a non-programmer—is why they don't just say "From now on, Emacs Lisp is the GNU extension language." Or, alternatively, that Guile continues to be the GNU extension language, but that as of Emacs 26 (or whatever version), Emacs Lisp will conform to the Guile specification.

Having both just seems like splitting resources to no good end to me.

Re:Lisp? (1)

Anonymous Coward | more than 2 years ago | (#37265868)

why they don't just say "[...] Emacs Lisp is the GNU extension language."

Emacs Lisp the language is quite full of crazy legacy baggage. Emacs Lisp or more precisely the Emacs virtual machine it runs on was never particularly designed to be easily linked into larger applications, unlike Guile/Lua/TCL/etc.

Ripping out the Emacs bytecode virtual machine core from Emacs and replacing it with the Guile core is still a long term plan for Emacs AFAIK. But it is not exactly something you can do between tea breaks. That doesn't mean emacs lisp being replaced by scheme in emacs at the same time, there are millions of lines of emacs lisp code in the wild, it's more about developing an emacs lisp "personality" for Guile - work that is being done - then integrating the guile vm into emacs instead of the existing vm.

Guile specification.

Guile isn't a specification.

http://www.gnu.org/s/guile/ [gnu.org] ... Guile is an efficient virtual machine that executes a portable instruction set generated by its optimizing compiler, and integrates very easily with C and C++ application code. In addition to Scheme, Guile includes compiler front-ends for ECMAScript and Emacs Lisp (support for Lua is underway), which means your application can be extended in the language (or languages) most appropriate for your user base.

Re:Lisp? (0)

Anonymous Coward | more than 2 years ago | (#37265544)

Scheme remains rather different from Emacs Lisp. Of the extant widely-used Lisp dialects, Emacs Lisp is generally fairly similar to Common Lisp, though more primitive in various ways, currently without a proper numeric tower, without Common Lisp "packages", but with various special objects oriented towards text editing (such as buffer and font face objects) that common lisp of course doesn't have as part of its official specification (but a common lisp text editor might have). Just recently, Emacs Lisp got lexical scoping a lot like Common Lisp's, suddenly making it a lot more "modern". A lot Scheme vs. Common Lisp comparison points apply similarly to Scheme vs. Emacs Lisp.

Re:Lisp? (1)

JonySuede (1908576) | more than 2 years ago | (#37265664)

scheme is better define than emacs lisp.
Scheme is based on the Revised 6 Report on the Algorithmic Language Scheme. It is a formal specification of what a minimal implementation of scheme should offer.
Emac lisp is based on whatever emac lisp can run, it is a bastardize old school lisp mixed with common lisp, sprikled with a bit of scheme and a dash of weird smelling stuff.

Re:Lisp? (1)

Creepy (93888) | more than 2 years ago | (#37265222)

Not quite - Scheme is more a subset of lisp with a few different features and a much smaller standard library.

I personally hate them both because (over(use(and(need(for(lots(of(parens(without(format(requirements)(drives me))))(crazy))))).

Re:Lisp? (1)

rpresser (610529) | more than 2 years ago | (#37265514)

LISP: Lost In Stupid Parentheses

Re:Lisp? (2, Funny)

Anonymous Coward | more than 2 years ago | (#37265368)

Unlambda would a better choice in my opinion, it has all the features and none of the cumbersome syntax.
Lisp is but a remnant of an age with far too much LSD and Napalm.

Re:Lisp? (2)

cpghost (719344) | more than 2 years ago | (#37265236)

As an extension language, something like ANSI Common Lisp would have been an extremely bloated language. As a general purpose language, it is fine though. On the other hand, Scheme is lightweight enough to be linked as a library to any application, even running in the most constrained environment.

Re:Lisp? (0)

Anonymous Coward | more than 2 years ago | (#37265748)

âoeEverything should be made as simple as possible, but no simpler.â

A decent module system definitively won't be luxury
http://www.phyast.pitt.edu/~micheles/scheme/module-system-talk/ [pitt.edu]

And after 30 years (0)

the_humeister (922869) | more than 2 years ago | (#37265036)

they still need a kernel.

GNU/Linux (2)

tepples (727027) | more than 2 years ago | (#37265132)

They have a kernel. If you're referring to GNU HURD, that's been deprioritized because as Mr. Stallman wrote in a Reddit interview [reddit.com] , "Linux works ok as a kernel." Linux is one of many third-party components of a GNU system.

Re:GNU/Linux (1, Interesting)

rubycodez (864176) | more than 2 years ago | (#37265322)

hahaha - what a cop-out. that's a nice mealy-mouthed way to say they totally and utterly failed to produce a viable kernel after decades of farting around. Let's face it, a task that requires real world engineering ability rather than ivory tower theory and navel-gazing is always beyond RMS and his close cohorts. Even the gcc would have been dead had not the engineering types rescued it (egc history)

Usage predicts lifespan (2)

G3ckoG33k (647276) | more than 2 years ago | (#37265064)

"Finally, we have the lifespan issue. If GNU had chosen Tcl because it was popular, we would have a mass of dead code"

If Tcl had been used it may well have been alive I guess. I suppose it is Turing complete.

Re:Usage predicts lifespan (2)

batrick (1274632) | more than 2 years ago | (#37265142)

So is brainfuck.

Re:Usage predicts lifespan (0)

Anonymous Coward | more than 2 years ago | (#37265146)

More to the point, if the W3C had selected Tcl instead of Javascript, Tcl would be very much alive now and for the next 20 years at least.

Meanwhile, they have Guile which is both dead & unpopular.

GNU, swallow your pride and use Javascript. It may not be beautiful, but it works.

It supports JS yet is "dead and unpopular". How? (1)

tepples (727027) | more than 2 years ago | (#37265332)

From the summary:

Guile does partially support Javascript syntax

Anonymous Coward wrote:

Meanwhile, they have Guile which is both dead & unpopular.

GNU, swallow your pride and use Javascript. It may not be beautiful, but it works.

If Guile supports JavaScript, why is it dead and unpopular, as you claim?

Re:It supports JS yet is "dead and unpopular". How (1)

jockm (233372) | more than 2 years ago | (#37265392)

Because it partially supports JavaScript. not supports it. And it doesn't (the last time I looked) provide much of the common JavaScript libraries. Making it a PITA and minefield to use

Re:It supports JS yet is "dead and unpopular". How (1)

3dr (169908) | more than 2 years ago | (#37265590)

Guile is not Javascript, and Guile does not fully support Javascript.

Are you saying Guile is alive, prosperous, and popular? I'll agree it's alive, but only barely.

Re:Usage predicts lifespan (1)

Berfert (831562) | more than 2 years ago | (#37265174)

If GNU had chosen Tcl because it was popular, we would have a mass of dead code'

Instead, they decided to build their own dead language. That's a solid plan. That being said, Tcl isn't dead and it's actually a fantastic scripting language to add to other programs. It's actually pretty solid as a full development language, too. It has it's warts, but so does every language.

Re:Usage predicts lifespan (1)

belmolis (702863) | more than 2 years ago | (#37265740)

Indeed. Tcl is still actively developed and is, and has been for quite a few years, a much better language than it was when RMS discussed this issue. The associated Tk windowing/graphics library is so good that a number of other languages, including Perl and Python, adopted it as their primary library. There are a large set of libraries and extensions for Tcl, including several that make it object-oriented. The Tcl community is very helpful. Tcl is actually used a good deal more than people realize because it is heavily used in internal industrial work such as automating testing, and in tools such as Expect that people do not always realize are in Tcl. That said, Lua would also be a good choice. It has a very clean design, a good set of libraries, and a very clear-headed and innovative designer, Roberto Ierusalimschy, who also writes very well.

It's true... (0)

Anonymous Coward | more than 2 years ago | (#37265072)

...Guile goes with everything!

Yes, sure. (1)

drolli (522659) | more than 2 years ago | (#37265088)

The port of emacs to guile is a breakthrough.

Re:Yes, sure. (3, Informative)

L1nuxGuy (588760) | more than 2 years ago | (#37265130)

Emacs is a great development environment. It just lacks a good text editor.

Re:Yes, sure. (2)

rubycodez (864176) | more than 2 years ago | (#37265346)

it's a passable operating system too, but yeah lacks a decent editor

Emacs can emulate vi (1)

tepples (727027) | more than 2 years ago | (#37265360)

If you think Emacs lacks a good text editor, install viper-mode.

Re:Emacs can emulate vi (1)

rpresser (610529) | more than 2 years ago | (#37265540)

Yes, let's take a 500 ton bulldozer, tape a fork to the front of it, and use it to eat salad.

Poor planning and bad arguments (2)

jockm (233372) | more than 2 years ago | (#37265094)

Perhaps if GNU had adopted TCL, then it would have stayed popular. Or what if GNU had provided a common backbone for extension so then it would be easy to plug in scripting languages (perhaps at run time)?

The simple fact is that paren languages are a really had sell outside of their niche. There is a hardcore who loves them, but the majority do not. Scheme is like the cilantro of languages -- you love it, or you hate it, but there isn't much of a middle ground. The Guile folk made all kinds of promises back in the day of supporting lots of syntaxes, but like Hurd what has come out has been very late, or comes no where near expectations.

And of course the fact that Emacs still hasn't adopted it, isn't a ringing endorsement either.

So give up on a single fixed scripting language, and provide an extension architecture so lots of options can be used... including Guile

I'm coining a new term: (3, Insightful)

O('_')O_Bush (1162487) | more than 2 years ago | (#37265104)

It is, "Just another paradigm changer" (JAPC). These sorts of articles come out all the time (see the recent OPA article). Basically, this term is to be used when another invested developer harks a new or underused language that will change the way most developers code. The problem is, most ignore some big hurdles in adoption:

1. Saturation. If there are already established tools that do more-or-less the same thing, then there is little incentive for developers to learn something different (often radically) for no tangible gains.

  2. Non-problems: Developers often get excited by "problems" that don't exist outside of their niche or mind, and then develope something to solve it. While this might work in the niche, it rarely works in the general case (thoguh there are a few notable exceptions).

Re:I'm coining a new term: (0)

O('_')O_Bush (1162487) | more than 2 years ago | (#37265124)

Also, please ignore the typos, its hard writing from a phone keyboard.

Re:I'm coining a new term: (1)

Anrego (830717) | more than 2 years ago | (#37265226)

I'm with you!

This has of course been going on forever, and I'm quite weary of it.

It also tends to evoke one of my more hated cringe phrases: "If people would only take the time to learn it, everyone would be using it!". Sometimes this is true.. however most of the time good things do become popular, and if something has been around for a while and not taken off, it's either way ahead of its time (rare) or not infact all that great (way more common).

3. Clear communication (0)

Anonymous Coward | more than 2 years ago | (#37265710)

You're missing one: clear communication of the purpose. I read the summary and couldn't work out what Guile was supposed to extend. Is it supposed to let me add non-POSIX extensions to the GNU POSIX tools? Add non-standard features to GCC? The blog post doesn't talk about any of that either.

When I really think about it I remember that GIMP supports scripting with Scheme, and GIMP plugins is an area which does have potential (albeit saturation is an issue - it's easy to write filters in other languages and chain them into a workflow). But if the people discussing this aren't clearly communicating the use cases no-one's going to care which language they choose.

Re:I'm coining a new term: (3, Interesting)

Z8 (1602647) | more than 2 years ago | (#37265778)

Exactly, lisp was chosen for several related reasons, none of which are relevant:
  1. Language Neutrality: The idea here is that users could program in whatever language they wanted. Unfortunately this never panned out because it requires the huge programming task of writing a translator from every languange into scheme. They should have known from the beginning that writing and maintaining all this code was unrealistic.
  2. Macros: Yes, Lisp is very elegant, you can define your own syntax! But how many people need to write new unheard of forms of flow control in an extension language? And need to do it so often that Lisp's elegance at doing this would pay off?
  3. Other CS Prof features: Yes, Lisp is usually tail recursive, so you can build stuff like coroutines. Again, how many people need coroutines when scripting GnuCash? And you can do coroutines in other languages, it just 10% less elegant (for instance, in Python you need a trampoline).

So basically their decision was optimized on all the wrong criteria. Instead it should have been optimized on:

  1. Ease of use: Can user, who may not be a professional programmer, look at an example, vaguely understand how it works, and modify it slightly? This is possible with Python probably, but not with Lisp.
  2. Community: How many programmers are already using it and what are its prospects for the future? GNU even further splintered the notoriously fragmented Scheme community when they chose to make their own scheme implementation instead of using one of the many very functional pre-existing Scheme implementations, several of which were explicitly designed as extension languages.
  3. Efficient use of resources: If they had chosen Python or Lua they could have leveraged the existing work put into those languages as well as all the future work that would be done by those communities. Instead they decided to reinvent the wheel and develop their own Scheme implementation, almost from scratch (yes I know it forked from SIOD).

Parrot to the rescue (0)

Anonymous Coward | more than 2 years ago | (#37265138)

16 years? And people bitch about Parrot and Perl 6....

Look, matey, I know a dead parrot when I see one, (1)

bobs666 (146801) | more than 2 years ago | (#37265876)

I think we should just ask Larry for an embeddable perl script library. I mean if it's not Perl Its Just not Perl.

PS. I started writing an extension script language as a Lisp library 28 years ago. But My boss told me that Fortran programmers would not write in Lisp. We where using 'C' on a VAX at the time. So I fired my Boss. (Ya, I got a new job) In the next year or so I saw Tcl at a UseNix convention, and that would have been better for the Fortran programmers. So I would pick Tcl over lisp at this point. But Perl script over Tcl, if there was such a thing.

LISP? really??? really?? (0)

MobyDisk (75490) | more than 2 years ago | (#37265216)

Having never heard of Guile, I think I can take a good guess as to why it has not been adopted:

Guile is an implementation and dialect of the Scheme programming language (Scheme is a dialect of LISP itself)

Oh my.

LISP found a niche as an AI research/programming language, and sometimes for symbolic math manipulation, but has never been used in the mainstream. Most programmers have never heard of it. Universities teach it in whatever token course covers 10 languages in one semester with no depth at all. Hardly anyone writes everyday software in LISP. It is not appropriate for general-purpose scripting.

I am prepared to be flamed...

Re:LISP? really??? really?? (1)

jockm (233372) | more than 2 years ago | (#37265358)

In their defense (and I am no fan of LISP like languages or of Guile) is that you could use Guile as a kind of common VM, with transcompilers to transform the syntax of Lua, JavaScript, Python, or whatever into Guile and be executed at runtime.

The problem is that never really happened in any kind of satisfactory way. There is a partial implementation of JavaScript, they are "working on" Lua; etc. None of the efforts have felt very satisfactory to date. And part of the reason is that a language is a lot more than syntax. Unless people are willing to port the core libraries and make sure they run well, then Python (or whatever) with a different runtime and libraries isn't going to feel right.

A far better solution (IMHO) is to do what Java and .NET do and have a common infrastructure for scripting language and then let anything that conforms to it play. So your app has a common API for exposing its internals and entry points, and then scripting can be done in any supported language. It is easier because these are VM languages, but it wouldn't be hard to do for compile languages either. Then we could use the real languages, and not some kind of simulacra...

Re:LISP? really??? really?? (1)

biodata (1981610) | more than 2 years ago | (#37265404)

The backend of http://biocyc.org/ [biocyc.org] is written in lisp AFAIK, and it's an impressive beast, connecting to and managing databases, generating graph images on the fly on the basis of query results and embedding them in lisp-driven web pages and so on, but it's the only lisp-driven heavy duty system I've ever come across.

Re:LISP? really??? really?? (0)

Anonymous Coward | more than 2 years ago | (#37265580)

Great job! You found *an* example of lisp in real-world use. Tens of thousands of applications in the world (probably more), and you managed to indeed find a real-world application that uses lisp.

Re:LISP? really??? really?? (1)

SteeldrivingJon (842919) | more than 2 years ago | (#37265586)

Back in 1994/1995, I spent some time working at Swiss Bank Corp. in Chicago. They had some older trading-related systems running on Symbolics machines.

Re:LISP? really??? really?? (1)

JasterBobaMereel (1102861) | more than 2 years ago | (#37265436)

Scheme is taught in universities, for programming language design, and is used to prototype new languages amongst many other things ...

Loads of people write in Scheme/Lisp - It's just that they have been taught properly and so do not shout for help every 5 minutes on general forums ...

It makes a very good scripting language, and data language, and general purpose language, etc ... unlike most of the alternatives this is why it was picked as the GNU extension language (note not just scripting, a fully fledged extension language)

JavaScript is a mediocre scripting language and a bad extension language
TCL is similar ...

If you want a scripting environment (like .NET) where you can use any language, then why not get someone to write an extension (in Guile) that does this, it is more than capable ...

Re:LISP? really??? really?? (1)

rubycodez (864176) | more than 2 years ago | (#37265440)

Actually, there are huge commercial uses of LISP. It is used for scheduling, modeling and rendering, CADD, and business analysis.

Examples include American Express' Authorization Assistant, Autodesk's AutoLISP for programming AutoCAD (my nemesis and love for many years), Gensym's G2 business rules engine, Marai (one of the rendering applications used for effects for Lord of the Rings), and the SPIKE scheduling system for satellites and telescopes.

Re:LISP? really??? really?? (1)

flink (18449) | more than 2 years ago | (#37265678)

Sun's eGate Integrator platform (a predecessor to JCAPS [wikimedia.org] ) used a LISP derived language called Monk as a scripting language. Of course, it's been phased out in recent versions :P

No Sarcasm: Do People Care? (2)

assertation (1255714) | more than 2 years ago | (#37265242)

No sarcasm meant, does this issue matter to more than a handful of people?

Will it matter once all of the "once ___ are done"s or will the tech world have moved onto other things?

Re:No Sarcasm: Do People Care? (1)

rubycodez (864176) | more than 2 years ago | (#37265480)

There probably are more than a thousand developers who would like a better extension language, though a LISPy one certainly would not be it

SSF Guile (1)

jbeaupre (752124) | more than 2 years ago | (#37265508)

Hey, Street Fighter matters! It just does. Now I wouldn't go with Guile necessarily, but he's good. Blanka was my preferred fighter.

Who cares? (1)

WPIDalamar (122110) | more than 2 years ago | (#37265254)

I read into these comments just to see if anybody cares.

It seems not.

If the Slashdot crowd doesn't, then why would the wider world?

You lose (0)

Anonymous Coward | more than 2 years ago | (#37265260)

Go home and be a family language!

Lisp (1)

DrXym (126579) | more than 2 years ago | (#37265300)

Proposing a Lisp dialect as the "official" extension language of GNU is a stillborn idea. It might find favour with the small fanbase of Lisp hackers but nobody else. It would make more sense to define a language neutral automation interface that any process can implement. Scripting languages would soon acquire the bindings to use it.

Re:Lisp (0)

Anonymous Coward | more than 2 years ago | (#37265484)

... It would make more sense to define a language neutral automation interface that any process can implement. Scripting languages would soon acquire the bindings to use it.

Love it or hate it, this is exactly what COM (aka ActiveX) was on Windows. Some things were hit or miss (i.e. TAPI 3), but for the most part, worked well.

Re:Lisp (1)

sourcerror (1718066) | more than 2 years ago | (#37265870)

You mean, they should use web services?

Because it's Lisp. (1)

david.given (6740) | more than 2 years ago | (#37265354)

...and Lisp is weird.

Yes, Lisp's awesome, and has got all sorts of fascinating and powerful features such as continuations and hygienic macros, but the sad fact is that it's just not accessible. Any programmer with modern training is going to be familiar with Algol languages, specifically C family languages, and is going to take one look at the incomprehensible mass of free-form parentheses that's a Lisp program and simply won't be interested.

This is one of the reasons Javascript's so successful --- although I agree with the author that it's a terrible language. Someone with C or Java training can look at Javascript and read the structure; the learning curve is shallow enough to get people hooked. Guile's learning curve starts with a cliff. Why should someone looking for an extension language pick Guile when languages like Python or Lua are available that people already know?

(As a secondary note, the LGPL's not really a very friendly license for an extension language, as it makes it hard to embed in anything that's not GPLd. I realise that the FSF is doing this deliberately to try and encourage people to write GPL software, but it is a factor affecting Guile's popularity.)

Re:Because it's Lisp. (1)

oldhack (1037484) | more than 2 years ago | (#37265470)

Lisp is not weird. It's just that it doesn't have much in the way of syntax other than "everything is a sequence of nested lists".

Re:Because it's Lisp. (1)

rokstar (865523) | more than 2 years ago | (#37265576)

Any programmer with modern training is going to be familiar with Algol languages, specifically C family languages, and is going to take one look at the incomprehensible mass of free-form parentheses that's a Lisp program and simply won't be interested.

I have modern training as a programmer which included scheme but you are likely correct in the general case. But you know what? More's the pity. Even if its not a lisp like language, programmers should be exposed to more families of languages as part of their education/training.

Re:Because it's Lisp. (0)

Anonymous Coward | more than 2 years ago | (#37265820)

Why the hate for the LGPL?
LGPL libraries can be used in any code with any license whatsoever, from public domain to baby-eating propietary.

JavaScript is weird, too (2)

alispguru (72689) | more than 2 years ago | (#37265866)

Compared to the mainstream of Java/C++, JavaScript's prototype-based OO [mozilla.org] is pretty strange.

People put up with language weirdness for two reasons:

* It's the only game in town (JavaScript and browser extension, Emacs Lisp, tcl/tk and X GUIs)
* It has something you really need/want (Lisp macros, Java JVM, C++ low-level access)

Neither of those can really be used to drive a universal GNU extension language. Wishing for it is like wishing for something to displace the x86 architecture.

Fad Languages (0)

Anonymous Coward | more than 2 years ago | (#37265424)

Out of concern that they might choose a language that would eventually die, they chose one that was already dead.

From the Guile Manual on JavaScript Support (1)

jockm (233372) | more than 2 years ago | (#37265466)

Quoting from the Guile Manual [gnu.org]

ECMAScript was not the first non-Schemey language implemented by Guile, but it was the first implemented for Guile's bytecode compiler. The goal was to support ECMAScript version 3.1, a relatively small language, but the implementor was completely irresponsible and got distracted by other things before finishing the standard library, and even some bits of the syntax. So, ECMAScript does deserve a mention in the manual, but it doesn't deserve an endorsement until its implementation is completed, perhaps by some more responsible hacker.

In the meantime, the charitable user might investigate such invocations as ,L ecmascript and cat test-suite/tests/ecmascript.test.

That is hardly a ringing endorsement...

Re:From the Guile Manual on JavaScript Support (1)

wvmarle (1070040) | more than 2 years ago | (#37265652)

So there was apparently one and only one person motivated enough to actually start hacking ECMAScript into Lisp. And after some time that person didn't have the time/interest/motivation/whatever to continue that one-man project.

Somehow even if it's a relatively small language to build a compiler for, I have the feeling that it's a bigger bite than a single hacker can chew. Especially as that hacker is doing it as a hobby project. It could have been helpful if that hacker had received some support and help with the work, instead of receiving such a negative mention in the manual. It's to me not something that would make me say "hey that's interesting, let's have a look and see whether I can help out a bit".

They should be thankful that at least someone made a serious start with it, and encourage other people to pick it up.

Scoping? Scoping?? (0)

Anonymous Coward | more than 2 years ago | (#37265524)

I like scheme, I really do. But to point to javascript's dynamic scoping as an issue is bizarre. There are advantages to the lexical scoping that scheme uses, but there are drawbacks too. Scoping models seem to be ultimately a matter of taste, not a criteria for what makes a language good.

TCL is dead? (0)

Anonymous Coward | more than 2 years ago | (#37265682)

Somebody should let these guys know so they can stop wasting their time:

http://www.tcl.tk/

From the inventor of TCL (0)

Anonymous Coward | more than 2 years ago | (#37265780)

Language designers love to argue about why this language or that language
*must* be better or worse a priori, but none of these arguments really
matter a lot. Ultimately all language issues get settled when users vote
with their feet. If Tcl makes people more productive then they will use
it; when some other language comes along that is better (or if it is
here already), then people will switch to that language. This is The
Law, and it is good. The Law says to me that Scheme (or any other Lisp
dialect) is probably not the "right" language: too many people have
voted with their feet over the last 30 years. I encourage all Tcl
dis-believers to produce the "right" language(s), make them publically
available, and let them be judged according to The Law.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?