NT AUTHORITY\SYSTEM is a user on cronk.stenoweb.net. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

NT AUTHORITY\SYSTEM @calvin@cronk.stenoweb.net

aoc day 3 Show more

aoc day 3 Show more

aoc day 3 Show more

Horrific #FSharp solution to day 3 of #AoC2017 Show more

@staticsafe TBH, I feel like the lack of IPv6 rollout support is, like, 85% about making it harder for people to self host stuff.

@micah Looks like I finally have a tolerable-enough equivalent to a non-existent Array2D.findIndex.... time to implement pathfinding I can barely understand the math for!

@micah well, I'm also running into possible stdlib limitations with 2D arrays, ugh

@micah I managed to implement Ulam's spiral (jn the least functional way possible) - now I need to implement the damn pathfinding algorithm...

jesus, day 3 of looks bloody difficult

I wish there was an dingus so I could jump to a buffer by fuzzy-searching for it - does this exist?

the advent of code drops at 1 AM and I am not wrecking my sleep schedule for it

Swans - Gucci Gang (Extended Mix) [16:20]

@h @enkiv2 @ajroach42 @uranther

1. HTTP/HTML are no worse for centralization than gopher and type 1 menus are. I scrolled up the thread and didn't see anything of the sort. Why, and what does Gopher bring to this, without having to add most of HTTP onto it?

2. Since I lacked space, to elaborate further, a blanket term for complexity; a bit of an exaggeration. Sorry for being unclear.

@h @enkiv2 @ajroach42 @uranther so really, my question is - why add this stuff onto Gopher, which is fun because it IS a simple relic of 1990? If your problem is with the garbage of the modern web, no one said HTTP and HTML are cancerous with it - it'd be little trouble to just use all the existing work of the web, and not take the bad parts. By extending gopher in these ways, what's the benefit?

wrt blockchains, I was pointing it out as a blanket thing for onions/IPFS even if those things aren't.

@enkiv2 @h @ajroach42 @uranther I thought IPFS would be more complex to support. This is good to know, though I'm not personally convinced on the utility of IPFS. (discussion for another time, I guess)

As stated upthread though, I just don't see the benefit of adding this to gopher instead of just using existing web technology minus the nasty. I like gopher because it's /dead/ simple, and from a time when that mattered.

@h @enkiv2 @ajroach42 @uranther I've been poking gopher for a while, but with a lot of the new talk about it, a lot of it is just adding extra protocols on top to increase complexity and ultimately bring it up to the point of "why not HTTP?" instead of some relic of a simpler time.

if you want to fight the modern web, putting go-faster stripes on gopher is not the way; you're better off serving better content on HTTP and rejecting the web for apps, and embrace the web for documents.

@h @enkiv2 @ajroach42 @uranther again, the strength of Gopher is the SHEER simplicity or just sending something to port 70 and getting it back. when you're talking about blockchains or markup parsers... why not just HTTP, and keep your content simple?