3 ms·

> Though simple, as such tests have to be, this is not a contrived example. Web apps have to do this sort of thing all the time. No. Web app prototypes do that

> Though simple, as such tests have to be, this is not a contrived example. Web apps have to do this sort of thing all the time. No. Web app prototypes do that sort of thing all the time. For production web apps, the problem ends up including such confounding factors as meeting accessibility policy, making the HTML surrounding the form elements match what a web designer came up, etc. The more web development work I do, the more wary I am of any system that writes HTML for me. Inevitably the system ends up putting too many constraints on what HTML can be output. Witness the ASP.NET framework, which writes lots of HTML for you. Unlike Arc it was written with the best practices of the time in mind, but it's aged badly as the web has grown and changed. Doing accessible, cross-browser, standards-based work in ASP.NET today involves a certain amount of fighting the framework which offsets the initial productivity gains. I understand that Arc is intended for exploratory work and rapid prototyping. But that's exactly why the Arc challenge is meaningless. We're being asked to compare Arc to languages that provide -- dare I say it -- a great deal more flexibility and expressive power when it comes to outputting HTML. So here's my challenge: Take a sample Arc application and modify it to replace tables with appropriate block elements that have designer-specified IDs and classes. Use <label> elements for each input if you aren't already. Replace a few regular submit buttons with image buttons or vice versa. Reorder some elements, and throw a few more arbitrary containers in here and there. Compare that process against a conventional language and let's see where we get. In my line of work, that kind of scut work is absolutely part of prototyping. Before I can build the real thing my prototype has to be approved by people who have a hard time looking past even minor visual inconsistencies with what they're used to. For that reason I'm very wary of any design that makes fine-grained control of HTML any harder than it has to be, and I've come to value clean view/everything else separation even in early prototypes. I suspect that Arc is much more appealing to people who don't live with such constraints.

pg 19y ago
Do you consider News.YC a mere prototype? It's been around for a year, never gets runtime errors, and serves about 80k pages a day without breaking a sweat. And the source is full of code like this. I think you're confusing types of software with organizations that sponsor them. Arc certainly wasn't designed for use in the sort of environment where programs are 10% functionality and 90% the embodiment of the random bureaucratic processes of the organization paying for them. More for the opposite end of the spectrum, in fact. That's where you need power. That said, if you care to make your challenge a precise one, it's likely I (or someone else) would try implementing it in Arc, if only out of curiosity.
- Annoynymous 19y ago
  Bureaucracy isn't the only reason to care about, or have to modify, HTML. Things like accessibility and browser compatiblity matter too, and that ground is constantly shifting. Beyond that, there aren't a whole lot of people outside the world of hackers and scientists who don't care about aesthetics. That means that the overwhelming majority of us will end up working for people who care how stuff looks, even at the prototype stage. That's not bureaucracy, it's human nature. Every time I've let somebody else's tools write HTML for me, it's caused me grief. Either because the tool author had an agenda that was at odds with my needs (Microsoft), because of bugs in the tool (everyone), or because the problem set shifted since the tool was written as browsers and techniques changed (everyone). Likewise, I'm wary of entertwining HTML output with the rest of the program the way Arc does because it makes it too much work to change things down the line. It would be interesting to write a templating system that separates HTML output without making Arc programs take much longer to write. I suspect that it could be done, but it's not entirely clear to me what shape it would take. If done right it would give users the option to leverage Arc's existing HTML output functions where desired. I'll have to play with it.
- dfranke 19y ago
  How about this: make news.yc look right in Dillo (http://www.dillo.org http://www.dillo.org).
  - s3graham 19y ago
    It looks reasonable in "links" (could use an alt-tag or two)
- richcollins 19y ago
  How about releasing the source to news.yc so we can see how terse it is for a non-trivial application :)
  - pg 19y ago
    I will eventually, but first I have to abstract out all the news.yc-specific stuff.

pg 19y ago

Do you consider News.YC a mere prototype? It's been around for a year, never gets runtime errors, and serves about 80k pages a day without breaking a sweat. And the source is full of code like this. I think you're confusing types of software with organizations that sponsor them. Arc certainly wasn't designed for use in the sort of environment where programs are 10% functionality and 90% the embodiment of the random bureaucratic processes of the organization paying for them. More for the opposite end of the spectrum, in fact. That's where you need power. That said, if you care to make your challenge a precise one, it's likely I (or someone else) would try implementing it in Arc, if only out of curiosity.

Annoynymous 19y ago
Bureaucracy isn't the only reason to care about, or have to modify, HTML. Things like accessibility and browser compatiblity matter too, and that ground is constantly shifting. Beyond that, there aren't a whole lot of people outside the world of hackers and scientists who don't care about aesthetics. That means that the overwhelming majority of us will end up working for people who care how stuff looks, even at the prototype stage. That's not bureaucracy, it's human nature. Every time I've let somebody else's tools write HTML for me, it's caused me grief. Either because the tool author had an agenda that was at odds with my needs (Microsoft), because of bugs in the tool (everyone), or because the problem set shifted since the tool was written as browsers and techniques changed (everyone). Likewise, I'm wary of entertwining HTML output with the rest of the program the way Arc does because it makes it too much work to change things down the line. It would be interesting to write a templating system that separates HTML output without making Arc programs take much longer to write. I suspect that it could be done, but it's not entirely clear to me what shape it would take. If done right it would give users the option to leverage Arc's existing HTML output functions where desired. I'll have to play with it.
dfranke 19y ago
How about this: make news.yc look right in Dillo (http://www.dillo.org http://www.dillo.org).
- s3graham 19y ago
  It looks reasonable in "links" (could use an alt-tag or two)
richcollins 19y ago
How about releasing the source to news.yc so we can see how terse it is for a non-trivial application :)
- pg 19y ago
  I will eventually, but first I have to abstract out all the news.yc-specific stuff.