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

Loopless Programming

code.jsoftware.com

Post reply on HN
Print view View original

121–129 of 129 posts

Re: Loopless Programming

#121

Post by inimino »

NOGDP wrote: post #85
inimino wrote: post #73

Earlier quoted context omitted.

> This seems like a pretty low-effort write-up. You're not the audience for the article and that's what this entire thread shows. You missed the fact that you were not the audience, and that makes this a low-effort dismissal. Rather than trying to get the point of the article, you're picking on minutiae and trying to pick it apart. This is why we can't have nice discussions about programming languages. The audience f…

I'm not trying to prove the article wrong, my point is only that it's not well written and filled with baseless claims such as: > J's approach to iteration is vastly better than other languages.

> baseless claims

Those are opinions.

> not well written

That's yours.

Re: Loopless Programming

#122

Post by jadbox »

whateveracct wrote: post #53
agumonkey wrote: post #38

Earlier quoted context omitted.

You can say this now but not long ago map/filter/reduce were almost esoteric.

I'd say even just 5 years ago they were weird FP features, with LINQ being the most mainstream version. Now Go is the only mainstream language without them hehe.

It's my #1 problem with Go, and there's no good solution imho other than Go getting some kind of generic type support.

Re: Loopless Programming

#123

Post by jadbox »

suzuki wrote: post #117
whateveracct wrote: post #53

Earlier quoted context omitted.

I'd say even just 5 years ago they were weird FP features, with LINQ being the most mainstream version. Now Go is the only mainstream language without them hehe.

You can write your own LINQ in Go with a very short program. See https://github.com/nukata/linq-in-go for example. Here is a self-contained excerpt: type Any = interface{} type Enumerator func(yield func(element Any)) // Select creates an Enumerator which applies f to each of elements. func (loop Enumerator) Select(f func(Any) Any) Enumerator { return func(yield func(Any)) { loop(func(element Any) { value := f(elemen…

It's a little annoying though to be forced to use interface{} as type parameters for higher order list operations as there's a performance overhead when using it. Hopefully this is remedied when Go gets type generic support.

Re: Loopless Programming

#124

Post by whateveracct »

jadbox wrote: post #123
suzuki wrote: post #117

Earlier quoted context omitted.

You can write your own LINQ in Go with a very short program. See https://github.com/nukata/linq-in-go for example. Here is a self-contained excerpt: type Any = interface{} type Enumerator func(yield func(element Any)) // Select creates an Enumerator which applies f to each of elements. func (loop Enumerator) Select(f func(Any) Any) Enumerator { return func(yield func(Any)) { loop(func(element Any) { value := f(elemen…

It's a little annoying though to be forced to use interface{} as type parameters for higher order list operations as there's a performance overhead when using it. Hopefully this is remedied when Go gets type generic support.

Not to mention the complete lack of type safety (there are unsafe-style casts even in the example code.)

Re: Loopless Programming

#125

Post by dang »

kragen wrote: post #120
inimino wrote: post #119

Earlier quoted context omitted.

At the risk of taking this too meta... there's something interesting here about online communities like HN. In everyday human interactions, we have a lot of contextual and social cues about who is more experienced, respected, expert, even who is older; in short, all kinds of social hierarchical information that guides and constrains our behavior. Online, especially in a community of sufficient size that most interact…

Those are wonderful points, and I really appreciate them. I am persuaded that it is important to set a good example of behavior for the kids. (And, perhaps, for myself when I'm talking about things I'm even more ignorant of than I am about J; an example is linked below.) There is some amount of "social hierarchical information" available, if you look carefully — the original poster in this thread has "karma" of 47, w…

Karma is mostly an indication of how much time people have spent posting to the site.

I agree with you about some of those examples and have reset the score on them; we do that routinely when we see good comments unfairly downvoted. So do a lot of users, while the upvote window is still open. The corrective upvote is a standard practice here. And yes, that still leaves some good comments in negative space. Voting is a big messy statistical cloud. I don't think there's a way to make it precise. Maybe it's worth noting that the examples you cited are already months old? There have been about a million comments posted to HN since those. It's inevitable that a sample that large will contain some shitty outliers, i.e. really unjust cases. Comments tend to fluctuate up and down in score; some are going to end up in the red just stochastically. Perhaps we should be more open to experimenting with the voting system, but years of looking closely at that data has diminished my sense of what's possible. I think the two biggest factors are human nature and randomness, and we can't do much about either. There could still be better mechanisms for channeling them, though.

Re: Loopless Programming

#126

Post by dang »

inimino wrote: post #119
kragen wrote: post #116

Earlier quoted context omitted.

I appreciate the feedback! I'm not a user of J or APL in any regular way, but I feel that there's something going on there that I don't understand (and, due to spreadsheets serving APL's 1970s constituency better than APL did, perhaps nobody ever will). I suspect that J itself is fatally flawed, but I don't understand its merits well enough to be sure how to fix it. My frustration comes from the quality of the discou…

At the risk of taking this too meta... there's something interesting here about online communities like HN. In everyday human interactions, we have a lot of contextual and social cues about who is more experienced, respected, expert, even who is older; in short, all kinds of social hierarchical information that guides and constrains our behavior. Online, especially in a community of sufficient size that most interact…

There are a lot of subtle observations here that I wish I had more time to respond to. One general response though. You're pointing to something I've noticed about online communities like HN: what happens here is mostly determined by the fundamentals. The fundamentals of HN are that it is a large [1], open, optionally anonymous public forum. Those simple conditions already determine most of what happens here. They also determine how moderation needs to function, and why things that work in other contexts (e.g. blunt rebuke) are so dysfunctional in this one.

It makes me want to take a deeper look at McLuhan, because "the medium is the message" describes this phenomenon like no other phrase can. The more experience I have the truer it seems, specifically about HN.

[1] Large is relative, and HN is small relative to the big fish—5M or so readers a month—but still large relative to human history and to the communities humans are used to. In a discussion like this one, where the participants have deep experience with online communities, it would be more precise to call HN medium-sized.

Re: Loopless Programming

#127

Post by NOGDP »

inimino wrote: post #121
NOGDP wrote: post #85

Earlier quoted context omitted.

I'm not trying to prove the article wrong, my point is only that it's not well written and filled with baseless claims such as: > J's approach to iteration is vastly better than other languages.

> baseless claims Those are opinions. > not well written That's yours.

> Those are opinions.

Opinions and claims are not mutually exclusive.

> That's yours.

Yup, thanks.

Re: Loopless Programming

#128

Post by suzuki »

whateveracct wrote: post #124
jadbox wrote: post #123

Earlier quoted context omitted.

It's a little annoying though to be forced to use interface{} as type parameters for higher order list operations as there's a performance overhead when using it. Hopefully this is remedied when Go gets type generic support.

Not to mention the complete lack of type safety (there are unsafe-style casts even in the example code.)

Good point! I'm looking forward to generics in Go.

Re: Loopless Programming

#129

Post by kragen »

dang wrote: post #125
kragen wrote: post #120

Earlier quoted context omitted.

Those are wonderful points, and I really appreciate them. I am persuaded that it is important to set a good example of behavior for the kids. (And, perhaps, for myself when I'm talking about things I'm even more ignorant of than I am about J; an example is linked below.) There is some amount of "social hierarchical information" available, if you look carefully — the original poster in this thread has "karma" of 47, w…

Karma is mostly an indication of how much time people have spent posting to the site. I agree with you about some of those examples and have reset the score on them; we do that routinely when we see good comments unfairly downvoted. So do a lot of users, while the upvote window is still open. The corrective upvote is a standard practice here. And yes, that still leaves some good comments in negative space. Voting is…

I'm glad you're here too.
Post reply on HN