This is what you argued originally is proof of your claim:
Let's say I have several tasks I need you to do. If I wanted to present those tasks to you in written form, what would those tasks look like? They would look like a series of procedures. Any human would present imperative instructions to you WITHOUT being taught anything beforehand. Nobody
Moreover, it's leading. You start with "I have several tasks" (which sounds like a list), and you want them written down (okay, so you want someone to write the list you just told them).
> Incorrect. the functional paradigm is a subset of imperative paradigm.
I must state again that I'm not defending or referencing functional programming in any of my replies. I started with a reference to Excel, and have also mentioned Etoys and Logo. None of these are considered strictly functional. When I mentioned temporal programming, that's another paradigm entirely separate from functional and imperative.
> The notion is that one thing happened after another thing, or another thing happened before something else. This concept is expressed through change.
This is a very indirect way of expressing time. The only thing that needs to mutate for time to pass is the timer. In the imperative model, the world is stopped until the next statement is executed. This is to match the paradigm to the computing hardware, not to the real world as you keep insisting.
> I'm saying that c-style syntax is innately understood at the biological level.
Okay, if you say so. You literally don't have a single study backing this up. The only argument you've offered is "it's obvious", which I assure you, it's not. If it's only obvious to you, then maybe all you're arguing is that you innately understand c-style syntax. Which, sure. But that isn't generalizable to "every human", as you are literally claiming.
Can you answer me this: have you ever taught C to anyone, like an 6-year old? Can you honestly tell me it the case that they were presented with C, and they immediately understood the syntax? I remember learning C at 6 and it wasn't a smooth process. Then again, maybe that just indicates I'm not a human.
> All the immutable parts of your program can be evaluated out of order.
That doesn't make it not imperative. If you think your imperative code is being executed in the order it's written, you should seriously investigate your compiled code. Optimizing compilers make all kind of decisions to reorder statements when they can.
> I will have to see this language to know what you're talking about. But lisp is usually taught functional first. Children searching for documentation have to dig deeper to find the c like syntax.
The first program all students write in Logo is to draw a square:
pd
repeat 4[forward 100 right 90]
pu
> Yes. A student readily understands 1, before understanding 1.0000111111.
I'm not disagreeing with that. I'm saying that children understand their world to be continuous even before they understand the number 1. Students then learn about integers, and then learn about then about the continuous nature of the number line. That nature is intuitive precisely because they understand the concept from physically interacting with the world. Seymour Papert discusses this idea in Mindstorms.
> No I'm saying here is "how I make a sandwich" can be EITHER declarative OR imperative.
In what way? Declarative programming is all about eliding the how and leaving it up to the compiler. If you answer this question declaratively, it won't contain instructions to make a sandwich. Such details are left to the implementation.
It is a strong claim and I stand by it. In your mind you feel as if you identified a counter example. I plainly already told you that it is NOT the case.
First off lisp like languages are by default geared toward an FP style. Documentation and syntax makes it easier to do the FP style over imperative. The language you chose has clear bias towards the FP style.
Additionally. Nothing stops people from doing python in the FP style. Python is very amenable to that. One could make the argument, according to your flawed logic, that with list comprehensions, reduce and recursion one should, if you're theory is correct automatically do FP when using the the python language.(I didn't choose this example earlier because it suffers from the same problem as logo, there is a clear bias towards imperative that's intrinsic to the language)
But this doesn't occur. People choose the paradigm that fits them better. Imperative.
Those kids may understand FP programming. They may be able to learn logo. But that doesn't mean that the imperative style would've been easier and more natural.
>Moreover, it's leading. You start with "I have several tasks" (which sounds like a list), and you want them written down (okay, so you want someone to write the list you just told them).
This is you illustrating my point. I have 5 things, I have 2 tasks, I have several things, I have several tasks. None of these things explicitly point to procedures that have to be in order. It's simply your natural bias. If I say write something down but I don't say write it down in a single sentence or write it down as a numbered list, your bias automatically inserts imperatives in there. The language itself is neutral, but your natural tendency to insert additional meaning into the sentence is proof of my point.
>I must state again that I'm not defending or referencing functional programming in any of my replies. I started with a reference to Excel, and have also mentioned Etoys and Logo. None of these are considered strictly functional. When I mentioned temporal programming, that's another paradigm entirely separate from functional and imperative.
Understood. My point here is just saying that the additional "features" you mentioned aren't exclusive to the declarative paradigm because the declarative paradigm is actually a restrictive style. Imperative programming has more features and more freedom then functional programming but that doesn't necessarily make it better.
>This is a very indirect way of expressing time. The only thing that needs to mutate for time to pass is the timer. In the imperative model, the world is stopped until the next statement is executed. This is to match the paradigm to the computing hardware, not to the real world as you keep insisting.
No. This is the most natural way. For most of human civilization mathematics did not exist. The concept of time as a symbolic measurement did not exist. People measured time through change. When you take symbols and language and strip it down to our base perceptions, time is mutation, time is change. It is the most primitive and fundamental measurement of time.
Again your bias with what you know (timers) influences your view here.
>Okay, if you say so. You literally don't have a single study backing this up. The only argument you've offered is "it's obvious", which I assure you, it's not. If it's only obvious to you, then maybe all you're arguing is that you innately understand c-style syntax. Which, sure. But that isn't generalizable to "every human", as you are literally claiming.
Why do we need studies for everything? It's like I can't have thoughts or strong opinions on everything if there's not some scientific study backing it up? I strongly believe that you are human. Do I need a study to prove such an obvious point? Science is just the definitive data driven way at arriving at an accurate conclusion. The downfall is that it's slow and expensive. You can arrive at similar conclusions using less accurate pathways like logic and common sense.
> There is a mountain of research to support this, I've already referenced for you.
links? From what you described though, the "research" doesn't confirm or deny anything. Like I said it only shows that children can learn functional. Doesn't show that functional is more natural then imperative.
>This doesn't look anything like C. It's completely imperative.
Do you mean functional?
>In what way? Declarative programming is all about eliding the how and leaving it up to the compiler. If you answer this question declaratively, it won't contain instructions to make a sandwich. Such details are left to the implementation.
No it can. Simply treat the time dimension as a spatial dimension. That's how FP languages do it. The "how" is simply a series of temporal tasks done in a certain order. If you treat time as physical geometry then you simply "declare" the whole procedure in one shot.
>I'm not disagreeing with that. I'm saying that children understand their world to be continuous even before they understand the number 1.
No this is not necessarily true. The brain is made up of multiple modules that understands things in different ways at the same time. The language module in your brain understands things discreetly by default, the spatial part of your brain understands things continuously. There is no "singular" form of understanding these concepts where one concept is understood before the other.
Strong claims require strong proof, and can be summarily dismissed if said proof isn't provided after a discussion spanning thousands of words. Sorry, but I don't think there's much more to say here until you've familiarized yourself with the literature. You've only just heard of Logo from me, which is decades old and is exactly the kind of programming language that touches on what you're trying to say here. The Logo team backs up their work with a system they implemented to explore how children learn to program, and then studied this system extensively with actual children. Their findings don't support what you're trying to say here. Your entire argument is based on "it just makes sense to me", which is fine if it makes sense to you logically, but that's not what the literature shows. Sometimes reality is counterintuitive. As proof of your assertion, you state that literally any single human being would give you an answer that comports with your point of view. I find this unconvincing when held up against the body of literature I've referenced here, which studies exactly the kind of person you're looking for to prove your point: people without any preconceived notions about programming. The literature emphatically shows that they are not innately and biologically predisposed to prefer c-styles syntax. It's just flat not true according to the literature.
I'm surprised you're so sure of yourself seeing as that you haven't read anything from this body of work. Maybe I'm not the one going off my own preconceived notions? Because I'm here citing sources, and all you can say is "it just makes sense to me, you're wrong because you're biased". This argument is unconvincing in any context, but especially when there's actual research contradicting you.
> First off lisp like languages are by default geared toward an FP style.
Let me stop you right there. Logo is not a functional language; it support programming in multiple paradigms including imperative. You just learned about it yesterday, so I don't know how you can keep asserting this. The syntax is lisp-like, but it's a multiparadigm language. Earlier I claimed that I thought perhaps you knew the different between syntax and semantics, but now I'm not so sure, as you keep insisting that `lisp syntax == fuctional language`.
> links? From what you described though, the "research" doesn't confirm or deny anything.
It shows young children can write very sophisticated programs when handed Logo, but are at a complete loss when given C. It's pretty hard to square that research against your assertion that humans are biologically predisposed to c-style syntax. If you were right, they would take to C just as naturally as they take to Logo. Research has found that's not the case.
I've given you all the information you need to find the sources I referenced. You can find "Mindstorms" at your local bookstore or library. The author is Seymour Papert. You can find out about Etoys from Alan Kay's body of work. You can find the Logo language online and code in it yourself to see it's multiparadigm and not strictly functional. It's an example of imperative programming used by kids that is devoid of the c-style syntax. Logo is taught to kids because they take to it better than C. C existed at the time Logo was created, and the designers of the language specifically made it to be optimally applicable to the learning style of children. The key insight of Logo (particularly the turtle graphics module) is to frame the program as kinematic actions from the point of view of the child. In this sense you are right that children can understand imperative programming as early as 1st grade. But it severely cuts against your argument that c-style syntax is what is innately familiar to humans at a biological level. It's this notion against which I push in these comments.
> Like I said it only shows that children can learn functional. Doesn't show that functional is more natural then imperative.
That you still call Logo "functional" tells me you haven't read any of the literature, nor used the language, so therefore you don't actually know what it shows. Insofar as Logo offers functional capabilities, they aren't presented to children in the highly imperative turtle graphics module.
And again, I'm not arguing functional is more natural than imperative.
> Do you mean functional?
No, the code I wrote is completely imperative. In C it would look like this:
pd();
for (int i = 0; i < 4; i++) {
forward(100);
right(90);
}
pu();
Anyway, that's all from me for this thread. Feel free to reply but I'm done here. Cheers!
No I didn't. I asked how do you make a sandwich. The answer doesn't have to be in list form. The child chooses to give me the answer in list form.
Your question, however, the only possible answer is declarative form. There is no other choice. You structured the question in such a way that it demanded a singular answer. "What do you want for lunch?"
>I'll note here that the only temporal notion offered by the imperative paradigm is the notion of an ordered sequence. There are far richer treatments of time in other paradigms, which include temporal operators specifying "as soon as", "before", "after", "until", "whenever", etc. These concepts cannot be expressed directly in imperative paradigms.
Incorrect. the functional paradigm is a subset of imperative paradigm. Imperative is simply a series of functional programs with mutation. All "richer" treatments are therefore part of the imperative style.
>The notion of time in most imperative languages I know of is CPU-time, or instruction time. It has little to do with wall time, so appeals to how close imperative programming adheres to an concept of time that's intuitive due to human experience falls short. Indeed, I often experience students frustrated by the inability to cleanly model these concepts in imperative languages.
There is a notion of time that doesn't have to be so technical. The notion is that one thing happened after another thing, or another thing happened before something else. This concept is expressed through change. Mutation. When you remove mutation then this concept of time disappears.
>It's interesting that this is how you phrase it, because in my experience children do indeed naturally ask for sandwiches often before they can even describe how they're made. Have you ever seen a kid get mad that the jelly is on the bottom of the PB&J, only to placate them by turning it over? Such a child has no idea how the sandwich is made.
No, this simply means they know about the sandwich as a blackbox abstraction. This has nothing to do with monadic IO. If a child knew how to make a sandwich, he for sure wouldn't know how to express the construction process as monadic do notation.
>To be clear, I'm not saying it is more intuitive. I'm not even mounting a defense of functional programming here. I'm pushing back against the notion that c-style syntax is innately understood at a biological level. In your various posts here you seem to conflate syntax and semantics, which I don't understand because you seem experienced enough to know the difference. Or maybe I'm misunderstanding you, but I feel like you've offered a pretty full-throated argument, so perhaps I'm just not following. But I think we're talking past one another at this point.
I'm saying that c-style syntax is innately understood at the biological level. C-syntax is equivalent to procedural syntax or semantics or whatever you want to call it.
> There's no reason at all this imperative program must be strictly evaluated. Evaluating z can be deferred until it's clear that it's needed in the print call.
The imperative part of the program must be strictly evaluated. You only lazily evaluated the declarative part of your program where the values are immutable. x must be evaluated before y and before print because those values mutate. They cannot be done in different order.
All the immutable parts of your program can be evaluated out of order. But the mutable parts cannot be.
>To be clear, Logo is an multi-paradigm Lisp-like language.
I will have to see this language to know what you're talking about. But lisp is usually taught functional first. Children searching for documentation have to dig deeper to find the c like syntax. By nature of documentation and usage, children are more likely to bias towards functional over imperative simply because the bias of the manual and users are also heading in the same direction.
>But is that understood at an innate biological level? I think not. Human beings, and in particular students of programming, experience their world continuously in time and space. This is why they are surprised that 0.1 + 0.2 != 0.3 in most languages.
Yes. A student readily understands 1, before understanding 1.0000111111. There's a dual interpretation arising from two separate modules in the brain. There's a part of the brain that's visual and there's another part that's symbolic and handles language.
The language aspect of our brain is by default discreet, the visual part is continuous. Our interpretation of symbols and language flowing through time is not continuous at all. But our interpretation of movement through space is.
>Throughout your posts, you are treating "here is how I make a sandwich" as programming, while you don't seem to consider "I want a sandwich" as programming. These are both programming. The former is imperative, the later is declarative.
No I'm saying here is "how I make a sandwich" can be EITHER declarative OR imperative. I am saying "I want a sandwich" is declarative programming with no way to convert to imperative.