tag:blogger.com,1999:blog-6655746112052720933.post8815004626050502332..comments2022-03-30T18:43:33.525-05:00Comments on Notes on Haskell: Say what you mean, mean what you sayAdam Turoffhttp://www.blogger.com/profile/11941071792943377879noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-6655746112052720933.post-90656776584334258302011-05-24T05:00:12.574-05:002011-05-24T05:00:12.574-05:00The link to John Hughes' paper is broken.
His ...The link to John Hughes' paper is broken.<br />His paper can now be found <a href="http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html" rel="nofollow">here</a> (it is not hosted by the "math" department anymore but the "cse" dpt.)Frédéricnoreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-52587823647472898702007-04-12T09:14:00.000-05:002007-04-12T09:14:00.000-05:00jaydonnell: "Isn't that imperative code akin to a ...jaydonnell: "Isn't that imperative code akin to a strawman?"<BR/><BR/>Yep, that's why functional programming matters!<BR/><BR/>Basically, this guy takes a silly solution to a silly problem, shows how that solution is wordy in an imperative language and less so in a functional language, and pulls out his desired conclusion: that Functional Programming is The Solution. Gah!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-13667090600876969152007-04-12T06:48:00.000-05:002007-04-12T06:48:00.000-05:00@ Jakub:>>> [(x, y) for x in range(2) for y in ran...@ Jakub:<BR/><BR/>>>> [(x, y) for x in range(2) for y in range(3)]<BR/>[(0, 0), (0, 1), (0, 2), (1, 0), (1, 1), (1, 2)]Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-80196902805219161772007-03-22T20:58:00.000-05:002007-03-22T20:58:00.000-05:00Python list comprehensions won't allow cartesian p...Python list comprehensions won't allow cartesian products AFAIK. [(x, y) for x, y in cartesian (xs, ys)] is as good as it gets but only if you write the cartesian function (as a lazy generator probably).jpchttps://www.blogger.com/profile/05403272030490907018noreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-82745278758777278562007-03-16T05:38:00.000-05:002007-03-16T05:38:00.000-05:00I think this is simply bias.I find the iterative o...I think this is simply bias.<BR/><BR/>I find the iterative one more readable. The for loops you sort of skip by; you recognize them virtually immediatly as the 'framing' of the logic, exactly analogous to how the 'select' operation in the FP example does a similar thing; it separtes the WHAT from the HOW. As long as this is easy (and it seems to be in both) we're in good shape.<BR/><BR/>Then the math: This is exactly the same in both samples; an equals and a numeric compare joined together in logical and. The syntax is virtually identical, in fact.<BR/><BR/>Finally, there's the act of displaying the total. This is arguably nicer in the FP example, but further inspection shows this is a red herring: There's absolutely no reason why the imperative code counts instead of adds, so in theory both could have finished with some sort of 'selectedEmployees.size()' with no problem.<BR/><BR/>Thus, I conclude this is simply bias: I find the imperative example more readable because I tend to work more with imperative code, and I'm betting you find the FP example more readable because that's how your brain prefers to interpret code.<BR/><BR/>This example doesn't strike me as a particularly appropriate showcase for inverting the logic order, by the way; there are plenty of examples where a select() operation really does come across as much nicer generally, even to a brain that is pre-disposed to reading for loops more than selections.<BR/><BR/>Of course, the opposite is true as well, and thus it helps if a language can do both, but on the whole this doesn't really make or break it for me; it's far too trivial and irregardless easily duplicated in any language that has some form of 'function block' notation, and I don't know any short of older variants of basic that don't have that.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6655746112052720933.post-43179875602613540902007-03-13T03:09:00.000-05:002007-03-13T03:09:00.000-05:00Isn't that imperative code akin to a strawman? Wou...Isn't that imperative code akin to a strawman? Wouldn't it most likely be written something like this?<BR/><BR/>int numberOfOldTimers = 0;<BR/>for(Employee emp: employeeList){<BR/> if(dept = emp.getDepartment() && emp.getYearsOfService() > dept.getAge()){<BR/> ++numberOfOldTimers;<BR/> }<BR/>}<BR/><BR/>The select is cleaner, but imperative code isn't as bad as the example would make it seem.jaydonnellhttps://www.blogger.com/profile/13279254863158598601noreply@blogger.com