Arne Babenhauserheide <arne_...@web.de>:
> Marko Rauhamaa <ma...@pacujo.net> writes:
>> Then, there's GOOPS, which in my opinion is simply an unnatural way
>> to go about object-oriented programming. It does violence both to
>> ordinary OO way of thinking and classic Lisp idioms.
>
> GOOPS works pretty well for me where I use it (for dispatch by type).
> Could you clarify your criticism: Do you think it is bad or is it just
> different?
GOOPS starts by defining slots. Slots are an objects internal business
and should not be visible to the outside. Instead, objects should be
black boxes that interact with methods. For example, the port interface
is a nice, classic OO API. You don't know anything about the slots of a
port.
Furthermore, I think an extensive type system is un-Lisp-like. OO is not
about things belonging to a type but objects interacting through
methods. In fact, the concept of a "class" could be done away with.
>> Continuations and multiple values are obstacles instead of enablers.
>
> I think multiple values are nice. But they are not well-integrated (I
> have to import something to use them). Why do you think them enablers?
Yes, the multiple values API is a problem in and of itself, but more
generally, what does:
(values a b c)
give you on top of, say:
(list a b c)
> Why do you think that continuations are an obstacle (do you mean
> general continuations or do you mean prompts)?
Continuations prevent you from implementing Python's try/finally and
emacs' (unwind-protect).
On the other hand, I don't think any application developer would come to
a point of thinking, "Hey, I know, I'll use a continuation!"
>> asyncio, type annotation,
>
> type annotations should provide nice ways to optimize for pypy and
> other more optimizing Python implementations.
You can't have it bothways. A dynamic language liberates you from
shackles and boilerplate even if it destroys your performance. The
moment you bring in the boilerplate, you are back to Java.
> Decorators are really cool to use:
Have yet to find a need for one.
>> dunder jungle,
>
> What’s that?
<URL: https://docs.python.org/3/genindex-_.html>
>> meta-object programming,
>
> That’s needed to make some things elegant. "Different 20%"-rule again.
Again, I haven't yet found a need to deviate from the regular object
semantics.
>> Unicode illusion. (Guile has fallen into that last trap as well,
>> unfortunately.)
>
> I’m using Python and Guile for physics and math (to some degree), and
> having good Unicode-support is great for that. What’s your practical
> criticism here?
In Linux, all pathnames, files, sockets, environment variables and
command-line arguments are, or deal with, bytes. The bytes are often
encoded with UTF-8, but a programming language cannot assume that, even
if LOCALE promises otherwise.
It would be better to leave Unicode out of Guile's system interface and
have the application encode and decode explicitly where needed.
>> There's one thing Python has over Guile, still: Python's system call
>> support is outstanding. For example, I managed to implement a
>> full-blown shell using Python. That was the first time I ever ran
>> into terminal-related system calls, and Python had them all.
>
> Which ones are missing in Guile?
For example tcgetattr(3). (Ok, not a system call.)
Missing epoll(2) is inconvenient. Not being able to transfer an open
file descriptor via sendmsg(2) is really bad.
Marko
