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

Where is Ruby Headed in 2021?

bignerdranch.com

Post reply on HN
Print view View original

121–130 of 360 posts

Re: Where is Ruby Headed in 2021?

#121

Post by saagarjha »

inopinatus wrote: post #119
saagarjha wrote: post #118

Earlier quoted context omitted.

I don’t see how this helps?

Ruby's dispatch is Smalltalk-like, not Java-like; it is (very) late-bound. The consequences for interface design are dramatic, the natural style being one in which objects notify each other, rather than telling each other what to do, and the result is loose coupling and ease of composition. People trying to write Java-like OO in Ruby end up confused and frustrated.

Ok, but Objective-C also does messages and most of them are defined statically and can be easily searched for in a codebase. I’m not saying Ruby needs header files to send messages to something, but being able to figure out where the code for something is isn’t off the table for languages with dynamic dispatch and it can come in handy.

Re: Where is Ruby Headed in 2021?

#122

Post by inopinatus »

saagarjha wrote: post #121
inopinatus wrote: post #119

Earlier quoted context omitted.

Ruby's dispatch is Smalltalk-like, not Java-like; it is (very) late-bound. The consequences for interface design are dramatic, the natural style being one in which objects notify each other, rather than telling each other what to do, and the result is loose coupling and ease of composition. People trying to write Java-like OO in Ruby end up confused and frustrated.

Ok, but Objective-C also does messages and most of them are defined statically and can be easily searched for in a codebase. I’m not saying Ruby needs header files to send messages to something, but being able to figure out where the code for something is isn’t off the table for languages with dynamic dispatch and it can come in handy.

For that, there's

    object.method(:name).source
    object.method(:name).source_location
but frankly this is still thinking in a rigid mindset that suits other languages better. Ruby isn't just "dynamic dispatch"; a typical metaprogramming technique handles all incoming calls without named methods, or by dynamically writing the code.

To put it bluntly, assuming there's a method on the other side of your message, is practically the antithesis of Ruby.

It's similar to the category error that leads folks to conflating type with class, and writing type checkers that look for class signatures.

Re: Where is Ruby Headed in 2021?

#123

Post by stjohnswarts »

hsn915 wrote: post #72
Mikeb85 wrote: post #8

Honestly I don't get why some people want to move to static types. Ruby is a dynamic language, that's the point of it... Giant orgs can just use Java or something. We need some languages to stay productive for those of us who work solo or in small groups. If I wanted static types I'd use Java, Go or something (probably Haskell).

I started using dynamic languages since around 2008 (Python and Javascript). Before that I was more into C/C++. Granted, I've only written C in University settings where I'm writing small programs. I had no idea how to write "real" programs. But with Python and Javascript it felt like I could more easily write "real" programs. What I found out is that I quickly burned out. Around 2011 I felt like I don't know how to…

:) I love typed languages and my current favorite is Rust. I got my most recent position because when asked what I if I preferred procedural style programming or OOP. I told them I tend to lean heavy on simple single inheritance schemes rather than complicated hard to trace architectures and over-engineered design patterns, the occasional interface class for OOP that makes sense, and mostly procedural concentrating on bending to the data rather than bending the data to your needs. It was the only thing that separated me from the other c++ candidates as we all had similar levels of experience and coding skill.

Re: Where is Ruby Headed in 2021?

#124

Post by Raphael »

sanderjd wrote: post #110
Buttons840 wrote: post #74

Earlier quoted context omitted.

> I’ve tried python, but I end up having to deal with the mess of importing modules Without those imports, how will people reading the code find the definitions? How will they track down the source code for all the methods being called? If the answer is "with an IDE / tools", then can't those same tools be used to solve the "mess of importing modules"? If you're using a good IDE, imports and go-to-definition are both…

The often impossibility of finding the definition of the methods I'm calling is the main thing that soured me on Rails. I think a more explicit style is more common nowadays, which is a good thing.

Would a Ruby IDE be able to figure it out?

Re: Where is Ruby Headed in 2021?

#125

Post by fn1 »

kayodelycaon wrote: post #4

This is really cool. I’ve used a number of languages and dabbled in a few frameworks but nothing I’ve used brings me joy like ruby does. I approach programming creatively. I think in large systems and architecture. Ruby allows me to skip worrying about the details. Code blocks abstract away thinking about loops and just focus on data. Just about every array operation I could want is there, waiting for a code block. I…

> Just about every array operation I could want is there, waiting for a code block. In other languages, things don’t flow like that.

This is a question about standard-library. The standard-library of kotlin is equally amazing (but Kotlin more or less requires the IntelliJ eco-system of course).

Re: Where is Ruby Headed in 2021?

#126

Post by eximius »

inopinatus wrote: post #122
saagarjha wrote: post #121

Earlier quoted context omitted.

Ok, but Objective-C also does messages and most of them are defined statically and can be easily searched for in a codebase. I’m not saying Ruby needs header files to send messages to something, but being able to figure out where the code for something is isn’t off the table for languages with dynamic dispatch and it can come in handy.

For that, there's object.method(:name).source object.method(:name).source_location but frankly this is still thinking in a rigid mindset that suits other languages better. Ruby isn't just "dynamic dispatch"; a typical metaprogramming technique handles all incoming calls without named methods, or by dynamically writing the code. To put it bluntly, assuming there's a method on the other side of your message, is practic…

While freeing to write, that is horrifying to inherit.

Re: Where is Ruby Headed in 2021?

#127

Post by clairity »

scrose wrote: post #87
kayodelycaon wrote: post #4

This is really cool. I’ve used a number of languages and dabbled in a few frameworks but nothing I’ve used brings me joy like ruby does. I approach programming creatively. I think in large systems and architecture. Ruby allows me to skip worrying about the details. Code blocks abstract away thinking about loops and just focus on data. Just about every array operation I could want is there, waiting for a code block. I…

> I’m sad about the move to mounds of JavaScript. Nothing can match the productivity of simple_form and bootstrap. You might like some of the recent Rails 7 previews. I believe they’re removing Webpack out of the box and trying to simplify things on that end[0]. [0] https://weblog.rubyonrails.org/2021/9/15/Rails-7-0-alpha-1-r...

to me, this is what makes the upcoming rails 7 release really exciting: no more node, npm, webpack, & yarn! all that js tooling complexity thrown right out the window, replaced with the much simpler set of es6 modules, turbo & stimulus (and maybe strada too).

Re: Where is Ruby Headed in 2021?

#128

Post by friedman23 »

Mikeb85 wrote: post #92
friedman23 wrote: post #41

Earlier quoted context omitted.

> Honestly I don't get why some people want to move to static types I don't understand how anyone that has experience with dynamically typed languages and the insane runtime errors that can result from them would ever consider using a dynamically typed language. It's terrible and it actually provides little to no benefit in development speed. People always say development is faster in a dynamically typed language, th…

> People always say development is faster in a dynamically typed language, this is not my experience. You need to actually run the program and step into it with a debugger in order to determine the type of anything at run time. You just develop on the running program... If you just write it in your editor, run, check for errors, stop, edit more, run, stop, etc... then yes, you don't gain anything.

> You just develop on the running program...

Ah yes, don't worry about correctness at all, just wing it. I take it you haven't had to debug some of the stuff you've written?

Re: Where is Ruby Headed in 2021?

#129

Post by jb3689 »

kayodelycaon wrote: post #4

This is really cool. I’ve used a number of languages and dabbled in a few frameworks but nothing I’ve used brings me joy like ruby does. I approach programming creatively. I think in large systems and architecture. Ruby allows me to skip worrying about the details. Code blocks abstract away thinking about loops and just focus on data. Just about every array operation I could want is there, waiting for a code block. I…

> Then there is Rails. Nothing even comes close

Have you tried Phoenix? It's really close. It's better in some ways. The data layer is quite different however. As much as I like Ruby, Elixir made a lot of things I liked about Ruby better

Re: Where is Ruby Headed in 2021?

#130

Post by t-writescode »

Raphael wrote: post #124
sanderjd wrote: post #110

Earlier quoted context omitted.

The often impossibility of finding the definition of the methods I'm calling is the main thing that soured me on Rails. I think a more explicit style is more common nowadays, which is a good thing.

Would a Ruby IDE be able to figure it out?

In my experience on a IntelliJ with Ruby extensions (so working like RubyMine), no.

Input and output parameters on a program with hundreds of thousands of lines becomes .. rough, to say the least. DryStruct has helped a lot; but several teams working on a single codebase with their own opinions of method calling patterns evolved over several generations all in a single codebase, and it’s … rough.

Post reply on HN