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

On Friday, 17 May 2019 at 15:02:51 UTC, Ola Fosheim Grøstad wrote:
> 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).

That said, a real problem with machine language is that restructuring the code becomes very expensive. So you need a waterfall development model. It is not very suitable for iterative development models.

Today, compilers often generate better code, so it is mostly pointless to use machine language unless you need to save space or want to utilize special properties of the hadware.

(sorry about the typos in the previous answer)

On Friday, 17 May 2019 at 11:06:57 UTC, Alex wrote:
>
> Your thinking pattern probably invades every aspect of your life. You focus on more practical rather than theoretical aspects of stuff. Hence it's hard for you to think outside the box but you can think inside the box well. You get in to arguments with people because what they say doesn't make sense in your box. You fail to realize there are many boxes... many different levels to view, and understand. I too have a similar problem, completely opposite in some sense. I am an outside thinker. I tend to forget that some people are inside thinkers. I can think inside the box, but it is not my preferred medium(it's very limiting to me). I think you should ask yourself if you can think outside the box. If not then it is a flaw you have and you should work on fixing it as it will make you a much more balanced and powerful human. If it's just your preference then just try to keep in mind that you will interact with other types of thinkers in the world. (and try to parse which box people are thinking in based on context)

Actually what you seem to have forgotten is that telling someone what personal traits they need to work on "fixing" is a pretty dickish thing to do. :)

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! ;)

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.

On Friday, 17 May 2019 at 18:09:16 UTC, Ola Fosheim Grøstad wrote:
> 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.

You keep saying that something is not an abstraction then use that abstraction. E.g., oop is a tool used to abstract...

Do you realize that a tool itself is an abstraction?

Until we can agree on a precise definition of abstraction we will just go in circles.

If you agree that your brain takes sensory data and presents it to you as abstractions. E.g., some cells fire on your finger tips and eventually through the magic of life your brain tells you that you just chopped off the tip of your finger is a process of abstraction(your brain builds up a model about reality and what happened given the sensory data and presents it to you as the reality(but it is still a model))... then, in fact, everything you know is an abstraction... because all your information came through you by sensory data which was abstracted.

You don't think about pumping your heart, your body does it for you... but your perception of what is going on is really an abstraction.

The problem we have is you seem to think abstractions are not real. That is the typical way to view them... But abstractions are not like a unicorn... abstracts are very real. Without them we couldn't even have this conversation, literally.

I'm presenting you with my extended definition of what abstraction is, you can keep using use or choose to use mine and see something new. My definition includes yours, where do you think I got mine from? (and that itself was an abstracting process)

Stop thinking of abstraction as what you learned from Stroustrup and think of it in modern terms. Concepts grow and evolve for a reason.

In mathematics, one of the most basic principles is the concept of a point/element... something that is so abstracted as to include everything and nothing at the same time. That singular concept IS what as allowed mathematics to do very real things. Abstractions are not imaginary. A baby is very much an abstraction. What a baby really is far more complex than anything our brains understand. Most people have no clue what a baby is but some simple abstraction of something that whines, shits, and giggles.

On Friday, 17 May 2019 at 19:43:15 UTC, Alex wrote:
> If you agree that your brain takes sensory data and presents it to you as abstractions.

Who is "you" then, if you say like the brain is separated from that "you"?

> then, in fact, everything you know is an abstraction...

So, abstraction becomes knowledge, in your definition?

> because all your information came through you by sensory data which was abstracted.

Not quite true (protip: every act of cognition assume that you already know about space or time).

> The problem we have is you seem to think abstractions are not real.

Depends on what is real.

> Without them we couldn't even have this conversation, literally.

Maybe, but it does not imply that they are real:

"Conversation is real and powered by abstractions."
"Magpies are black-and-white and powered by food."

> Abstractions are not imaginary.

If so, and real is something that I theoretically can touch, can I touch a number?

On Saturday, 18 May 2019 at 01:23:38 UTC, dayllenger wrote:
> Depends on what is real.

That's right, in our context "reality" is the problem domain we model and the context the program is going to be used in.

So, if you we create a Star Trek themed RPG then we model the imaginary reality of the Star Trek universe.

Or, if we create a program to support an engineering discipline then "reality" is the practices of that engineering discipline (which could include parts of linear algebra for instance)

On Friday, 17 May 2019 at 19:43:15 UTC, Alex wrote:
> You keep saying that something is not an abstraction then use that abstraction. E.g., oop is a tool used to abstract...

Not sure what you mean. OO abstractions are in your head. OOP-language-features are just mechanisms that makes it easier to express those abstractions in code.

> Do you realize that a tool itself is an abstraction?

No. Why would it be? The tool itself "just is". You may interpret it, that interpretation embodies abstractions.

> Until we can agree on a precise definition of abstraction we will just go in circles.

Seems like it.

> it to you as the reality(but it is still a model))... then, in fact, everything you know is an abstraction... because all your information came through you by sensory data which was abstracted.

Yes, the brain is an abstraction machine.

Current generation compilers are not. There are some attempts in that direction, like refactoring engines. E.g. deforesting, where you expand a program until it contains no functions, then you restructure the program, find similar branches and restructure those branches back into functions.

But in general, compilers and common tooling don't do much abstraction. Some optimization passes work with abstractions, to gain performance, but that is not happening on a semantic level.

> In mathematics, one of the most basic principles is the concept of a point/element... something that is so abstracted as to include everything and nothing at the same time. That singular concept IS what as allowed mathematics to do very real things.

Not sure what you mean by saying that a point includes everything and nothing...

Anyway, what the most basic concept is, is a matter of viewpoint. Some would say that a set is the most crucial concept.

In general, I don't think such arguments leads anywhere. It is a matter of interpretation based on what you are interested in expressing.

> Abstractions are not imaginary. A baby is very much an abstraction. What a baby really is far more complex than anything our brains understand. Most people have no clue what a baby is but some simple abstraction of something that whines, shits, and giggles.

The baby is physical matter. Our conceptualization of a baby is our individual abstractions of what we have perceived. My understanding of what a baby is changed drastically after I become a father.

Anyway, how does this  relate to programming languages?

Programming languages are just symbolic machinery.

Those languages makes it possible to encode models.

Those models embody abstractions.


Same as in math.  You can encode ("model") integers like this:

"0" = Zero.
"1" = Successor(Zero).
"2" = Successor(Successor(Zero)).

The right hand side is what we express in the programming language to be executed on a machine.

The left hand side is how we map it to the conceptual model (or abstraction) that we have in our head.

FWIW, the notion of "abstract datatypes" is tangential to the above discussion.