[sepp2k]

Continuation of an off-topic side discussion in Is this a list?. To recap:

sepp2k, on 17 October 2012 - 03:42 AM, said:

Quote

There are cooler ways, but this is the easiest to get your head around.

Are you sure about that? I'm not an educator, but I could imagine that something like a list comprehension (which is very close to the set-notation that one knows from math class) would be more familiar (and thus easier to understand) to newbies who aren't used to imperative loops and mutation.

And even without the connection to math, I feel like it might be easier simply because it's more declarative and requires you to wrap your head around less concepts than a loop would (taking into account that loops, lists and mutation are all new concepts to a newbie).

That said, I started programming with Basic a billion years ago, so I really have no clue what is and isn't easy for newbies - and of course it depends on the person, too.

jon.kiparsky, on 17 October 2012 - 04:30 AM, said:

sepp2k, on 16 October 2012 - 08:42 PM, said:

Quote

There are cooler ways, but this is the easiest to get your head around.

Are you sure about that? I'm not an educator, but I could imagine that something like a list comprehension (which is very close to the set-notation that one knows from math class) would be more familiar (and thus easier to understand) to newbies who aren't used to imperative loops and mutation.

I actually don't think the list comprehension syntax is nearly as clear as the die-hard pythonistas seem to find it, and I have watched other people try to learn it - they struggled with it as well. These included both novices and some people with extensive programming experience. It's just really not that intuitive.
Speaking generally, I find that the concepts of functional programming are not generally easier to learn than imperative concepts. Once learned, they're generally easier to use, but that's a very different thing. The same goes for the syntax of these languages - there's a ton of gotchas in python, and Scala has just as many traps. Like any language, you just have to learn them, but it's not any easier than Java or C. What's easier (again) is doing cool stuff with them once you learn them.
I have only my experience and some anecdotal evidence to support this, but looking at the forum chatter in the Odersky scala course might bear me out. The people insisting that these concepts are easy seem to mostly be people already familiar with them. The people new to the ideas are struggling hard, and it's really no help to them to tell them "but it's so easy!". (which is the usual response from the people who get it already)

(you can sign up for the course at coursera if you want to check out the forum chatter and draw your own conclusions)

But perhaps we should fork this if we want to pursue this tangent, no need to hijack this thread for it.

This post has been edited by sepp2k: 16 October 2012 - 10:27 PM

[jon.kiparsky]

To complete the recap, the imperative version that I felt was the simplest for a newbie was this:

l = list()   # please don't call your list "list"
for i in range(5):
  l.append(random.randrange (0,101, 1))

Thanks for starting this thread, sepp - I'm really interested in hearing from people on this one. Special shout-out to newbies - if you're learning a language like python, scala, lisp, clojure, etc - what's easy? What's hard?

[sepp2k]

jon.kiparsky, on 17 October 2012 - 04:30 AM, said:

I actually don't think the list comprehension syntax is nearly as clear as the die-hard pythonistas seem to find it, and I have watched other people try to learn it - they struggled with it as well. These included both novices and some people with extensive programming experience. It's just really not that intuitive.

Hm. Do you find mathematical set notation (like {x+y| x € N, y € N, x*y < 42}) intuitive? Did you learn it in school? List comprehensions really aren't a major leap from that.

Quote

I have only my experience and some anecdotal evidence to support this, but looking at the forum chatter in the Odersky scala course might bear me out.

You have to take into account though that the people on that forum aren't programming newbies. I really do think that, at least for some newbie programmers, the functional or declarative style might be more natural.

To bring some anecdotal evidence of my own: When I look through the C++ and Java (and also sometimes Python) forums, I often see newbies posting code like this:

int read_int(){
  if(reading int from user succeeded) {
    return read int
  } else {
    print("try again")
    return read_int()
  }
}

These people seem to have some trouble understanding loops, but don't seem to have problems with recursion. They are then usually told that they should use loops, not recursion, to solve this because of performance and stack overflows and what not. This is, of course, good advice in imperative languages, but I really find it interesting that, at least to some percentage of newbies, the recursive approach seems much more intuitive than loops.

I also sometimes see people who try to access a variable's value before it is assigned - not because of a typo, but because they have not yet fully understand the fact that statements are executes sequentially and that consequently order matters. I can't help but wonder, whether those people wouldn't have an easier time learning something like Haskell where order really does not matter. Probably not though as Haskell is really somewhat unfriendly to beginners for different reasons.

[fromTheSprawl]

I think it depends on what their first language is. If they come from learning programming through C, C++, Java or a similar language, I believe the loops are easier to implement, but if they learn Python first or a similar language, they'll find the functional/declarative way to do easier.

I'm from the imperative bunch, and it's not that it's hard to implement list comprehensions and what not in Python, it's just that I'm overwhelmed tjat there are a lot of ways to do something and add to that my preconceived notions on how to solve them through imperative programming, it clouds my mind from entirely using the Python way of doing things.

There are times when I think what I made is very Python but then someone points out that I'm still doing it in the imperative way.

I'd like to hear what someone in reverse(coming from a functional language first, then to imperative) has to say.

[sepp2k]

sepp2k, on 17 October 2012 - 05:03 AM, said:

These people seem to have some trouble understanding loops, but don't seem to have problems with recursion.

I forgot to add that there are, of course, equally many people who seem to have great trouble understanding recursion. Presumably those people never encountered the concept in math class (or didn't understand it then either).

I think it might simply boil down to which people have a mathematical, or at least abstract, way of thinking, and which people need to think in terms of steps being executed in order to make sense of what's going on.

[fromTheSprawl]

sepp2k, on 17 October 2012 - 05:03 AM, said:

I forgot to add that there are, of course, equally many people who seem to have great trouble understanding recursion. Presumably those people never encountered the concept in math class (or didn't understand it then either).

I can attest to this. We were never thought about recursion. I guess it's because I took up IT, and our math was only discrete mathematics. I think the Computer Science majors took this one up.

[jon.kiparsky]

sepp2k, on 16 October 2012 - 10:17 PM, said:

I think it might simply boil down to which people have a mathematical, or at least abstract, way of thinking, and which people need to think in terms of steps being executed in order to make sense of what's going on.

This is likely. I have my suspicions as to which group of people are more prevalent in the population at large.

[jon.kiparsky]

sepp2k, on 16 October 2012 - 10:03 PM, said:

You have to take into account though that the people on that forum aren't programming newbies. I really do think that, at least for some newbie programmers, the functional or declarative style might be more natural.

I could see how you could make the case that not having developed the imperative programming habits of style, you'd find it easier to pick up the functional approach. However, I think that it takes a certain amount of experience in programming to see just why it is that the functional style would make sense at all. For the most part, it's very hard to get beginners to use the techniques that make programming easier, because they actually want to spell out each step.
For example, this programmer declares five chars and five ints to get the five digits of a number submitted as a String. Why?
I think it's because that's the easiest way to conceive of the problem at first. It's the most concrete way to present it, for sure. As you move into arrays and loops, you begin to get into abstractions, and abstraction is difficult. Then you start thinking about methods, and that's another abstraction: now we're naming bits of functionality. That's hard, and every day in every forum we have evidence of this. If it were easy, we wouldn't have any trouble getting people to do it.

I think it's safe to say that the gains of higher-level languages are generally gains of abstraction, and thus of increased expressiveness, and the gains of the functional style reflect this. If abstraction is generally difficult to get a grasp on, then it's not hard to understand why functional languages would be harder to learn, even for someone without the habits of imperative programming.

Frankly, it really takes some experience in programming to understand why being able to pass a function around as a value would be a good thing, and some people never seem to get it.

Quote

To bring some anecdotal evidence of my own [snip] I really find it interesting that, at least to some percentage of newbies, the recursive approach seems much more intuitive than loops.

Well, yes. Except I never see them making good recursions. Though to be fair, if they did they wouldn't be asking about them.

Quote

Probably not though as Haskell is really somewhat unfriendly to beginners for different reasons.

Other reasons like the haskell programmers?

[Lemur]

I'm primarily a functional programmer. I came from imperative land.

I came from an insanely abstract background. I detested programming. I hated all the boilerplate code and imperative syntax and just simply walked through it because I had to for classes.

If it hadn't been for my father getting on my case, I would have majored in Music or Art. I'm perfectly capable of being a professional in either of those fields. I came from a highly creative and abstract thinking background.

Math was annoying to me, it felt like there were so many rules and regulations to follow on things, and it had to be done a certain way (which I later found out was crap teaching.) Teachers forced us to do something one way, and the next year the next teacher would teach the same thing a different way and give us an F if we didn't do it that way. It's no wonder I hated math from that.

In College we're taught C#.NET with heavy emphasis on boilerplate code. I understood it, but it never made sense to me why there was only one rigid way of doing it. I was thinking in levels of abstraction of how we could simplify all of this and mitigate the need for all this junk code.

I'd effectively derived the basics of functional programming in my head thinking of ways to fix C#, but I never realized that until a few years later.

I wanted the freedom of art and music in my work, and I hated all the rules and regulations. I found Ruby which led me down a rabbit hole to LISP. It just made sense. No one told you how to do something, you could make it up, even the programming language was up for grabs. It was beautiful. It just made sense.

For a creative type, I would argue that functional programming is incredibly liberating. It's not a matter of ease for some newbies, it's a matter of feel. I would rather feel in control than have to follow a strict rules set.

The more abstract and creative you are, the more you tend to detest most imperative methods, at least in my experience. Your mileage may vary.

Now then, how to transition, or best languages:

From Imperative to Functional - Ruby. It gets your feet wet in a hybrid environment and introduces you to some functional concepts such as map, reduce, iterators, blocks, procs, and the like.

From Scratch to Functional - Scheme. MIT does one heck of a job explaining it in their video courses online, 'The Little Schemer' is an excellent book to get started.

Again, my experiences are rather odd to most, so again your mileage can and probably will vary.

[sepp2k]

jon.kiparsky, on 17 October 2012 - 07:32 AM, said:

Other reasons like the haskell programmers?

Haskell programmers are a two edge sword: On one hand they really are a friendly bunch and happy to explain stuff in detail to anyone who'll listen. On the other hand they are terribly prone to go off on tangents and use the most mathy and obscure category theory terms for the simplest concepts, which can make many newbies soil their pants in fear. Also they tend to over-abstract things (not unlike some Java developers), making typical Haskell code somewhat difficult to read for newcomers. They also often overvalue conciseness.

As for properties of the language itself: It is very difficult to write programs using IO without having first understood monads. That's the flip side of laziness. I'm dreaming of a beginner-friendly lazy language that's built around declarative GUIs¹ instead of Console IO, thus avoiding the need for Monads (or a World type) until you need to do file IO.

Another language-related problem is the power of the type system which is often used to its full extent by libraries, leading to type signatures that only someone with a PhD in type theory can understand² (exaggerating). This is also driven by the need to make everything as generic as possible. Scala also suffers from this.

Also the tendency of library designers to name stuff of category theory concepts instead of giving functions names that signify their use (related to my points about the community above).

¹ Really I think that more newbie-friendly approaches to GUIs are needed in general. Nobody wants to create console applications these days - the only reason why newbies start out by making console applications is because it's so much easier; it shouldn't be. I'm dreaming of a language where all you need to write are a bunch of ordinary function definitions and the language automatically creates a GUI for you that allows you to call your functions and inspect the results. It would then offer a way for you to add annotations to affect the look, layout and behavior of the GUI, but all you'd need to get started are your function definitions.

² Case in point: This monster, which I just wrote today to see whether I could, making me part of the problem, I suppose.

[sepp2k]

Oh and regarding higher order functions: It's definitely true that you won't appreciate them until you've experienced the need for them yourself. But I'm not advocating getting newbies started with higher order functions. I'm advocating¹ getting newbies (or at least those newbies that have an easier time with recursion than loops) started in a side-effect free environment where they use recursion to solve their problems. This way they don't have to learn about mutation and loops.

Once they've gained experience working this way and have written their fair share of repetitive code, you can show them how to abstract that code using higher-order functions and they'll hopefully appreciate it.

¹ Really not so much advocating as saying it would be an interesting experiment to try this.

[Lemur]

But I like console applications. I rather detest gui programs, they get in the way of me getting things done. The time I spend on wrong a form would be better used to improve functionality. This coming from the sysadmin and networking crazy.

I consider functional language to be comparable to learning languages themselves. Imperative is English, too many rules and regulations that frankly make it a pain to ever learn, but if you grew up in it you never really see why that's bad until you learn another language. I just find functional languages so much more elegant.

[sepp2k]

Lemur, on 17 October 2012 - 09:17 AM, said:

But I like console applications.

Yeah, but then you're talking about scriptable console applications applications, right? I.e. ones that you can easily use in the middle of a series of pipes. Not the kinds of console programs that newcomers write where they ask for input from stdin (with prompts written to stdout and all) and then read a random char at the end to keep the window open.

Quote

The time I spend on wrong a form would be better used to improve functionality. This coming from the sysadmin and networking crazy.

"wrong" == "writing"? If so that point is kind of moot in my hypothetical scenario where you don't actually need to write any GUI code to get a(n ugly) GUI.

The point is that writing IO code (whether it's creating GUIs or reading input from stdin and converting it to the proper type) is the boring part of programming, and in case of lazy languages also the complicated part. If this bit can be automated for you, a lot is gained in terms of productivity (especially in cases where it really doesn't matter that the UI should look good).

Of course it would also be possible to come up with a declarative framework for writing certain kinds of console apps without doing any IO explicitly...

[baavgai]

I'm NOT a functional programmer. I'd like to be. I dip my toe in occasionally. But my head ain't quite there yet.

That said, do you SQL extensively and when I do, I avoid procedural crutches. Many programmers hate SQL or simply suck at it. I suspect this is because imperative programmers always want to use their paradigm in a declarative world. I'm also a big fan of XSLT; same problem.

Python gives me just the amount of functional I'm willing to deal with. I love list comprehensions and use them any chance I get. I often feel I've failed if I have to call append. It happens, but less often than you might think. Here's some code on my screen right now.

def getFiles(self):
	def toFile(row):
		file_name, size, mtime, file_hash_id, hash_value = row
		fileHash = None
		if file_hash_id:
			fileHash = FileHash(file_hash_id, hash_value)
		return File(self, file_name, size, mtime, fileHash)
			
	rows = dbExec("""
		select file_name, size, mtime, file_hash_id, hash_value
		from vw_file
		where file_path_id=?
		""", (self.id, ) )
	return [ toFile(row) for row in rows ]

Sure, I could have declared list, looped, appended; but why? Could just be a style thing, but this makes me happier.

I like throwing around function references without messing with some of the cruft other languages force on me. Python does this well, Javascript actually does this better. C# is close if you like some of the recent functional upgrades.

I'd write jon's list as l = [ random.randrange (0,101, 1) for i in range(5) ]. Is it clearer? Depends. The syntax is can be challenging if you've never encountered it. If you're familiar with it, then it's probably preferable.

I favor traditional loops to answer questions, since a loop is almost certainly part of the curriculum. If the querent offers a list comprehension in their code, then all bets are off. Same rules for passing a function reference, or a lambda, or any other neat element that may come for left field. In C style languages, I give the same consideration to ternary expressions.

That said, I will chuck these things at people I know won't know them; in small doses. I believe it's better to encounter such ideas in code you care about, like something you're struggling to get done. Seeing them in action in code your really want to read facilitates learning.

It would be presumptuous not to share things you think might be hard. Rather, you throw them out there and if you get back a "please explain that strange thingy," you do. Hiding the "hard" stuff may not be doing any favors. Better to get it in smaller, more easily digestible, doses.

[mojo666]

Quote

if you're learning a language like python, scala, lisp, clojure, etc - what's easy? What's hard?

When I do excersizes in a class on functional programming, I find them very easy and natural. But coming from an imperative background, I have trouble thinking functionally in my day to day programming. The scala class would probably be impossible for me if we had to code those assignments from scratch. So, if the environment is already set to accept a functional solution then I would find that preferable to iterative solutions. However, if I also have to set up the environment, then I would revert back to imperative thinking from start to finish.

baavgai, on 17 October 2012 - 05:16 AM, said:

I'm also a big fan of XSLT; same problem.

I've become somewhat proficient in XSLT 1.0 due to my company using microsoft's integration product "Biztalk". If you want a prime example of iterative programmers screwing up a functional language I would suggest taking a look at that product. They try to make mapping easier for the user by giving us a drag-and-drop environment that they translate into XSLT, but tools are klunky to use and the resulting xslt code is hideous. For a simple example, if I want to do the following:

<xsl:element name="newelem">
  <xsl:value-of select="parent[child/name='mojo']/child/value" />
</xsl:element>

their functoids instead produce something like the following.

<xsl:for-each select="parent/child">
  <xsl:if test="name='mojo'">
    <newelem>
      <xsl:value-of select="value" />
    </newelem>
  </xsl:if>
</xsl:for-each>

A lot of their functoids also perform the same operation as xslt functions, but they opt to use c# scripts instead. I often end up just writing XSLT from scratch.