guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: out-of-control GC


From: Linas Vepstas
Subject: Re: out-of-control GC
Date: Thu, 14 Sep 2017 15:15:17 -0500

Hi Marko, long off-topic reply about the nature of programming languages.

On Thu, Sep 14, 2017 at 1:58 PM, Marko Rauhamaa <address@hidden> wrote:

> Linas Vepstas <address@hidden>:
>
> > Well that's a can of worms. Aside from static typing to benefit the
> > compiler, there's static typing to help the programmer understand what
> > the heck is being passed as an argument to some poorly documented,
> > overly-long function. This has always been a kind-of bugaboo of
> > reading other people's scheme code -- its too often too hard to
> > understand.
> >
> > This is also why python is popular: any shmo feels they can code in
> > it; its the new visual-basic of the 21st century, with all of the
> > culture and code-quality that implies.
>
> I strongly disagree. Python is popular because its level of abstraction
> is optimal for a whole slew of use cases. I see no reason why Scheme
> couldn't surpass Python some day in the future for the same reason.
>

What would that leve of abstraction be?  Racket, ex PLT/scheme seems to
have taken steps in that direction; I can't tell if they've been successful
at this. Should guile move in that direction?

>
> Not everybody can write software in good style. In fact, in my
> experience very few programmers can do it. That is not a property of the
> programming language.
>

Perhaps.  Back in the day, when young programmers were learning C++ for the
first time, they felt obligated to use each of the nifty new tricks they
just learned: multiple inheritance, overloaded operators, virtual methods,
virtual base classes, templates: not just use, but abuse these, even when
something simpler was available.  It was like working with quick-set
concrete: after the code was written, it seemed like it was impossible to
make any significant changes to it that would even compile, much less do
the right thing.  This kind of code was hard to read cause it was badly
written.

Sometimes, with scheme, I get the sense that if you haven't read SICP you
can't understand what the code does: that you can't understand the code
cause it's well-written.


>
> Static type declarations have undeniable quality benefits, but in my
> experience the noise they introduce is also a quality problem. One of
> the prime quality boosters for high-level programming languages is the
> clear but concise expressivity. You can see the forest for the trees.
>

Speaking of SICP -- one of the early examples they have there is for
working with 2D numeric data, and using either (x,y) under the covers, or
using (r,theta). Which is all very spiffy, except that, for the user who
just glances at the function signature, its not clear exactly what that
function was expecting to get as arguments.

Somehow, that doesn't happen in Python, even in it's current untyped state.
But I cannot put my finger on it, its a gut-sense thing.

>
> > For a certain class of problems, coding in python simply doesn't work:
> > graph data structures are naturally recursive and functional; they're
> > a natural fit for scheme, and are hard/painful/nearly impossible to
> > manipulate in python.
>
> I don't see that.
>

Hmm. I have C++ code with guile, cython and haskell bindings.  It is used
to work with data structures that resemble json-like nested, recursive
tree-structures.  By json-like I mean they are trees, with various
different types at the vertexes.  A graph (directed or non-directed, with
loops in general) is specified by specifying the various trees that partly
span the graph.   I kind of wish I had javascript bindings for this thing,
but can't figure out how.

The guile bindings for this are very elegant, and are about as readable as
json is.  The python bindings are real clunkers -- they're much more
verbose, by factors of 3x to 5x,  To add injury to insult, the insanely
stupid python whitespace rules means that it is impossible to indent them
into the natural tree structure that they naturally "want" to have.

Perhaps our python bindings are mis-designed. They were created by a python
fanatic to be "pythonic" which I think means "I don't know how to code"
:-(   Our guile bindings are also mis-designed (by me), I regret many of
the decisions I made... but they're still nicer than the python...


> The greatest benefit of Scheme (and other Lisps) is the data/code
> unification. All code is data and all data is code. Apart from that,
> Python has adopted almost everything from Lisp. Now, Scheme and Lisp
> famously allow you to expand the language syntax dynamically, but I'd
> say you most often shouldn't use that power. Good Scheme code embraces
> the lambda and leaves ad-hoc syntax aside.
>

Since we are off-topic, I want to mention two things that scheme doesn't
have that I'm supremely interested in.  Of course, it would not be scheme,
any more, once these were added, but these are things important for some
unspecified future.

One is a knowledge-representation language subset.  Something like the
datalog subset of prolog, or something like SQL: some subset of scheme that
can be manipulated and queried and persisted to a file.  Think pattern
matching .. but not the current anemic, super-simplistic model used in
scheme, but something full-featured, like SQL. Applied not to tables, but
to s-exps.

Another neato trick would be some kind of term-rewriting system.  Something
kind-of-ish like the scheme macro subsystem, but instead, the macros could
be invoked repeatedly, ad infinitum, on arbitrary data, instead of just
once on fixed data.  Again, kind-of-like SQL query statements: you can
re-use them over and over, even as the table of data underneath it all
changes. Pattern-matching, all grown up.

If you had these two, you've have a graph DB that far exceeded what the
tinkerpop folks can do. and with it being scheme ... or at least s-exps ...

--linas



>
>
> Marko
>



-- 
*"The problem is not that artificial intelligence will get too smart and
take over the world," computer scientist Pedro Domingos writes, "the
problem is that it's too stupid and already has." *


reply via email to

[Prev in Thread] Current Thread [Next in Thread]