Re: my latest blog post

[Fis Trivial]

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