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

111–120 of 139 posts

Re: Why your first Rust FizzBuzz implementation may not work

#111

Post by mapleoin »

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)

That is very non-idiomatic python. Use True and False instead of 1 and 0 when comparing the (boolean) result of a comparison.

Re: Why your first Rust FizzBuzz implementation may not work

#112

Post by klibertp »

sillysaurus3 wrote: post #26
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

I guess beauty is in the eye of the programmer. I'd choose Python's or Ruby's FizzBuzz. It's beautiful that everyone can immediately understand those. This one, not so much. As a little experiment, I've deliberately avoided learning Rust to see if I can understand its idioms without reading any docs. I can sort of guess at what's going on here by reverse engineering what should happen with FizzBuzz, but it's not at a…

> As a little experiment, I've deliberately avoided learning Rust to see if I can understand its idioms without reading any docs.

A result of applying this approach to languages in general would be only knowing a couple of fairly similar languages. Which is bad. Really, really bad. Language influences our way of thinking in a non-trivial way, knowing only one kind of language is limiting.

Even worse, you're going to forever stay constrained to one family of languages that you didn't (probably) even chose yourself. In a current world it's ok if you were introduced to a C-like language as your first, but what if it was Pascal or Scheme?

In short: DON'T DO THIS. Learn more languages, the more FOREIGN (ie. you can't understand anything without docs) the BETTER. The 'intuitive' languages only let you express the same solution again and again, while breaking AWAY from your intuitions and learning 'non-intuitive' languages let's you see and implement DIFFERENT solutions.

Re: Why your first Rust FizzBuzz implementation may not work

#115

Post by Wilduck »

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)

Some people are sayint this is extremely non idiomatic python. I think most of the problem is not following the style guides. Here's a pep8 compliant solution that is a bit more idomatic, and almost as compact.

In Python, the way to do pattern matching is with dictionaries of functions.

    fizz_buzz = {(True, True): lambda x: "Fizzbuzz",
                 (True, False): lambda x: "Fizz",
                 (False, True): lambda x: "Buzz",
                 (False, False): lambda x: x}

    for i in range(1, 30):
        fbsign = (i % 3 == 0, i % 5 == 0)
        print(fizz_buzz[fbsign](i))

Re: Why your first Rust FizzBuzz implementation may not work

#116

Post by stonemetal »

sillysaurus3 wrote: post #26
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

I guess beauty is in the eye of the programmer. I'd choose Python's or Ruby's FizzBuzz. It's beautiful that everyone can immediately understand those. This one, not so much. As a little experiment, I've deliberately avoided learning Rust to see if I can understand its idioms without reading any docs. I can sort of guess at what's going on here by reverse engineering what should happen with FizzBuzz, but it's not at a…

It must just be a matter of familiarity. Rust's pattern matching is quite similar to other languages with pattern matching.

For example in OCaml the match statement would be:

     match ( i mod 3, i mod 5) with 
      | (0,0) -> Printf.printf "Fizzbuzz"
      | (0,_) -> Printf.printf "Fizz"
      | (_,0) -> Printf.printf "buzz"
      | (_,_) -> Printf.printf "%d" i
Other than the irrelevant syntax bits like 'with', the semantics are identical, in order matching with no fall through, and _ for unnamed and unused bindings.

To me with very limited experience in it, Rust really feels like OCaml with a skin that C programmers will understand.

Re: Why your first Rust FizzBuzz implementation may not work

#117

Post by kibwen »

dbaupp wrote: post #110
kibwen wrote: post #109

Earlier quoted context omitted.

I think this is an anti-pattern. I'm not a fan of the slicing syntax in general, which seems to exist only to paper over the missing traits that wycats mentions.

We will almost certainly just have `Deref for String` and so autoderef will handle `some_string.some_slice_method()` correctly.

Will we be able to kill the slicing syntax, then? :)

Re: Why your first Rust FizzBuzz implementation may not work

#118

Post by steveklabnik »

jerf wrote: post #113

You know Rust team, it almost might be worth specializing this exact error message about mismatched string lifetimes to include a URL to this post, if not mismatched lifetimes in general. You know it's going to be a FAQ....

We have unique diagnostic codes for each error, and I have plans (and an in-progress PR) that points to a web page with a much longer "this is what this error looks like, here are some strategies with how to fix it" in the works.

Re: Why your first Rust FizzBuzz implementation may not work

#119

Post by blt »

"may not compile" would be a better title than "may not work". To a programmer familiar with compiled languages, "may not work" implies that the code will compile but produce the wrong result/a crash/undefined behavior. Rust aims to catch mistakes at compile time, so the headline is quite sensational under this interpretation.

Re: Why your first Rust FizzBuzz implementation may not work

#120

Post by Tyr42 »

frankzinger wrote: post #98
shurcooL wrote: post #91

Earlier quoted context omitted.

Because writing and compiling code/projects in it is very painful. Header files, custom makefiles, etc.

Pardon me, but 'custom makefiles' have absolutely nothing to do with C++. There are IDEs with C++ support. Also, while working with headerless languages may be easier, calling working with headers 'very painful' is hyperbole.

Irregardless of IDEs, I'd still need to learn how to use cmake and other systems to build and use libraries. It's a large pain compared to `pip install ...`.
Post reply on HN