Comments for Just another lambdabananacamel, http://greenokapi.net/blog Perl, Haskell, stuff Tue, 09 Mar 2010 20:25:27 +0000 http://wordpress.org/?v=2.5.1 Comment on Notes on new Macbook Pro by Sol http://greenokapi.net/blog/2010/03/08/notes-on-new-macbook-pro/#comment-2009 Sol Mon, 08 Mar 2010 16:59:13 +0000 http://greenokapi.net/blog/?p=175#comment-2009 You can indeed click anywhere on the pad to get a click. In fact, IMO the pad is good enough by itself to almost justify the extra $1000 cost over buying a Windows laptop. (But also, my MBP definitely run hot.) You can indeed click anywhere on the pad to get a click. In fact, IMO the pad is good enough by itself to almost justify the extra $1000 cost over buying a Windows laptop.

(But also, my MBP definitely run hot.)

]]> Comment on Global state in Web Applications: Catalyst’s stash. by dima http://greenokapi.net/blog/2009/06/04/global-state-in-web-applications-catalysts-stash/#comment-1997 dima Sat, 23 Jan 2010 06:43:41 +0000 http://greenokapi.net/blog/?p=164#comment-1997 MVC Catalyst I liked, a very good framework MVC Catalyst I liked, a very good framework

]]> Comment on Spreadsheet imports: imperative vs. functional by RandomGuy http://greenokapi.net/blog/2009/12/26/spreadsheet-imports-imperative-vs-functional/#comment-1988 RandomGuy Thu, 31 Dec 2009 09:39:08 +0000 http://greenokapi.net/blog/?p=174#comment-1988 Would you mind tagging your perl stuff somehow so it doesn't show up on the haskell world blog? Would you mind tagging your perl stuff somehow so it doesn't show up on the haskell world blog?

]]> Comment on Spreadsheet imports: imperative vs. functional by Evan Carroll http://greenokapi.net/blog/2009/12/26/spreadsheet-imports-imperative-vs-functional/#comment-1986 Evan Carroll Wed, 30 Dec 2009 16:12:01 +0000 http://greenokapi.net/blog/?p=174#comment-1986 Yes, with sample data. I'd be able to show you a mock up of how a spreadsheet import would be done: for csv -- it is as simple as Text::CSV which can handle headers even and return a hash ref for each row. For fixed width stuff, try my DataExtract::FixedWidth. As for a statefull parser you don't have to do all this stuff you're doing. All you have to do is isolate a primary key and the parse the row using the same criteria, if that primary key is null you append the previous hashref or perform appropriately. But again, without a code sample, and raw input it becomes more work to throw new approaches. How would you tackle this task? Is there even an elegant way to do it imperatively? I'm just not sure how to answer that, if there was no real code, or real input data to present the answer with. Yes, with sample data. I'd be able to show you a mock up of how a spreadsheet import would be done: for csv -- it is as simple as Text::CSV which can handle headers even and return a hash ref for each row. For fixed width stuff, try my DataExtract::FixedWidth. As for a statefull parser you don't have to do all this stuff you're doing. All you have to do is isolate a primary key and the parse the row using the same criteria, if that primary key is null you append the previous hashref or perform appropriately. But again, without a code sample, and raw input it becomes more work to throw new approaches.

How would you tackle this task? Is there even an elegant way to do it imperatively?

I'm just not sure how to answer that, if there was no real code, or real input data to present the answer with.

]]> Comment on Spreadsheet imports: imperative vs. functional by osfameron http://greenokapi.net/blog/2009/12/26/spreadsheet-imports-imperative-vs-functional/#comment-1985 osfameron Wed, 30 Dec 2009 11:35:20 +0000 http://greenokapi.net/blog/?p=174#comment-1985 @EvanCarroll, interesting comment. That said, this was for a piece of $real_work, and the code/samples above are extracted from that and simplified a bit. Turning it into a mini-project with sample code and data would be a nice-to-have, but I don't feel it's vital to have those for every blog post you make... And yes, I was soliciting feedback, in the sense that I'd like to know how other people would approach the problem: I've already presented 2 possible ways to do it (1 of which I'm using myself), so I don't feel like I'm holding much back. Am I missing your point? @EvanCarroll, interesting comment. That said, this was for a piece of $real_work, and the code/samples above are extracted from that and simplified a bit. Turning it into a mini-project with sample code and data would be a nice-to-have, but I don't feel it's vital to have those for every blog post you make...

And yes, I was soliciting feedback, in the sense that I'd like to know how other people would approach the problem: I've already presented 2 possible ways to do it (1 of which I'm using myself), so I don't feel like I'm holding much back. Am I missing your point?

]]> Comment on Spreadsheet imports: imperative vs. functional by Evan Carroll http://greenokapi.net/blog/2009/12/26/spreadsheet-imports-imperative-vs-functional/#comment-1983 Evan Carroll Tue, 29 Dec 2009 17:58:45 +0000 http://greenokapi.net/blog/?p=174#comment-1983 I'm downvoting this on reddit simply because without a sample raw input and code it seems like a bad attempt to solicit feed back. Put the sample code, and raw examples up on gist.github.com or something... I'm downvoting this on reddit simply because without a sample raw input and code it seems like a bad attempt to solicit feed back. Put the sample code, and raw examples up on gist.github.com or something...

]]> Comment on Github language statistics by Programmer http://greenokapi.net/blog/2009/12/15/github-language-statistics/#comment-1971 Programmer Sat, 19 Dec 2009 20:27:30 +0000 http://greenokapi.net/blog/?p=173#comment-1971 Adding nearly 22k perl projects (2/3rd of which are probably defunct) to, once again, try to make perl look more alive than it is? Embarrassing. Perl5 is dead, you people should be moving to perl6 before you wreck its chances to be a player. Adding nearly 22k perl projects (2/3rd of which are probably defunct) to, once again, try to make perl look more alive than it is? Embarrassing. Perl5 is dead, you people should be moving to perl6 before you wreck its chances to be a player.

]]> Comment on Github language statistics by dagolden http://greenokapi.net/blog/2009/12/15/github-language-statistics/#comment-1968 dagolden Fri, 18 Dec 2009 12:28:43 +0000 http://greenokapi.net/blog/?p=173#comment-1968 His criteria of having at least 3 watchers really limits the data set to projects whose contributors primarily use github for tracking and collaboration. (E.g. adding 21,000 Perl projects that no one watches doesn't really change things.) The statistics have huge selection bias so drawing any sort of conclusion from them is absurd. His criteria of having at least 3 watchers really limits the data set to projects whose contributors primarily use github for tracking and collaboration. (E.g. adding 21,000 Perl projects that no one watches doesn't really change things.) The statistics have huge selection bias so drawing any sort of conclusion from them is absurd.

]]> Comment on Github language statistics by Mark Wotton http://greenokapi.net/blog/2009/12/15/github-language-statistics/#comment-1965 Mark Wotton Tue, 15 Dec 2009 23:55:29 +0000 http://greenokapi.net/blog/?p=173#comment-1965 Could also be that Perl hackers tend to bite off small, discrete chunks that can actually be finished. Could also be that Perl hackers tend to bite off small, discrete chunks that can actually be finished.

]]> Comment on Github language statistics by Alexandr Ciornii http://greenokapi.net/blog/2009/12/15/github-language-statistics/#comment-1963 Alexandr Ciornii Tue, 15 Dec 2009 19:32:00 +0000 http://greenokapi.net/blog/?p=173#comment-1963 There are big lies and there is statistics... "I eliminated projects with less than 3 watchers" - Perl projects are usually smaller, so there are less watchers. "Perl decline" is also suspicious: "This graph shows the number of commits per day, over the first 300 days of a project's life.". Currently there are many old Perl projects that are uploaded to GitHub, they usually were written by only one developers, or commited by only one developer. So this result is not surprising. There are big lies and there is statistics... "I eliminated projects with less than 3 watchers" - Perl projects are usually smaller, so there are less watchers. "Perl decline" is also suspicious: "This graph shows the number of commits per day, over the first 300 days of a project's life.". Currently there are many old Perl projects that are uploaded to GitHub, they usually were written by only one developers, or commited by only one developer. So this result is not surprising.

]]>