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

FP-Go: Functional programming library for Golang

github.com

Post reply on HN
Print view View original

151–160 of 185 posts

Re: FP-Go: Functional programming library for Golang

#151

Post by awused »

randomdata wrote: post #150
awused wrote: post #148

Earlier quoted context omitted.

I recommend you read your own posts sometimes. Your claim of "in Go values must always be useful" was rebutted multiple times. That you're trying to move the goalposts to something neither of us was arguing speaks loudly. You also dance dishonestly around the actual point I made in that last post. Again, I'd recommend following your advice about reading a thread before responding to it.

> Your claim of "in Go values must always be useful" I said no such thing. I said idiomatic Go indicates that you must always make values useful. This is an onus placed on the programmer, not something guaranteed by the language. However, since the Either monad here was said to be introduced to wrap idiomatic Go code, not whatever haphazardly written Go code you happened to find in a SourceForge repository, that is o…

>whatever haphazardly written Go code you happened to find

Well, if the Go stdlib is haphazardly written and unidiomatic then I think the burden is on you to demonstrate that idiomatic Go, as per your definition, exists.

>more baseless ad-hominem and ignoring the points

I'll boil it down to one sentence: Go forces programmers to use (T, error) when it is not appropriate, and Go would be better if it did not.

Re: FP-Go: Functional programming library for Golang

#152

Post by randomdata »

awused wrote: post #151
randomdata wrote: post #150

Earlier quoted context omitted.

> Your claim of "in Go values must always be useful" I said no such thing. I said idiomatic Go indicates that you must always make values useful. This is an onus placed on the programmer, not something guaranteed by the language. However, since the Either monad here was said to be introduced to wrap idiomatic Go code, not whatever haphazardly written Go code you happened to find in a SourceForge repository, that is o…

> whatever haphazardly written Go code you happened to find Well, if the Go stdlib is haphazardly written and unidiomatic then I think the burden is on you to demonstrate that idiomatic Go, as per your definition, exists. > more baseless ad-hominem and ignoring the points I'll boil it down to one sentence: Go forces programmers to use (T, error) when it is not appropriate, and Go would be better if it did not.

> Well, if the Go stdlib is haphazardly written and unidiomatic

Yeah, the older parts of the standard library are definitely not idiomatic. Lots of functions in the stdlib which return errors don't even return an error type. But, of course they aren't idiomatic. Idiomatacy is emergent. They couldn't possibly have been written idiomatically.

> I'll boil it down to one sentence: Go forces programmers to use (T, error) when it is not appropriate, and Go would be better if it did not.

That may be true, but of no relevance. I can see why I didn't bother reading it. Thanks for clarifying that it would have been a waste of my time.

Re: FP-Go: Functional programming library for Golang

#153

Post by awused »

randomdata wrote: post #152
awused wrote: post #151

Earlier quoted context omitted.

> whatever haphazardly written Go code you happened to find Well, if the Go stdlib is haphazardly written and unidiomatic then I think the burden is on you to demonstrate that idiomatic Go, as per your definition, exists. > more baseless ad-hominem and ignoring the points I'll boil it down to one sentence: Go forces programmers to use (T, error) when it is not appropriate, and Go would be better if it did not.

> Well, if the Go stdlib is haphazardly written and unidiomatic Yeah, the older parts of the standard library are definitely not idiomatic. Lots of functions in the stdlib which return errors don't even return an error type. But, of course they aren't idiomatic. Idiomatacy is emergent. They couldn't possibly have been written idiomatically. > I'll boil it down to one sentence: Go forces programmers to use (T, error)…

So you've defined idiomatic Go code in your own way, that no one else's definitions match with, such that no idiomatic Go code actually exists. If no idiomatic Go code exists, then it's definitionally true that all idiomatic Go code is without flaws, but I don't agree with your personalized definition of idiomatic Go in the first place.

>That may be true, but of no relevance.

So you agree with this, and it rebuts the entire contents of the first post I responded to. I wonder why you were posting irrelevant, off-topic content yourself. But I'm glad you finally agree that Go isn't flawless.

Re: FP-Go: Functional programming library for Golang

#155

Post by jpk »

eweise wrote: post #121
jpk wrote: post #43

Earlier quoted context omitted.

Big Scala vibes here, see also [1]. 1: https://github.com/scala/scala/blob/v2.13.11/src/library/sca...

That looks pretty straightforward actually.

Ultimately it is, but I guess my point is that having goofy signatures like these down in the bowels of a library (like FP-Go, or Scala's stdlib) might just be necessary goofiness because FP is FP. (Not to knock FP. Engineering is about tradeoffs.)

Re: FP-Go: Functional programming library for Golang

#156

Post by eweise »

jpk wrote: post #155
eweise wrote: post #121

Earlier quoted context omitted.

That looks pretty straightforward actually.

Ultimately it is, but I guess my point is that having goofy signatures like these down in the bowels of a library (like FP-Go, or Scala's stdlib) might just be necessary goofiness because FP is FP. (Not to knock FP. Engineering is about tradeoffs.)

From the Go standard library

"func CompareFunc[S1 ~[]E1, S2 ~[]E2, E1, E2 any](s1 S1, s2 S2, cmp func(E1, E2) int) int { "

Looks like Scala

Re: FP-Go: Functional programming library for Golang

#157

Post by zelphirkalt »

mc10 wrote: post #49
dveeden2 wrote: post #40

Earlier quoted context omitted.

True, however the README does link to this: https://github.com/IBM/fp-go/tree/main/samples

data := F.Pipe3( T.MakeTuple2("https://jsonplaceholder.typicode.com/posts/1", "https://catfact.ninja/fact"), T.Map2(H.MakeGetRequest, H.MakeGetRequest), R.TraverseTuple2( readSinglePost, readSingleCatFact, ), R.ChainFirstIOK(IO.Logf[T.Tuple2[PostItem, CatFact]]("Log Result: %v")), ) This looks like a pain to modify if you're not intimately familiar with the fp-go library and are just trying to insert a debug statemen…

Is there no way to access all arguments or rest arguments in Go? Why limit map and traverse tuple to 2?

Re: FP-Go: Functional programming library for Golang

#158

Post by _a_a_a_ »

cle wrote: post #139
_a_a_a_ wrote: post #130

Earlier quoted context omitted.

Do we have to do the "I don't really get it so nobody else should have it" kind of thing. I have a reasonable level of experience with FP and a lot of general experience (I'm not someone who "read a blog post", I've used it commercially) and I find that it's very handy at the right time. So it can be abused like anything else. So people can write over-complex stuff, true, so blame the language because it's easier tha…

> Do we have to do the "I don't really get it so nobody else should have it" kind of thing. Do we have to do the ad hominem thing? I studied FP and type theory in grad school. It's possible to know about FP and not want to use it in software engineering.

Okay, let's do it. ISTM you started the ad hom with loose accusations of people reading blog posts, ignoring that many people actually have solid commercial experience with it and are being "actually being productive" with it, nor did you justify your view they were "productivity sinks", so I couldn't take you seriously.

Then it got even harder with you dissing generics, which are so fundamentally valuable, such a labour-saver, that the idea of programming being better without them is beyond my ken.

So please lay out your case and I'd be willing to talk.

Re: FP-Go: Functional programming library for Golang

#159

Post by Huggernaut »

awused wrote: post #153
randomdata wrote: post #152

Earlier quoted context omitted.

> Well, if the Go stdlib is haphazardly written and unidiomatic Yeah, the older parts of the standard library are definitely not idiomatic. Lots of functions in the stdlib which return errors don't even return an error type. But, of course they aren't idiomatic. Idiomatacy is emergent. They couldn't possibly have been written idiomatically. > I'll boil it down to one sentence: Go forces programmers to use (T, error)…

So you've defined idiomatic Go code in your own way, that no one else's definitions match with, such that no idiomatic Go code actually exists. If no idiomatic Go code exists, then it's definitionally true that all idiomatic Go code is without flaws, but I don't agree with your personalized definition of idiomatic Go in the first place. > That may be true, but of no relevance. So you agree with this, and it rebuts th…

Just in support of your position, the Google Style Guide says the following:

> If a function returns an error, callers must treat all non-error return values as unspecified unless explicitly documented otherwise

It is absolutely not idiomatic to give any meaning to non-error values under error conditions in the usual case. That is extremely unusual and would be generally confusing.

https://google.github.io/styleguide/go/decisions#returning-e...

Re: FP-Go: Functional programming library for Golang

#160

Post by randomdata »

awused wrote: post #153
randomdata wrote: post #152

Earlier quoted context omitted.

> Well, if the Go stdlib is haphazardly written and unidiomatic Yeah, the older parts of the standard library are definitely not idiomatic. Lots of functions in the stdlib which return errors don't even return an error type. But, of course they aren't idiomatic. Idiomatacy is emergent. They couldn't possibly have been written idiomatically. > I'll boil it down to one sentence: Go forces programmers to use (T, error)…

So you've defined idiomatic Go code in your own way, that no one else's definitions match with, such that no idiomatic Go code actually exists. If no idiomatic Go code exists, then it's definitionally true that all idiomatic Go code is without flaws, but I don't agree with your personalized definition of idiomatic Go in the first place. > That may be true, but of no relevance. So you agree with this, and it rebuts th…

> I don't agree with your personalized definition of idiomatic Go in the first place.

"That's the point. They are not equivalent, they represent different things" – Oh snap. Well, so much for that silly tangent.

If you want to actually have a discussion, you are going to have to go and understand the discussion that was taking place before you tried to take it in some weird and nonsensical direction. The non-sequitors may be entertaining, maybe even true, but off in la-la land with respect to the conversation taking place.

If your intent is simply to be my personal jester, then by all means, run with it. I'll continue to enjoy the laughs. Most people would pay good money to see an entertainer of this caliber, and you are offering it to me for free! I feel privileged.

Post reply on HN