6 ms·

What a complicated answer to a question with a simple one. I spend all my time on YC now. The last release of Arc was years ago. So this case doesn't prove a

by pg 14y ago

What a complicated answer to a question with a simple one. I spend all my time on YC now. The last release of Arc was years ago. So this case doesn't prove anything one way or the other about programming languages.

orangethirty 14y ago
Do you ever stop and think about working on it? After all, a language is a very personal project.
akkartik 14y ago
At the very least his point about continuation-based webservers is a good one. I recently realized why the arc webserver needed to track IPs to ignore almost from day 1: everytime somebody requests a page, memory usage goes up. This includes crawlers, drive-by users, everybody. The standard way arc encourages webapps to be programmed (http://paulgraham.com/arcchallenge.html http://paulgraham.com/arcchallenge.html) is by leaking memory. Every load of the front-page creates 30 closures just for the 'flag' links. Ignoring IPs is just a band-aid to cover up this huge sink[1]. I've been programming in arc for 3 years and am still active on the arc forum. I love that arc is a small and simple language without lots of bells and whistles[2]. I really couldn't care less that it's 'not taken off'. But there's a different between toys that encourage exploratory play, and painting yourself into a corner design-wise. I now think of continuation-based webservers as an evolutionary dead end. [1] Another ill-effect of the ip-ignoring is that every newcomer to arc who tries to run it behind a proxy server immediately runs into a gotcha: The arc webserver now thinks all requests are coming from the same IP address and so throttles everybody. http://www.arclanguage.org/item?id=11199 http://www.arclanguage.org/item?id=11199 [2] If you spend any time with it it literally begs to be tinkered with. And the experience of programming in a language while referring to its compiler in another window is something everybody should experience.
- mcartyem 14y ago
  His point on continuations is invalid. "The problem: because closures can’t be stored in databases, you really have to use a hash table on your web daemon." This is not true. Closures can be stored anywhere you want.
  - mgummelt 14y ago
    Yea, I think Gödel had something to say about this.
- pg 14y ago
  I'm not sure what you mean by continuation-based. The Arc server can use closures to store state, but it doesn't use continuations. Using closures to store state is like using lists as data structures: it's a rapid prototyping technique. You're in no way painting yourself into a corner, and the current news software is proof of that. You have a very old version of it. In the years since we released the version you have, we've gradually squeezed most of the closures out of the more common things, and we do have a proxy in front of the Arc server. That's how we manage to serve 1.7 million pages a day off one core.
  - akkartik 14y ago
    I see. Yeah, I stand corrected. I was conflating continuation-based and closure-based webservers because both allow straight-line code instead of explicitly managing url handlers. And the traditional rhetoric in favor of this technique has come from Seaside, which popularized the name 'continuation-based' (http://www.linux-mag.com/id/7424 http://www.linux-mag.com/id/7424; http://www.bluishcoder.co.nz/2006/05/server-side-javascript.html http://www.bluishcoder.co.nz/2006/05/server-side-javascript....) I'd never seen anybody say this is just an early-prototyping technique. But searching found Patrick Collison concur: http://www.quora.com/Whats-the-best-continuation-based-web-framework http://www.quora.com/Whats-the-best-continuation-based-web-f... It was too harsh to say it paints us into a corner; it is possible to replace fnid links with new defops. I went back and looked at the frontpage when not logged-in, and saw that there are 0 fnid links in that common case. (One possible way to gradually use a second server would be to just serve the frontpage off it. You'd need to move to a centralized store for user/profile/story objects, but the fnids table could continue to live on one server.) It also turns out that there's at least one company trying to scale continuation-based servers (http://bc.tech.coop/blog/040404.html http://bc.tech.coop/blog/040404.html). So it was overly harsh to call it a dead end.
  - jsgrahamus 14y ago
    PG: It could be instructive to be able to compare your new version with what is currently available.
whyme 14y ago
Would it be fair to say that if Arc had more success when you first released it that you would have been less willing to let the effort die? If so then the full analysis could still have merit.
- pg 14y ago
  In retrospect YC would have taken over my life no matter what. It has pushed out essays too, mostly. I don't consider Arc to have died, incidentally. You used it to say that, and I'm using it to reply. If I ever retired from YC I'd probably start working on it more actively again.
  - whyme 14y ago
    I didn't intend to say Arc died, rather I thought I was stating that your effort died, but i can certainly see how it may come across that way. FYI... I still use arc for certain projects and still have hope that one day it will get the attention it deserves. I know you've taken a lot of criticism about Arc, but I'll suggest there are quite a few of us that do appreciate the work you have done so far.
  - vidar 14y ago
    Do you have any timeframe for your involvement in YC?

by pg 14y ago

orangethirty 14y ago

Do you ever stop and think about working on it? After all, a language is a very personal project.

akkartik 14y ago

At the very least his point about continuation-based webservers is a good one. I recently realized why the arc webserver needed to track IPs to ignore almost from day 1: everytime somebody requests a page, memory usage goes up. This includes crawlers, drive-by users, everybody. The standard way arc encourages webapps to be programmed (http://paulgraham.com/arcchallenge.html http://paulgraham.com/arcchallenge.html) is by leaking memory. Every load of the front-page creates 30 closures just for the 'flag' links. Ignoring IPs is just a band-aid to cover up this huge sink[1]. I've been programming in arc for 3 years and am still active on the arc forum. I love that arc is a small and simple language without lots of bells and whistles[2]. I really couldn't care less that it's 'not taken off'. But there's a different between toys that encourage exploratory play, and painting yourself into a corner design-wise. I now think of continuation-based webservers as an evolutionary dead end. [1] Another ill-effect of the ip-ignoring is that every newcomer to arc who tries to run it behind a proxy server immediately runs into a gotcha: The arc webserver now thinks all requests are coming from the same IP address and so throttles everybody. http://www.arclanguage.org/item?id=11199 http://www.arclanguage.org/item?id=11199 [2] If you spend any time with it it literally begs to be tinkered with. And the experience of programming in a language while referring to its compiler in another window is something everybody should experience.

mcartyem 14y ago
His point on continuations is invalid. "The problem: because closures can’t be stored in databases, you really have to use a hash table on your web daemon." This is not true. Closures can be stored anywhere you want.
- mgummelt 14y ago
  Yea, I think Gödel had something to say about this.
pg 14y ago
I'm not sure what you mean by continuation-based. The Arc server can use closures to store state, but it doesn't use continuations. Using closures to store state is like using lists as data structures: it's a rapid prototyping technique. You're in no way painting yourself into a corner, and the current news software is proof of that. You have a very old version of it. In the years since we released the version you have, we've gradually squeezed most of the closures out of the more common things, and we do have a proxy in front of the Arc server. That's how we manage to serve 1.7 million pages a day off one core.
- akkartik 14y ago
  I see. Yeah, I stand corrected. I was conflating continuation-based and closure-based webservers because both allow straight-line code instead of explicitly managing url handlers. And the traditional rhetoric in favor of this technique has come from Seaside, which popularized the name 'continuation-based' (http://www.linux-mag.com/id/7424 http://www.linux-mag.com/id/7424; http://www.bluishcoder.co.nz/2006/05/server-side-javascript.html http://www.bluishcoder.co.nz/2006/05/server-side-javascript....) I'd never seen anybody say this is just an early-prototyping technique. But searching found Patrick Collison concur: http://www.quora.com/Whats-the-best-continuation-based-web-framework http://www.quora.com/Whats-the-best-continuation-based-web-f... It was too harsh to say it paints us into a corner; it is possible to replace fnid links with new defops. I went back and looked at the frontpage when not logged-in, and saw that there are 0 fnid links in that common case. (One possible way to gradually use a second server would be to just serve the frontpage off it. You'd need to move to a centralized store for user/profile/story objects, but the fnids table could continue to live on one server.) It also turns out that there's at least one company trying to scale continuation-based servers (http://bc.tech.coop/blog/040404.html http://bc.tech.coop/blog/040404.html). So it was overly harsh to call it a dead end.
- jsgrahamus 14y ago
  PG: It could be instructive to be able to compare your new version with what is currently available.

whyme 14y ago

Would it be fair to say that if Arc had more success when you first released it that you would have been less willing to let the effort die? If so then the full analysis could still have merit.

pg 14y ago
In retrospect YC would have taken over my life no matter what. It has pushed out essays too, mostly. I don't consider Arc to have died, incidentally. You used it to say that, and I'm using it to reply. If I ever retired from YC I'd probably start working on it more actively again.
- whyme 14y ago
  I didn't intend to say Arc died, rather I thought I was stating that your effort died, but i can certainly see how it may come across that way. FYI... I still use arc for certain projects and still have hope that one day it will get the attention it deserves. I know you've taken a lot of criticism about Arc, but I'll suggest there are quite a few of us that do appreciate the work you have done so far.
- vidar 14y ago
  Do you have any timeframe for your involvement in YC?