As noted above, I think this overlooks quite a lot of human experience.
Incidentally, I'd love to see a real world example, outside the sphere of computing, where functional computation is used. Because every algorithm I encounter out in the real world (how to look up names in a phone book, how to bake bread, how to replace a tire) is expressed as a linear sequence of steps (aka, procedurally).
Then again, maybe my view of computation is too narrow, but I think of computation as taking inputs, performing operations, and generating outputs (which maps to the various "algorithms" I listed above), and I can't think of an example, in normal human experience, where a functional programming model is used.
From my personal experience of teaching people functional programming, it's nothing to do with imperative programming matching the brain better. Instead, it's to do with people learning to write imperative programs first, and then having a very steep unlearning curve to deal with at the same time as the learning curve for functional programming.
I disagree. Which is easier, explaining Quicksort in terms of a linear sequence of steps, or using a functional declarative model? In my experience, the former wins out, hands down, as far as intuitiveness goes. Why? Because, every day, people encounter algorithms, and they are invariably expressed as a sequence of linear steps. Recipes, instruction books, knitting patterns, you name it. Thus, to understand procedural programming, they need only translate what they are already familiar with (linear algorithms) into a computational model (incidentally, this is also, I think, why recursion is so difficult for programmers to grasp at first... there is really no natural, real world example of algorithmic recursion, and so the concept is alien).
Now, maybe the people I know and interact with are just really dumb:), but that's universally been my experience.
That's because the "normal person" (read: normal programmer)'s mental model of computation is based on imperative languages
No, it's because the "normal person" (read: average everyday human being)'s mental model of computation is based on instruction books, recipes, lessons, etc. Humans think of algorithms in terms of steps. The jump to a functional model is just that, a leap, and it requires a drastic change in thinking. It is, in this humble programmer's opinion, highly non-intuitive (ie, it is not easily grasped without a great deal of effort), *particularly* when you have to introduce complexities such as monads simply so you can model basic stateful concepts (like I/O).
Incidentally, I realize all the advantages that functional programming offers. I'm simply saying that functional programming isn't, in general, natural.
Agreed, but I think it far more likely that features to handle parallelism will be added to existing languages, rather than a mass migration to pure functional languages, regardless of their superiority.
Oh, you mean that the human mind keeps track for changes of state in the environment? Sorry to break the news to you, but that can also be done in functional languages.
No, I mean the human mind thinks in linear steps. "I do X, then I do Y, and then I do Z". Every recipe, every instruction book, every mathematical algorithm (say, factoring a quadratic equation) is represented as a linear sequence of steps. It's just the way we're wired. Frankly, I don't understand why this is such a controversial claim. Give me just one single instance of a normal, everyday situation in which humans use a functional model of computation, and I'll be quite impressed (and hopefully enlightened in the process:).
BTW, I'm quite aware that state can be modeled in functional languages. But I'd hardly call monads intuitive.
Yes, procedural programming has a close relation to step-by-step instructions, just as functional programming has a close relation to definitions. Both are things that people commonly understand and work with in the real world.
Perhaps, but I would argue that computation by definition is not, as a general case, intuitive. *shrug* 'course, it's hard for someone to understand this when they've already trained themselves to think that way.:)
SQL, which (like functional languages) is declarative rather than procedural seems to be at least as simple as most programming languages for even neophytes to understand.
You said it yourself, SQL is declarative, not functional. But more importantly, people can think of SQL in procedural terms, which is why it's easy to understand. "Take X from table A, join it with Y in table B and pull out rows that match criteria W, U, and V".
OTOH, if your first experience with computer programming is spending years exclusively with functional languages
Sure, after spending years with any computational model, it will become natural, at least to some degree (the same is true of, say, Quantum Mechanics, but no one would call it intuitive). But I don't believe this is the case for neophytes.
See, people understand steps. They understand the idea that a computer executes instructions one after the other, and the aggregate of those steps is a software program. It's intuitive because it maps to how people think of algorithms in the real world.
Functional programming, on the other hand, has no analogy in human experience. It's an alien thought process, which is why it's difficult to grasp. Yeah, take someone with no prejudices, and I'm sure they can learn functional programming. But I maintain and procedural programming is simply more natural.
Oh, totally agreed. I've gone out of my way to play with all manner of programming languages, specifically because it's intriguing to work with their different programming models and features. For example, Smalltalk teaches you the incredible power of blocks and closures. Haskell is all about lazy evaluation and an innovative type system. Then there's Lisp's view of code and data interchangeability. All are interesting, and they can provide insights that are applicable across multiple application domains (for example, I enjoy using higher-order functional programming in languages like Perl, Python, and C#, which support such things, thanks to my exposure to Smalltalk and Lisp).
But no sane person would believe that pure functional programming languages will every really leave their niches. I repeat, they just don't match the normal person's mental model of computation.
It seems to be a very strange system designed *specifically* to favour two parties. After all, in a three-party (or more) system, it's possible (even likely) that no one party would receive a plurality of votes, so you'd always end up going to the House. And odds are the House will vote across party lines, which favours the incumbent party.
the same way that in mainstream languages you don't need to understands stacks to use subroutines.
What? You *do* need to understand stacks to use subroutines. How else do you explain why this code doesn't work:
int *func() {
int j = 3;
return }
And monads are no more complicated than pointers.
Care to explain that comment? No, seriously, I *really* can't understand monads, so if you can explain them as an analogy to pointers, I'd love to hear it. Because, last I checked, they were a rigorous mathematical construct that somehow encapsulates state, but no one could explain them without resorting to opaque mathematical notation.
That's like saying you don't *have* to understand how I/O works to write data out to a file. Yeah, it's true, but any developer worth his title must.
Besides, basic I/O is just one case of side-effects, and Monads are ridiculously hard to understand and work with relative to procedural solutions to the same problems.
Mmmm... yes, I see you picked a few practical, real world examples, and didn't try to stack the deck with tasks that Haskell (or a similar language) would be particularly well-suited for.
People will get more intelligent just by using functional languages.
Don't be ridiculous. Functional vs procedural isn't a matter of intelligence. It's simply a way of thinking. And the reality is that procedural languages better match the way the human mind works.
IMHO, learning to program in a functional style is like a right-handed person learning to write with their left. Yeah, they can do it, but it requires a ton of work for dubious real-world benefit, and in the end, it's never really natural, simply because that's not the way the brain is wired (except for the odd freakish exception;).
And that's exactly the problem. What are Monads? I'm not really sure (I sort of have a vague intuition of what they are, but that's it). But I do know that you need them in order to do anything that involves side-effects in the world outside of Haskell. And that includes I/O. Yes, that's right, you need to understand a rigorous mathematical construct in order to write a "Hello World" program. There's simply *no way in hell* a language like that will become popular in the mainstream.
The fact is, side-effects are simply a reality in computing. Should they be avoided where possible? Yup. But forcing the programmer through incredibly confusing hoops just to write data out to a file is plain and simply unreasonable.
People don't vote for president. States do. It's the law. Get over it.
Or you could change the law if it's become anachronistic (I'm not saying it has, but saying "It's the law. Get over it" is rather silly... if one were to take that view, women and minorities wouldn't have the right to vote in the US).
Complete disregard for constitutional law is exactly why we're having so many problems today
Funny, many other countries don't have a US-style constitution, and yet they don't have the problems the US does. Mayhap you're looking in the wrong place for an excuse?
To win the Presidency in a one on one race, a candidate needs to get 270 electoral votes, because there are a total of 538 votes in the Electoral College.
I'm confused (note, I'm Canadian:). Why? What if, for some strange and bizarre reason, Bob Barr actually won Texas, while Obama and McCain split the remaining electoral college votes in such a way that no one had >270 votes. Are you saying no one is elected president in that scenario? Does that mean one or more of the other states *much* change their vote allocation in order for someone to be elected president?
Creating complex mortgage-backed derivatives is fine; it's erroneously valuing them that caused the problems.
And allowing regular people to have nuclear weapons is fine, as long as they're trained properly.
Sorry, but the very nature of those derivatives makes it incredibly difficult to evaluate them effectively. Better to just disallow them entirely. Will that reduce the amount of credit available to the real estate industry? Yup. Tough. Better that than a financial meltdown.
The only other option is to regulate how those instruments are rated (as it appears the ratings agencies, at best, *massively* failed in their duties, and at worst, were in cahoots with the industry to pump up their ratings), but I'm not convinced it's worth the risk.
In either case, the industry has demonstrated that it can't be left to it's own devices. The free market failed. So the government needs to step in and do something, whatever that "something" is.
What I find truly bizarre is this belief that adding more technology to the problem will fix it. As you say, here in Canada we use simple paper ballots marked by hand. Once voting is complete the votes are hand counted. The process is simple, transparent, and reliable.
The American system, by contrast, seems like an exercise in complexity for the sake of complexity. Yeah, there's more people voting, but that just means there's more people who can do the counting. Yeah, the ballots are more complex, but there's no reason why you can't design a straightforward ballot that's easy to fill in and easy to count. Yeah, there's the whole states rights issue, but given the problems in the electoral system, I sincerely doubt it would be hard for the federal government to get a majority of the states onboard with a standardized system. There really seems to be no excuse, other than sheer incompetence. It's truly strange.
Whoever was contracted for this should be made to solve the problem for providing a product that clearly lacked testing.
Testing? This is a requirements problem, plain and simple. Unless the spec says "Must be able to perform name lookup in the case of name variation, such as missing middle initials or shortened forms", then they would've implemented it.
The real question is, who wrote the requirements for the thing, and why did this get missed?
The model would be that XBMC would run on an Xbox, and it would connect to Myth over the network just like another frontend.
Incidentally, from what I can tell, XBMC now has a basic, native MythTV client built in. It can be used to watch and delete recordings, and watch and record live TV. However, it has no EPG support, no commercials skip, etc. See here:
Can't blame you there, it is... rough. But it is immensely capable, so I've learned to live with it's rough edges in exchange for the incredible power it provides (and being a programmer, I can't help but love being able to write custom SQL recording rules:).
that combined with the free TV guides going away
You chose a closed solution with little flexibility over paying $20 *per year* for guide data? Really? Meh, to each his/her own, I guess.
Fortunately, you can hook XBMC into MythTV. Wouldn't that be a solution for you?
Slashdot Mirror
As noted above, I think this overlooks quite a lot of human experience.
Incidentally, I'd love to see a real world example, outside the sphere of computing, where functional computation is used. Because every algorithm I encounter out in the real world (how to look up names in a phone book, how to bake bread, how to replace a tire) is expressed as a linear sequence of steps (aka, procedurally).
Then again, maybe my view of computation is too narrow, but I think of computation as taking inputs, performing operations, and generating outputs (which maps to the various "algorithms" I listed above), and I can't think of an example, in normal human experience, where a functional programming model is used.
From my personal experience of teaching people functional programming, it's nothing to do with imperative programming matching the brain better. Instead, it's to do with people learning to write imperative programs first, and then having a very steep unlearning curve to deal with at the same time as the learning curve for functional programming.
I disagree. Which is easier, explaining Quicksort in terms of a linear sequence of steps, or using a functional declarative model? In my experience, the former wins out, hands down, as far as intuitiveness goes. Why? Because, every day, people encounter algorithms, and they are invariably expressed as a sequence of linear steps. Recipes, instruction books, knitting patterns, you name it. Thus, to understand procedural programming, they need only translate what they are already familiar with (linear algorithms) into a computational model (incidentally, this is also, I think, why recursion is so difficult for programmers to grasp at first... there is really no natural, real world example of algorithmic recursion, and so the concept is alien).
Now, maybe the people I know and interact with are just really dumb :), but that's universally been my experience.
That's because the "normal person" (read: normal programmer)'s mental model of computation is based on imperative languages
No, it's because the "normal person" (read: average everyday human being)'s mental model of computation is based on instruction books, recipes, lessons, etc. Humans think of algorithms in terms of steps. The jump to a functional model is just that, a leap, and it requires a drastic change in thinking. It is, in this humble programmer's opinion, highly non-intuitive (ie, it is not easily grasped without a great deal of effort), *particularly* when you have to introduce complexities such as monads simply so you can model basic stateful concepts (like I/O).
Incidentally, I realize all the advantages that functional programming offers. I'm simply saying that functional programming isn't, in general, natural.
Agreed, but I think it far more likely that features to handle parallelism will be added to existing languages, rather than a mass migration to pure functional languages, regardless of their superiority.
Oh, you mean that the human mind keeps track for changes of state in the environment? Sorry to break the news to you, but that can also be done in functional languages.
No, I mean the human mind thinks in linear steps. "I do X, then I do Y, and then I do Z". Every recipe, every instruction book, every mathematical algorithm (say, factoring a quadratic equation) is represented as a linear sequence of steps. It's just the way we're wired. Frankly, I don't understand why this is such a controversial claim. Give me just one single instance of a normal, everyday situation in which humans use a functional model of computation, and I'll be quite impressed (and hopefully enlightened in the process :).
BTW, I'm quite aware that state can be modeled in functional languages. But I'd hardly call monads intuitive.
Yes, procedural programming has a close relation to step-by-step instructions, just as functional programming has a close relation to definitions. Both are things that people commonly understand and work with in the real world.
Perhaps, but I would argue that computation by definition is not, as a general case, intuitive. *shrug* 'course, it's hard for someone to understand this when they've already trained themselves to think that way. :)
SQL, which (like functional languages) is declarative rather than procedural seems to be at least as simple as most programming languages for even neophytes to understand.
You said it yourself, SQL is declarative, not functional. But more importantly, people can think of SQL in procedural terms, which is why it's easy to understand. "Take X from table A, join it with Y in table B and pull out rows that match criteria W, U, and V".
OTOH, if your first experience with computer programming is spending years exclusively with functional languages
Sure, after spending years with any computational model, it will become natural, at least to some degree (the same is true of, say, Quantum Mechanics, but no one would call it intuitive). But I don't believe this is the case for neophytes.
See, people understand steps. They understand the idea that a computer executes instructions one after the other, and the aggregate of those steps is a software program. It's intuitive because it maps to how people think of algorithms in the real world.
Functional programming, on the other hand, has no analogy in human experience. It's an alien thought process, which is why it's difficult to grasp. Yeah, take someone with no prejudices, and I'm sure they can learn functional programming. But I maintain and procedural programming is simply more natural.
Oh, totally agreed. I've gone out of my way to play with all manner of programming languages, specifically because it's intriguing to work with their different programming models and features. For example, Smalltalk teaches you the incredible power of blocks and closures. Haskell is all about lazy evaluation and an innovative type system. Then there's Lisp's view of code and data interchangeability. All are interesting, and they can provide insights that are applicable across multiple application domains (for example, I enjoy using higher-order functional programming in languages like Perl, Python, and C#, which support such things, thanks to my exposure to Smalltalk and Lisp).
But no sane person would believe that pure functional programming languages will every really leave their niches. I repeat, they just don't match the normal person's mental model of computation.
It seems to be a very strange system designed *specifically* to favour two parties. After all, in a three-party (or more) system, it's possible (even likely) that no one party would receive a plurality of votes, so you'd always end up going to the House. And odds are the House will vote across party lines, which favours the incumbent party.
Yup, very very strange... :)
So, not having Texas vote *doesn't* actually create a constitutional crisis, it just means that said ballot must be performed, no?
Stupid HTML. That example should've returned a pointer to j, in case it wasn't clear. :)
the same way that in mainstream languages you don't need to understands stacks to use subroutines.
What? You *do* need to understand stacks to use subroutines. How else do you explain why this code doesn't work:
int *func()
{
int j = 3;
return
}
And monads are no more complicated than pointers.
Care to explain that comment? No, seriously, I *really* can't understand monads, so if you can explain them as an analogy to pointers, I'd love to hear it. Because, last I checked, they were a rigorous mathematical construct that somehow encapsulates state, but no one could explain them without resorting to opaque mathematical notation.
That's like saying you don't *have* to understand how I/O works to write data out to a file. Yeah, it's true, but any developer worth his title must.
Besides, basic I/O is just one case of side-effects, and Monads are ridiculously hard to understand and work with relative to procedural solutions to the same problems.
Mmmm... yes, I see you picked a few practical, real world examples, and didn't try to stack the deck with tasks that Haskell (or a similar language) would be particularly well-suited for.
Or not.
People will get more intelligent just by using functional languages.
Don't be ridiculous. Functional vs procedural isn't a matter of intelligence. It's simply a way of thinking. And the reality is that procedural languages better match the way the human mind works.
IMHO, learning to program in a functional style is like a right-handed person learning to write with their left. Yeah, they can do it, but it requires a ton of work for dubious real-world benefit, and in the end, it's never really natural, simply because that's not the way the brain is wired (except for the odd freakish exception ;).
Monads and all that kind of confuses me.
And that's exactly the problem. What are Monads? I'm not really sure (I sort of have a vague intuition of what they are, but that's it). But I do know that you need them in order to do anything that involves side-effects in the world outside of Haskell. And that includes I/O. Yes, that's right, you need to understand a rigorous mathematical construct in order to write a "Hello World" program. There's simply *no way in hell* a language like that will become popular in the mainstream.
The fact is, side-effects are simply a reality in computing. Should they be avoided where possible? Yup. But forcing the programmer through incredibly confusing hoops just to write data out to a file is plain and simply unreasonable.
People don't vote for president. States do. It's the law. Get over it.
Or you could change the law if it's become anachronistic (I'm not saying it has, but saying "It's the law. Get over it" is rather silly... if one were to take that view, women and minorities wouldn't have the right to vote in the US).
Complete disregard for constitutional law is exactly why we're having so many problems today
Funny, many other countries don't have a US-style constitution, and yet they don't have the problems the US does. Mayhap you're looking in the wrong place for an excuse?
To win the Presidency in a one on one race, a candidate needs to get 270 electoral votes, because there are a total of 538 votes in the Electoral College.
I'm confused (note, I'm Canadian :). Why? What if, for some strange and bizarre reason, Bob Barr actually won Texas, while Obama and McCain split the remaining electoral college votes in such a way that no one had >270 votes. Are you saying no one is elected president in that scenario? Does that mean one or more of the other states *much* change their vote allocation in order for someone to be elected president?
Creating complex mortgage-backed derivatives is fine; it's erroneously valuing them that caused the problems.
And allowing regular people to have nuclear weapons is fine, as long as they're trained properly.
Sorry, but the very nature of those derivatives makes it incredibly difficult to evaluate them effectively. Better to just disallow them entirely. Will that reduce the amount of credit available to the real estate industry? Yup. Tough. Better that than a financial meltdown.
The only other option is to regulate how those instruments are rated (as it appears the ratings agencies, at best, *massively* failed in their duties, and at worst, were in cahoots with the industry to pump up their ratings), but I'm not convinced it's worth the risk.
In either case, the industry has demonstrated that it can't be left to it's own devices. The free market failed. So the government needs to step in and do something, whatever that "something" is.
Everyone's vote should be equal; having some people's vote count more than other people's vote is absurd.
Unless you're from a rural neigbourhood or a small state. Then you need to be protected from those pinko commies in New York and California!
What I find truly bizarre is this belief that adding more technology to the problem will fix it. As you say, here in Canada we use simple paper ballots marked by hand. Once voting is complete the votes are hand counted. The process is simple, transparent, and reliable.
The American system, by contrast, seems like an exercise in complexity for the sake of complexity. Yeah, there's more people voting, but that just means there's more people who can do the counting. Yeah, the ballots are more complex, but there's no reason why you can't design a straightforward ballot that's easy to fill in and easy to count. Yeah, there's the whole states rights issue, but given the problems in the electoral system, I sincerely doubt it would be hard for the federal government to get a majority of the states onboard with a standardized system. There really seems to be no excuse, other than sheer incompetence. It's truly strange.
Err... that is... "If the spec says". :)
Whoever was contracted for this should be made to solve the problem for providing a product that clearly lacked testing.
Testing? This is a requirements problem, plain and simple. Unless the spec says "Must be able to perform name lookup in the case of name variation, such as missing middle initials or shortened forms", then they would've implemented it.
The real question is, who wrote the requirements for the thing, and why did this get missed?
The model would be that XBMC would run on an Xbox, and it would connect to Myth over the network just like another frontend.
Incidentally, from what I can tell, XBMC now has a basic, native MythTV client built in. It can be used to watch and delete recordings, and watch and record live TV. However, it has no EPG support, no commercials skip, etc. See here:
http://www.gossamer-threads.com/lists/mythtv/users/326091
Looks like an interesting option.
I used to use MythTV but hated the interface;
Can't blame you there, it is... rough. But it is immensely capable, so I've learned to live with it's rough edges in exchange for the incredible power it provides (and being a programmer, I can't help but love being able to write custom SQL recording rules :).
that combined with the free TV guides going away
You chose a closed solution with little flexibility over paying $20 *per year* for guide data? Really? Meh, to each his/her own, I guess.
Fortunately, you can hook XBMC into MythTV. Wouldn't that be a solution for you?