[rusk]

There is no language that is innately understood. All computer languages are learned, so when they describe "intuitive" I don't think this is what is meant. However, a large portion of early programming education does take place amongst C-style curly-brackets.

It's this learned setting for our precepts that makes other languages intuitive or not. If we were all learning fortran or pascal in college it might be different, but we're not.

That said, having C-style syntax is clearly not a pre-requisite for the success of a language as is attested by the success of Python, Ruby, various flavours of BASIC and other less loved languages like COBOL ...

But "intuitive" is very important for getting traction. Once you can "intuitively" model a problem in a language such that somebody familiar with the problem can understand what's going on, then that's intuitive. I'm talking about a different kind of intuitive here.

Most people engage with computers on imperative terms, i.e. they want to tell it to do things. Imperative languages are "intuitive" because they allow you to map out a list of instructions in order.

So for instance, when you're writing a program to make a cup of tea you issue those steps one by one. You don't want to have refine the model into a functional space, do a handstand and flip the bag into a mug with your little toe while inducing a small raincloud and microwaving the drops on the way down.

Similarly true object oriented langauges (I'm not talking about C or Java here, where classes are glorified structs) model how we think of information in terms of object-relations.

Functional languages to me as an experienced programmer are "intuitive", but even I sometimes flinch when I'm exposed to a stack of lisp ellipses ...

[the_af]

I think you're under-stating some things. Imperative programming languages are hard beyond their initial appeal at the "this is like a recipe" level. It's debatable how people best engage with computers. There are plenty of anecdotes, if you look for them, of people failing to understand that the assignment operator in imperative languages means "place this value in this box" instead of "this means that". It's just that you (and me) are used to this learned mode of understanding.

Modern programs seldom look like a list of imperative actions anyway, beyond toy examples. They look weird and unintuitive. If you can make the leap to "this is what an actual imperative program looks like nowadays", you can make a leap to declarative/functional programs just as well. Doubly so if you don't have to unlearn years of conditioning about how programs are supposed to look :)

It currently is a self-inflicted hurdle. I don't pretend this problem doesn't exist. One way to fix it would be to start teaching programming in a different way, and with different languages.

[AnimalMuppet]

> There are plenty of anecdotes, if you look for them, of people failing to understand that the assignment operator in imperative languages means "place this value in this box" instead of "this means that".

Are there anecdotes of non-absolute-beginners failing to understand that? For first-year students, sure. Do working software engineers have trouble with it? Do they have bugs and/or lower productivity because of it?

> If you can make the leap to "this is what an actual imperative program looks like nowadays", you can make a leap to declarative/functional programs just as well.

My own suspicion (completely unsupported by data) is that some peoples' brains find imperative languages to be more the way they think, and some find functional languages to fit their way of thinking better. You could run an experiment to test that - you'd take a group (call it A) of functional programmers, and a group B of imperative programmers, and measure their productivity. You'd then split the groups in half. A1 stays functional; A2 starts programming in imperative languages. B1 stays imperative; B2 goes to functional. Two years later, you measure everybody's productivity again. What I expect you'd find is that some of the people who switched (either way) increased productivity, and some declined.

What you might find is that everybody who switched from functional to imperative was less productive, but that might be because the (somewhat rare) people who are already functional programmers are almost exclusively the ones whose minds work better that way. You could fix that by starting with students or with fresh graduates, and arbitrarily assigning them to group A or group B. Then you'd have to wait a couple of years to measure their productivity the first time.

The difficulty, of course, is figuring out a way to at least somewhat objectively measure their productivity...

[the_af]

> Are there anecdotes of non-absolute-beginners failing to understand that? For first-year students, sure. Do working software engineers have trouble with it?

Sorry, I was unclear: I was talking about beginners. My argument was about intuitivity and "it's easier/harder to learn programming this way". Software engineers are already down the road of "I'm used to this, therefore this is the best way" :P

If I understand you correctly, what you say is entirely possible: that some people think best one way or the other, and that there is no universal paradigm that is more intuitive.

[AnimalMuppet]

So a language is more intuitive if it's similar to what we already know, and we already know math, and therefore "=" for assignment is not intuitive? OK, for first learning a language, I can buy that.

I don't recall ever having trouble with that myself, but that's anecdote, not data...

[the_af]

To be fair, I never had trouble with that either. It was just an example of something I've occasionally read about some people approaching programming languages for the first time.