Sorry I started this thread in the wrong place in the hierarchy (as it
appears in the archive).
Thank you, Adam Spitz for your philosophical response.
In the realm of declarative programming, I have been interested in
concurrent constraints. I envision using a combination of language and
execution environment where the language proper would be purely declarative
but the environment would provide access to such facilities as fall outside
declarativity but are needed or desired for dealing with the outside world.
I'm thinking that such an approach might not clash badly with the syntax of
Self and maybe some of the other ideas related to Self.
The "slots" in an "object" might consist of a fixed label paired with a
"variable", which is a thing that could exist for part of its history as
having unknown value, but a procedure/method could constrain it to have a
particular value. Trying to constrain it in logically inconsistent ways
would be an error. I suppose part of the source of objects having slots
that haven't yet been constrained would be the aforementioned runtime
environment. Maybe an operation to create such an object would require at
least these two inputs: a pattern or prototype to give the object its known
behaviors, and an "oracle" as described by Burton and Lennart; this latter
would come from a stream of arbitrarily many oracles as needed supplied by
the magic runtime environment.
On Wed, Apr 22, 2020 at 8:38 AM Adam Spitz wrote:
> I agree that "copy and mutate" sounds like it might not be compatible with
> declarative programming, but I think there are deeper psychological
> principles that make Self worth understanding even if you don't want
> imperative programming.
> I don't know whether you've heard the prototype spiel before, and Dave and
> various others here can do it better than I can, but:
> Part of the motivation behind prototype-based languages is that when human
> beings come up with categorization systems that feel intuitive, they
> usually don't really look like "here are the properties that are shared by
> every member of this category"; they look much more like "here are some
> properties that are typically shared by the more-central members of this
> category, most of the time; membership in the category is fuzzy, and varies
> depending on how similar the thing is to the central examples of the
> category; we define things by describing how they're different from other
> things." (George Lakoff makes the case for this in Women, Fire, and
> Dangerous Things.)
> For example, here are some observations about the way humans categorize
> - A robin is a better example of a bird than an ostrich is. (Membership
> gradience - some examples are more central than others, and people
> more-readily identify the central examples as belonging to that category.)
> - Most humans have ten fingers, but a few don't, and they probably still
> qualify as human. (Family resemblances - not all properties are shared.)
> - If someone shows you a picture of a tabby cat and asks you what it is,
> you say "cat", not "animal" or "tabby". (The most cognitively-basic part of
> the abstraction hierarchy is somewhere in the middle, rather than the top
> or bottom.)
> - etc.
> (Of course, human beings also came up with the more-rigid categorization
> systems that are used in most of mathematics, and those systems still
> sorta-kinda count as categorization systems, despite not having all of the
> properties that the more-typical categorization systems have. ;))
> I'm not saying that you *can't* find some way to represent those kinds of
> qualities in a class-based language like Smalltalk or a type-theory-based
> language like Haskell; I'm just saying that these considerations are (as
> far as I've seen) not even really on the radar of people who talk about
> those languages. (Which isn't to say that Self does it perfectly. I don't
> think Self - or any other prototype-based language that I know of - fully
> captures the flavour of the categorization model that Lakoff describes. But
> Self's "you make new things by copying and modifying existing things" is
> meant to be a step in that direction. It's something that the Self people
> have spent some time thinking about.) If you buy Lakoff's theory, there's
> something in human psychology that isn't a good fit for the kinds of rigid
> categorization systems used in existing declarative languages like Haskell.
> With that said, I've spent the past few years learning about Haskell and
> functional programming and type theory and category theory and proofs and
> various other things that I used to consider icky, and I like it very much.
> I'm convinced that it's usually a very good idea to avoid imperativeness
> and mutation as much as possible, and I'm convinced that there's a huge
> amount of value in the kinds of mathematically-precise abstractions
> (functors, monads, algebraic data types, etc.) that are used in those kinds
> of languages, and I'm convinced that type systems are much much more-useful
> and less-awful than I believed back when the only typed languages I knew
> were C++ and Java. I wouldn't be happy going back to a dynamically-typed
> imperative language like Self (though I do desperately miss the Self
> environment). But I think there are some insights about human psychology
> that the Self people understand better than the Haskell people.
> I'm not sure about this part, but I don't think those psychological
> insights are fundamentally incompatible with declarative programming; I
> just think it's the kind of thing that the declarative-programming world
> hasn't spent a lot of time focusing on. So, yes, I think there's a lot in
> Self's classless outlook that could light the way toward creating a better
> declarative language.
> On Tue, Apr 21, 2020 at 11:52 PM Jack Waugh <tzh9741mq402(a)sneakemail.com>
>> As I understand it, the Self language uses imperativity all the way down
>> to its fundament. In particular, I believe the usual (and only?) way to set
>> up an object is to clone an existing one (the prototype) and then mutate
>> one clone. I don't see anything about the language, nor more generally
>> about a classless outlook, that would light the way toward creating a good
>> declarative language. Am I missing something?
>> Jack WAUGH