8 Replies - 1250 Views - Last Post: 20 August 2018 - 08:24 AM

#1 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 6404
  • View blog
  • Posts: 21,972
  • Joined: 05-May 12

Eric Lippert's Arrays considered somewhat harmful

Post icon  Posted 17 August 2018 - 07:17 PM

I stumbled across this again today while I was looking for something else Eric Lippert wrote.

Arrays considered somewhat harmful

For me what jumped out was:

Quote

Coding which is more declarative than imperative, coding which avoids side effects, coding which emphasizes algorithms and purposes over mechanisms, that kind of coding is the future in a world of parallelism.


But of course, this is contrary to how programming is currently taught. Imperative programming is at the core of data structures and algorithms classes. Mutable structures and arrays abound in most beginning programming classes. Micromanaging things is taught in our operating systems and networking classes.

Eric does acknowledge that teaching is a hard problem and he is glad that it's not his problem to solve.

This post has been edited by macosxnerd101: 19 August 2018 - 07:18 PM
Reason for edit:: Featured


Is This A Good Question/Topic? 1
  • +

Replies To: Eric Lippert's Arrays considered somewhat harmful

#2 jon.kiparsky   User is offline

  • Beginner
  • member icon


Reputation: 11204
  • View blog
  • Posts: 19,203
  • Joined: 19-March 11

Re: Eric Lippert's Arrays considered somewhat harmful

Posted 17 August 2018 - 09:37 PM

View PostSkydiver, on 17 August 2018 - 09:17 PM, said:

Imperative programming is at the core of data structures and algorithms classes. Mutable structures and arrays abound in most beginning programming classes. Micromanaging things is taught in our operating systems and networking classes.


Well, there's an obvious reason for this. Two of them, actually. The first obvious reason is that there's a very heavy academic tradition descended from Knuth via Sedgewick, and generations of programmers and teachers have learned in this model. Devising a new model would be an interesting challenge, but I don't know that anyone's really made that effort as yet, or how much luck they've had, or how much uptake they'd get.
The second obvious reason sort of dovetails with the first, and that's the dirty little truth that imperative programming is easier to learn and easier to reason about than functional programming, particularly when you're trying to think in algorithmic terms. People just seem to be better at reasoning about loops than recursions.
Of course, I'm not saying "imperative roolz, functional droolz" or anything of that sort, but the fact is that for all the claims that FP advocates make, readability and clarity are not features that most programmers associate with functional programming, particularly when they're trying to learn the fundamentals of computing.

I mean, it is probably worth taking a minute to consider that all of the best explanations of functional programming concepts are given in terms of imperative programming models. Is it really surprising that we start out with the concept that the beginner can grasp most easily?

Quote

Eric does acknowledge that teaching is a hard problem and he is glad that it's not his problem to solve.


Well, yes. But that feels like sort of a cop-out to me.
Was This Post Helpful? 1
  • +
  • -

#3 baavgai   User is offline

  • Dreaming Coder
  • member icon


Reputation: 7234
  • View blog
  • Posts: 15,075
  • Joined: 16-October 07

Re: Eric Lippert's Arrays considered somewhat harmful

Posted 18 August 2018 - 12:24 AM

Quote

Coding which is more declarative than imperative, coding which avoids side effects, coding which emphasizes algorithms and purposes over mechanisms, that kind of coding is the future in a world of parallelism.

The funny thing is, this isn't really controversial in any way. The OOP honeymoon has been over for years. A hardware reality where it's easier to have more processors than more monolithic power has made parallelism a more practical concern.

Imperative programming is also the default because, really, that's how computers actually think: Mutability is what makes a computer a computer: sequential operations, moving values in and out of registers, etc. Knuth wrote code for a computer that didn't exist, as did many of his contemporaries, imagining a machine where the basic rules of I/O were understood.

It always struck me as curious that the declarative camp did have a foot hold in academia. MIT went with the Wizard Book. However, this was TOO academic and didn't seem practical at the time. Times have changed.
Was This Post Helpful? 0
  • +
  • -

#4 sepp2k   User is offline

  • D.I.C Lover
  • member icon

Reputation: 2639
  • View blog
  • Posts: 4,210
  • Joined: 21-June 11

Re: Eric Lippert's Arrays considered somewhat harmful

Posted 18 August 2018 - 04:45 AM

View Postjon.kiparsky, on 18 August 2018 - 06:37 AM, said:

I mean, it is probably worth taking a minute to consider that all of the best explanations of functional programming concepts are given in terms of imperative programming models.


They are? Can you give an example of that?
Was This Post Helpful? 0
  • +
  • -

#5 jon.kiparsky   User is offline

  • Beginner
  • member icon


Reputation: 11204
  • View blog
  • Posts: 19,203
  • Joined: 19-March 11

Re: Eric Lippert's Arrays considered somewhat harmful

Posted 18 August 2018 - 08:26 PM

Well, examples abound. I don't know of any introduction to functional programming outside of TLS or SICP that doesn't assume imperative concepts and constructs, and those are weird cases*. Maps and fiilers and sums are explained in terms of loops over collections, mutability and the problems thereof are shown in terms of mutable objects like arrays, etc.
In a way, this is sort of an unfair claim, since really every introduction to FP that I know is aimed at people who have already learned the Bad Ways, and so it's being introduced as a contrast to that, and obviously we use the concepts that we expect the students to know. So it could be that the writers are just sensibly resorting to what they can expect as baseline knowledge - but this really just pushes the question back a step: why do CS programs always start with imperative programming?
It could be, as baavgai says, that it's because that's the way computers really work. That's reasonable. But I think we also don't usually start out by explaining transistors and circuits and all the electronical bits and bobs that make up the machine, and that's also the way computers really work, so I'm not really convinced by that. I think if FP were really a clearer and simpler way to think about programming, we would be starting there in general, and we aren't.

If you know of any serious attempt to introduce people to computing without going through imperative programming first, I'd be very interested in knowing about it. The closest I've managed to come is certain Prolog textbooks which do a pretty good job of introducing that language on its own merits, with no reference to or reliance on imperative languages, but of course this isn't an attempt to teach CS or computing or any of that - in fact, questions of computation are strictly avoided in those books. The books I'm thinking of are strictly an attempt to explain how Prolog expresses logical relations, so it's not quite what I'm looking for

* For one thing, both are quite dated, though they've held up well. Also, TLS is really a minimally explanatory book, more of a series of koans, and SICP implicitly assumes a high degree of programming literacy, which in the context of an intro computing course at MIT in the 1980s implies imperative programming experience. (try to imagine reading SICP as a complete computing novice...)
Was This Post Helpful? 0
  • +
  • -

#6 andrewsw   User is offline

  • Unprocessable Entity
  • member icon

Reputation: 6594
  • View blog
  • Posts: 26,832
  • Joined: 12-December 12

Re: Eric Lippert's Arrays considered somewhat harmful

Posted 19 August 2018 - 12:49 AM

I haven't used the initialism TLS (other than for the Times Literary Supplement), I believe it is in reference to The Little Schemer.
Was This Post Helpful? 2
  • +
  • -

#7 sepp2k   User is offline

  • D.I.C Lover
  • member icon

Reputation: 2639
  • View blog
  • Posts: 4,210
  • Joined: 21-June 11

Re: Eric Lippert's Arrays considered somewhat harmful

Posted 19 August 2018 - 04:32 AM

View Postjon.kiparsky, on 19 August 2018 - 05:26 AM, said:

Well, examples abound. I don't know of any introduction to functional programming outside of TLS or SICP that doesn't assume imperative concepts and constructs, and those are weird cases*.


I agree with you so far. Most materials explaining functional programming assume that the reader comes from an imperative background because that's most often the case. However I do not think that most materials explain functional features in terms of imperative features because of that - or that that would be the best way to do it.

Quote

Maps and fiilers and sums are explained in terms of loops over collections


You mean something like this?

ys = map(f, xs)
# This is equivalent to:
ys = []
for x in xs:
  ys.push(f(x))



I wouldn't have thought that that's a common way to explain these functions and I certainly don't agree that it's the best. What about "map(f, xs) returns a list containing the results of applying f to each element in xs" or maybe "map(f, [x1, ..., xn]) = [f(x1), ..., f(xn)]"? Those seem more natural to me and don't require familiarity with any imperative features.

And for sum it should just be "sum(xs) returns the sum of the elements in xs". Surely anything beyond that would be overkill.

Quote

mutability and the problems thereof are shown in terms of mutable objects like arrays, etc.


Yes, imperative programming features and their problems are best explained in terms of imperative programming.
Was This Post Helpful? 1
  • +
  • -

#8 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 6404
  • View blog
  • Posts: 21,972
  • Joined: 05-May 12

Re: Eric Lippert's Arrays considered somewhat harmful

Posted 20 August 2018 - 07:20 AM

Perhaps it's my lack of practice in writing functional code, but how would one go about writing a OS's CPU scheduler in a functional style? The only thing that I can visualize is that there is an imperative style timer based loop; or a an event handler that fires on time quota expiration or thread yield. The loop body or event handler itself can be written functionally to choose what gets to run next, but the mechanism that invokes the functional code is still imperative.
Was This Post Helpful? 0
  • +
  • -

#9 jon.kiparsky   User is offline

  • Beginner
  • member icon


Reputation: 11204
  • View blog
  • Posts: 19,203
  • Joined: 19-March 11

Re: Eric Lippert's Arrays considered somewhat harmful

Posted 20 August 2018 - 08:24 AM

View Postsepp2k, on 19 August 2018 - 06:32 AM, said:

However I do not think that most materials explain functional features in terms of imperative features because of that - or that that would be the best way to do it.


I've been looking at a lot of materials, specifically javascript tutorials about functional features of the language, aimed at newb programmers, as part of my mentoring role at Resilient Coders. It is indeed an extremely common pattern in that context. I haven't spent as much time looking at materials aimed at other languages and levels, but it's certainly something I've seen a lot of.

Whether it's the best, I suppose, is a matter of opinion, and as I said above depends a lot on your assumptions about the user's background knowledge and context. I suppose it also depends on the author's mindset. If someone came from the imperative world, they could easily find this to be the most compelling mode of explanation.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1