5 ms·

>While Arc includes some handy libraries for writing web apps--libraries so powerful, apparently, that it's cheating to compare Arc to other languages using a p

by nickb 19y ago

>While Arc includes some handy libraries for writing web apps--libraries so powerful, apparently, that it's cheating to compare Arc to other languages using a problem that requires saving a string on the server--that is not the focus right now. HAHA... great quote, pg!! As for language features, I think Arc's on the right track. If anything, be flexible and don't resist the urge to change everything. At this stage, the main thing is to get core right and not worry about backward compatibility.

olavk 19y ago
> libraries so powerful, apparently, that it's cheating to compare Arc to other languages using a problem that requires saving a string on the server It is kind of a straw man though, but he also got a point. Clearly the use of continuations allows very compact descriptions of multi-page control flow. The only languages that can match the succinctness of Arc in the Arc-challenge are other lisps, Ruby and Smalltalk/Seaside, which all of them also uses continuations. Python which is otherwise known for succinctness but which doesn't expose continuations, does not allow such compact code. On the other hand it is a straw man because you would not use continuation for navigation in real-world production web sites. You would have to store a continuation for every hit on the site forever, which is clearly not scalable. Therefore it is obvious that serious web frameworks uses other approaches more in line with the stateless nature of HTTP, even if it leads to more verbose code. I still think the arc-challenge is fun (and I agree that brevity is very desirable), but I think it would be more "fair" if it was framed with real world requirements (scalable, pages bookmarkable etc.) rather than random constraints (the user input must not be exposed in the URL) which only serves to disqualify some non-continuation-based frameworks. Continuation-based web frameworks suffers IMHO from the same mistake as ASP.NET - trying to make web development look like traditional application code. ASP.NET tries to make it look like event-based desktop GUI app development, Arc tries to make it look like a long-running interactive app written in a function style. What web-frameworks are really trying to, is to create a new kind of DSL which embraces the spirit and constraints of the web rather than try to hide it. We are not there yet, and such a holy-grail web app DSL might very well be written in Arc one day. It would probably be very short then.
- olavk 19y ago
  OK, I just realized that the example in the Arc-challenge might be possible to implement without the use of closures persisted between requests. If the page URLs are generated from the expression tree - outer expression is "/said", page 2 is "/said/anonymous1", page 3 is "/said/anonymous1/anonymous1" or something like that, the framework could locate and execute the correct expression for every hit. The framework would have to be smart enough to detect that the "foo" input to the page 2 is used on page 3, so it is passed on in the generated link. This approach could actually be fully scalable. (But damn! It would be disqualified because the input is passed from page 2 to 3 in the URL. I suppose it would be cheating to encrypt it?)
  - aston 19y ago
    Hint: many web stacks suppport server-side sessions. Via cookies.
    - olavk 19y ago
      Yeah, but you don't want to keep navigation state in the session. Otherwise you have to keep the session alive indefinitely to support bookmarking. Also, session based navigation state breaks if you browse the site in two tabs at the same time. And it breaks the back-button.
      - aston 19y ago
        pg's server-side closures are just a variation on the session theme, except that the data being stored is a procedure. You've just listed a bunch of flaws evident on this very forum . Any link with fnid as a parameter is pointing to a server-side session closure that might expire before you actually click the link.
        olavk 19y ago
        OK, agreed, I took your "hint" to indicate that you believed the problem could be solved by cookie-based sessions.

by nickb 19y ago

olavk 19y ago

> libraries so powerful, apparently, that it's cheating to compare Arc to other languages using a problem that requires saving a string on the server It is kind of a straw man though, but he also got a point. Clearly the use of continuations allows very compact descriptions of multi-page control flow. The only languages that can match the succinctness of Arc in the Arc-challenge are other lisps, Ruby and Smalltalk/Seaside, which all of them also uses continuations. Python which is otherwise known for succinctness but which doesn't expose continuations, does not allow such compact code. On the other hand it is a straw man because you would not use continuation for navigation in real-world production web sites. You would have to store a continuation for every hit on the site forever, which is clearly not scalable. Therefore it is obvious that serious web frameworks uses other approaches more in line with the stateless nature of HTTP, even if it leads to more verbose code. I still think the arc-challenge is fun (and I agree that brevity is very desirable), but I think it would be more "fair" if it was framed with real world requirements (scalable, pages bookmarkable etc.) rather than random constraints (the user input must not be exposed in the URL) which only serves to disqualify some non-continuation-based frameworks. Continuation-based web frameworks suffers IMHO from the same mistake as ASP.NET - trying to make web development look like traditional application code. ASP.NET tries to make it look like event-based desktop GUI app development, Arc tries to make it look like a long-running interactive app written in a function style. What web-frameworks are really trying to, is to create a new kind of DSL which embraces the spirit and constraints of the web rather than try to hide it. We are not there yet, and such a holy-grail web app DSL might very well be written in Arc one day. It would probably be very short then.

olavk 19y ago
OK, I just realized that the example in the Arc-challenge might be possible to implement without the use of closures persisted between requests. If the page URLs are generated from the expression tree - outer expression is "/said", page 2 is "/said/anonymous1", page 3 is "/said/anonymous1/anonymous1" or something like that, the framework could locate and execute the correct expression for every hit. The framework would have to be smart enough to detect that the "foo" input to the page 2 is used on page 3, so it is passed on in the generated link. This approach could actually be fully scalable. (But damn! It would be disqualified because the input is passed from page 2 to 3 in the URL. I suppose it would be cheating to encrypt it?)
- aston 19y ago
  Hint: many web stacks suppport server-side sessions. Via cookies.
  - olavk 19y ago
    Yeah, but you don't want to keep navigation state in the session. Otherwise you have to keep the session alive indefinitely to support bookmarking. Also, session based navigation state breaks if you browse the site in two tabs at the same time. And it breaks the back-button.
    - aston 19y ago
      pg's server-side closures are just a variation on the session theme, except that the data being stored is a procedure. You've just listed a bunch of flaws evident on this very forum . Any link with fnid as a parameter is pointing to a server-side session closure that might expire before you actually click the link.
      - olavk 19y ago
        OK, agreed, I took your "hint" to indicate that you believed the problem could be solved by cookie-based sessions.