unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Fis Trivial <ybbs.daans@hotmail.com>
To: Christopher Lemmer Webber <cwebber@dustycloud.org>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>,
	Joshua Branson <jbranso@fastmail.com>
Subject: Re: my latest blog post
Date: Fri, 8 Jun 2018 06:18:49 +0000	[thread overview]
Message-ID: <SN1PR16MB05119750F557C0C51A25BB8B927B0@SN1PR16MB0511.namprd16.prod.outlook.com> (raw)
In-Reply-To: <87po11j46q.fsf@dustycloud.org>


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

  reply	other threads:[~2018-06-08  6:18 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-07 15:25 my latest blog post Catonano
2018-06-07 16:28 ` Joshua Branson
2018-06-08  4:24   ` Christopher Lemmer Webber
2018-06-08  6:18     ` Fis Trivial [this message]
2018-06-08 14:02       ` Ricardo Wurmus
2018-06-08  8:25     ` Catonano
2018-06-08 13:51       ` Fis Trivial
2018-06-08 14:25       ` Ricardo Wurmus
2018-06-09  7:47         ` Catonano
2018-06-09 12:24           ` Ricardo Wurmus
2018-06-09 13:07             ` Catonano
2018-06-09 15:29               ` Christopher Lemmer Webber
2018-06-09 13:51             ` Christopher Lemmer Webber
2018-06-07 17:03 ` Mark H Weaver
2018-06-07 19:40   ` Catonano
2018-06-08  9:39     ` Nils Gillmann
2018-06-08  9:45       ` Catonano
2018-06-08 18:05     ` Mark H Weaver
2018-06-09  7:00       ` Catonano
2018-06-09 10:39         ` Ricardo Wurmus
2018-06-09 10:52           ` Catonano
2018-06-09 12:14             ` Ricardo Wurmus
2018-06-09 13:03               ` Catonano
2018-06-10 10:53         ` Mark H Weaver
2018-06-07 18:11 ` Thorsten Wilms
2018-06-07 21:45 ` Alex Vong
2018-06-08  9:15 ` Julien Lepiller
2018-06-08  9:34   ` Clément Lassieur
2018-06-08  9:45     ` Julien Lepiller
2018-06-08 13:50   ` Widen info Oleg Pykhalov
2018-06-08 13:59     ` Julien Lepiller
2018-06-08 13:49 ` my latest blog post Ludovic Courtès
2018-06-09  5:59   ` Catonano
2018-06-09 22:49 ` myglc2
2018-06-10  0:51   ` Mark H Weaver
2018-06-10  6:55     ` Pjotr Prins
2018-06-10  9:07       ` Catonano
2018-06-10  9:29         ` Ricardo Wurmus
2018-06-10  9:30           ` Catonano
2018-06-10 10:37             ` Ricardo Wurmus
2018-06-10 10:45         ` Mark H Weaver
2018-06-10 12:06         ` Pjotr Prins
2018-06-10  7:58     ` Catonano
2018-06-10  9:26       ` Ricardo Wurmus
2018-06-10  9:27         ` Catonano
2018-06-10 19:13           ` Ludovic Courtès
2018-06-10  8:07   ` Catonano
2018-06-10 19:23     ` Ludovic Courtès
2018-06-10  8:17 ` my latest blog post [everyone, please take a cooldown break] Nils Gillmann
2018-06-10 13:33   ` Christopher Lemmer Webber
2018-06-10 14:18     ` Gábor Boskovits
2018-06-10 14:37       ` Kei Kebreau
2018-06-11  6:01         ` swedebugia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SN1PR16MB05119750F557C0C51A25BB8B927B0@SN1PR16MB0511.namprd16.prod.outlook.com \
    --to=ybbs.daans@hotmail.com \
    --cc=cwebber@dustycloud.org \
    --cc=guix-devel@gnu.org \
    --cc=jbranso@fastmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).