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

Ruby methods are colorless

jpcamara.com

Post reply on HN
Print view View original

151–160 of 242 posts

Re: Ruby methods are colorless

#151

Post by grumple »

vlucas wrote: post #81

Long-time JS/TS/Node programmer here. Knowing ahead of time which functions are async is a feature . It's a big neon sign that says "hey, this function call is expensive ". This is a good thing for programmers to easily see and know at the call site. If you make multiple calls with async/await in a row, the performance issues are plainly obvious at the call site. With "colorless" functions, this information is hidden…

I hate that async functions are the ones we are forcing to wait and become synchronous. The naming was a failure imo.

Re: Ruby methods are colorless

#152

Post by sapiogram »

hombre_fatal wrote: post #33
explaininjs wrote: post #27

Earlier quoted context omitted.

Coming from a heavy TS background into a go-forward company, I’d say the main thing you get with async is it makes it incredibly obvious when computation can be performed non-sequentially (async…). For example, It’s very common to see the below in go code: a := &blah{} rA, err := engine.doSomethingWithA() b := &bloop{} rB, err := engine.doSomethingWithB() This might have started out with both the doSomethings being v…

Of course, the other nice thing about the JS example compared to Go is that it's trivial at the callsite to do this: const [[rA, errA], [rB, errB]] = await Promise.all([ engine.doSomethingWithA(), engine.doSomethingWithB() ]) At least these days you can ask an LLM to write the WaitGroup boilerplate for you in Go.

WaitGroup/ErrGroup doesn't even work here, because the functions return data. I mean, you can use ErrGroup, but it requires additional error-prone concurrency orchestration to work.

Re: Ruby methods are colorless

#154

Post by sapiogram »

kmeisthax wrote: post #55
thechao wrote: post #15

I've implemented coroutines in C and C++; my preferred multitasking environment is message-passing between processes. I'm not quite sure what the async/await stuff is buying us (I'm thinking C++, here). Like, I get multi-shot stackless coroutines, i.e., function objects, but I don't get why you'd want to orchestrate some sort of temporal Turing pit of async functions bleeding across your code base. I dunno. Maybe I'm…

JavaScript has async/await because it solves a very specifically JavaScript problem: the language has no threads and all your code lives in the main event loop of the browser tab. If you do the normal thing of pausing your JavaScript until an I/O operation returns, the browser hangs. So you need to write everything with callbacks (continuation passing style), which is a pain in the ass and breaks exception handling.…

> For example, Go uses (or at least one point it did) its own thread management and variable-size stacks.

Go developer here: Yup, the language still works like that, and probably always will.

Re: Ruby methods are colorless

#155

Post by Joker_vD »

lta wrote: post #98
vlucas wrote: post #81

Long-time JS/TS/Node programmer here. Knowing ahead of time which functions are async is a feature . It's a big neon sign that says "hey, this function call is expensive ". This is a good thing for programmers to easily see and know at the call site. If you make multiple calls with async/await in a row, the performance issues are plainly obvious at the call site. With "colorless" functions, this information is hidden…

> is a feature I was quite shocked to read this, as in it never brushed my mind that it could be. I personally doesn't feel like it is and is one of the reasons why I try to avoid working with that stack at all cost. I don't think the neon sign is a good excuse for the mess colored functions are. You easily can create a synchronous O(n^4) function, and there are probably tons of quick async functions. Moreover, your…

> The information is only hidden with colorless methods if you consider the documentation to be a place to hide information (o^o)

That's exactly the mindset of quite a number of programmers nowadays, sadly. Two anecdotes: First, there was a blog post (probably even featured on HN) about problems in the design of the API of... Python's requests library, I think? It was quite a bizarre reading, complaints made almost no sense to me until I got to about the middle of the article when it clicked: the author was trying to figure out how to use the API by just reading the names of the classes, methods, and parameter names and making guesses as how it all would connect together instead of, you know, reading the docs. Which do exist, by the way.

The second example happened just yesterday at my job. In the essence, some fellow programmer added a call to function foo() which he thought would do some particular thing and return a particular answer while in reality it did not quite do that, and the return value is essentially meaningless (the function basically always returns "yep, I've scheduled do_foo() to run asynchronously some time soon"). Now, this foo() dunction is not documented, and if you read it's source (3 lines of code), it's quite obvious that its return value is useless... so why did they think it works the way they wanted it to work? When asked about it, the answer was "Well, it's named foo(), so I just thought that's what it would do". Sadly, calling strange third-party functions and hoping them to work they way you'd like them to work is no basis for writing the working programs.

Re: Ruby methods are colorless

#156

Post by downsplat »

Translated into simple language, Ruby chose to expose the multithreading paradigm (multple threads over shared data), like Java and others.

Multithreading is strictly more powerful than single threaded event loops. For some kinds of software there is just no alternative - a modern browser engine for example needs to be multithreaded.

The trade off is that you need to make sure your code is thread safe, which is not trivial as the collection of articles explains. That's your function color right there, green functions are verified thread safe, gray functions are not or not sure.

Personally in nearly 30 years of programming I've never needed to write multithreaded code. I still haven't found a business need that could not be met with suitable choices between multiprocessing (i.e fork) and event loops.

I'll definitely take wait/async programming over having to worry about concurrent thread safety any day of the week.

Re: Ruby methods are colorless

#157

Post by _ea1k »

Joker_vD wrote: post #155
lta wrote: post #98

Earlier quoted context omitted.

> is a feature I was quite shocked to read this, as in it never brushed my mind that it could be. I personally doesn't feel like it is and is one of the reasons why I try to avoid working with that stack at all cost. I don't think the neon sign is a good excuse for the mess colored functions are. You easily can create a synchronous O(n^4) function, and there are probably tons of quick async functions. Moreover, your…

> The information is only hidden with colorless methods if you consider the documentation to be a place to hide information (o^o) That's exactly the mindset of quite a number of programmers nowadays, sadly. Two anecdotes: First, there was a blog post (probably even featured on HN) about problems in the design of the API of... Python's requests library, I think? It was quite a bizarre reading, complaints made almost n…

And of course, these developers will also complain that the project lacks documentation. Often this is the case for projects that are actually well documented, its just that the dev didn't read it.

Re: Ruby methods are colorless

#158

Post by CuriousSkeptic »

stephen wrote: post #53

Maybe its Stockholm syndrome after ~4-5 years of TypeScript, but I like knowing "this method call is going to do I/O somewhere" (that its red). To the point where I consider "colorless functions" to be a leaky abstraction; i.e. I do a lot of ORM stuff, and "I'll just call author.getBooks().get(0) b/c that is a cheap, in-memory, synchronous collection access ... oh wait its actually a colorless SQL call that blocks (s…

I seem to recall a similar argument being made a while ago: https://scholar.harvard.edu/files/waldo/files/waldo-94.pdf

Re: Ruby methods are colorless

#159

Post by zanellato19 »

munificent wrote: post #82
dang wrote: post #65

Related: What color is your function? (2015) - https://news.ycombinator.com/item?id=28657358 - Sept 2021 (58 comments) What Color Is Your Function? (2015) - https://news.ycombinator.com/item?id=23218782 - May 2020 (85 comments) What Color is Your Function? (2015) - https://news.ycombinator.com/item?id=16732948 - April 2018 (45 comments) What Color Is Your Function? - https://news.ycombinator.com/item?id=8984648 - Feb…

It fills me with delight that apparently my lasting contribution to computer science is a piece of writing that also contains the phase "Spidermouth the Night Clown".

Do you still maintain more or less the same opinion from the post?

Re: Ruby methods are colorless

#160

Post by resonious »

_ea1k wrote: post #157
Joker_vD wrote: post #155

Earlier quoted context omitted.

> The information is only hidden with colorless methods if you consider the documentation to be a place to hide information (o^o) That's exactly the mindset of quite a number of programmers nowadays, sadly. Two anecdotes: First, there was a blog post (probably even featured on HN) about problems in the design of the API of... Python's requests library, I think? It was quite a bizarre reading, complaints made almost n…

And of course, these developers will also complain that the project lacks documentation. Often this is the case for projects that are actually well documented, its just that the dev didn't read it.

Was also going to say this. I've seen so many people fumble around figuring something else, then write a doc for how to do it, just to find that someone else wrote effectively the exact same doc 5 months ago.
Post reply on HN