What's up with the "alternative" form of Python? What about braces, semicolons, and an explicit main() function makes that version worth showing?
Why your first Rust FizzBuzz implementation may not work
11–20 of 139 posts
Re: Why your first Rust FizzBuzz implementation may not work
#12Earlier 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.
and yet people write:
let result = if i % 15 == 0 {
"FizzBuzz"
} else if i % 5 == 0 {
"Buzz"
} else if i % 3 == 0 {
"Fizz"
} else {
i
};
Re: Why your first Rust FizzBuzz implementation may not work
#13The feature list in rust really does have my eye. The biggest one in particular was type inference.
The reason type inference was such a big one was because if you use it right, annoying situations like "Two types of strings? What is this?" go the hell away. You have three types, static built in and binary strings, and a third that only makes the gaurentee that the datatype can do all the things a string aught to be able to do, and from there the compiler works out the practical implementations.
This article has done a great job in killing my enthusiasm for the language.
I guess it's implementation of type inference only goes as far as golangs, in that const keyword.
Maybe I was being a bit naive in what I was expecting, hell maybe what I'm expecting isn't reasonably possible. bleh.
Re: Why your first Rust FizzBuzz implementation may not work
#14What's up with the "alternative" form of Python? What about braces, semicolons, and an explicit main() function makes that version worth showing?
Well, "from __future__ import braces" is a joke, so applying the transitive property of jokes, I assume this alternative version is a joke as well.
Re: Why your first Rust FizzBuzz implementation may not work
#15Earlier quoted context omitted.
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.
and yet people write: let result = if i % 15 == 0 { "FizzBuzz" } else if i % 5 == 0 { "Buzz" } else if i % 3 == 0 { "Fizz" } else { i }; in rust? either this is good, readable code or this is poorly written, unintelligible code. you cannot make the argument that sometimes it is readable and sometimes not based on the presence of braces.
The comparison is not "readable", it is "idiomatic". (I'm not saying either is unreadable, just pointing out that you're attacking the wrong thing.)
Re: Why your first Rust FizzBuzz implementation may not work
#16Earlier quoted context omitted.
> it's so much faster and shorter to write This is not obviously true to me, Rust provides more tools for building abstractions, even just "handle errors less manually"-abstractions, so they're possibly not that different (this certainly applies to the 'shorter' section). I guess it may be true for the things Go is suited/designed for; time and experience will tell.
Anecdotes and personal opinions follow. I'm pretty happy with the speed at which I write Rust code, but I can definitely churn out Go code more quickly. (Probably on the order of how quickly I can write Python, although refactoring Go code is much faster.) I'm not sure exactly why, but my guess is that there are fewer abstractions to deal with (and fewer opportunities to make abstractions). I have written several med…
Yeah, that's why I focused on 'shorter' more than 'quicker'. (And I wasn't saying it is not true, just pointing out that it's cut and dried.)
Re: Why your first Rust FizzBuzz implementation may not work
#17meh.
fizz x = mod x 3 == 0
buzz x = mod x 5 == 0
fizzbuzz x
| fizz x && buzz x = FizzBuzz
| fizz x = Fizz
| buzz x = Buzz
| otherwise = NoFizzBuzz x
data FizzBuzz = Fizz | Buzz | FizzBuzz | NoFizzBuzz Int
instance Show FizzBuzz where
show Fizz = "Fizz"
show Buzz = "Buzz"
show FizzBuzz = "FizzBuzz"
show (NoFizzBuzz x) = show x
main = mapM_ (putStrLn . show) $ map fizzbuzz [1..101]Re: Why your first Rust FizzBuzz implementation may not work
#18for i in range(1, 101): print('FizzBuzz' if i % 15 == 0 else 'Buzz' if i % 5 == 0 else 'Fizz' if i % 3 == 0 else i) python doesn't have expressions? oh dear me.
I think that "{true} if {cond} else {false}" is quite an unnatural and confusing construct, especially when you attempt to nest them. Although I'm not really familiar with Python I thought that was concatenating 'FizzBuzz' with the value of some nested ternary expression and only realised the order was inverted when I tried to parse the inner one.
The vast majority of conditionals in languages I know follow the {cond} {true} {false} order: IIf({cond}, {true}, {false}) in VB, SQL, and spreadsheets; if({cond}) {true} else {false} and ternary {cond}?{true}:{false} in C and C-derived languages; (if {cond} {true} {false}) in the Lisp family; if {cond} then {true} else {false} in ALGOL/Pascal, etc. There's probably a reason for this order, as seeing a condition in the middle of an expression feels surprising and unexpected.
Re: Why your first Rust FizzBuzz implementation may not work
#19The feature list in rust really does have my eye. The biggest one in particular was type inference . The reason type inference was such a big one was because if you use it right, annoying situations like "Two types of strings? What is this?" go the hell away. You have three types, static built in and binary strings, and a third that only makes the gaurentee that the datatype can do all the things a string aught to be…
The type inference does mean that you can care less about what specific type you’re working with, and that it is rare that you will need to write types out (except in signatures—the type inference is deliberately only local), but the distinctions are certainly still there, and due to the nature of the language must be.
Really, this is showing one of the more tricky parts of Rust, potentially to balance the claims of excessive bullishness for Rust that I have heard levelled at me! Don’t let it dim your enthusiasm too far; Rust is still very much worth while trying out in practice.
Re: Why your first Rust FizzBuzz implementation may not work
#20Putting 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),
}
}