| |||||||||||||
GCC and static analysisGCC and static analysisPosted Apr 22, 2012 12:09 UTC (Sun) by khim (subscriber, #9252)In reply to: GCC and static analysis by KSteffensen Parent article: GCC and static analysis
Experience. I've teached CS at one time and we had functional programming as a mandatory course (toy simplified language, nothing too fancy). Small group of students took to it immediately and did everything in very short amount of time (later we added quite a bunch of optional tasks to make sure they'll have things to do in the course). Yet significant percentage of students were never able to do even simple things in the course without extereme struggles and it often looked that they employ “combinatorial programming” (shuffle symbols and variable names around till you'll get working program by some random chance). Many of them went on to become SWE.
(Log in to post comments)
GCC and static analysis Posted Apr 22, 2012 16:58 UTC (Sun) by rwst (guest, #84121) [Link]
Combinatorial, heh, I know the beginner's experience with Haskell. Headers, globals/locals, data structures ok but I never knew when to put $ or (...). Finally, monads are a black art, but presumably the most powerful construct. Though I didn't stay in that language, I would come back and try again should I need to.
Is it true what someone said: to parallelize a Haskell program needs the mere setting of a switch?
GCC and static analysis Posted Apr 22, 2012 17:29 UTC (Sun) by khim (subscriber, #9252) [Link] Is it true what someone said: to parallelize a Haskell program needs the mere setting of a switch? This is exaggeration but with a kernel of truth. Programs in functional languages are usually easily parallelizable by a compiler if the underlying algorithm is parallelizable. But it is possible to write even well-parallelizable algorithm in such a way as to make it impossible. This is an art, though - and an ugly one. Trivial proof-of-concept: implement Turing Machine on top of Haskell, implement your algorithm on top of said machine… mission accomplished.
GCC and static analysis Posted Apr 23, 2012 11:41 UTC (Mon) by sorpigal (subscriber, #36106) [Link] Interesting. Have you read "The camel has two humps"? It seems like this might be related. To quote the introduction: most people can’t learn to program: between 30% and 60% of every university computer science department’s intake fail the first programming course. Does a similar curve to the one they describe (e.g. figure 14) occur for functional programming, or is it different?
Learning to program Posted Apr 23, 2012 13:40 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
When I learned, the introductory programming course at university used a functional programming language (ML) for no other reason than because students were extremely unlikely to already be familiar with the language and would therefore have to attend at least the early classes in order to have any idea what was going on, giving faculty and opportunity to impress upon those (like me) who already thought they could program a computer that there was a good deal more to it than we thought.
But I don't remember washout rates as high as those suggested. I guess it's conceivable that some of my colleagues just avoided all subsequent programming but it seems very unlikely.
Learning to program Posted Apr 23, 2012 14:22 UTC (Mon) by juliank (subscriber, #45896) [Link]
People should use Haskell, and only Haskell. Haskell is the most important language in the FP area. Once people have mastered Haskell or in parallel, they should learn C Programming in an environment sufficiently compatible to POSIX.1-2001 (or Linux), and Makefiles.
Almost everything else apart from Haskell programming and POSIX programming is just non-sense.
Learning to program Posted Apr 23, 2012 16:39 UTC (Mon) by dps (subscriber, #5725) [Link]
When I did my 1st degree in (Mathematics and) CS we used a functional programming language before an imperative one. One of the exercises was to write an interactive program which appeared to have state. Obviously actually having state was impossible because that would violate fundamental principles of functional programming.
I think that functional programming languages are mathematically beautiful inferior to imperative languages for most tasks. Attempting to use an imperative programming language as functional one, or vica-vesra, is both stupid and painful.
Serious numerical analysis is *never* done using functional programming languages: any language without BLAS and linpack can be ruled out immediately. The popular choices include high performance fortran, which does not support recursion.
Learning to program Posted Apr 23, 2012 18:08 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>Obviously actually having state was impossible because that would violate fundamental principles of functional programming.
It's certainly possible. You just pass the state of the 'world' as a parameter to functions that can affect it.
>Serious numerical analysis is *never* done using functional programming languages: any language without BLAS and linpack can be ruled out immediately. The popular choices include high performance fortran, which does not support recursion.
Wow! So much bogosity in two statements.
Learning to program Posted Apr 26, 2012 3:16 UTC (Thu) by samlh (subscriber, #56788) [Link]
> And serious numeric analysis is now often done with NumPy which is _interpreted_.
Much of NumPy is a thin wrapper around BLAS, linpack, etc. What makes it popular is that it provides an intuitive interface, but the number-crunching is rarely written in Python.
Learning to program Posted Apr 26, 2012 12:58 UTC (Thu) by nix (subscriber, #2304) [Link] Serious numerical analysis is *never* done using functional programming languages: any language without BLAS and linpack can be ruled out immediately. The popular choices include high performance fortran, which does not support recursion.I don't do numerical analysis, nor do I know anyone who does, so I cannot argue regarding the truth of your assertion. But as a simple Google search will show, Haskell has bindings to BLAS.
Learning to program Posted Apr 28, 2012 0:20 UTC (Sat) by giraffedata (subscriber, #1954) [Link] "most people can’t learn to program: between 30% and 60% of every university computer science department’s intake fail the first programming course."But I don't remember washout rates as high as those suggested. It's misleading. A footnote implies most of those who failed received credit for the class and moved on to the next level. By "failed," the authors mean they failed to learn the subject matter -- to program -- and they say the policy in these classes is to pass a certain fraction of the class rather than to apply an absolute standard as the researchers did.
GCC and static analysis Posted Apr 23, 2012 20:32 UTC (Mon) by khim (subscriber, #9252) [Link] Interesting. Have you read "The camel has two humps"? It seems like this might be related. Yes, I've read this thing - sadly after I've stopped teaching. It's related but different. The camel has two humps explains that the most important thing for a programmer it to understand that programming is The Glass Bead Game: computer has no common sense thus it's your responsibility to bring sense to the program. And that it's very hard, almost impossible, to teach it to someone who's not accepting that right away! Functional programming is similar but different: it separates the result of said game from the process! It certainly feels that even people who can play The Glass Bead Game successfully not all can do this next step - and that means they'll not be able to successfully utilize functional programming. Even if they'll be able to write programs using functional languages they'll do in a very inefficient way. Think STL: it mostly tries to use functional style, but sometimes fails. For example map::insert function - it returns the pair<iterator, bool>. This is obvious thing to do in the imperative world. But in functional world (which is related to SMP world, BTW) it's bad idea: it means that the whole insert operation must be done sequentially before insert method will return! Does a similar curve to the one they describe (e.g. figure 14) occur for functional programming, or is it different? Well, I no longer teach CS thus I can not check, but it certainly felt this way: people either "got" functional programming easily or were unable to pick it at all. They tried to invent a way (often successful) to shoehorn cycles to the language which had noting of the sort. Of course most people had problem with just an imperative programming (as The camel has two humps shows) thus I can not really say what percentage of students had trouble with programming and what percentage only had trouble with functional programming. I only remember the key result: people who groked functional programming were able to program imperatively (I can not recall even a single person who was able to succeed with functional programming but had trouble with imperative one - this probably happens, but it's extremely rare), yet people who were barely able to pass functional programming part often did very well with imperative part.
GCC and static analysis Posted Apr 24, 2012 11:59 UTC (Tue) by renox (subscriber, #23785) [Link]
> computer has no common sense thus it's your responsibility to bring sense to the program. And that it's very hard, almost impossible, to teach it to someone who's not accepting that right away!
This specific part depends probably a lot if you're teaching Prolog or if you're teaching assembly language..
GCC and static analysis Posted May 17, 2012 15:50 UTC (Thu) by nye (guest, #51576) [Link]
>I only remember the key result: people who groked functional programming were able to program imperatively (I can not recall even a single person who was able to succeed with functional programming but had trouble with imperative one - this probably happens, but it's extremely rare)
That's interesting - not particularly surprising but it still makes me feel weird.
When I started my CS course (about a decade ago) we started with Scheme, which I found simple and intuitive. It took me quite a while to get used to imperative programming (in C and Ada) after that - it felt very unnatural and I didn't really feel like I understood what I was doing, more like shooting in the dark.
Later we had a couple of courses using Prolog, and I *never* managed to grok that programming style, so I find it easy to believe that some people are intrinsically more inclined towards one programming style versus another.
GCC and static analysis Posted May 20, 2012 21:49 UTC (Sun) by mathstuf (subscriber, #69389) [Link]
> Later we had a couple of courses using Prolog, and I *never* managed to grok that programming style, so I find it easy to believe that some people are intrinsically more inclined towards one programming style versus another.
It took until the last weekend of a two week project for things to "click" with Prolog. My experience tells me that half of Prolog programming is knowing where to stick '!' in between your statements. Of course, my imperative skills were a little "broken" after that project, but I'm glad I got to work with Prolog even though I don't use it for anything today.
GCC and static analysis Posted Apr 23, 2012 21:23 UTC (Mon) by HelloWorld (guest, #56129) [Link]
I have only read the abstract for now, but it seems to make for an interesting read. Thanks for that!
GCC and static analysis Posted Apr 23, 2012 23:27 UTC (Mon) by neilbrown (subscriber, #359) [Link]
Thanks so much for that link. A delightfully written - as well as interesting - paper.
I particularly liked:
> what distinguishes the three groups in the first test is their different attitudes to meaninglessness.
That sums it all up so beautifully!
GCC and static analysis Posted Apr 23, 2012 23:30 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
It is a good paper, is there any follow-up work happening? Are the full tests (and scoring info) available anywhere?
GCC and static analysis Posted Apr 24, 2012 10:58 UTC (Tue) by sorpigal (subscriber, #36106) [Link] Yes, there have been several follow-up papers from the same people on the same subject. I've just skimmed them, but they mostly look like defense against various attempts to deny the results of the first paper. There are additional statistics, though, which are interesting.
GCC and static analysis Posted Apr 26, 2012 13:05 UTC (Thu) by nix (subscriber, #2304) [Link]
Quite. I'm not so sure about the division they jokingly draw a few paras further down, though, dividing software practitioners into those who can take the full dose of CS formality and those who are doomed to not enjoy programming, become software engineers, and be drowned in UML. Some of us had trouble with formal CS stuff (certainly at that age) but still enjoy programming very much, thank you (and see UML as the useless pile of notation that it is!).
GCC and static analysis Posted Apr 24, 2012 12:51 UTC (Tue) by piman (subscriber, #8957) [Link]
> Interesting. Have you read "The camel has two humps"? It seems like this might be related.
I'm sick of seeing this paper thrown around. To quote the followup paper from the same author,
> Two years ago we appeared to have discovered an exciting and enigmatic new predictor of success in a first programming course. We now report that after six experiments, involving more than 500 students at six institutions in three countries, the predictive effect of our test has failed to live up to that early promise.
In other words, more research is needed, especially before lay people go around citing the original paper as evidence of any particular teaching method or subject.
GCC and static analysis Posted Apr 24, 2012 16:13 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
and there's a newer paper (July 2009) than the one you are referring (Jan 2008) to that seems to say that there is correlation
GCC and static analysis Posted Apr 26, 2012 4:21 UTC (Thu) by fuhchee (subscriber, #40059) [Link]
"We now report that [...] the predictive effect of our test has failed to live up to that early promise."
What a breath of fresh air, to scientifically evaluate one's prediction, then publish its failure. Bravo.
GCC and static analysis Posted Apr 24, 2012 8:58 UTC (Tue) by ssmith32 (subscriber, #72404) [Link]
How did you factor in the teaching skill? After all, your teaching was the one constant here. In the early programmer courses I took, there always students who felt hopeless, and just did brute forces symbol manipulation, until you pulled them aside and explain things to the differently. I had a few people that helped me, and I helped a few people once I learned. The teachers often just kept doing the same wrong things over and over again.
Most off-hand statistics like this also ignore the previous experience of the students. Even studies which supposedly factor this out only use things like "previous classes" or "previous work" or "how the student rated themselves". Yet all of these are not-so-great proxies for previous experience on a specific problem with specific approach. More often then not, the students I knew who just "got it", often were hacking on similar problems in their spare time with similar tools, before they ever started a class. Once again, I've been on both sides of this equation: and OS class with a horrible teacher and friends who just "magically" got it, assured me that it was a bad teacher and not me (I was in doubt). After which I started hacking on linux at home. Then I took a more advanced OS class with an even more horrible teacher, and just "got it", leaving another friend frustrated. So I had to pull them aside, step through stuff, assure them that it was not them, the teacher just sucked.
That's how the other side looks to most of us normal, imperative people. Maybe we just suck, but we write most of the software, so :P
PS. Also, you basically contradicted yourself - you started off saying "no one can learn functional programming", yet somehow concluded that it will be the answer, because it's the only thing that works... if no one can use it, sorry, it won't be the answer.
GCC and static analysis Posted Apr 24, 2012 16:07 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
I have been in a lot of different programming classes, with a lot of different teachers with different styles, as well as doing tutoring of fellow students. I also now have quite a few years of working in a company that does a lot of development.
The idea that some people just can't wrap their mind around programming, and others can get the job done, but always with a struggle really matches my experience.
The claim that this relates to people accepting that the program is really meaningless really rings true as I think about it.
GCC and static analysis Posted Apr 24, 2012 16:45 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
by the way, the studies don't say that the best results were from people who were correct initially, just that the best results were from the people who were most consistent initially.
This also feels right to me. Someone who applies the wrong rules consistently just needs to learn what the right rules are. People who don't consistently use the same rules are in much worse shape.
GCC and static analysis Posted Apr 24, 2012 21:32 UTC (Tue) by neilbrown (subscriber, #359) [Link]
My own reflections suggest that the consistency is probably a bit of a distraction and that it is the meaninglessness that is really important.
When people are not consistent it isn't because it is their nature to be inconsistent, but rather because they cannot see any possible consistency because they are blinded by the meaninglessness.
I actually suspect a strong correlation here with enjoying Science Fiction, which can often seem quite meaningless to outsiders and requires serious suspension-of-disbelief.
To enjoy SciFi (and fantasy, and probably D&D is a good predictor too) you need to immerse yourself in a world that has clear rules (mostly) but very different rules from the ones we are used to. So you cannot use your "intuition" to understand what is happening, you must reason from the stated rules. This is exactly the attitude that you need to bring to computer programming.
The people who were consistent made up rules and followed them. The people who were not consistent simply couldn't find any rules and their intuition failed them (as you would expect it to).
The paper also recalls previous reports of a correlation between programming ability and and ability with native language (already noted by Dijkstra). I think this fits the pattern. Meaning in language comes through use and people who depend on meaning will simply copy the usage they are exposed to which will be a/ limited and b/ erroneous (Like people using "Bob and I" as the object of the verb - I hate that!). People who are finding meaning in "meaningless" rules will understand the grammar (often seen as meaningless by people who haven't 'got' it) and other aspects of the language that they are not so often exposed to and thus have a richer language model to speak from.
Now I just need to convince some academic to test my brilliant hypothesis.
GCC and static analysis Posted Apr 24, 2012 23:02 UTC (Tue) by mathstuf (subscriber, #69389) [Link]
> …finding meaning in "meaningless"[ness]…
Sounds like something down Hofstadter's alley to me.
GCC and static analysis Posted Apr 24, 2012 23:32 UTC (Tue) by neilbrown (subscriber, #359) [Link]
> Sounds like something down Hofstadter's alley to me.
Yes - just to the left of the 'l'. :-)
|
|||||||||||||