From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fis Trivial Subject: Re: my latest blog post Date: Fri, 8 Jun 2018 06:18:49 +0000 Message-ID: References: <877enaimsn.fsf@fastmail.com> <87po11j46q.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46341) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fRAjf-00040c-RS for guix-devel@gnu.org; Fri, 08 Jun 2018 02:18:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fRAjc-0006Je-NZ for guix-devel@gnu.org; Fri, 08 Jun 2018 02:18:55 -0400 Received: from mail-oln040092013027.outbound.protection.outlook.com ([40.92.13.27]:45082 helo=NAM05-CO1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fRAjc-0006ID-9v for guix-devel@gnu.org; Fri, 08 Jun 2018 02:18:52 -0400 In-Reply-To: <87po11j46q.fsf@dustycloud.org> Content-Language: en-US List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Christopher Lemmer Webber Cc: "guix-devel@gnu.org" , Joshua Branson Christopher Lemmer Webber writes: > I think Catonano and Mark discussed things nicely earlier in the thread, > so I'm not going to weigh in on that (though I do agree that we would > can and should do better, but that also it's important to realize that > community members only have so many personal resources to be able to > respond sometimes). > > Guile still matters a lot to me. I think Guile has a long way to go, > but I look at it more that there is an opportunity for us to do better > than that we have failed currently. What can we do to move in the right > direction? > Hi, I have been interested in utilizing guix to make a development environment like the one offered in python. Guix can provide package management like pip, isolated environment like virtualenv and many many more. The only thing not in position is a build system that can use all this like setup tools in python. I don't have good enough knowledge to do it over day, but anyway I tried to "get started". Actually I have already wrote a little prototype that generates ninja syntax in scheme. But I uses chez scheme to run the code even I stick with r6rs. I will explain why. During the process, I bumped into some problems that I have never encountered before. One of them is that GNU's tool chain, in general, it's quite not user friendly. I didn't notice it before, but now it has becoming more and more explicit. In the case of guile, is the lack of proper error message, usable interactive debugger. I made a few attempt to improve it but I was told that it would be too difficult for me[1]. I don't have the problem with this answer, actually I was glad that someone points out the fact I need more experience so I won't waste my time. Little off topic, what I want to say is that, if I didn't tried to evaluate any code from string, how come a modern interpreter can tell me the error is happened in "unknown file" "unknown line"? Especially the "unknown file". All the error messages points to the internal of compiler, when it comes to the part that's relevant to my code, it becomes unknown. I used to believe these user related feature is well established, and would be included in any formal non-alpha version of compiler or interpreter. Please don't feel offended, I wrote this mail and the one to the guile's mailing list is because I wanted to help, not to complain. The case can be made to other parts of GNU tool chain, like in the gcc mailing list, people suggested others to use clang-tidy[2], the language server is never implemented, lacks of tutorial style documents. The failing of autotools is also an example. Even more, texinfo lacks all the merit in modern documentation facility, like code highlighting, snarfing documentation from source code, a text form that's easy to read and follow like markdown or org-mode. Emacs made an exception, I believe the rich document embedded inside various parts of Emacs and the precise and helpful information for every defined variables play an great contribution.(I especially appreciate the feature that let me jump around elisp code even the variable is defined in C source). So, in general, I believe that, if the guile project still have the desire of making some waves, user friendliness should be the first priority. Not those improvement mentioned in the manual like implementing python. Once we can get the tool chain in right position to lower the bar for new comers, implementing optional feature isn't too far away. Guile's performance and system facility is quite good in the realm of interpreted languages, based on it we can made a lots of stuff like implementing a improved scala, being an extension language like lua. But all this is based on the assumption that people can use their very limited spare time to get started (Not get it done, just get started). If you read this through, thanks for your patient and time. Best wishes. [1]: http://lists.gnu.org/archive/html/guile-devel/2018-06/msg00003.html [2]: https://gcc.gnu.org/ml/gcc/2018-05/msg00067.html