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

Ruby 2.7

ruby-lang.org

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Ruby 2.7

#61

Post by Twirrim »

meowface wrote: post #60
mattmarcus wrote: post #58

I'm most excited for Enumerable#tally for counting occurrences of elements. From the example in the release: ["a", "b", "c", "b"].tally #=> {"a"=>1, "b"=>2, "c"=>1} There's more about this change here ( https://medium.com/@baweaver/ruby-2-7-enumerable-tally-a706a... ). I probably do this a few times a week: list.each_with_object(Hash.new(0)) { |v, h| h[v.something] += 1 }

For Python developers: this exists as collections.Counter.

I stumbled across collections.Counter during last year's Advent of Code, and promptly kicked myself for the number of times I'd implmeented that by hand.

Re: Ruby 2.7

#62

Post by Lio »

atmosx wrote: post #59
cheald wrote: post #57

Earlier quoted context omitted.

You've been able to use `send` to pierce the protected/private restriction forever, so this doesn't particularly change the nature of Ruby's method visibility rules. Now you can just use `self.foo` and it's the same as `self.send :foo`. class Foo def test priv # works self.send(:priv) # works self.priv # doesn't work under ruby 2.6- Foo.new.priv # doesn't work end private def priv puts "ran private" end end You shoul…

> You've been able to use `send` to pierce the protected/private restriction forever, so this doesn't particularly change the nature of Ruby's method visibility rules. I wasn't aware, thanks for pointing that out.

Previously this was a good reason for preferring public_send over send where possible.

Re: Ruby 2.7

#63

Post by jolux »

coldtea wrote: post #55
jolux wrote: post #49

Earlier quoted context omitted.

Yeah I suppose my bigger beef is I just don't like dynamic languages. Perhaps it is in fact a good idea for them, but being someone primarily interested in types, it largely falls into the realm of "don't care."

Huh? Both Maybe / Optional and pattern matching is used in Haskell, Scala, and other typed languages... It's not about dynamic languages...

If you’ll notice my other comments in this thread, I think you’ll see I vastly prefer statically typed functional languages over dynamic ones. I was more commenting that I like monads and functors and Maybe and Either/Result but don't like dynamic languages.

Re: Ruby 2.7

#64

Post by gdxhyrd »

jhayward wrote: post #52
gdxhyrd wrote: post #43

Earlier quoted context omitted.

3) Use C++17 with minimal features. This gives you a lot of needed libraries built-in and it is better supported than C99 (due to Windows).

> Use C++17 with minimal features To paraphrase JWZ, "now you have N+M problems"

C++17 is a very close language to C18 if you avoid exceptions, classes and templates.

Re: Ruby 2.7

#65

Post by faitswulff »

mattmarcus wrote: post #58

I'm most excited for Enumerable#tally for counting occurrences of elements. From the example in the release: ["a", "b", "c", "b"].tally #=> {"a"=>1, "b"=>2, "c"=>1} There's more about this change here ( https://medium.com/@baweaver/ruby-2-7-enumerable-tally-a706a... ). I probably do this a few times a week: list.each_with_object(Hash.new(0)) { |v, h| h[v.something] += 1 }

I was a fan of

    list.group_by(&:itself).transform_values(&:count)
...but I'll be very happy to replace that with #tally!

Re: Ruby 2.7

#66

Post by ljm »

obstacle1 wrote: post #18
ljm wrote: post #10

Earlier quoted context omitted.

Maybe I’ve just been bitten by the functional bug but I find they can communicate intent much better than scattering around null checks or catching exceptions (many of which require reading the source to understand what exceptions you might get). It’s great in large scale projects, which I think is where a dynamic language starts to show its warts.

An alternative to scattering null checks around or using exceptions for control flow could be more thoughtfully designing your data/object model. No additional language constructs required!

What if using those functional concepts is my attempt at thoughtful design? You're making a hell of an assumption with that one.

Re: Ruby 2.7

#67

Post by ksec »

cesarb wrote: post #45
ufo wrote: post #26

One of the interesting news is that they are now going to start requiring a C99 compiler, instead of only C90. I've been considering to do the same on my own projects. What does HN have to say about this? Is anyone here still working in a context where C99 is not an option? Did anyone else also recently switch to C99? How did it go?

It's now 2019, and as far as I know, MSVC still doesn't have full support for the 20-year-old C99 standard. So either you restrict yourself to the subset of C99 which MSVC understands (AFAIK, newer MSVC releases understand more and more of the C99 standard), or just decide MSVC is no longer relevant (which is easier now that clang-cl exists; some big projects like Firefox and Chrome went this way, see for instance ht…

I sometimes wonder if someday Microsoft would actively contribute to LLVM.

Re: Ruby 2.7

#68

Post by [deleted] »

codr7 wrote: post #35
brudgers wrote: post #30

Earlier quoted context omitted.

Why? Not being facetious. Wondering about the weights of benefits versus costs for users.

Mostly portable implementations of extensions for me; __thread, bool, inttypes.h, variadic macros, flexible array members etc. But declaring variables closer to the point of use is nice, as is struct initializers, compound literals and single line comments. Compared to the rest, C99 contains a lot of useful improvements.

[deleted]
Post reply on HN