Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why your first Rust FizzBuzz implementation may not work

chrismorgan.info

Post reply on HN
Print view View original

81–90 of 139 posts

Re: Why your first Rust FizzBuzz implementation may not work

#81

Post by bluecalm »

icedog wrote: post #20

Putting the String issue aside, I just wanted to show the beauty of pattern matching. for i in range(1i, 101) { match (i % 3, i % 5) { (0, 0) => println!("Fizzbuzz"), (0, _) => println!("Fizz"), (_, 0) => println!("Buzz"), _ => println!("{}", i), } } -- edited: removed `.to_string()`, thanks chrismorgan

Python doesn't have pattern matching but the code is basically the same. I guess better cases for showing off the feature are ones where the patterns aren't just True/False tuples.

    for i in range (1, 101):
    	fbsign = (i % 3 == 0, i % 5 == 0)
	if fbsign == (1, 1): print("Fizzbuzz")
	elif fbsign == (1, 0): print("Fizz")
	elif fbsign == (0, 1): print("Buzz")
	else: print(i)

Re: Why your first Rust FizzBuzz implementation may not work

#82

Post by steveklabnik »

bjz_ wrote: post #79
steveklabnik wrote: post #67

Earlier quoted context omitted.

Small note, technically Rust never did HM, and now we _certainly_ don't. It's still inference, just not that algorithm.

Oh - I thought it was a variant on HM, extended for region inference?

I'm not _totally_ sure, but I do know when I tried to reference HM in the docs I got yelled at... and now I'm pretty sure we do http://smallcultfollowing.com/babysteps/blog/2014/07/09/an-e...

Re: Why your first Rust FizzBuzz implementation may not work

#83

Post by steveklabnik »

bluecalm wrote: post #81
icedog wrote: post #20

Putting the String issue aside, I just wanted to show the beauty of pattern matching. for i in range(1i, 101) { match (i % 3, i % 5) { (0, 0) => println!("Fizzbuzz"), (0, _) => println!("Fizz"), (_, 0) => println!("Buzz"), _ => println!("{}", i), } } -- edited: removed `.to_string()`, thanks chrismorgan

Python doesn't have pattern matching but the code is basically the same. I guess better cases for showing off the feature are ones where the patterns aren't just True/False tuples. for i in range (1, 101): fbsign = (i % 3 == 0, i % 5 == 0) if fbsign == (1, 1): print("Fizzbuzz") elif fbsign == (1, 0): print("Fizz") elif fbsign == (0, 1): print("Buzz") else: print(i)

One difference is that this won't do exhaustiveness checks, where the pattern match will.

Re: Why your first Rust FizzBuzz implementation may not work

#84

Post by throwaway283719 »

icedog wrote: post #34
kyllo wrote: post #31

Earlier quoted context omitted.

Weird to see this mix of a very imperative for-range iterative loop with a very functional pattern match, which makes it look similar to an SML or OCaml solution to FizzBuzz. I guess this is the definition of multi-paradigm right here. Will Rust's type checker warn you of a non-exhaustive pattern match?

Here's the same approach in F# without the different types of String; therefore, easier to get more functional. let fizzbuzz num = match num % 3, num % 5 with | 0,0 -> "FizzBuzz" | 0,_ -> "Fizz" | _,0 -> "Buzz" | _,_ -> num.ToString() [1..100] |> List.map fizzbuzz |> List.iter (fun (s:string) -> printfn "%s" s)

Haskell -

  fizzbuzz x = case (x `mod` 3, x `mod` 5) of
      (0, 0) -> "FizzBuzz"
      (0, _) -> "Fizz"
      (_, 0) -> "Buzz"
       _     -> show i

  mapM_ (putStrLn . fizzbuzz) [1..100]

Re: Why your first Rust FizzBuzz implementation may not work

#85

Post by [deleted] »

icedog wrote: post #20

Putting the String issue aside, I just wanted to show the beauty of pattern matching. for i in range(1i, 101) { match (i % 3, i % 5) { (0, 0) => println!("Fizzbuzz"), (0, _) => println!("Fizz"), (_, 0) => println!("Buzz"), _ => println!("{}", i), } } -- edited: removed `.to_string()`, thanks chrismorgan

[deleted]

Re: Why your first Rust FizzBuzz implementation may not work

#86

Post by throway-4-0-1 »

throwaway283719 wrote: post #84
icedog wrote: post #34

Earlier quoted context omitted.

Here's the same approach in F# without the different types of String; therefore, easier to get more functional. let fizzbuzz num = match num % 3, num % 5 with | 0,0 -> "FizzBuzz" | 0,_ -> "Fizz" | _,0 -> "Buzz" | _,_ -> num.ToString() [1..100] |> List.map fizzbuzz |> List.iter (fun (s:string) -> printfn "%s" s)

Haskell - fizzbuzz x = case (x `mod` 3, x `mod` 5) of (0, 0) -> "FizzBuzz" (0, _) -> "Fizz" (_, 0) -> "Buzz" _ -> show i mapM_ (putStrLn . fizzbuzz) [1..100]

Currying often allows for elegant point free code. Like in your last line, for F# they could also have written

    [1..100] |> List.iter (fizzbuzz >> printfn "%s")

Re: Why your first Rust FizzBuzz implementation may not work

#87

Post by mkesper »

retroencabulato wrote: post #72
shurcooL wrote: post #2

That was informative... and it reinforced my perception of Rust as something to look into if I ever have to do something that absolutely necessitates the use of something low level like C++/Assembly. But for everything else that I can get away with (and that is a lot so far) I'll stick with Go because it's so much faster and shorter to write.

If something absolutely necessitates using C++, why not use C++? (I'm genuinely asking.)

Because BUGS.

http://doc.rust-lang.org/nightly/intro.html#safety-%3Cem%3Ea...

Re: Why your first Rust FizzBuzz implementation may not work

#88

Post by mihai_ionic »

Here's what the final example from the blog would look like, if you were to directly translate it into C++: http://coliru.stacked-crooked.com/a/265c6ec6fb6751a9

Now, of course, no one would program that way, but I think it does help visualize what really happens.

The obvious cost from delaying the printing is that you have to branch a second time, later in the code, to consume the value. I wonder how feasible it would be to introduce some kind of compiler transform that could invert the control flow, essentially pasting the surrounding code into the inner branches, to make this abstraction cost-free.

Re: Why your first Rust FizzBuzz implementation may not work

#89

Post by Erwin »

steveklabnik wrote: post #83
bluecalm wrote: post #81

Earlier quoted context omitted.

Python doesn't have pattern matching but the code is basically the same. I guess better cases for showing off the feature are ones where the patterns aren't just True/False tuples. for i in range (1, 101): fbsign = (i % 3 == 0, i % 5 == 0) if fbsign == (1, 1): print("Fizzbuzz") elif fbsign == (1, 0): print("Fizz") elif fbsign == (0, 1): print("Buzz") else: print(i)

One difference is that this won't do exhaustiveness checks, where the pattern match will.

Well, here's an exhaustively checking version. Not statically still of course.

    for x in range(1,101):
        print [
                          # %3 = 0
        [      x,         "Fizz"  ],
        [   "Buzz",     "FizzBuzz"] # %5 = 0
        ][x%3 == 0][x%5 == 0]
(I'll note this was hard to get than if-checks and pattern matching so I won't be replacing such logic with matrices in my Python program any time soon...)

Re: Why your first Rust FizzBuzz implementation may not work

#90

Post by rplnt »

burntsushi wrote: post #8
Hello71 wrote: post #7

Earlier quoted context omitted.

sure, but when you're implicitly comparing code segments (by placing them next to each other), you should at least make the effort to make them more the same, instead of pointing out that one language is missing a feature used in the other language, especially when this claim is false. the formatting can of course be improved: for i in range(1, 101): print('FizzBuzz' if i % 15 == 0 else 'Buzz' if i % 5 == 0 else 'Fiz…

I disagree. I think code comparisons should be done using idiomatic code. I personally would not consider chaining `if` expressions like you've done here idiomatic Python.

I don't see a problem with code chosen for each example. What is a problem is explicitly stating that python doesn't have such functionality.
Post reply on HN