This quote from the comments summarizes my thoughts on this:
"Robert says:
30 August 2011 11:55 PM
It isn't whether Guile is good, bad, usable, or not usable. It is whether people will and do USE it. I have not seen that as the case for Guile or Scheme in general."
I don't know anybody anywhere who has even tried to use Guile. I don't even know if anybody I know have ever looked at it. I don't know how many people even know it exists.
I personally love Scheme as a language, but I honestly can't see myself ever investing enough time into Guile to be able to write program extensions in it. I don't see my friends (some of whom I believe would write extensions to popular open source software if they could do so in a language that is sufficiently similar to one they already know - I certainly would be a lot more likely to do so and I'm not even Lisp averse) doing so either.
"First of all, what does it mean to have a GNU system based on a non-GNU technology? What would be left of GNU?"
So pick a non-GNU language and create a GNU implementation.
Personally, I think the best choice would be Lua. Its mature, a lot of people already use it as an extension language and its very similar to a lot of popular languages, so resistance for people to learn it is low (it is reasonably similar to Javascript and to a lesser extent, Ruby and Python; also, as has been proven by the game industry, it is easy to learn for C, C++ and Java programmers. Finally, while not GNU, it has some exceptionally good implementations).
Well, I've never used Guile, but I have used Elisp, to great success. It allowed me--with little previous Elisp experience--to easily write a minor and a major mode without having to spend too much time in the manual. Given that Guile is very similar--just more modern and polished--to Elisp, I definitely see it as a reasonable extension language.
I think the issue with the limited number of extensions written in Guile is more with the projects that can be extended than with the language--I'm not aware of any that I use, and certainly none that I would like to extend.
I get the impression that the majority of emacs users are not averse to learning seemingly weird and dificult new things (otherwise you probably would not have learned to use emacs in the first place). The majority of users are, in my experience anyway, put off by all sorts of things (and often quite unrelated to the merits (or lack of) the language itself). I have also experienced quite a bit of lisp hostility. All of these things add up for me to feel there are better choices as an extension language if you want the average[1] user to write extensions.
[1] by average I mean that they have the technical skill to do so, but aren't terribly invested in learning lots of new things. I imagine (I'm a vim user myself and I find its true for me) that an emacs user has already invested in the tool enough that learning a little more to make it even more useful is not a big deal.
I can't help thinking that your average user is much less likely to write an extension at all. Also, I suspect a disproportionate number of GNU program users sufficiently invested in them to write extensions are either Emacs users already (it is Gnu Emacs, after all) or at least fairly familiar with Lisp.
The sort of person who doesn't go out of his way to learn a new tool is also the sort of person who probably doesn't go out of his way to extend an existing tool either. I think targeting advanced users for writing extensions is completely reasonable.
Plenty of "average" (by your definition) programmers who use Eclipse know Java well enough to write Eclispe plugins. How many of them do? I suspect a large portion of those who do would have written the plugins in Guile as well.
Probably not all that relevant here, but I think that Java's verbosity is a barrier to entry in itself, even if Java programmers do not think so. When I worked in a Java shop a few years ago I would have happily coded up quick extensions and scripts[1] in something like python, but never even considered doing so in Java because there was too much effort involved. I guess I'm arguing that the users must feel that the benefit of writing a script or extension must feel like its much greater than the effort of not doing so and the effort of writing the extension and that Guile is just plain too unfamiliar to most that the effort seems to outweigh the benefits, even if in reality this is not true.
[1] I did actually write a few Python scripts to generate repetitive Java code because I felt that doing so would be much less effort than writing the code by hand.
I think that one big advantage of Lua (also Python and Ruby) over Guile for extensions is that the techniques you use in Lua programming are a lot more generally applicable to writing one's own scripts and programs in the future than Guile's - not just in Lua, but also in Ruby, Python, JavaScript, Java, C#, C, and so on.
I agree. The language advocacy in the linked article is fine as far as that goes, but 17 years after the Tcl wars, it should be possible to evaluate an extension language strategy by whether it WORKS. Sure, guile is powerful and it COULD be used to build all sorts of powerful extensions, but IS it actually used that way?
I would argue that overall[1], guile has had pretty much no meaningful adoption in GNU projects. Emacs is (of course) still using its own flavor of lisp. gdb, which badly needs a powerful scripting language (and which I think was scheduled to have Tcl support when the wars started), still has no good scripting integration. I cannot think of any other major GNU project using guile.
[1] There are certainly some exceptions. Lilypond uses guile extensively and successfully.
While it's true that Guile isn't exactly pervasive as an extension language I can name two projects off the top of my head that do use it as their scripting language: LilyPond[1] and gEDA[2]. I haven't actually done anything with that capability but Guile is in use as an extension language to some degree.
Oh, I'm not arguing that its not in use - I'm arguing from the point of view of the users of the software itself (not its authors) who may want to write extensions. I feel users are unlikely to jump through hoops to write extensions to software, yet I feel that Guile creates hoops for a number of reasons, including (but certainly not limited to) an aversion to lisp (i have personally observed this), unfamiliarity compared to the users every day language, the difficulty of a functional-focused vs imperative focused language for quickly hacking an extension together and ease of obtaining documentation.
I think we agree then. The (to most people) unfamiliar syntax and programming paradigm are certainly barriers to entry. It's not what people expect and I doubt most people writing plugins for programs want to do so in unfamiliar territory.
"Robert says:
30 August 2011 11:55 PM
It isn't whether Guile is good, bad, usable, or not usable. It is whether people will and do USE it. I have not seen that as the case for Guile or Scheme in general."
I don't know anybody anywhere who has even tried to use Guile. I don't even know if anybody I know have ever looked at it. I don't know how many people even know it exists.
I personally love Scheme as a language, but I honestly can't see myself ever investing enough time into Guile to be able to write program extensions in it. I don't see my friends (some of whom I believe would write extensions to popular open source software if they could do so in a language that is sufficiently similar to one they already know - I certainly would be a lot more likely to do so and I'm not even Lisp averse) doing so either.
"First of all, what does it mean to have a GNU system based on a non-GNU technology? What would be left of GNU?"
So pick a non-GNU language and create a GNU implementation.
Personally, I think the best choice would be Lua. Its mature, a lot of people already use it as an extension language and its very similar to a lot of popular languages, so resistance for people to learn it is low (it is reasonably similar to Javascript and to a lesser extent, Ruby and Python; also, as has been proven by the game industry, it is easy to learn for C, C++ and Java programmers. Finally, while not GNU, it has some exceptionally good implementations).