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

"Unknown or expired link." - Why?

google.com

Post reply on HN
Print view View original

111–120 of 142 posts

Re: "Unknown or expired link." - Why?

#111

Post by gnaritas »

wvenable wrote: post #76
gnaritas wrote: post #67

Earlier quoted context omitted.

No, the issue is time, specifically, pg's time; using callbacks takes less programmer time than manually building every URL statelessly. Yes, it could be done another way, but it wouldn't exist at all if he'd had to do that for every link because it'd have taken too much of his time.

What is it about Arc or the architecture of HN that makes callbacks so easy and stateless URLs so hard? I've written a forum in under 3 hours the "traditional" way in PHP. I find the stateless concept a lot simpler in general. None of these links should require any server state at all.

Generated html; callbacks make for rapid prototyping by grabbing necessary state directly from the environment rather than making you specify the state field by field in the URL. Your 3 hour prototype doesn't come close to the features in this forum so it's not comparable. No links ever require sever state if you take the pains to manually specify routing and parameter information for your links, but that's something callbacks eliminate the need for by trading server state for programmer time.

Re: "Unknown or expired link." - Why?

#112

Post by DiabloD3 »

jgrahamc wrote: post #13

It's an artefact of the way in which news.arc (actually srv.arc) uses functions for links. Here's the key code: (= dead-msg* "\nUnknown or expired link.") (defop-raw x (str req) (w/stdout str (aif (fns* (sym (arg req "fnid"))) (it req) (pr dead-msg*)))) If the fnid (function ID) isn't in the fns* list then you get the dead message. (def flink (f) (string fnurl* "?fnid=" (fnid (fn (req) (prn) (f req))))) In many place…

A website written in Lisp? That is awesome.

Re: "Unknown or expired link." - Why?

#113

Post by wvenable »

gnaritas wrote: post #111
wvenable wrote: post #76

Earlier quoted context omitted.

What is it about Arc or the architecture of HN that makes callbacks so easy and stateless URLs so hard? I've written a forum in under 3 hours the "traditional" way in PHP. I find the stateless concept a lot simpler in general. None of these links should require any server state at all.

Generated html; callbacks make for rapid prototyping by grabbing necessary state directly from the environment rather than making you specify the state field by field in the URL. Your 3 hour prototype doesn't come close to the features in this forum so it's not comparable. No links ever require sever state if you take the pains to manually specify routing and parameter information for your links, but that's something…

I think you massively over-estimate the functionality of this site. I can actually see the immense value of using closures for maintaining state in an application that actually needs state (any site containing a progression of forms, for example). HN is ridiculously simple for a site. With few requests requiring requiring much in the way of previous state.

I understand why it's designed this way -- he's got a tool meant for more complex tasks than what it's used for on this site. He used that tool because it's what he knows. But I really can't see it saving that much programmer effort in general.

Re: "Unknown or expired link." - Why?

#114

Post by gnaritas »

dasil003 wrote: post #73
gnaritas wrote: post #59

Earlier quoted context omitted.

> The way I would approach this is to keep the link cache in memory, but have the links contain the minimal necessary state to reconstruct the link from disk-based storage in the case where the cache is gone. It's not a cache, and you clearly don't understand the issue. These are callbacks to closures, embedding the state in the URL is what they attempt to avoid because doing that is tedious .

Sorry, bad choice of words. I was just shooting from the hip here in response to the parent that suggests you can't both keep something in RAM for the majority of cases and still make it robust. The fact that embedding state in the URL is tedious is neither here nor there, but in any case it's a pretty garbage excuse. You know what's more tedious than writing code to pass a few integers around in links? Thousands of…

You seem to not be aware of the architecture of this site, it's all run out of ram, no database; just simple lazy load on demand files on a single server running in a single process. Because of this, memory is tight, that's why those closures are purged. It simply means pg hasn't had the time to convert more of the prototyped code into production stateless code that always works. But that's his prerogative, this site is a hobby for him, he doesn't need to make any excuses about anything. If you don't like his site, go somewhere else.

Re: "Unknown or expired link." - Why?

#115

Post by pg »

staunch wrote: post #106
pg wrote: post #82

Earlier quoted context omitted.

Your comment is in a sense its own refutation, because the ultimate test of user experience is whether users continue to use the software. Getting user experience right depends on the users. I wouldn't use this technique in an online store. Random online shoppers would be confused by expired links, and you'd lose sales. But HN users aren't confused by them. What HN users care about is the quality of the stuff on the…

I use HN as much as anyone and it doesn't get in my way at all. The most annoying thing about the issue is hearing the repeated discussion around it. I'd rather have any kind of cool new feature, like messaging, than have this fixed.

We've had messaging for years. I just never turned it on in the general case. (We use it to talk to YC applicants.)

Re: "Unknown or expired link." - Why?

#116

Post by gnaritas »

DougBTX wrote: post #83
gnaritas wrote: post #63

Earlier quoted context omitted.

No, it's a design choice, he favors ease of programming more than user experience. You might not agree with that choice, but it's not a flaw, he did it on purpose and knew the consequences.

A better name might be technical debt. It is a flaw from the perspective of someone seeing the error message. But for the developer it is a way of saving development time, which can be paid off later to fix it.

Yes, this is a better way to say it.

Re: "Unknown or expired link." - Why?

#117

Post by staunch »

pg wrote: post #115
staunch wrote: post #106

Earlier quoted context omitted.

I use HN as much as anyone and it doesn't get in my way at all. The most annoying thing about the issue is hearing the repeated discussion around it. I'd rather have any kind of cool new feature, like messaging, than have this fixed.

We've had messaging for years. I just never turned it on in the general case. (We use it to talk to YC applicants.)

Well, I applied to YC for the first time, so maybe I'll get to see it!

Re: "Unknown or expired link." - Why?

#118

Post by seven_stones »

pg wrote: post #82
tomcreighton wrote: post #79

I find it interesting that most discussions I've seen about this exact topic are about Arc and closures... instead of about the fact that this may well be an interesting programming thing to do but it's a moronic user experience thing to do.

Your comment is in a sense its own refutation, because the ultimate test of user experience is whether users continue to use the software. Getting user experience right depends on the users. I wouldn't use this technique in an online store. Random online shoppers would be confused by expired links, and you'd lose sales. But HN users aren't confused by them. What HN users care about is the quality of the stuff on the…

> because the ultimate test of user experience is whether users continue to use the software.

TIL Windows has always been an amazing user experience. Just look at their numbers.

> But HN users aren't confused by them.

"About 2,200,000 results" -- says they are.

I have a question: What advice would you give to one of your YC startups if they were having this same issue?

"Ah, your users won't be confused. Ignore all evidence that says they are."

I can tell you exactly why people continue to use Hacker News. It's because it's YOUR SITE. They put up with the broken web design where links die after a few minutes.

Your site won't get beat out by a competitor because it has you, and you fund people. So people continuing to use the site is orthogonal to whether the user experience is any good. You have lots of feedback indicating that it isn't.

Aren't you the one who says "listen to your users"?

Re: "Unknown or expired link." - Why?

#119

Post by gnaritas »

wvenable wrote: post #113
gnaritas wrote: post #111

Earlier quoted context omitted.

Generated html; callbacks make for rapid prototyping by grabbing necessary state directly from the environment rather than making you specify the state field by field in the URL. Your 3 hour prototype doesn't come close to the features in this forum so it's not comparable. No links ever require sever state if you take the pains to manually specify routing and parameter information for your links, but that's something…

I think you massively over-estimate the functionality of this site. I can actually see the immense value of using closures for maintaining state in an application that actually needs state (any site containing a progression of forms, for example). HN is ridiculously simple for a site. With few requests requiring requiring much in the way of previous state. I understand why it's designed this way -- he's got a tool me…

I think you over-estimate what you can do in three hours and underestimate how much non UI stuff there is in trying to keep out garbage and prevent voter rings and score karma and vary behavior based on that karma and probably a dozen other little small things.

Re: "Unknown or expired link." - Why?

#120

Post by wvenable »

gnaritas wrote: post #119
wvenable wrote: post #113

Earlier quoted context omitted.

I think you massively over-estimate the functionality of this site. I can actually see the immense value of using closures for maintaining state in an application that actually needs state (any site containing a progression of forms, for example). HN is ridiculously simple for a site. With few requests requiring requiring much in the way of previous state. I understand why it's designed this way -- he's got a tool me…

I think you over-estimate what you can do in three hours and underestimate how much non UI stuff there is in trying to keep out garbage and prevent voter rings and score karma and vary behavior based on that karma and probably a dozen other little small things.

I certainly don't think 3 hours is enough for this site but then pg has put in a lot more time in than just his initial prototype as well. But the functionality of closures and server-side state aren't needed for this kind of site at all. Nothing you mentioned above seems related to that functionality either.
Post reply on HN