Hacker News new | ask | show | jobs
by Morgawr 4204 days ago
If there is one thing that has always bothered me, is people evaluating student's prowess in "Computer Science" (which is not programming, shame on you) by having them learn your normal run-of-the-mill programming language/paradigm like Javascript, Python, PHP and whatnot and then claim they are not apt to program because they cannot solve problems or handle variables, mutability, etc etc.

There are A LOT of different programming/automation paradigms in the world, lots of different languages, declarative, functional, OOP, imperative, logic, etc etc, maybe some of these students just can't get the convoluted mutable and unsafe structure of a Python or Java program but they might grok and appreciate the safety and simplicity of ML/Haskell or the flexibility of Lisp, why would you turn them down in such a way or force them through a path they don't really need to go through?

During my first year of Bachelor Computer Science at University we had introduction to programming in Scheme. It was a mind-expanding experience to me, I already knew how to program in C, Java, C++ and C# with a bit of PHP/Javascript back then and I was much ahead most of my peers but still I sat at the computer, trying to earn this alien language to me, and luckily I was humble enough to force myself through it and adapt my mind to a different paradigm. I know for certain that a lot of my friends and colleagues who already knew how to program struggled hard on that exam and some had to re-take it the following year (Which was unfortunately changed to C++ and they managed to pass without troubles) simply because they didn't think Scheme was a "real" programming language or useful at all. It was just too different from their previous experience.

What's even more interesting, I know some people from that class who had never touched a programming language before and weren't particularly strong at math. Those people are the ones I recall enjoying the course the most, they found it the easiest among all the other courses we had and passed it with excellent grades. Simply because their mind was apparently better wired for such paradigm and they had no preconceptions or prejudices that prevented them from learning it properly.

So my bottom line is, what makes you think that some people might not just have a "differently wired" brain that makes them think more easily with a different non-imperative paradigm for programming?

3 comments

"Differently wired" wired brain is the ability to manipulate abstractions. Which is required no matter what kind of programming language you use. And it also required for doing algebra.
Recursion is as hard as mutable state to grasp if not harder. We might find a few people who can do one thing sligtly better than the other one, but not complete blanks.
The whole point of what I said is that "hard" is a difficult thing to judge. For some tasks and some languages recursion is much easier to understand, teach and use. Just take the good ol' classical example of quicksort in Haskell or fibonacci in Lisp.

Some people can grok recursion in a functional programming language much faster and more easily than they would understand the concept of branching, variable assignment (with mutability) and non-pure functions (what we used to call "procedures" back in the day).

Just take the good ol' classical example of quicksort in Haskell or fibonacci in Lisp.

Hell, recursive quicksort and mergesort are easier to teach and remember than the iterative versions even in C and Java. They're divide-and-conquer algorithms, which makes them a natural fit for a recursive solution.

The classic C/C++ versions are recursive, and using the STL, c++'s quick sort looks very similar to the functional one.

From cppreference.com: http://coliru.stacked-crooked.com/view?id=0b2cec4d8c69ffaf

http://en.cppreference.com/w/cpp/algorithm/partition

I disagree. Recursion is simply inductive reasoning, which people are able to grasp at a young age.
maybe the initial concept, but what is easier to debug afterwards?

So much teaching material for beginning programming is tainted by the cult of mutability that I have coworkers writing for loops instead of maps or the like for relatively trivial tasks. The end result is I have a harder time reading code, and the amount of possible bugs grows.

In 35 years of programming across platforms and languages covering embedded to web applications it is my opinion that recursion is dangerous and useless. There is no way I would use recursion to evaluate how good a programmer might be. To quote the movie: "Frankly dear, I don't give a damn".
Do you imply that functional programming in general is dangerous and useless?

And what's your standing regarding the total languages? How dangerous is, say, Agda2? How useless is HOL?

Nothing whatsoever to do with functional programming.
How is it so? Recursion is the only possible form of iterative control flow in the functional languages. If you do not want to allow any forms of recursion, you cannot use functional languages at all.

Of course, you can explicitly demand totality, and it's perfectly fine, but still it is quite a severe limitation, and you'll have to allow optional unrestricted recursion if you want to have (at leat local) Turing completeness.

Recursion is a tool. It can be misused, but it is just a tool. And sometimes it can be very useful.
Recursion is mostly an academic tool. In the real world it is a bad idea.

It's interesting that a bunch of people went off in a down-vote spree yet not one person offered a non-trivial use of recursion in commercial, medical or military software.

It wastes resources and it simply isn't safe. Used in the wrong place it can actually kill people.

> Recursion is mostly an academic tool.

Wrong.

> In the real world it is a bad idea.

Wrong. Your view of the real world is severely distorted.

> yet not one person offered a non-trivial use of recursion in commercial, medical or military software.

I suspect your 35 years of experience was 1 year repeated 35 times. Otherwise you would have known thousands of cases where recursion is unavoidable.

Take any real world compiler, for example. People nowadays are spoiled, they want meaningful error messages, they want semantic highlighting in IDEs, and so on. So forget about the dragon book, automatons and all such crap - your only option is a recursive descent parser.

If you want a guaranteed quality and proven correctness of your software (since you've mentioned medical and military), you have no other option but to use total languages. It's just too hard to reason about anything else. Which means - you only have recursion and no other means of control flow. Want your software to be 100% correct, robust and predictable - use recursion. I can go on forever, but things I've listed are already more than enough to debunk your point.

> It wastes resources

Wrong.

> and it simply isn't safe.

Wrong.

> Used in the wrong place it can actually kill people.

Incompetent coders kill people. Epileptoids suffering from severe forms of Dunning-Kruger effect kill people. Those who repeat 1 year of experience instead of building experience progressively kill people.

Very nice attempt at shooting the messenger to attempt to make a really lame point. Of course ypu can use recursion in non mission critical applications such as a compiler. Take a moment to educate yourself as to the requirements for industrial, medical and military devices and you might begin to understand. And, BTW, we don't have to agree, that's the beauty of it. You can go on beleiving you are right and I can now see about repeating that one year of experience for the 36th. time.
Why?
Just so I can answer, why what?
Just in case this is what you were trying to understand:

https://www.google.com/search?q=recursion+is+dangerous&rlz=1...

http://m.slashdot.org/story/198499

You can certainly dig up more information. For me, and this is just my opinion based on 35 years of software and hardware engineering, recursion is a neat academic idea but in the real world it is useless and dangerous.

I'm seeing stack overflows (not a problem with tail-call optimization) as the biggest problem here. There are equally dangerous problems, though. Buffer overflows are a very real concern, especially in embedded software; but that doesn't mean that people don't ever use pointers. Everything about software has risks. Yes, they probably shouldn't have used recursion there in that car; but honestly, it's just a stack. Enough calls and some state could have been frozen. They should have put mitigations in place to stop the potential for a stack overflow to have actual, detrimental results. Do you refuse to ever make a function call for fear that you might be at the top of the stack somehow? After all, how can you know that you haven't accidentally created a state machine with function calls and are at the peak of it now, and end up causing the same problem. Recursion may have been the final manifestation, but it's certainly not the only place that failed.

I argue against your thought that recursion is useless, as well. It's a natural and intuitive solution for a lot of problems. The very concept of a dynamic programming solution starts with a recurrence relationship. It starts with recursion. Sorting algorithms are intutively recursive in many cases, Quicksort and Mergesort are just two examples.

And, 'dangerous' is an interesting term. I understand you've worked in embedded systems and hardware, and so those things are often critical systems that have to be super secure and completely bug free. Not every system is like that, though.

I want to understand why you believe that recursion is both useless and dangerous. Could you give some broad examples of the dangers of recursion from your years of experience?

It's trivial to blow the stack even on languages with tail call optimization.
And how exactly it is related to recursion? You should have said "memory leaks are dangerous", and everyone would agree.
Ah, Scheme.. You must be an Indiana University grad.

Only school I know that uses Scheme that much.

Lots of top schools use scheme (via SICP). Cal, Stanford and MIT all do (or at least did when I was an undergrad).
After the dot.com bust cratered EECS enrollment (down by more than half after being steady for decades), MIT revised its curriculum and completely purged Scheme from it (or at least the required parts). It's all Python and Java now :-(.
Dude you went to MIT? That's rad. EDIT: why downvote someone for complimenting them on their top schooling?
Because it is noise (do you really think that either the poster or the rest of HN need to hear that you are impressed by MIT?), and also because it isn't even stated that he did go to MIT.
Of course they don't need to hear that; it's pretty much a given. Their superiority is well-established at this point.
Nope, sorry. Wrong side of the ocean.
UCL?
Minnesota used Scheme when my son studied there. MIT did until about that year too.
"that much"

It's just one intro CS201 course. There might be another Scheme elective, though.