Thoughts about "Compile-time types" talk

[Alex]

On Friday, 17 May 2019 at 15:02:51 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 17 May 2019 at 14:33:59 UTC, Alex wrote:
>> All I will say about this is that all the different 
>> programming languages are just different expressions of the 
>> same. No matter how different they seem, they all attempt to 
>> accomplish the same. In mathematics, it has been found that 
>> all the different branches are identical and just look 
>> different because the "inventors" approaches it from different 
>> angles with different intents and experiences.
>
> Not exactly sure what you are talking about here, if you are 
> thinking about Turing Machines then that is sort of a misnomer 
> as that only deals with the possibility of writing 
> batch-programs that computes the same result. It doesn't say if 
> it is feasible to actually do it with a real world programmer. 
> In terms of applied programming languages are very different 
> once we move outside of imperative languages.
>
>> Everything you describe is simply mathematical logic 
>> implemented using different syntactical and semantical 
>> constructs that all reduce to the same underlying boolean 
>> logic.
>
> Not really. If you limit the input and output to fixed sizes 
> then all programs can be implemented boolean expressions.  
> However, that is not what we are talking about here. We are 
> talking about modelling and type systems.
>
>> We already have general theorem solving languages and any 
>> compiler is a theorem solver because all programs are theorems.
>
> Usually not. Almost all compiled real world programs defer 
> resolution to runtime, thus they have a solver that is too 
> weak. Compiler do as much as they can, then they emit runtime 
> checks (or programs are simply left incorrect and crashes 
> occationally at runtime).
>
>> Functional programs do this well because they are directly 
>> based in abstraction(category theory).
>
> Actually, I think it has more to do with limiting the size of 
> the available state. Since you seldom write FP programs with 
> high speed in mind you also can relax more and pick more 
> readable (but less efficient) data-structures. However there 
> are many types of algorithms that are far easier to implement 
> in imperative languages. I'd say most real world performance 
> oriented algorithms fall into that category.
>
>> As the program goes in complexity so does the code because 
>> there is no higher levels of abstraction to deal with it.
>
> I don't think this is correct. Abstraction is a property of 
> modelling, not really a property of the language. The language 
> may provide more or less useful modelling mechanisms, but the 
> real source for abstraction-failures are entirely human for any 
> sensible real world language.
>
>> covered. This is why no one programs in assembly... not 
>> because it's a bad language necessarily but because it doesn't 
>> allow for abstraction.
>
> That's not quite true either. You can do abstraction just fine 
> in assembly with a readable assmbly language like Motoroal 68K 
> and a good macro assembler. It is more work, easier to make 
> mistakes, but whether you manage to do abstraction well is 
> mostly a property of the programmer (if the basic tooling is 
> suitable).
>
>> it just has a lot of other issues that makes it not a great 
>> language for practical usage.
>
> It was not designed for writing large programs, it is more of a 
> PL-exploration platform than a software engineering solution.
>
> AFAIK, Haskell lacks abstraction mechanisms for programming in 
> the large.
>
>> No one here will actually be alive to find out if I'm right or 
>> wrong so ultimately I can say what I want ;)
>
> It is a safe bet to say that you are both right and wrong (and 
> so are we all, at the end of the day).

We must have different concepts of abstraction.

Category theory is the theory of abstraction. Abstraction is 
generalization.

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

d/dx, int, sum, interface, functor, category, set, point, etc are 
all abstractions of concepts that are complex. But having a 
"name"(a symbol) for these complex processes we can substitute 
the symbol for the process and it makes it much easier to use and 
remember. All words are abstractions. All symbols are 
abstractions, and just about everything we humans do is to 
abstract away complexity. Definitions are abstractions that use 
other words(Abstractions) to create a new abstraction. A oop 
hierarchy is an abstraction as is a struct. They are used to bind 
bits(which are abstractions) together in to a certain structure.

You cannot abstract in masm because masm does not have language 
capabilities to abstract. There is no class. There is a struct 
which does some abstraction but it is limited because you can't 
generalize it by inclusion/use. Tasm is the same as it does not 
have these capabilities. Instruction mneumonics are abstractions. 
mov ax, 34 is an abstraction. The assembler converts the symbols 
in to bits and those bits then toggle transistor states, which 
are also abstractions since transistors are made up of different 
configurations of silica and doped with different oxides to 
create a switching effect, which is abstracting logical 
operations.

Logic itself is the most concrete form of anything as everything 
is logic. Even a baby playing is an abstraction of logic because 
neurons that fire in the baby's brain are just abstractions of 
logic and very much related to transistors(neurons are switches 
and interconnect to form matrices just like transistors do... 
it's not a coincidence because transistors were abstracted from 
neurology).


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. The 
boundaries that we see do not exist. It is true there is a 
change, but the change we see is an abstraction of that change.

In computer programming, we use abstractions which are 
expressions. These expressions, whatever their representation, 
eventually get compiled in to an abstraction that computers 
understand(which is machine code) and ultimately down in to 
transistor configurations.

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).

Now, you are very well aware that computer languages have evolved 
to add more abstraction and those abstractions allow for more 
powerful programs. C->C++ is probably the most well known 
advancement in this area.

C did not have oop. You can write any program that is written in 
C++ in C or assembly or hex. It is not a matter of representation 
but a matter of abstraction.

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.

See, a typical 1MB program would be impossible to memorize as the 
sequence of bits in it's executable... but not terribly hard to 
memorize in terms of it's abstractions. The details are not 
required to be memorized.

For example, suppose you had to *reimplement* a program from 
scratch but you could memorize the HL code or machine code... 
which one one would you choose? If you had to do it perfectly 
you'd want to use machine. If you only needed a good 
approximation you'd go with the abstraction.

Now, my point with all this is that this thing I'm calling 
abstraction is in everything. Mathematics is all about 
abstraction. 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...

A building is built in a certain way. One does not or cannot 
start with the windows... the windows require something to attach 
too[It's true you can build the windows off site but you can 
never start with the windows first and place them in 3D space and 
then build the building around them].

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).

What I am talking about is 1. the progression of things towards 
more abstraction 2. How that is playing out in programming 
languages.

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.

Abstraction is power. If you could not abstract you could not 
think. Even animals abstract, just not so well. Thinking is 
basically abstracting. As far as programming goes, the better we 
can create abstracting abstractions the more powerful the 
programming language and the more complicated programs we can 
create. Visualization is an abstraction as it allows one to 
represent something in more general terms.

If you understand all that then what I'm saying is that category 
theory IS the theory of abstraction(there is no other theory that 
deals with it rigorously and correctly except other theories that 
are equivalent). Category theory is the theory of abstraction(by 
design) and therefor is very important in programming as it is in 
math and many other things in life(if not all).

So when I speak of abstraction I am talking about a very specific 
process. It is a process of relationship. It is also called 
generalization.

None of these definitions are what I mean:

the quality of dealing with ideas rather than events.
"topics will vary in degrees of abstraction"

     something which exists only as an idea.
     plural noun: abstractions
     "the question can no longer be treated as an academic 
abstraction"
     synonyms:	concept, idea, notion, thought, generality, 
generalization, theory, theorem, formula, hypothesis, 
speculation, conjecture, supposition, presumption
     "his style of writing focuses on facts rather than 
abstractions"
     antonyms:	fact, material consideration

2.
freedom from representational qualities in art.
"geometric abstraction has been a mainstay in her work"

     an abstract work of art.

3.
a state of preoccupation.
"she sensed his momentary abstraction"
synonyms:	absentmindedness, distraction, preoccupation, 
daydreaming, dreaminess, inattentiveness, inattention, 
woolgathering, absence, heedlessness, obliviousness; More
thoughtfulness, pensiveness, musing, brooding, absorption, 
engrossment, raptness
"she sensed his momentary abstraction"
antonyms:	attention
4.
the process of considering something independently of its 
associations, attributes, or concrete accompaniments.
"duty is no longer determined in abstraction from the 
consequences"
5.
the process of removing something, especially water from a river 
or other source.


https://en.wikipedia.org/wiki/Abstraction_(computer_science)

Is far closer. But my abstraction is even more abstract than the 
above because I include the abstractions of mathematics since 
they are essentially the same.

E.g., an equation such as int(x^2 + cos(x),x=0..43) is actually a 
program and this is why we can write a program in D to compute 
the equation... because they are actually both programs that use 
different language. Math is a language and all languages are 
programming languages(even English).

You have to realize that I'm looking at the forest from outer 
space... it covers the whole planet. It's one organism, it's not 
a bunch of arbitrarily marked off boundaries created by man due 
to his ignorance. [In case it's not clear, I'm taking a very 
inclusive view of programming in general... all programming, and 
trying to abstract it in to a single concept that applies to it 
all. What this concept is, is more universal and hence more 
powerful. It has to throw away details but it has to keep the 
underlying structure that binds all programming together. That 
underlying structure is what is important, it is what makes a 
programming language a programming language. Without it, it would 
be something else]

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