7 ms·

It's trivially easy to write perfectly valid looking Haskell programs that are abysmally slow because of how they are actually executed, and since the reason fo

by stiff 13y ago

It's trivially easy to write perfectly valid looking Haskell programs that are abysmally slow because of how they are actually executed, and since the reason for this can't be explained at a level of abstraction of such a course, people learn to treat the language as a closed black box, while you can't really competently use any language without understanding its execution model. Abstractions are fine, but you have to be able to switch the abstractions level when necessary and understand the bits underneath, and I think it's natural to learn starting from low abstractions level and then building up. There are many basic low level issues that surface no matter how high level is the language you are using, I am not advocating teaching assembly to beginners, but a language like C and issues like: - Direct addressing vs. indirect adressing, aka storing a value vs storing an address, aka pointers vs. values, aka call-by-value vs call-by-reference, ... Beginning programmers brought up on very high level languages are endlessly confused by the difference between copying the value and copying the reference. - Understanding the stack and how procedure calls work. It might then be easier to understand why tail recursion in functional languages is cool but non-tail recursion not so much. - Basic memory management. Why data structures are such a big deal. ... All this shows why abstraction is necessary and useful in the first place, and what it's limitations are.

tel 13y ago
It's worth noting that Djikstra (to my understanding) thought almost none of that was even contained in the field of CS. His perspective was that CS was about process and verification and proof and thus while the current implementation of computers is interesting, it didn't deserve any privilege. So being able to prove certain nice properties about algorithms without worrying about the underlying implementation is exactly what Djikstra believed important and something that Haskell does allow you to do... even if the result is abysmal performance. It's worth noting as well that there's a whole wonderful book [1] that provides a great glimpse of good Haskell style with the conceit that one should program the most abysmally slow correct thing first and then use algebraic theories to transform it along obviously correct paths to something highly performant. [1] http://www.amazon.com/Pearls-Functional-Algorithm-Design-Richard/dp/0521513383 http://www.amazon.com/Pearls-Functional-Algorithm-Design-Ric...
- SilasX 13y ago
  >His perspective was that CS was about process and verification and proof and thus while the current implementation of computers is interesting, it didn't deserve any privilege. Is that the basis for the quote about "CS isn't about computers any more than astronomy is about telescopes"? http://en.wikiquote.org/wiki/Edsger_W._Dijkstra#Disputed http://en.wikiquote.org/wiki/Edsger_W._Dijkstra#Disputed
- knz42 13y ago
  "one should program the most abysmally slow correct thing first and then use algebraic theories to transform it along obviously correct paths to something highly performant." Except that the syntactic variance problem [1] makes this impossible to do in theory. Unfortunately so long we use Turing-equivalent computers there will be a need for "performance programmers" and low-level programming because we cannot automate their job by formal transformations from high-level, "obviously correct" programs (theory proves so). [1] http://dx.doi.org/10.1145/502175.502181 http://dx.doi.org/10.1145/502175.502181
- abc_lisper 13y ago
  Well said! Understanding the machine, while useful, does not usually help you solve the problem at hand. A better approach is to teach how to create models, mental and the ones on the computer(datastructures, types etc), and show how that maps to problems at hand. Teaching how to verify models for rigor, efficiency(algorithmic), taste for elegance , and help seeing that computer science is not all that different from math, is what helps you build structures that stand the test of time.
platz 13y ago
As Brian Beckman explained, as an aside, in "Don't fear the Monad" [1], these two differing views were born in the '70s and split two programmers into two camps: The bottom-up people, and the top-down people: - The bottom-up people start with the hardware and only add abstractions and trade performance where necessary (fortran, c, java) - The top-down people started with perfect abstraction/logic and reduced/removed abstraction to get access to the hardware and performance where necessary (lisp, ml, haskell) I don't think the two camps may ever get along. Kind of like our version of Conservative and Liberal. (nor should they, in the true spirit of democracy?) [1] http://www.youtube.com/watch?v=ZhuHCtR3xq8 http://www.youtube.com/watch?v=ZhuHCtR3xq8
- dded 13y ago
  > The bottom-up people [...] only add abstractions [later] I don't think bottom-up verses top-down are like political camps. I think it's more innate, like right-brained vs. left-brained. I can't understand abstractions till I first understand the lower level. I could never learn algebra without first learning arithmetic. (BTW, I'm old enough to have lived through the New Math philosophy which insisted that every grade school text book start with a chapter on set theory before moving on to, say, fractions.) This doesn't mean that I can't start with a functional model, but it does mean that I start with simple functions and move up.
  - kazagistar 13y ago
    I don't think anyone understands abstractions right away. Most people learn through examples, and have to recreate the abstractions themselves, even if the abstraction is explained as well as possible. I think the main difference is purely in which abtraction people prefer to think in (imperative, OOP, functional, etc) but everyone wants to turn it into something else because to them, their model "feels" more right.
  - platz 13y ago
    Good points, didn't know about New Math, but the failure is very insightful. I'm not sure if perhaps there should be a distinction between operational abstractions vs logical abstractions. Scripting seems sit in a strange middle ground. Scripting languages tend to be very high level, but are often very approachable for beginners, e.g. Logo
btian 13y ago
Changing naive recursion to tail recursion is a very common optimization in functional language compilers.
- deleted 13y ago
  [deleted]
stcredzero 13y ago
people learn to treat the language as a closed black box, while you can't really competently use any language without understanding its execution model. I wonder if there isn't an opportunity here. Azul's Zing VM's incremental GC basically compensates for cluelessness about how to architect and tune a GC'd language project for high performance. The first reaction might be against such cluelessness, but isn't GC that doesn't require arcane knowledge for high performance a better GC, according to the goals that GC was developed for in the first place?

by stiff 13y ago

tel 13y ago

It's worth noting that Djikstra (to my understanding) thought almost none of that was even contained in the field of CS. His perspective was that CS was about process and verification and proof and thus while the current implementation of computers is interesting, it didn't deserve any privilege. So being able to prove certain nice properties about algorithms without worrying about the underlying implementation is exactly what Djikstra believed important and something that Haskell does allow you to do... even if the result is abysmal performance. It's worth noting as well that there's a whole wonderful book [1] that provides a great glimpse of good Haskell style with the conceit that one should program the most abysmally slow correct thing first and then use algebraic theories to transform it along obviously correct paths to something highly performant. [1] http://www.amazon.com/Pearls-Functional-Algorithm-Design-Richard/dp/0521513383 http://www.amazon.com/Pearls-Functional-Algorithm-Design-Ric...

SilasX 13y ago
>His perspective was that CS was about process and verification and proof and thus while the current implementation of computers is interesting, it didn't deserve any privilege. Is that the basis for the quote about "CS isn't about computers any more than astronomy is about telescopes"? http://en.wikiquote.org/wiki/Edsger_W._Dijkstra#Disputed http://en.wikiquote.org/wiki/Edsger_W._Dijkstra#Disputed
knz42 13y ago
"one should program the most abysmally slow correct thing first and then use algebraic theories to transform it along obviously correct paths to something highly performant." Except that the syntactic variance problem [1] makes this impossible to do in theory. Unfortunately so long we use Turing-equivalent computers there will be a need for "performance programmers" and low-level programming because we cannot automate their job by formal transformations from high-level, "obviously correct" programs (theory proves so). [1] http://dx.doi.org/10.1145/502175.502181 http://dx.doi.org/10.1145/502175.502181
abc_lisper 13y ago
Well said! Understanding the machine, while useful, does not usually help you solve the problem at hand. A better approach is to teach how to create models, mental and the ones on the computer(datastructures, types etc), and show how that maps to problems at hand. Teaching how to verify models for rigor, efficiency(algorithmic), taste for elegance , and help seeing that computer science is not all that different from math, is what helps you build structures that stand the test of time.

platz 13y ago

As Brian Beckman explained, as an aside, in "Don't fear the Monad" [1], these two differing views were born in the '70s and split two programmers into two camps: The bottom-up people, and the top-down people: - The bottom-up people start with the hardware and only add abstractions and trade performance where necessary (fortran, c, java) - The top-down people started with perfect abstraction/logic and reduced/removed abstraction to get access to the hardware and performance where necessary (lisp, ml, haskell) I don't think the two camps may ever get along. Kind of like our version of Conservative and Liberal. (nor should they, in the true spirit of democracy?) [1] http://www.youtube.com/watch?v=ZhuHCtR3xq8 http://www.youtube.com/watch?v=ZhuHCtR3xq8

dded 13y ago
> The bottom-up people [...] only add abstractions [later] I don't think bottom-up verses top-down are like political camps. I think it's more innate, like right-brained vs. left-brained. I can't understand abstractions till I first understand the lower level. I could never learn algebra without first learning arithmetic. (BTW, I'm old enough to have lived through the New Math philosophy which insisted that every grade school text book start with a chapter on set theory before moving on to, say, fractions.) This doesn't mean that I can't start with a functional model, but it does mean that I start with simple functions and move up.
- kazagistar 13y ago
  I don't think anyone understands abstractions right away. Most people learn through examples, and have to recreate the abstractions themselves, even if the abstraction is explained as well as possible. I think the main difference is purely in which abtraction people prefer to think in (imperative, OOP, functional, etc) but everyone wants to turn it into something else because to them, their model "feels" more right.
- platz 13y ago
  Good points, didn't know about New Math, but the failure is very insightful. I'm not sure if perhaps there should be a distinction between operational abstractions vs logical abstractions. Scripting seems sit in a strange middle ground. Scripting languages tend to be very high level, but are often very approachable for beginners, e.g. Logo

btian 13y ago

Changing naive recursion to tail recursion is a very common optimization in functional language compilers.

deleted 13y ago
[deleted]

stcredzero 13y ago

people learn to treat the language as a closed black box, while you can't really competently use any language without understanding its execution model. I wonder if there isn't an opportunity here. Azul's Zing VM's incremental GC basically compensates for cluelessness about how to architect and tune a GC'd language project for high performance. The first reaction might be against such cluelessness, but isn't GC that doesn't require arcane knowledge for high performance a better GC, according to the goals that GC was developed for in the first place?