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

Optimizing Ruby Path Methods

byroot.github.io

Post reply on HN
Print view View original

51–60 of 66 posts

Re: Optimizing Ruby Path Methods

#51

Post by pmontra »

DeathArrow wrote: post #36

What happened to Ruby? It was very successful at some point. Maybe kids started using JS exclusively. But what happened to older developers? Did they move over? Rails seemed to enable very fast prototyping and iteration. Isn't it still the case? I see PHP usage going down, but PHP doesn't seem to have any advantages over JS, .NET, Python or Go. While Ruby coupled with Rails promised easy and rapid development. Of cou…

> But what happened to older developers? Did they move over?

I'm working on a project with a Rails backend and a Vue frontend.

I've been working on a JS backend and frontend project in the early 2010s but I think that it was the only project with a JS backend. There are plenty of projects with server generated HTML. In my case the backends were Ruby, Python, Elixir, Java, PHP.

Re: Optimizing Ruby Path Methods

#53

Post by krowek »

wanderlust123 wrote: post #37
matltc wrote: post #34

Makes me miss Ruby. Been in node typescript recently. Everything is a callback returning a promise in some weird resolution chain, mapped and conditional types, having to define schemas for everything and getting yelled at by lsp all day... Oh then you gotta write react components and worry about rerenders and undefined behavior caused by impurity in state, npm, arcane .json configs Versus active record, mvc, yaml co…

Lack of static types is one of the main reasons. Trying to decipher a complex ruby on rails codebase is unnecessarily difficult compared typescript. The tooling is also shit unless you use Ruby Mine. An absolute shame given how good the functionality is baked into RoR.

I think the only thing you need is grep and know what you are doing.

Re: Optimizing Ruby Path Methods

#54

Post by teaearlgraycold »

chalmovsky wrote: post #39
teaearlgraycold wrote: post #38

Earlier quoted context omitted.

> getting yelled at by lsp all day God forbid you get forced to fix bugs before they reach production.

This might shock you but vast majority of bugs are logical.

Sure but I like it when I don’t have bugs that can be detected by static analysis.

Re: Optimizing Ruby Path Methods

#56

Post by weaksauce »

saghm wrote: post #49
t-writescode wrote: post #41

Earlier quoted context omitted.

Sorry, I mis-spoke earlier, this is what I should have shared: [].slice(5, 100) ^-- *THIS* either returns nil or throws an exception. Edit: Longer example: puts "[1, 2, 3].slice(1, 100) -> #{[1, 2, 3].slice(1, 100).to_s}" puts "[1, 2, 3].slice(3, 100) -> #{[1, 2, 3].slice(3, 100).to_s}" puts "[1, 2, 3].slice(4, 100) -> #{[1, 2, 3].slice(4, 100).to_s}" Yields: [1, 2, 3].slice(1, 100) -> [2, 3] [1, 2, 3].slice(3, 100)…

Interesting! From playing around with it, seems like if the start index is exactly the same as the length, it returns empty array, but if it's further than that it returns nil. That's certainly not something I would have been able to predict, so I'd also be curious if anyone happens to know the explanation for it. My instinct is that it does seem like the type of edge case that might come up with a way to implement i…

the docs say... if index is out of range return nil. the edge case is that if you specify the exact end index of the array and want a slice of that index to 100 it will return an empty array. if you go out of bounds it informs you that you are out of bounds with nil. not sure it's the best api but probably is mimicking some C api somewhere as a lot of ruby does that. that said it will never error on this alone but it will almost certainly error if you chain it with something not expecting nil.

The easiest way to get around that if you are not carefully using the ranges would be to do `Array(array.slice(a, b))` as that will guarantee an array even if it's invalid. you could override slice if you really wanted to but that would be a performance penalty if you are doing it often.

Re: Optimizing Ruby Path Methods

#57

Post by weaksauce »

t-writescode wrote: post #41
saghm wrote: post #25

Earlier quoted context omitted.

Yeah, returning an empty array is pretty much exactly what I would expect given the first example. It would be a lot weirder to me if you were allowed to give an end index past the last element only if the array happened to be non-empty.

Sorry, I mis-spoke earlier, this is what I should have shared: [].slice(5, 100) ^-- *THIS* either returns nil or throws an exception. Edit: Longer example: puts "[1, 2, 3].slice(1, 100) -> #{[1, 2, 3].slice(1, 100).to_s}" puts "[1, 2, 3].slice(3, 100) -> #{[1, 2, 3].slice(3, 100).to_s}" puts "[1, 2, 3].slice(4, 100) -> #{[1, 2, 3].slice(4, 100).to_s}" Yields: [1, 2, 3].slice(1, 100) -> [2, 3] [1, 2, 3].slice(3, 100)…

looked into it more and the docs say that an index out of bounds will return nil. also says if offset == size and length >= 0 it will return an empty array.

``` If offset == self.size and size >= 0, returns a new empty array.

If size is negative, returns nil. ```

either way if you are doing stuff with arrays and not checking bounds you can throw an `Array(some_array.slice(x, x+100))` and it will always behave.

Re: Optimizing Ruby Path Methods

#58

Post by t-writescode »

weaksauce wrote: post #56
saghm wrote: post #49

Earlier quoted context omitted.

Interesting! From playing around with it, seems like if the start index is exactly the same as the length, it returns empty array, but if it's further than that it returns nil. That's certainly not something I would have been able to predict, so I'd also be curious if anyone happens to know the explanation for it. My instinct is that it does seem like the type of edge case that might come up with a way to implement i…

the docs say... if index is out of range return nil. the edge case is that if you specify the exact end index of the array and want a slice of that index to 100 it will return an empty array. if you go out of bounds it informs you that you are out of bounds with nil. not sure it's the best api but probably is mimicking some C api somewhere as a lot of ruby does that. that said it will never error on this alone but it…

Indeed. I had heard that it was a carryover from C; but for an "implicit is better than explicit" and "magic ducktyping, it just works, I promise" language, like Ruby, this feels like a direct contradiction to its intended behavior and this specific example has always stood out to me in a "... but why?" sort of way.

Re: Optimizing Ruby Path Methods

#59

Post by saghm »

weaksauce wrote: post #57
t-writescode wrote: post #41

Earlier quoted context omitted.

Sorry, I mis-spoke earlier, this is what I should have shared: [].slice(5, 100) ^-- *THIS* either returns nil or throws an exception. Edit: Longer example: puts "[1, 2, 3].slice(1, 100) -> #{[1, 2, 3].slice(1, 100).to_s}" puts "[1, 2, 3].slice(3, 100) -> #{[1, 2, 3].slice(3, 100).to_s}" puts "[1, 2, 3].slice(4, 100) -> #{[1, 2, 3].slice(4, 100).to_s}" Yields: [1, 2, 3].slice(1, 100) -> [2, 3] [1, 2, 3].slice(3, 100)…

looked into it more and the docs say that an index out of bounds will return nil. also says if offset == size and length >= 0 it will return an empty array. ``` If offset == self.size and size >= 0, returns a new empty array. If size is negative, returns nil. ``` either way if you are doing stuff with arrays and not checking bounds you can throw an `Array(some_array.slice(x, x+100))` and it will always behave.

Sure, the docs seem to be accurate, but that only explains "what will this do?", not "why is this what it will do?" It's not what I expect most people would come up with if they designed this API, so I have to wonder why they didn't pick something more intuitive

Re: Optimizing Ruby Path Methods

#60

Post by saghm »

t-writescode wrote: post #58
weaksauce wrote: post #56

Earlier quoted context omitted.

the docs say... if index is out of range return nil. the edge case is that if you specify the exact end index of the array and want a slice of that index to 100 it will return an empty array. if you go out of bounds it informs you that you are out of bounds with nil. not sure it's the best api but probably is mimicking some C api somewhere as a lot of ruby does that. that said it will never error on this alone but it…

Indeed. I had heard that it was a carryover from C; but for an "implicit is better than explicit" and "magic ducktyping, it just works, I promise" language, like Ruby, this feels like a direct contradiction to its intended behavior and this specific example has always stood out to me in a "... but why?" sort of way.

Yeah, I'd argue that it would be less confusing to return the same thing even if it's inconsistent with some C API that plenty of Ruby programmers might never have encountered. I'm honestly not sure I even understand what the C API is that's being referred to; slices and bounds checks aren't things I typically associate with being built into C.
Post reply on HN