7 ms·

"Sequential programming is dead. So stop teaching it"

52 points by jaydub 18y ago

morbidkk 18y ago
so java programmers get deep into java.util.concurrent
- crabapple 18y ago
  no, java programmers pick up haskell is more likely.
  - jimbokun 18y ago
    no, clojure
    - crabapple 18y ago
      no, haskell. clojure in the end runs on the jvm. the ghc compiler has parallelism baked into it in a fundamental way. don't get me wrong, i like clojure, but it won't be better for multicore until the jvm is better for multicore
axod 18y ago
dead??? Not sure about that one. There is more to programming than just multicore server backend stuff. Regardless, you don't "stop teaching it", you just teach more related to multi-core architectures if those do start to become more prevalent.
festivusr 18y ago
Aside from the inflammatory headline, what the article seems to be saying is "teach more about concurrent programming during early software programming courses," which seems reasonable enough. Like pointers, concurrent programming concepts seem to be a tough pill for some CS students.
- apgwoz 18y ago
  I'm not sure how you can talk about concurrency without talking about locks and other such topics, which I think is very ambitious for new programmers. However, if universities start teaching programming with pure functional languages (which is highly unlikely), concurrency becomes a much easier topic for discussion. Perhaps this is the sort of thinking that will lead to more universities adopting something like PLT Scheme, which in recent versions, has moved the notion of mutable pairs into a library. Doing this might bring functional languages out of academia and more into the mainstream, which would be fantastic. I remember fellow students having trouble grasping pointers, even after a 2nd year architecture course, which I thought was completely absurd since they were writing assembly code without tremendous strain.
  - stcredzero 18y ago
    Often when competent programmers are having trouble grasping pointers, they are actually doing fine with thinking about pointers in abstract, but having trouble with the notation describing a particular instance of them. (Especially with C programs.) One of the things that doing good OO and following the Law of Demeter does for you is to reduce the levels of indirection you have to deal with to one or two.
    - lallysingh 18y ago
      What really helps in that situation is a good debugger, that lets you quickly look up blocks of memory (e.g. where the pointer references). Obviously it should be stable enough to handle bad pointers (giving an error message instead of crashing is nice). The old CodeWarrior debugger was great for this. Lots of windows you could pop up for every in-memory object you cared about. sigh
      - a-priori 18y ago
        You should take a look at ddd. I've never used CodeWarrior, but from your description it sounds a lot like ddd.
swombat 18y ago
That's ridiculous. Programming is not all about multi-core performance. Also, programs do not all need to directly implement parallelism to be performant. The architecture can support parallel processing with sequential languages. A great example of that is Rails, when set up with mongrel processes, each of which can run on its own core if necessary. Hyperbole, hyperbole, hyperbole <-- summary of this article.
- crabapple 18y ago
  That's ridiculous. Programming is not all about multi-core performance. it will be. you're getting beaten over the head by chip designers telling you that your future cpu is going to consist of a (possibly large) array of processing cores with a high-capacity bus connecting them. they are telling you this is the only way they can give you higher performance. you had better start believing them because these systems are starting to get delivered now. A great example of that is Rails, when set up with mongrel processes, each of which can run on its own core if necessary ?????? so mongrel comes with its own OS kernel that has better support for multicore than linux and freebsd? wow!! coolzzz!
  - swombat 18y ago
    I don't write OS kernels, I write rails application. I don't give a rat's ass about the OS kernel. I don't even give a rat's ass about how Mongrel is programmed. The Rails applications themselves don't need to be altered to run in a multi-core environment. Mongrel naturally scales to as many servers or CPUs as you want to run it on, since there is no interaction between different mongrel instances, all that happens at the database. Let me make that point even clearer: I don't give a shit how the database has been programmed. Someone there has obviously had to think about parallelism, but I don't need to, because I'm not writing a fricken database. Got it?
    - crabapple 18y ago
      I don't write OS kernels, I write rails application. I don't give a rat's ass about the OS kernel then stop spouting off uninformed comments about how processes are scheduled The Rails applications themselves don't need to be altered to run in a multi-core environment. nor do any other program compiled for that architecture. its the OS that schedules processes, not your userland program. the point is, some programs can be written in a way that makes it easier for the OS to exploit multicore. since ruby is not a functional language, my guess is that it would tend to not help the kernel exploit these resources. but obviously in the worst case, a process can run inside one core and never get the advantages of the rest of the chip architecture. this is about exploiting multicore Got it? yes, i get that you know very little about how computers function
drewr 18y ago
Perfect timing. My copy of JCIP came in the mail yesterday.
snorkel 18y ago
Parallelism still costs overhead. Concurrency is not free so you have to weigh the cost/benefit before deciding to use sequential or parallel for the task at hand.
ntoshev 18y ago
How can you teach concurrent programming without teaching sequental programming first?
- tjr 18y ago
  Teach them concurrently?
13ren 18y ago
Many-core overshoots needed performance for most uses. Hence the rise in sub-notebooks, iPhones, best-selling games console being by far the least powerful console (wii). + Concurrency is a unsolved problem. There are locks etc; there's smalltalk/Erlang pure-message passing and Web Services/SOA (it's concurrency). Concurrency is of academic interest, and niche apps (game engines; simulations; etc. = unsolved problem that is not needed... so far, anyway
deleted 18y ago
[deleted]
cabalamat 18y ago
Rumours of its death have been exaggerated. 99% of programming is sequential.
- 13ren 18y ago
  Well, he did say it was a diktat, which I had to lookup: http://www.tfd.com/diktat http://www.tfd.com/diktat
wheels 18y ago
In other news, Microsoft announces that UNIX is dead, so it should not be taught anymore.
sherl0ck 18y ago
I recently read the other thread, that IE 6 won't go anywhere, so it's the same with sequential programming. I don't think it won't be dead.
Tichy 18y ago
The purpose of programming is not to maximize performance of Intel CPUs. If I want to calculate 1+1 or sqrt(2), why should I bother with parallel algorithms. Also, a lot of the time there will just be parallel threads exploiting the cores (like multiple applications running on an OS). What would be interesting would be a kind of "complex systems" programming, stuff like cellular automata, but maybe it is impossible to make them tractable enough. Also, aren't the most performant "parallel computations" simply specialized matrix operations. I am not sure if learning specialized and hard to understand programming languages for parallel computation are the best way forward.
rgrieselhuber 18y ago
This ignores the millions of single core/processor, embedded systems out there (and surely also represent a growing industry.
mattmaroon 18y ago
In a nutshell "we moved our product in a direction that is largely useless. Please help us."
bpyne 18y ago
The idea of solving problems by breaking down solution steps and running them in parallel is exciting. However, identifying areas where the solution to a problem can be parallelized is the largest problem. As critical is analyzing whether or not the administrative overhead that goes along with parallelization is going to negate the benefit. Put more succinctly, computer science curricula should emphasize this kind of analysis well before introducing the techniques for achieving parallelization. Donald Knuth's skepticism over the benefits of concurrency makes me want to rethink my own assumptions. I haven't really seen anyone describe the changes that should be made to curricula. Do any educators on this thread have specific changes in mind?
projectileboy 18y ago
"People aren't using the hardware you're building. So stop building it."
wolfmurphy 18y ago
What I delightful thread. I am indirectly part of the creation of this inflammatory headline. It comes from the Panel discussion we are holding next Monday evening at SC08 in Austin. The panel's title is "There Is No More Sequential Programming! Why Are We Still Teaching It?" It is a complex issue. I taught myself to program at 16 to play blackjack. 41 years later, I am still creating and playing games (not video games). For over thirty years I worked for supercomputer companies. Along the way, I went to grad school and formalized my education. I believe my experience is not atypical. My students who succeed as CS are ones who at some point have a passion to solve a problem and are intent on gaining the skills to do it. Some start from flow charts and pseudo code; some start by debugging an empty file. What does this mean for this discussion? I don't care whether we view sequential as a special case of parallel; or parallel as a special case of sequential. Ideally, I'm going to help my students have the thinking skills and the experience to solve interesting problems by cutting code with threads, with MPI calls, via Cuda, or just with other code. But there is no question that many of the rarified programming skills of my supercomputer days are fast becoming everyday programming skills.
PaulSteinberg 18y ago
As the instigator of the offending post, I am delighted to see the discussion. I am down at Supercomputing 08 with Tom and others and we will be discussing this topic on a panel this evening,. The discussants include NVIDIA and Intel (and SUN and IBM and AMD) so clearly this is an issue of concern to ALL computer manufacturers. If you are in Austin - come to room 10B this evening (Monday, Nov 17). If you are not, we are doing a live webcast on the subject http://is.gd/7Rvz http://is.gd/7Rvz on Thursday Nov 20. I would love to be able to carry discussion on this topic further. One idea would be an open forum using some kind of internet voice/text app. Not sure which yet. I know I could drag some Intel folks and I'm pretty sure I could get a few folks from elsewhere in the industry and acacdemia to join in. Maybe we could even make this a semi-regular and continuing discussion on broader topics – you guys clearly have both the opinions and the savvy. So let me know -post something on my blog if you like the idea http://is.gd/7RyX http://is.gd/7RyX and we'll figure out how to make it happen. .

52 points by jaydub 18y ago

morbidkk 18y ago

so java programmers get deep into java.util.concurrent

crabapple 18y ago
no, java programmers pick up haskell is more likely.
- jimbokun 18y ago
  no, clojure
  - crabapple 18y ago
    no, haskell. clojure in the end runs on the jvm. the ghc compiler has parallelism baked into it in a fundamental way. don't get me wrong, i like clojure, but it won't be better for multicore until the jvm is better for multicore

axod 18y ago

dead??? Not sure about that one. There is more to programming than just multicore server backend stuff. Regardless, you don't "stop teaching it", you just teach more related to multi-core architectures if those do start to become more prevalent.

festivusr 18y ago

Aside from the inflammatory headline, what the article seems to be saying is "teach more about concurrent programming during early software programming courses," which seems reasonable enough. Like pointers, concurrent programming concepts seem to be a tough pill for some CS students.

apgwoz 18y ago
I'm not sure how you can talk about concurrency without talking about locks and other such topics, which I think is very ambitious for new programmers. However, if universities start teaching programming with pure functional languages (which is highly unlikely), concurrency becomes a much easier topic for discussion. Perhaps this is the sort of thinking that will lead to more universities adopting something like PLT Scheme, which in recent versions, has moved the notion of mutable pairs into a library. Doing this might bring functional languages out of academia and more into the mainstream, which would be fantastic. I remember fellow students having trouble grasping pointers, even after a 2nd year architecture course, which I thought was completely absurd since they were writing assembly code without tremendous strain.
- stcredzero 18y ago
  Often when competent programmers are having trouble grasping pointers, they are actually doing fine with thinking about pointers in abstract, but having trouble with the notation describing a particular instance of them. (Especially with C programs.) One of the things that doing good OO and following the Law of Demeter does for you is to reduce the levels of indirection you have to deal with to one or two.
  - lallysingh 18y ago
    What really helps in that situation is a good debugger, that lets you quickly look up blocks of memory (e.g. where the pointer references). Obviously it should be stable enough to handle bad pointers (giving an error message instead of crashing is nice). The old CodeWarrior debugger was great for this. Lots of windows you could pop up for every in-memory object you cared about. sigh
    - a-priori 18y ago
      You should take a look at ddd. I've never used CodeWarrior, but from your description it sounds a lot like ddd.

swombat 18y ago

That's ridiculous. Programming is not all about multi-core performance. Also, programs do not all need to directly implement parallelism to be performant. The architecture can support parallel processing with sequential languages. A great example of that is Rails, when set up with mongrel processes, each of which can run on its own core if necessary. Hyperbole, hyperbole, hyperbole <-- summary of this article.

crabapple 18y ago
That's ridiculous. Programming is not all about multi-core performance. it will be. you're getting beaten over the head by chip designers telling you that your future cpu is going to consist of a (possibly large) array of processing cores with a high-capacity bus connecting them. they are telling you this is the only way they can give you higher performance. you had better start believing them because these systems are starting to get delivered now. A great example of that is Rails, when set up with mongrel processes, each of which can run on its own core if necessary ?????? so mongrel comes with its own OS kernel that has better support for multicore than linux and freebsd? wow!! coolzzz!
- swombat 18y ago
  I don't write OS kernels, I write rails application. I don't give a rat's ass about the OS kernel. I don't even give a rat's ass about how Mongrel is programmed. The Rails applications themselves don't need to be altered to run in a multi-core environment. Mongrel naturally scales to as many servers or CPUs as you want to run it on, since there is no interaction between different mongrel instances, all that happens at the database. Let me make that point even clearer: I don't give a shit how the database has been programmed. Someone there has obviously had to think about parallelism, but I don't need to, because I'm not writing a fricken database. Got it?
  - crabapple 18y ago
    I don't write OS kernels, I write rails application. I don't give a rat's ass about the OS kernel then stop spouting off uninformed comments about how processes are scheduled The Rails applications themselves don't need to be altered to run in a multi-core environment. nor do any other program compiled for that architecture. its the OS that schedules processes, not your userland program. the point is, some programs can be written in a way that makes it easier for the OS to exploit multicore. since ruby is not a functional language, my guess is that it would tend to not help the kernel exploit these resources. but obviously in the worst case, a process can run inside one core and never get the advantages of the rest of the chip architecture. this is about exploiting multicore Got it? yes, i get that you know very little about how computers function

drewr 18y ago

Perfect timing. My copy of JCIP came in the mail yesterday.

snorkel 18y ago

Parallelism still costs overhead. Concurrency is not free so you have to weigh the cost/benefit before deciding to use sequential or parallel for the task at hand.

ntoshev 18y ago

How can you teach concurrent programming without teaching sequental programming first?

tjr 18y ago
Teach them concurrently?

13ren 18y ago

Many-core overshoots needed performance for most uses. Hence the rise in sub-notebooks, iPhones, best-selling games console being by far the least powerful console (wii). + Concurrency is a unsolved problem. There are locks etc; there's smalltalk/Erlang pure-message passing and Web Services/SOA (it's concurrency). Concurrency is of academic interest, and niche apps (game engines; simulations; etc. = unsolved problem that is not needed... so far, anyway

deleted 18y ago

[deleted]

cabalamat 18y ago

Rumours of its death have been exaggerated. 99% of programming is sequential.

13ren 18y ago
Well, he did say it was a diktat, which I had to lookup: http://www.tfd.com/diktat http://www.tfd.com/diktat

wheels 18y ago

In other news, Microsoft announces that UNIX is dead, so it should not be taught anymore.

sherl0ck 18y ago

I recently read the other thread, that IE 6 won't go anywhere, so it's the same with sequential programming. I don't think it won't be dead.

Tichy 18y ago

The purpose of programming is not to maximize performance of Intel CPUs. If I want to calculate 1+1 or sqrt(2), why should I bother with parallel algorithms. Also, a lot of the time there will just be parallel threads exploiting the cores (like multiple applications running on an OS). What would be interesting would be a kind of "complex systems" programming, stuff like cellular automata, but maybe it is impossible to make them tractable enough. Also, aren't the most performant "parallel computations" simply specialized matrix operations. I am not sure if learning specialized and hard to understand programming languages for parallel computation are the best way forward.

rgrieselhuber 18y ago

This ignores the millions of single core/processor, embedded systems out there (and surely also represent a growing industry.

mattmaroon 18y ago

In a nutshell "we moved our product in a direction that is largely useless. Please help us."

bpyne 18y ago

The idea of solving problems by breaking down solution steps and running them in parallel is exciting. However, identifying areas where the solution to a problem can be parallelized is the largest problem. As critical is analyzing whether or not the administrative overhead that goes along with parallelization is going to negate the benefit. Put more succinctly, computer science curricula should emphasize this kind of analysis well before introducing the techniques for achieving parallelization. Donald Knuth's skepticism over the benefits of concurrency makes me want to rethink my own assumptions. I haven't really seen anyone describe the changes that should be made to curricula. Do any educators on this thread have specific changes in mind?

projectileboy 18y ago

"People aren't using the hardware you're building. So stop building it."

wolfmurphy 18y ago

What I delightful thread. I am indirectly part of the creation of this inflammatory headline. It comes from the Panel discussion we are holding next Monday evening at SC08 in Austin. The panel's title is "There Is No More Sequential Programming! Why Are We Still Teaching It?" It is a complex issue. I taught myself to program at 16 to play blackjack. 41 years later, I am still creating and playing games (not video games). For over thirty years I worked for supercomputer companies. Along the way, I went to grad school and formalized my education. I believe my experience is not atypical. My students who succeed as CS are ones who at some point have a passion to solve a problem and are intent on gaining the skills to do it. Some start from flow charts and pseudo code; some start by debugging an empty file. What does this mean for this discussion? I don't care whether we view sequential as a special case of parallel; or parallel as a special case of sequential. Ideally, I'm going to help my students have the thinking skills and the experience to solve interesting problems by cutting code with threads, with MPI calls, via Cuda, or just with other code. But there is no question that many of the rarified programming skills of my supercomputer days are fast becoming everyday programming skills.

PaulSteinberg 18y ago

As the instigator of the offending post, I am delighted to see the discussion. I am down at Supercomputing 08 with Tom and others and we will be discussing this topic on a panel this evening,. The discussants include NVIDIA and Intel (and SUN and IBM and AMD) so clearly this is an issue of concern to ALL computer manufacturers. If you are in Austin - come to room 10B this evening (Monday, Nov 17). If you are not, we are doing a live webcast on the subject http://is.gd/7Rvz http://is.gd/7Rvz on Thursday Nov 20. I would love to be able to carry discussion on this topic further. One idea would be an open forum using some kind of internet voice/text app. Not sure which yet. I know I could drag some Intel folks and I'm pretty sure I could get a few folks from elsewhere in the industry and acacdemia to join in. Maybe we could even make this a semi-regular and continuing discussion on broader topics – you guys clearly have both the opinions and the savvy. So let me know -post something on my blog if you like the idea http://is.gd/7RyX http://is.gd/7RyX and we'll figure out how to make it happen. .