|
|
|
|
|
|
Submitted by Bryce on Tue, 08/28/2012 - 10:01
|
I just finished reading the book Coders at Work by Peter Seibel. This wonderful book is filled with interviews with prominent programmers: Joe Armstrong, Simon Peyton Jones, Donald Knuth, among others. My review isn't going to be the standard book review. Instead I'm going to talk about some of the specific ideas I picked up while reading the book and discuss those ideas, rather than the book itself. For those of you who are looking for more of a standard review, all I can really say is that Coders at Work is well worth the time for a programmer or a computer historian/hobbyist. Unfortunately for the casual non-computer-field reader, the interview topics (and the interviewees) assume a certain level of prior knowledge. What makes this book so good is that different people will be able to walk away from it with different ideas, depending on their areas of expertise and interest. As the industry grows and changes, we definitely do things based on what the people before us have already discovered - Seibel’s interview subjects are the fascinating programmers whose ideas and hard work make possible all the cool things we get to play with today.
Code Readings:
In the interview with Douglas Crockford there was a lot of talk about code readings. If you’re not sure what those are (I wasn’t), from the way Douglas describes it they are regular meetings where programmers read the code base together. In my mind it sounds like someone is giving a presentation but instead of it being PowerPoint slides, it’s code. I picture the presenter going line by line and describing what is going on and why he or she decided to do things a particular way. These sound like an excellent idea to me. In my experience so far, the code review process seems to have been relegated to using Reviewboard or other similar website-based tools. I'm not trying to insult these tools, but they remove the human factor of the code review and hinder the discussion that can happen over a particular piece of code. I understand that programmer time is expensive and managers should be careful how much of that time is spent in meetings. But I think these meetings could benefit everyone and will have a return on investment (that is the time spent) in ways that cannot be quickly seen. One benefit is that everyone who attends will come out with a basic idea of what the code looks like within a given project, even if they’re not working on that project directly. So if things shift around (as they inevitably do) and a new person is moved into that project, he or she won’t be starting from scratch. Even just a little bit of knowledge might help a programmer get over the initial shock of having to dive into a new project.
Programmers need Empathy:
In the interview with Joshua Bloch there was a quick chat about programmer personalities. There were a couple of choice quotes regarding programmer empathy for the users, like, “...intelligence is not a scalar quantity; it’s a vector quantity. And if you lack empathy or emotional intelligence, then you shouldn’t be designing APIs or GUIs or languages.” and “What we’re doing is an aesthetic pursuit. It involves craftsmanship as well as mathematics and it involves people skills and prose skills—all of these things that we don’t necessarily think of as engineering but without which I don’t think you’ll ever be a really good engineer.”
I bring these quotes up because I agree with them, and because they speak of issues that are largely ignored in the engineering community (again, in my experience). I've sure we’ve all run into programmers that only care about the technical aspects of the project or the correctness of their code and do not concern themselves for how the user might interact with the system. For example, the company I work for designed a web-app that included separate “Kill” and “Terminate” buttons. This was a complete UI fail that could have been avoided, had the programmer (we’ll call him/her “Terry”) had empathy for the user. As a programmer, I understand the difference between SIGKILL and SIGTERM, but those buttons would be confusing to even the more-advanced-than-average user (and go far beyond failing the grandmother test). When this was brought up as a ticket for “Terry” to fix, “Terry” argued that there was nothing technically incorrect about the problem and closed the ticket “Won't Fix.”
Hiring:
One thing I noticed in a lot of the interviews was that Peter asked the interviewee what he or she looked for in a potential new hire. What I found fascinating is that none of them said, “I like to ask really hard questions.” or “I ask really obscure questions about the programming language they use to see how well they know it.” They mostly talked about looking for someone who had passion for the craft.
As someone who is frequently on both sides of the hiring table, I know that the current hiring process in Silicon Valley doesn't normally ask questions about WHO is being hired. Questions about hobbies or interests are rare. It's mostly just technical questions, as if the person who is applying for the job is another computer whose sole purpose is to solve a company's problems. All the emphasis seems to be focused on the technical skills of the interviewee. While it's important to know if someone can “do the job,” tech skills alone do not make a person a great programmer - a good one, yes, but I don’t get the impression that companies are settling for “good” anymore. Passion is what gives someone the tenacity to work through the obstacles and become a great programmer, and if we as interviewers insist on focusing only on hard skills, we risk cheating ourselves out of the truly great engineers.
Donald Knuth:
Peter also asked every single interviewee about Donald Knuth's books and his “literate programming”
style of writing code. I will admit that I have not read his books, but I want to. I'm not sure what this literate programming style is, but I'm curious enough about it to learn, and see if there are some aspects of it I can incorporate into my own coding and documentation style. Next step, pick up an electronic version of the book, “Literate Programming” and give it a good read.
I fully enjoyed Coders at Work. I took away much more from the interviews than I talked about here, and I’m sure there’s even more to learn. I'm planning on rereading it again in a couple of years; as I grow as a programmer I will have a different perspective on the craft, and might find a whole new or different set of lessons from what I got this time. If not, at the very least I’ll have the pleasure of reading it again.
|
|
|
|
|
|
|
|
|
|
Submitted by Bryce on Wed, 07/25/2012 - 09:45
|
“The following iterative sequence is defined for the set of positive integers: n → n/2 (n is even) n → 3n + 1 (n is odd). Using the rule above and starting with 13, we generate the following sequence: 13 → 40 → 20 → 10 → 5 → 16 → 8 → 4 → 2 → 1. It can be seen that this sequence (starting at 13 and finishing at 1) contains 10 terms. Although it has not been proved yet (Collatz Problem), it is thought that all starting numbers finish at 1. Which starting number, under one million, produces the longest chain? NOTE: Once the chain starts the terms are allowed to go above one million.”
Not many of you may be aware of this, but about a year ago I wrote up a blog post that discussed Collatz chains in Haskell. You can find that post here: . Having some of the code already written made coming up with the solution easier. However, just because I had one function doesn't mean I had the whole problem licked. I still had a fair amount of work in front of me. Below is my code from the first attempt at a solution:
module Main where import Data.List chain' 1 = [1] chain' n | n <= 0 = [] | odd n = n : chain' (n * 3 + 1) main = do let seqx = map chain' [3..1000000]
This code appears to be logically correct but was incredibly slow - so slow that after over 2 minutes it still hadn’t completed. I admit I can be a little impatient with these things from time to time, but in this case something was obviously wrong.
I devised two optimizations:
- Reverse the order of the list. I will be more likely to find the number with the longest chain near 1,000,000 than 3.
- Use odd numbers only. This is based on the fact that in the chain' function an odd number gets multiplied right off the bat, whereas an even number is instantly divided by 2, and also on the assumption that a higher number will be more likely to have a longer chain. (I admit this was a complete experiment - I had no proof that it would work ahead of time, and knew it gave me the right answer only after the fact.)
The code then morphed into:
module Main where import Data.List chain' 1 = [1] chain' n | n <= 0 = [] | odd n = n : chain' (n * 3 + 1) main = do let seqx = map chain' [999999,999997..3]
The problem I ran into with this code was that I received stack overflow errors; my list of tuples holding another long list of int’s was taking up to much memory. I fixed this problem by computing the length of the list immediately after generating it. The new code looked like this:
import Data.List chain' 1 = [1] chain' n | n <= 0 = [] | odd n = n : chain' (n * 3 + 1) main = do let seqx = map (\x → (x , length $ chain' x ) [999999,999997..3]
This got me a result within the one minute time frame, but it still wasn't the right answer. Can you figure out why? Using the great code Jedai posted in the comments of my Apache log post, I was able to get my answer and finally complete the problem:
module Main where import Data.Tuple import Data.List (sortBy) import Data.Function (on) chain' 1 = [1] chain' n | n <= 0 = [] | odd n = n : chain' (n * 3 + 1) main = do let seqx = map (\x -> (x , length $ chain' x )) [999999,999997..3]
After figuring that out, getting the python answer was a breeze:
#!/usr/bin/python """Python solution for Project Euler problem #14.""" from itertools import imap def sequence(number): t_num = number count = 1 while(t_num > 1): if t_num % 2 == 0: t_num /= 2 else: t_num = (t_num * 3) + 1 count += 1 return (count, number) if __name__ == "__main__": print max(imap(sequence, xrange(999999,3,-2)))
Here are the speed numbers:
Haskell (complied) : 14.758s
Python : 18.537s
Haskell (runghc): 15.217s
I think the use of recursion in my Haskell code is affecting its speed of computation. As I learned from problem 12, I can use the State Monad again to speed things up. But I also learned from the comments of problem 12 that some people were able to substitute a scan or fold in the State Monad’s place. So I decided to shoot for one more solution. After studying up on scan and fold, and finding that neither was really what I wanted, I found iterate. Using iterate I was able to change the program to this:
module Main where import Data.Tuple import Data.Function (on) chain' n | n < 1 = 0 main = do let seqx = map (\x -> (x , chain' x )) [999999,999997..3]
The new chain' function doesn't read as cleanly as the old one, but it does remove the recursion I was talking about earlier. The computer gods rewarded my efforts by reducing the run times to these:
Haskell (complied) : 10.933s
Haskell (runghc): 11.744s
From 14.758 to 10.933 - almost 4 seconds taken off the clock! I think a speed up like that calls for some celebrating. Which is exactly what I'm going to do before I start on problem 15.
|
|
|
|
|
|
|
|
|
|
Submitted by Bryce on Fri, 06/29/2012 - 09:30
|
Another 365 have come and gone since the last time I've written one of these birthday posts, and like last time I'm still surprised and still proud that this blog and my creative juices have survived this long.
I will be the first to admit that I'm totally amazed over 17 THOUSAND people from all over the world have dropped by my site and read my writing. Who know what I had to say was that interesting? Knowing that interest is growing really makes me want to continue improving my writing and finding more interesting projects to explore. Last year Scrollingtext saw a little more than 10 thousand people - there’s been an amazing amount of growth over the last year, and I think I'm going to make it a personal goal to continue this trend.
The five most popular posts for the year are:
- PXE Network Boot VirtualBox, PT 2 – This one has been up here for a long time. Seeing this in the top 5 makes me think I should think about doing follow-up posts on VirtualBox. Apparently people find this helpful.
- Using curl and a user agent string for web scraping – I had no idea that web scraping would be so popular. Maybe I should write a follow-up article for this one too.
- Project Euler: Problem 5 – The biggest thing for me about this post was learning about lcm's. As has been pointed out to me in the comments for Problem 12, and as a statement about programming in general, understanding the problem and knowing the right algorithm (or two) that solve it is more than half the battle.
- Project Euler: Problem 4 – I think this one takes the cake for most comments on a single post. Oh and OJ, I was just reading over those comments and I think I picked up on your subtle optimization. Nice little trick!
- Project Euler: Problem 12 – I was really proud of this post. I spent a lot of time and energy learning how to use the State Monad to get the problem to run and the result was totally worth the effort.
Things I've learned:
For the last year I've had an actual programming job, and within that job I've learned a lot of python programming tricks and idioms - some of which I know have carried over into my personal style. My playing around with Haskell as also affected my style of programming. My boss can identify my code on sight because I use fewer variables than my co-workers. So in a way I've learned that everything I do, both at work and on my own, are connected. The time spent thinking about Project Euler problems and writing that code may not directly translate to what I do at work, but it definitely has an effect on the code I end up writing at work (and the quality of that code).
No retrospective post would not be complete without the “Thank yous.” First, thank you to my girlfriend , Kelsey. If it wasn't for her I wouldn't be able to properly articulate my thoughts to the world. And secondly thank you to the 17 thousand people who visited the site last year, all the people who visited in the previous two, and everyone who keeps coming back. Having a place where I can post what I'm currently working on in my spare time is a nifty thing. But having people actually read it makes it so much cooler! So thank you to everyone who's ever read something on my site, where ever you are now.
On that note, Happy 3rd birthday Scrollingtext. Here’s to another year and hopefully many more.
** Photo copied from here: http://www.flickr.com/photos/ebelbeb/5244753318/
|
|
|
|
|
|
|
|
|
|
Submitted by Bryce on Tue, 05/22/2012 - 09:48
|
Problem thirteen from Project Euler is one of those problems that's so simple, I don't understand why it's in the double digits section. The problem reads: “Work out the first ten digits of the sum of the following one-hundred 50-digit numbers.”
It then proceeds to list 100 long numbers. I'm not going to paste them here because they are in the code solutions below and I don't want to clog up the “tubez” with more redundant information than I'm about to.
Enough of my jibber-jabber. Here is my Haskell solution first (trying to change things up here):
module Main where main = do where big_number = [ 37107287533902102798797998220837590246510135740250 , 46376937677490009712648124896970078050417018260538 , 74324986199524741059474233309513058123726617309629 , 91942213363574161572522430563301811072406154908250 , 23067588207539346171171980310421047513778063246676 , 89261670696623633820136378418383684178734361726757 , 28112879812849979408065481931592621691275889832738 , 44274228917432520321923589422876796487670272189318 , 47451445736001306439091167216856844588711603153276 , 70386486105843025439939619828917593665686757934951 , 62176457141856560629502157223196586755079324193331 , 64906352462741904929101432445813822663347944758178 , 92575867718337217661963751590579239728245598838407 , 58203565325359399008402633568948830189458628227828 , 80181199384826282014278194139940567587151170094390 , 35398664372827112653829987240784473053190104293586 , 86515506006295864861532075273371959191420517255829 , 71693888707715466499115593487603532921714970056938 , 54370070576826684624621495650076471787294438377604 , 53282654108756828443191190634694037855217779295145 , 36123272525000296071075082563815656710885258350721 , 45876576172410976447339110607218265236877223636045 , 17423706905851860660448207621209813287860733969412 , 81142660418086830619328460811191061556940512689692 , 51934325451728388641918047049293215058642563049483 , 62467221648435076201727918039944693004732956340691 , 15732444386908125794514089057706229429197107928209 , 55037687525678773091862540744969844508330393682126 , 18336384825330154686196124348767681297534375946515 , 80386287592878490201521685554828717201219257766954 , 78182833757993103614740356856449095527097864797581 , 16726320100436897842553539920931837441497806860984 , 48403098129077791799088218795327364475675590848030 , 87086987551392711854517078544161852424320693150332 , 59959406895756536782107074926966537676326235447210 , 69793950679652694742597709739166693763042633987085 , 41052684708299085211399427365734116182760315001271 , 65378607361501080857009149939512557028198746004375 , 35829035317434717326932123578154982629742552737307 , 94953759765105305946966067683156574377167401875275 , 88902802571733229619176668713819931811048770190271 , 25267680276078003013678680992525463401061632866526 , 36270218540497705585629946580636237993140746255962 , 24074486908231174977792365466257246923322810917141 , 91430288197103288597806669760892938638285025333403 , 34413065578016127815921815005561868836468420090470 , 23053081172816430487623791969842487255036638784583 , 11487696932154902810424020138335124462181441773470 , 63783299490636259666498587618221225225512486764533 , 67720186971698544312419572409913959008952310058822 , 95548255300263520781532296796249481641953868218774 , 76085327132285723110424803456124867697064507995236 , 37774242535411291684276865538926205024910326572967 , 23701913275725675285653248258265463092207058596522 , 29798860272258331913126375147341994889534765745501 , 18495701454879288984856827726077713721403798879715 , 38298203783031473527721580348144513491373226651381 , 34829543829199918180278916522431027392251122869539 , 40957953066405232632538044100059654939159879593635 , 29746152185502371307642255121183693803580388584903 , 41698116222072977186158236678424689157993532961922 , 62467957194401269043877107275048102390895523597457 , 23189706772547915061505504953922979530901129967519 , 86188088225875314529584099251203829009407770775672 , 11306739708304724483816533873502340845647058077308 , 82959174767140363198008187129011875491310547126581 , 97623331044818386269515456334926366572897563400500 , 42846280183517070527831839425882145521227251250327 , 55121603546981200581762165212827652751691296897789 , 32238195734329339946437501907836945765883352399886 , 75506164965184775180738168837861091527357929701337 , 62177842752192623401942399639168044983993173312731 , 32924185707147349566916674687634660915035914677504 , 99518671430235219628894890102423325116913619626622 , 73267460800591547471830798392868535206946944540724 , 76841822524674417161514036427982273348055556214818 , 97142617910342598647204516893989422179826088076852 , 87783646182799346313767754307809363333018982642090 , 10848802521674670883215120185883543223812876952786 , 71329612474782464538636993009049310363619763878039 , 62184073572399794223406235393808339651327408011116 , 66627891981488087797941876876144230030984490851411 , 60661826293682836764744779239180335110989069790714 , 85786944089552990653640447425576083659976645795096 , 66024396409905389607120198219976047599490197230297 , 64913982680032973156037120041377903785566085089252 , 16730939319872750275468906903707539413042652315011 , 94809377245048795150954100921645863754710598436791 , 78639167021187492431995700641917969777599028300699 , 15368713711936614952811305876380278410754449733078 , 40789923115535562561142322423255033685442488917353 , 44889911501440648020369068063960672322193204149535 , 41503128880339536053299340368006977710650566631954 , 81234880673210146739058568557934581403627822703280 , 82616570773948327592232845941706525094512325230608 , 22918802058777319719839450180888072429661980811197 , 77158542502016545090413245809786882778948721859617 , 72107838435069186155435662884062257473692284509516 , 20849603980134001723930671666823555245252804609722 , 53503534226472524250874054075591789781264330331690]
followed by my Python solution:
#!/usr/bin/python """ code solution for project euler's problem #13 in python. """ from __future__ import print_function def print_10(number): print(str(number)[0:10]) if __name__ == "__main__": big_number = [ 37107287533902102798797998220837590246510135740250, 46376937677490009712648124896970078050417018260538, 74324986199524741059474233309513058123726617309629, 91942213363574161572522430563301811072406154908250, 23067588207539346171171980310421047513778063246676, 89261670696623633820136378418383684178734361726757, 28112879812849979408065481931592621691275889832738, 44274228917432520321923589422876796487670272189318, 47451445736001306439091167216856844588711603153276, 70386486105843025439939619828917593665686757934951, 62176457141856560629502157223196586755079324193331, 64906352462741904929101432445813822663347944758178, 92575867718337217661963751590579239728245598838407, 58203565325359399008402633568948830189458628227828, 80181199384826282014278194139940567587151170094390, 35398664372827112653829987240784473053190104293586, 86515506006295864861532075273371959191420517255829, 71693888707715466499115593487603532921714970056938, 54370070576826684624621495650076471787294438377604, 53282654108756828443191190634694037855217779295145, 36123272525000296071075082563815656710885258350721, 45876576172410976447339110607218265236877223636045, 17423706905851860660448207621209813287860733969412, 81142660418086830619328460811191061556940512689692, 51934325451728388641918047049293215058642563049483, 62467221648435076201727918039944693004732956340691, 15732444386908125794514089057706229429197107928209, 55037687525678773091862540744969844508330393682126, 18336384825330154686196124348767681297534375946515, 80386287592878490201521685554828717201219257766954, 78182833757993103614740356856449095527097864797581, 16726320100436897842553539920931837441497806860984, 48403098129077791799088218795327364475675590848030, 87086987551392711854517078544161852424320693150332, 59959406895756536782107074926966537676326235447210, 69793950679652694742597709739166693763042633987085, 41052684708299085211399427365734116182760315001271, 65378607361501080857009149939512557028198746004375, 35829035317434717326932123578154982629742552737307, 94953759765105305946966067683156574377167401875275, 88902802571733229619176668713819931811048770190271, 25267680276078003013678680992525463401061632866526, 36270218540497705585629946580636237993140746255962, 24074486908231174977792365466257246923322810917141, 91430288197103288597806669760892938638285025333403, 34413065578016127815921815005561868836468420090470, 23053081172816430487623791969842487255036638784583, 11487696932154902810424020138335124462181441773470, 63783299490636259666498587618221225225512486764533, 67720186971698544312419572409913959008952310058822, 95548255300263520781532296796249481641953868218774, 76085327132285723110424803456124867697064507995236, 37774242535411291684276865538926205024910326572967, 23701913275725675285653248258265463092207058596522, 29798860272258331913126375147341994889534765745501, 18495701454879288984856827726077713721403798879715, 38298203783031473527721580348144513491373226651381, 34829543829199918180278916522431027392251122869539, 40957953066405232632538044100059654939159879593635, 29746152185502371307642255121183693803580388584903, 41698116222072977186158236678424689157993532961922, 62467957194401269043877107275048102390895523597457, 23189706772547915061505504953922979530901129967519, 86188088225875314529584099251203829009407770775672, 11306739708304724483816533873502340845647058077308, 82959174767140363198008187129011875491310547126581, 97623331044818386269515456334926366572897563400500, 42846280183517070527831839425882145521227251250327, 55121603546981200581762165212827652751691296897789, 32238195734329339946437501907836945765883352399886, 75506164965184775180738168837861091527357929701337, 62177842752192623401942399639168044983993173312731, 32924185707147349566916674687634660915035914677504, 99518671430235219628894890102423325116913619626622, 73267460800591547471830798392868535206946944540724, 76841822524674417161514036427982273348055556214818, 97142617910342598647204516893989422179826088076852, 87783646182799346313767754307809363333018982642090, 10848802521674670883215120185883543223812876952786, 71329612474782464538636993009049310363619763878039, 62184073572399794223406235393808339651327408011116, 66627891981488087797941876876144230030984490851411, 60661826293682836764744779239180335110989069790714, 85786944089552990653640447425576083659976645795096, 66024396409905389607120198219976047599490197230297, 64913982680032973156037120041377903785566085089252, 16730939319872750275468906903707539413042652315011, 94809377245048795150954100921645863754710598436791, 78639167021187492431995700641917969777599028300699, 15368713711936614952811305876380278410754449733078, 40789923115535562561142322423255033685442488917353, 44889911501440648020369068063960672322193204149535, 41503128880339536053299340368006977710650566631954, 81234880673210146739058568557934581403627822703280, 82616570773948327592232845941706525094512325230608, 22918802058777319719839450180888072429661980811197, 77158542502016545090413245809786882778948721859617, 72107838435069186155435662884062257473692284509516, 20849603980134001723930671666823555245252804609722, 53503534226472524250874054075591789781264330331690] print_10(sum(big_number))
and to continue adding in the spice, I have included a solution in Scala:
def main (args : Array [String ]){ val big _number = List ("37107287533902102798797998220837590246510135740250", "46376937677490009712648124896970078050417018260538", "74324986199524741059474233309513058123726617309629", "91942213363574161572522430563301811072406154908250", "23067588207539346171171980310421047513778063246676", "89261670696623633820136378418383684178734361726757", "28112879812849979408065481931592621691275889832738", "44274228917432520321923589422876796487670272189318", "47451445736001306439091167216856844588711603153276", "70386486105843025439939619828917593665686757934951", "62176457141856560629502157223196586755079324193331", "64906352462741904929101432445813822663347944758178", "92575867718337217661963751590579239728245598838407", "58203565325359399008402633568948830189458628227828", "80181199384826282014278194139940567587151170094390", "35398664372827112653829987240784473053190104293586", "86515506006295864861532075273371959191420517255829", "71693888707715466499115593487603532921714970056938", "54370070576826684624621495650076471787294438377604", "53282654108756828443191190634694037855217779295145", "36123272525000296071075082563815656710885258350721", "45876576172410976447339110607218265236877223636045", "17423706905851860660448207621209813287860733969412", "81142660418086830619328460811191061556940512689692", "51934325451728388641918047049293215058642563049483", "62467221648435076201727918039944693004732956340691", "15732444386908125794514089057706229429197107928209", "55037687525678773091862540744969844508330393682126", "18336384825330154686196124348767681297534375946515", "80386287592878490201521685554828717201219257766954", "78182833757993103614740356856449095527097864797581", "16726320100436897842553539920931837441497806860984", "48403098129077791799088218795327364475675590848030", "87086987551392711854517078544161852424320693150332", "59959406895756536782107074926966537676326235447210", "69793950679652694742597709739166693763042633987085", "41052684708299085211399427365734116182760315001271", "65378607361501080857009149939512557028198746004375", "35829035317434717326932123578154982629742552737307", "94953759765105305946966067683156574377167401875275", "88902802571733229619176668713819931811048770190271", "25267680276078003013678680992525463401061632866526", "36270218540497705585629946580636237993140746255962", "24074486908231174977792365466257246923322810917141", "91430288197103288597806669760892938638285025333403", "34413065578016127815921815005561868836468420090470", "23053081172816430487623791969842487255036638784583", "11487696932154902810424020138335124462181441773470", "63783299490636259666498587618221225225512486764533", "67720186971698544312419572409913959008952310058822", "95548255300263520781532296796249481641953868218774", "76085327132285723110424803456124867697064507995236", "37774242535411291684276865538926205024910326572967", "23701913275725675285653248258265463092207058596522", "29798860272258331913126375147341994889534765745501", "18495701454879288984856827726077713721403798879715", "38298203783031473527721580348144513491373226651381", "34829543829199918180278916522431027392251122869539", "40957953066405232632538044100059654939159879593635", "29746152185502371307642255121183693803580388584903", "41698116222072977186158236678424689157993532961922", "62467957194401269043877107275048102390895523597457", "23189706772547915061505504953922979530901129967519", "86188088225875314529584099251203829009407770775672", "11306739708304724483816533873502340845647058077308", "82959174767140363198008187129011875491310547126581", "97623331044818386269515456334926366572897563400500", "42846280183517070527831839425882145521227251250327", "55121603546981200581762165212827652751691296897789", "32238195734329339946437501907836945765883352399886", "75506164965184775180738168837861091527357929701337", "62177842752192623401942399639168044983993173312731", "32924185707147349566916674687634660915035914677504", "99518671430235219628894890102423325116913619626622", "73267460800591547471830798392868535206946944540724", "76841822524674417161514036427982273348055556214818", "97142617910342598647204516893989422179826088076852", "87783646182799346313767754307809363333018982642090", "10848802521674670883215120185883543223812876952786", "71329612474782464538636993009049310363619763878039", "62184073572399794223406235393808339651327408011116", "66627891981488087797941876876144230030984490851411", "60661826293682836764744779239180335110989069790714", "85786944089552990653640447425576083659976645795096", "66024396409905389607120198219976047599490197230297", "64913982680032973156037120041377903785566085089252", "16730939319872750275468906903707539413042652315011", "94809377245048795150954100921645863754710598436791", "78639167021187492431995700641917969777599028300699", "15368713711936614952811305876380278410754449733078", "40789923115535562561142322423255033685442488917353", "44889911501440648020369068063960672322193204149535", "41503128880339536053299340368006977710650566631954", "81234880673210146739058568557934581403627822703280", "82616570773948327592232845941706525094512325230608", "22918802058777319719839450180888072429661980811197", "77158542502016545090413245809786882778948721859617", "72107838435069186155435662884062257473692284509516", "20849603980134001723930671666823555245252804609722", "53503534226472524250874054075591789781264330331690") map {BigInt(_)} val sums = big _number sum println(su10) } }
Some of you may be wondering, “Why a Scala solution?” To which I respond, “Why not?” Because that's a little short, I'll add that it has something to do with Scala starting to gain traction in the industry and me seeing if I would like to get paid to program in it.
The solution, in all three languages, is pretty simple. The recipe essentially says, “Put all numbers into a list. Get the sum of that list, turn that number into a string, and get the first 10 characters of that string.”
Times:
Haskell (compiled) : real 0m0.004s
Haskell (runghc) : real 0m0.314s
Python : real 0m0.059s
Scala (compiled) : real 0m0.757s
For the most part it's pretty standard in these tests to see performance times such that Haskell (compiled) < Python < Haskell (runghc). Java and Perl usually fall somewhere between the Haskell (compiled) and Python, in that order. To see Scala be 2x slower than Haskell (runghc) was a shocker. The only thing that makes sense to me for the slowdown is having to use the BigInt library. That is probably the biggest thing I took away from these time tests - if I want to do REALLY large number crunching and performance DOES matter, JVM-based languages might not be the best option.
A few thoughts on Scala:
If I haven't stated it already in this blog, I should now give the disclaimer that I'm not a Java fan. I know it still has its loyal followers, but I'm not one of them. Moving on. This was my first time working with Scala, and I'd like to finally welcome Java to the 21st century. While doing some research on the Scala language itself I read that “the industry” was moving to replace Java with Scala. I welcome that change. Does that mean I “like” Scala? The honest answer is, to butcher the quote the appliances from the Flintstones, “Eh, it's a language.” Scala is definitely an improvement over Java – not really that hard to do in my opinion – but, the language still feels unpolished. One quick way to kill the interpreter in Scala is to type “Int” then hit the enter key. Instead of error-ing out, the interpreter does a great job of interpreting a crash test car hitting a cement wall (I had to restart the whole thing.) When I tried the same “technique” in the Python interpreter, I got as a response and for Haskell's interpreter I received “Not in scope: data constructor `Int'”. I also found Scala's function composition to be a little lacking when compared to Haskell. I wasn't able to cleanly change the BigInt data type to String, and then only print out ten characters without requiring three separate val's. Yes, I could have used one var instead, but that's beside the point. I will admit it could be my inexperience with the language showing, so if anyone knows a smoother way to do this in Scala please share it in the comments.
All that being said, I do like the way Scala is trying to handle the reducing of Java's dot notation, and I think it's starting to make strides in the right direction in other areas. I'm open to working with Scala more, and look forward to seeing how it evolves over the next few years.
|
|
|
|
|
|
|
