<story><title>Introducing GNU Guix</title><url>http://lists.gnu.org/archive/html/gnu-system-discuss/2012-11/msg00000.html</url></story><parent_chain><item><author>dhruvbird</author><text>Might as well use python because of greater?? adoption and ease of use?</text></item><item><author>josteink</author><text>&lt;i&gt;Why utilize scheme?&lt;/i&gt;&lt;p&gt;If emacs has thaught us anything, it is that when you give people a fully featured language to fool around with, things you could never imagine can start happening.&lt;p&gt;Why &lt;i&gt;not&lt;/i&gt; scheme? It&apos;s liberally licensed and already has mind-share. It&apos;s a simple, no fuzz language with little obfuscating magic and great expressive power.&lt;p&gt;It allows you to build your solutions as bare-bones as you like or go on full architect should you need to. Sounds like just what the doctor ordered.</text></item><item><author>nwmcsween</author><text>It seems everyone reinvents package management poorly again and again. Some things that obviously stand out to me:&lt;p&gt;* Why utilize scheme? It&apos;s declaritive utilize a markup like yaml, don&apos;t go off the deep end because you can.&lt;p&gt;* Utilize OS specific features such as jails, bind mounts, namespaces, you can have the same NIX style separation without destroying FHS.&lt;p&gt;* Parse the config files for options, it&apos;s easy cmake, autocrap, etc all have parsable formatting this way you don&apos;t need to mess with adding build time options.&lt;p&gt;* Parse the source for dependencies, there are lots of white papers of people doing this and beating human made spec files.&lt;p&gt;* Utilize machine learning for classification of options, dependency resolution (utilizing previous data).</text></item></parent_chain><comment><author>sparkie</author><text>Packages are mostly just declarations of how you want a package to be built/installed, but sometimes they require additional logic or computation. Using python would require a separate file format to put definitions into (e.g, YAML), and those definitions would need a rigid schema and versioning system. Some existing package managers take this approach, but what happens when you need a feature that doesn&apos;t exist in the declarative schema? You would need to extend the YAML format and bump the version numbers to allow your new features.&lt;p&gt;On the other hand, a LISP does not need a distinction between a declarative format and the computation language itself - it does both in a consistent syntax. (Homoiconicity is the term). It makes it much simpler to mix your declarations and computations, alleviating much of the need for a rigid specification on package definitions.&lt;p&gt;If you look at places where the former system is used, you&apos;ll find they usually age pretty quickly - or have many version increments because the original design omitted features people wanted in their package definitions. In effect, this leads to standards proliferation, because people invent new systems when the existing ones don&apos;t do what they need. Rather than trying to second guess the features people might need, it can be easier to just give them the ability to add them when they want.&lt;p&gt;A recent example of the former system is this project from GNOME: &lt;a href=&quot;https://live.gnome.org/BuilDj&quot; rel=&quot;nofollow&quot;&gt;https://live.gnome.org/BuilDj&lt;/a&gt;. If you look at what it&apos;s trying to do, it really just wants to reinvent makefiles in YAML. A clear example of NIH, which will fail because as soon as someone needs to do something which their YAML schema doesn&apos;t support, it&apos;s a useless tool.</text></comment>
<story><title>Introducing GNU Guix</title><url>http://lists.gnu.org/archive/html/gnu-system-discuss/2012-11/msg00000.html</url></story><parent_chain><item><author>dhruvbird</author><text>Might as well use python because of greater?? adoption and ease of use?</text></item><item><author>josteink</author><text>&lt;i&gt;Why utilize scheme?&lt;/i&gt;&lt;p&gt;If emacs has thaught us anything, it is that when you give people a fully featured language to fool around with, things you could never imagine can start happening.&lt;p&gt;Why &lt;i&gt;not&lt;/i&gt; scheme? It&apos;s liberally licensed and already has mind-share. It&apos;s a simple, no fuzz language with little obfuscating magic and great expressive power.&lt;p&gt;It allows you to build your solutions as bare-bones as you like or go on full architect should you need to. Sounds like just what the doctor ordered.</text></item><item><author>nwmcsween</author><text>It seems everyone reinvents package management poorly again and again. Some things that obviously stand out to me:&lt;p&gt;* Why utilize scheme? It&apos;s declaritive utilize a markup like yaml, don&apos;t go off the deep end because you can.&lt;p&gt;* Utilize OS specific features such as jails, bind mounts, namespaces, you can have the same NIX style separation without destroying FHS.&lt;p&gt;* Parse the config files for options, it&apos;s easy cmake, autocrap, etc all have parsable formatting this way you don&apos;t need to mess with adding build time options.&lt;p&gt;* Parse the source for dependencies, there are lots of white papers of people doing this and beating human made spec files.&lt;p&gt;* Utilize machine learning for classification of options, dependency resolution (utilizing previous data).</text></item></parent_chain><comment><author>josteink</author><text>Not to start a flame-war, but I would argue that Python is not as fully featured as a LISP language-wise.&lt;p&gt;And as far as LISPs go, Scheme is extremely simplistic and friendly.</text></comment>