Re: theory and practice: ying and yang

I don't mean to beat up on you, but some of the points you raise are critical and I take an apparently diametrically-opposed view.

Alexandr Savinov wrote:
> Implementations of programming languages. There exist declarative
> approaches where we make some statements but eventually we always get
> arrays (so the programming language simply hides this fact).

There's no "eventually" about it. In Java, for example, if I use a Set, I never address it as an array, or use reflection to pry the "underlying array" from inside it. The trouble with this point of view is that it's too often used as a justification to simply regress from what's needed (a set) to the more primitive array. This industry suffers some sort of addiction to being "close to the metal." Screw the metal - and that includes implementations. Our focus should, generally, be elsewhere. Simply because we occasionally have to troubleshoot implementation problems doesn't mean we should all fall back into machine code in order to see (for example) the JVM manipulating address registers.

> Yes, in the model itself we do not need to know that sets are arrays. In
> practice and in more general approaches we unfortunately need to deal
> with order of elements.

No, often we don't. When order is important, then you don't HAVE a set - you need something else. If order is important, you use an appropriate data structure. In Java, for example, I use Map and Set frequently, and often eliminate much unneeded preexisting code by converting a List to a Set, or multiple Lists to a Map, etc.

> A well known example is where we can specify a
> characteristic property of elements rather than enumerating them
> explicitly. A somewhat opposite point of view is where we need to build
> a thing or provide a *constructive* procedure for building it in order
> to consider it a legal element.

Selection of values (i.e. "construction of immutable instances") is one thing; storage / organization is quite another. On the above distinction, I think that while both are needed (some sets, like parts in my car, don't have a useful intentional definition), the former is preferable when possible.

> When I said that sets are not real I followed an approach where
> *representation* (and access) is of crucial importance. It can be viewed
> a variation of constructivism. In this approach all legal things need to
> be somehow represented.

Access primitives are usually (and usefully) at a level of abstraction higher than the representation.

> The second point then is that there is no
> mechanism for representing elements of a set (without order).

Although the representation (actually implementation) has an order, that order is hidden. If you need the order, you're not working with a set.

> If there
> is a set then there has to be some explicit or implicit order of its
> elements at some level of representation. This can be viewed as a
> fundamental property of reality where all existing things have some
> coordinates in space.

Perhaps, but there's no need to think about it, unless you're implementing a language or just philosophizing. Programming language evolution should result in a decrease in the number of things a developer has to remember, and a separation of concerns.

> Currently both approaches (declarative and procedural) are used but the
> thing is that declarative statements need to be translated into
> procedures (because declarative statements cannot be executed by
> themselves). This means that if we want to have a set we get an array
> and if we specify a criterion for selecting records then it is
> translated into a loop of some other procedure.
>
> The main problem is what approach is more natural and productive but I
> think it cannot be solved in a discussion.

"Natural" is not necessarily "productive." Naturally, I'd like to take a nap right now. Productively... well, I should be doing something else, but I'm typing this. :-)

Computers aren't natural. Where there's a tradeoff between nature and power, power is often the better choice. Where there's a choice between declarative and operational (procedural), the former is preferable.

• Eric