Looking on the outside it looks like its a decent Scheme and the problem is lack of use and adoption (like in Emacs). Is that a correct assessment, or is the lack of adoption caused by issues with the implementation itself?
Or am I just all wrong about the state of Guile itself, and it's quite widely adopted, just that nobody speaks too much about it?
The Scheme philosophy, which was developed in opposition to batteries-included aka "bloated" Common Lisp, was to have a small core and emphasize simplicity, purity, etc. For years proponents of Scheme have emphasized how beautiful and simple the small standard of 50 pages is, compared with Common Lisps "bloated" 1000+ pages standard.
This had two consequences:
1. It was extremely easy to write a scheme implementation, soinstead of writing code _in_ scheme, people wrote _schemes_. Hundreds of them. And while other people spent the last 20 years writing thousands of useful libraries in C, python, java, scheme implementors spent reinventing the wheel, over and over and over and over again. Today there are more implementations of scheme than libraries in scheme.
2. The emphasis on "small core" might be cute for teaching SICP, but in order to be able to do anything useful with the implementation, it forced the implementors to reinvent the wheels for everything else. And each implementation did it their own way because standardization was considered "selling out" and aping the nemesis Common Lisp. This led to _extreme_ code unportability.
Nowadays they are somehow trying to standardize, but with the consequence that they are realizing that by doing that, they are becoming indistinguishable from their old nemesis Common Lisp, which went through the same balkanization phase 20 years ago, so the point of splitting off Scheme from Lisp is becoming questionable. Instead of wasting precious time writing 1001 scheme implementations, they could have spent the last 20 years writing useful common lisp libraries and competing with other batteries-included languages like java and python.
In short: Besides the social problems that every Scheme suffers from and the Lisp world suffered during the 80s, Guile on its own is doing quite well. Once it is integrated into Emacs, Emacs will become Guile's killer app, boost its popularity and set it apart from other schemes.
(There is one more problem I have with Scheme, which is the name. It sounds identical to a vulgar Turkish word for "my penis"; resulting in awkward situations when talking about the language in Turkey, where I live. :))
edit:
- the Turkish word
+ a vulgar Turkish wordIsn't this what SFRI 9 is?
Click the speaker button on the bottom left of the text box to listen:
http://translate.google.com/#en/fr/scheme http://translate.google.com/#tr/fr/sikim
They have distinctly different pronunciations.
Do you say Sch-eme or Sk-eme? I think both are ok, but please correct me if you are a native english speaker.
One might think that the similarity is so vague, that wouldn't pose a problem to speak it out loud. I, personally never recognised the similarity, until I spoke the word out loud.
[1] http://www.turkishdictionary.net/?word=sik
[2] Turkish is slightly similar to Latin.
edit: add a newline between footnotes
Also, at least IIRC, at one point in time you could "check in, but never leave" to hotel Guile from C code. Once you called the Guile function, you pretty much handed off control. Or something like that, my memory is a bit fuzzy.
Here we go:
https://www.gnu.org/software/guile/docs/docs-1.6/guile-ref/S...
So embedding Guile in something like Apache was tricky. IIRC, this is done so that Guile can GC stuff on the C stack by walking backwards and examining it.
(Edit is -> was)
http://www.gnu.org/software/guile/manual/html_node/Guile-Ini...
If the culture is to GPL lots of libraries and projects, well that scares me away.
You say that like Guile becoming the Emacs Lisp runtime is a foregone conclusion. It's not. The Emacs Lisp interpreter is so tightly bound to the C core (which uses lisp primitives for error handling, memory allocation, and data storage) that ripping it would involve massive modifications to large parts of that core.
Even if Guile were included in Emacs, it would be running Emacs Lisp almost all the time, not Scheme. Elisp, being a Lisp-2, is much closer to Common Lisp than it is to Scheme, and the recent integration of the cl-lib package has brought it even closer. We even have a CLOS workalike.
Embedding Guile in Emacs is a waste of time and energy. There are many desperately needed features in Emacs, and implementing them isn't going to be any easier after rebasing the runtime. No, being able to write code in JavaScript or Scheme isn't going to make things easier. It'll make things harder due to language fragmentation and impedance mismatches between the various languages.
https://www.gnu.org/software/guile/gnu-guile-projects.html
That being said, most languages need some form of dependency management, and this story has yet to see an ending in Guile. People continue work on one called Guildhall, but it is not yet complete.
http://wingolog.org/archives/2011/07/04/guile-2-0-2-building...
I tried deploying on my Arch Linux laptop, and encountered some issues. I also thought it would be cool to try Guile and GNOME for quick apps, but without dependency managers and incomplete documentation, it is hard for me as I am, if I can toot my own horn, a low-intermediate Linux user and a very novice Scheme student.
So long story short: toolchain and documentation are not there yet. I continue to hope because it is still cool.
Also, check this blog. I and others mentioned it. It is very cool and gives you very deep technical insight from a Guile maintainer into all the hard work being put into its core improvements.
In short, it is no Lua (or really Lua+LuaJIT), but it might be there one day.
Guix is really the killer app that will push Guile forwards, and towards realizing Guile for it was originally meant to be - an extension language for the GNU system. DMD is also being developed in Guile as part of the GNU system - to allow for dependency based daemon initialization without completely invading your system like certain others.
I don't see Guile as a candidate for merely "tacking onto" existing apps like you typically do with Lua, but as more of an integrated part of a dynamically configurable operating system, much like emacs but for the whole system.
Maybe I am the last of the Linux kids using Stow, and I like it because it makes me worry less about source installations on my computer. It would be great to see Guix build on this idea. As much as I would love to transition to a new Linux distro, I would love even more having a ~/guix or ~/.guix path with different builds. If I really mess up my computer, I can delete this folder and all those binaries and the appropriate symlinks go away.
This is what worries me about NixOS. Eventually with Stow NixOS, and other declarative package management you hit a little where you cannot outhink your dependenices. If your root is nixos and everything else is symlinked, that sounds hard for a mere mortal like me to debug.
It's also gonna be pretty hard to screw up your computer too, since multiple versions of software can be installed without problems, and you can perform safe rollbacks. The store is read-only and shouldn't be hard deleted by mortals anyway, but you should perform all the deletions through nix/guix.
The advantage of building an OS out of nix/guix is that you generally don't want to perform any kind of change to a system which is not reproducible (ie, no "hidden knowledge" that went into configuring a system) - so that if your system does ever break due to some unforeseen circumstances, you have a declarative configuration of the system in its entirety before it broke, and you can rebuild the system in a few commands.
It's probably worth abandoning the idea that applications (or symlinks) should go into /usr/bin or anywhere else - the need for symlinks exists mostly for compatibility, but from the POV of a package or configuration, you should only refer to a specific identity of a derivation in the store.
For example, if I wanted a shortcut of say, emacs on my desktop - I could have a "desktop_icons.scm" package in which I define them - and rather than pointing to some /usr/bin/emacs, I would point to some "emacs" variable (referring to a specific version) imported from the emacs package, and append the relative bin path. Then if I change the version "emacs" points to, the desktop icon will be updated too.
Lua and Guile have different use cases. Typically, Lua is embedded in an application. With Guile, you can still embed, but it's not really the best way to do things. It's much better to write your application as a shared library that Guile can load and thus extend Guile. Even better is to write your application in pure Guile, using the C FFI when needed.
From the website (http://gnu.org/s/guile):
"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. And Guile's tools for parsing and compiling are exposed as part of its standard module set, so support for additional languages can be added without writing a single line of C."
That's how I usually use Lua.