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

131–139 of 139 posts

Re: Why your first Rust FizzBuzz implementation may not work

#131

Post by thinkpad20 »

kibwen wrote: post #108
steveklabnik wrote: post #82

Earlier quoted context omitted.

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...

It wasn't strictly HM, as it had extensions for the subtyping that lifetimes require. It was based on HM, however. The new bespoke scheme gives approximately the same results as HM but is drastically simpler. For all I know this could inhibit Rust's future ability to do even more powerful things with types, but AIUI this scheme has the advantage of being actually decidable given the extensions to HM that we would req…

Strictly speaking, I think almost no extant languages, and certainly no mainstream ones, use pure HM, but many take it as a starting point. Certainly, HM has no notion of ML modules, or type classes, or record types, or lifetimes. Nevertheless many languages using those things use HM as a starting point.

I'm curious (and a bit skeptical) of your claim that the scheme is "drastically simpler" than HM. HM is a beautifully simple design, which can be expressed (abstractly) in just a couple of lines.

Re: Why your first Rust FizzBuzz implementation may not work

#132

Post by kibwen »

thinkpad20 wrote: post #131
kibwen wrote: post #108

Earlier quoted context omitted.

It wasn't strictly HM, as it had extensions for the subtyping that lifetimes require. It was based on HM, however. The new bespoke scheme gives approximately the same results as HM but is drastically simpler. For all I know this could inhibit Rust's future ability to do even more powerful things with types, but AIUI this scheme has the advantage of being actually decidable given the extensions to HM that we would req…

Strictly speaking, I think almost no extant languages, and certainly no mainstream ones, use pure HM, but many take it as a starting point. Certainly, HM has no notion of ML modules, or type classes, or record types, or lifetimes. Nevertheless many languages using those things use HM as a starting point. I'm curious (and a bit skeptical) of your claim that the scheme is "drastically simpler" than HM. HM is a beautifu…

I'm paraphrasing Niko Matsakis, Rust's type guru.

http://smallcultfollowing.com/babysteps/blog/2014/07/09/an-e...

"This scheme simplifies the code of the type inferencer dramatically and (I think) helps to meet our intutions (as I will explain). It is however somewhat less flexible than the existing inference scheme, though all of rustc and all the libraries compile without any changes."

Re: Why your first Rust FizzBuzz implementation may not work

#133

Post by heinrich5991 »

kibwen wrote: post #117
dbaupp wrote: post #110

Earlier quoted context omitted.

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? :)

Slicing syntax is about being able to do stuff like string[1:3] AFAIK, so I hope it won't get killed.

Re: Why your first Rust FizzBuzz implementation may not work

#134

Post by frankzinger »

Tyr42 wrote: post #120
frankzinger wrote: post #98

Earlier quoted context omitted.

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 ...`.

...need to learn how to use cmake and other systems to build and use libraries.

On OSes for which this is true you'd be forced to compile python yourself as well, because it's also just a dependency (of pip, for one!) written in a compiled language.

Edit: My point is: usually it's as easy as 'yum install', but on the rare occasion you will need to compile, I admit. However, that could happen with pip too; don't tell me its repos are always completely up to date. And in those cases it won't be quite as simple as 'pip install'.

Re: Why your first Rust FizzBuzz implementation may not work

#135

Post by mercurial »

steveklabnik wrote: post #70
mercurial wrote: post #64

Earlier quoted context omitted.

Doesn't type inference stop at function boundaries, though? I'll grant you that idiomatic Haskell uses type annotations for function signatures (unlike idiomatic OCaml), but it is optional (which is convenient in a REPL).

Yes, it does, but that's a deliberate design decision, not a flaw. We decided enforcing this idiom was a good idea.

I think it was related to the quality of error messages as well.

Re: Why your first Rust FizzBuzz implementation may not work

#136

Post by bluecalm »

Wilduck wrote: post #115
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)

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): l…

I see it as over thinking simple stuff. Maybe I think about performance too much but constructing a dictionary and then defining functions to do simple signature thing is imo just over designing things. Too much abstraction for expressing a simple concept. Performance aside, you need to go find the dictionary once you see code like that while with chain of if-else statements it's right there in front of your eyes.

As to 0 and 1 thing... Python has C'ish boolean (basically an integer type). Using True and False as numbers is completely standard as PEP 285 indicates. I tend to agree that maybe here using True/False is a bit more natural but it really is type-purity nitpick in my view.

Could you point out which part of PEP8 the code in my original post violates? While I don't really like a lot of currently popular style I see a lot of values in following the PEP's and long established conventions.

Re: Why your first Rust FizzBuzz implementation may not work

#137

Post by [deleted] »

tel wrote: post #124
Wilduck wrote: post #115

Earlier quoted context omitted.

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): l…

That's not genuinely pattern matching, however. It only works for patterns without member binding.

[deleted]

Re: Why your first Rust FizzBuzz implementation may not work

#138

Post by shurcooL »

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.

I was referring to "development using C++", which encompasses the language, compilers, build tools, code editors, ecosystem, basically everything that is involved when you're doing work and distributing result binaries.

There are IDEs that have their proprietary project formats that are incompatible.

Having header files makes refactoring by hand much more difficult than necessary, yet refactoring tools for C++ are mostly not possible.

Finally, https://gist.github.com/shurcooL/86949a392dcdac1f94cf.

Re: Why your first Rust FizzBuzz implementation may not work

#139

Post by steveklabnik »

mercurial wrote: post #135
steveklabnik wrote: post #70

Earlier quoted context omitted.

Yes, it does, but that's a deliberate design decision, not a flaw. We decided enforcing this idiom was a good idea.

I think it was related to the quality of error messages as well.

Right. When you infer signatures, a change in one place can cause an error somewhere else, and so the error message is very misleading.
Post reply on HN