Thoughts about "Compile-time types" talk

[Ola Fosheim Grøstad]

On Friday, 17 May 2019 at 16:35:16 UTC, Alex wrote:
>
> We must have different concepts of abstraction.

Well, if you are talking about abstraction mechanisms that 
languages provide then I kinda get you.

But in general abstraction starts with modelling. One does this 
best with pencil and paper, no need for a fixed theoretical 
framework. What one can benefit from is experience with various 
modelling techniques, or just experience. The most important 
aspect of this, in the beginning is to build intuition, which is 
modelling, albeit a fuzzy and "emotional" model.

> What abstraction does is allow for symbolic representation of 
> complex processes.

Simplified representation, usually. So, it is a view or an 
interpretation of reality, but not actually a true representation 
of reality.

> A oop hierarchy is an abstraction as is a struct.

Not quite.  You start with object oriented modelling, then you 
pick a set of tools that lets you implement the model, and 
possibly evolve it over time. That is the real purpose of OOP, to 
enable the implementation of a model and to make it maintainable. 
Keep in mind that Nygaard and Dahl created Simula for doing 
simulations. It provided a set of mechanism to enable that such 
as coroutines, block prefixing, class main program with an inner 
injection point (IIRC) and class inheritance with virtual 
functions.

So, the abstraction (of reality) is the model. The OOP mechanisms 
are mechanisms for implementing the model.

> You cannot abstract in masm because masm does not have language 
> capabilities to abstract.

I don't know about masm, but there is no problem implementing an 
OO model in machine language or C.

> everything is logic. Even a baby playing is an abstraction of 
> logic because neurons that fire in the baby's brain are just

No, you are modelling a baby using logic, that model is the 
abstraction, the baby is reality.

> The point is that we humans see the world in abstraction. There 
> are no lines in the world. A cup of water IS an abstraction.

Yes, we create models of reality in our heads and classify parts 
of reality that we have segmented into objects. Our visual system 
has that in part hardcoded.

So yes, everything that isn't the signal of a sensing cell is an 
interpretation that is turned into a model.

> But I've only went in one direction. All that stuff was built 
> up from the most concrete to the most abstract in reality by 
> humans. Humans NEVER build from the abstract to the concrete, 
> it doesn't even make sense to do so(we can specialize 
> abstractions but but all abstractions start out as less 
> abstract things).

That's not quite true. Say, an artist can start by drawing a 
circle, then put two more circles within that circle and then 
gradually refine it into a face. You can do the same with 
programming.

Also, in genetic programming there isn't necessarily programming 
level abstraction in play, except for the fitness function 
(measuring degree of success). It could be viewed as a  
randomized  search within a technical architecture (that 
implements a low level model, that model is an abstraction of 
what happens in the hardware). But it might not be fruitful to 
view the mechanisms as abstractions, since they are not 
approached as such. Thus abstraction is something that is in our 
heads, in our model, something entirely subjective. Although some 
might argue that programmers have an inter-subjective model of 
the programming field.

But it is not like all programmers view or use the same 
constructs for the same purposes.

So a programming construct has the potential to be used to 
implement a model (an abstraction), but the meaning of how the 
construct was used depends on the individual programmer.

> OOP allowed one to write far more complex programs SOLELY 
> because it allowed one to abstract the bits and pieces and the 
> abstraction allows the human mind to understand it.

Mostly by making programs more maintainable and easier to evolve. 
Of course, the availability of OO mechanisms in languages created 
a market for OO modelling techniques. So yes, more people started 
modelling differently because of the availability. However, the 
modelling should happen before you program...

> abstraction is in everything. Mathematics is all about 
> abstraction.

Well, that is one interpretation.

Another one is that it just is a space of possible symbolic 
models that one (try to) prove to be internally consistent. Then 
you can try to do abstractions over the interpretation of the 
symbolic models and come up with concepts like rings, groups etc. 
The school math is one particular version, but there are 
infinitely many others available... perhaps not useful or 
interesting, but they are available, you just have to define 
them. No real abstraction in that. It could be viewed as 
uninterpreted symbolic machinery. Doesn't have to represent 
anything in particular. That is of course unusual, but that 
doesn't mean that you cannot do it.

> We start with the integers and get the rationals, the rationals 
> were abstracted to the reals, the reals to the complex, and 
> then one gets more such as padics, quaternions, and then 
> vectors come out of and then tensors out of vectors...

Yes, but those are interpretations or rather, the model that you 
map over to the symbolic machinery. So you have a mapping from 
your model to something more concrete.

> OOP is simply the ability to abstract. Inheritance is 
> abstraction. When one inherits from a class they are 
> generalizing or abstracting that class. It's very powerful when 
> you had no ability to do this before(C).

No. OO-modelling is a tool for abstraction. Inheritance is a 
relationship that is in the model. When you inherit you 
specialize the more abstract super class. The superclass is more 
abstract because it lacks more information about the phenomon 
(reality) being modelled than the subclass. So the subclass 
contains more details, and closer reflects the properties of 
reality than the superclass.

However, the language constructs are just tools that provide 
machinery for implementing the model. Just like the symbolic 
machinery of logic is a tool for implementing integers and 
operations over integers in math. You can have many different 
symbolic implementations of integers. Right? Unfortunately, in 
math people might say that a specific symbolic representation is 
a model of integer. Whereas in computer-terminology "integer" 
would be the model and the representation would be the 
implementation.

> Ultimately it has nothing to do with specific languages except 
> that they provide examples of where we are at in the process of 
> all this.

Well, the whole is greater than the sum of the individual parts, 
so what really does make a difference is how everything work 
together. That includes the IDE and different tools for 
interactive code analysis.

> If you understand all that then what I'm saying is that 
> category theory IS the theory of abstraction

There is no doubt that it is A theory of abstraction...

> Of course, if one abstracts too much one arrives a singular 
> point! Which turns out to be quite powerful! ;)

The problem with abstraction is that one deliberately (or 
mistakenly) ignores information, that is true.