unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Christopher Allan Webber <cwebber@dustycloud.org>
To: Cecil McGregor <trailingdots@gmail.com>
Cc: guile-user@gnu.org
Subject: Re: guile-user Digest, Vol 171, Issue 14
Date: Tue, 14 Feb 2017 13:19:23 -0600	[thread overview]
Message-ID: <87vasc4m2s.fsf@dustycloud.org> (raw)
In-Reply-To: <CAAOdWZAAne_bz8RDie-DD+6wBd8TSGKVm_XspOxq7KO=2Lkk9Q@mail.gmail.com>

Cecil McGregor writes:

> My first problem lies in the lack of a decent debugger.  (I can hear
> the screams of more enlightened Guilers already!) The stack traces
> seldom provide filenames and line numbers to hint where a problem
> might hide.  While I've read advice to allow the appearance of
> filenames/line numbers, I still can't seem to consistently find these
> in a stack trace.
>
> I would really like the filename/line number to appear in a stack
> trace with the actual source code and not some partially opaque macro
> expansion.

Usually I find the debugger to be quite good in giving exactly the right
line, so your experience doesn't match mine.  I've also found that it
provides quite a few tools that I haven't found much anywhere else; the
debugging trap infrastructure and etc are a dream to work with.
(Sometimes some lines are lost in the call stack though due to Guile's
compiler's optimizing code... I hear that can be disabled but I haven't
tried it.)

> Then there is the matter of a good code coverage tool. Having
> experienced the benefits of TDD, Test Driven Development, I insist on
> good coverage when I develop in NodeJS and python. I really need to
> know that all my code has been tested.

Good news, Guile includes a testing module.  It could be better
integrated, and guile-lib apparently includes extendsions, but I unit
test my Guile libraries / programs.

> Has anyone followed up on the SICP classes and asked why scheme was
> not more popular?  Was it so unpopular that the students took up
> C/C++/Java instead? SICP uses a "portable" form of Scheme that
> apparently works with almost any Scheme implementation. SICP doesn't
> deal with messy system issues or implementing larger projects. Small
> programs such as SICP offers does not require serious debugging. As
> programs become systems the necessity of serious debugging rears an
> ugly side.

SICP's goal is to teach you how to understand the foundations of
computer science, not as much to write code as you would in
"production".

And in fact the best reason why SICP hasn't turned into real world
production programmers probably comes from one of the co-authors, Gerald
Sussman (or a relayed anecdote), on why MIT moved away from SICP as its
core book:

  https://cemerick.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program/

In short, the world has shifted to one where understanding computer
science fundamentals is less critical to getting code out the door than
to understand how to hook together a large set of prebuilt libraries.  I
would say for the first decade of my programming career, this is how I
programmed, and I did fine.  Python has so many of the tools you want
and you can just hook them together like legos, and it's a delight.

SICP still provides something valuable though.  Joining the Guile
community and reading SICP and other lispy books like The Little Schemer
have transformed me as a programmer.  Not everyone needs to do it, but
there you go.  I think we should have more introductory resources that
aren't as CS theory based, but SICP deserves the love it gets.

There's much that we can learn from Python and etc, and I think many of
us want to allow Guile to fill that role too.  Anyone who was there for
FOSDEM this (or last!) year knows what an energized group of people
constitutes this community and how much we want to improve it.

> (Yes, there are holes and exceptions in the above.  Flames to
> /dev/null.)

TBH, I found your post to be a bit flamey and combative itself, which is
unfortunate, and I know it bummed some others out too.  Maybe you did
not mean it that way, but there it goes.  Keep in mind that a lot of
people on this list care about Guile a lot, and in my experience are
extremely open to constructive criticism.  But let's keep it
constructive and positive.  We want to make Guile better and too much
negative energy can make that hard.

Indeed, if you pay close attention to Guile over the last couple of
years, I would say that it *has* been getting better by leaps and
bounds.  There's still much of ways to go!  But if we can stay
energized, we can get there.

Stay positive, and let's build Guile into something great!
 - Chris



  reply	other threads:[~2017-02-14 19:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.52572.1487077879.22737.guile-user@gnu.org>
2017-02-14 17:24 ` guile-user Digest, Vol 171, Issue 14 Cecil McGregor
2017-02-14 19:19   ` Christopher Allan Webber [this message]
2017-02-14 22:00   ` Amirouche
2017-02-14 22:16   ` Stack traces Ludovic Courtès
2017-02-15 15:36     ` Christopher Allan Webber
2017-02-16  1:10       ` Matt Wette
2017-02-18  0:13       ` Matt Wette
2017-02-18 15:50         ` Amirouche
2017-02-18 15:53           ` Amirouche
2017-02-18 16:58             ` Matt Wette
2017-02-18 19:59               ` Amirouche
2017-02-18 20:31                 ` Matt Wette
2017-02-27 20:23                 ` Andy Wingo
2017-02-27 20:40                   ` Amirouche
2017-05-18 13:38                     ` Christopher Allan Webber
2017-05-19  3:05                       ` Matt Wette
2017-05-19  9:17                       ` Andy Wingo
2017-06-10  9:58                       ` Catonano

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://www.gnu.org/software/guile/

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

  git send-email \
    --in-reply-to=87vasc4m2s.fsf@dustycloud.org \
    --to=cwebber@dustycloud.org \
    --cc=guile-user@gnu.org \
    --cc=trailingdots@gmail.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.
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).