6 ms·

Yes, I had the same problem with the initial challenge. I could patch virtually and programming language implementation such that it would be possible to write

by wheels 17y ago

Yes, I had the same problem with the initial challenge. I could patch virtually and programming language implementation such that it would be possible to write a 5 line web app, but that doesn't really say much about the language.

jrockway 17y ago
But Arc itself is is exactly this "patch of a programming language implementation". Also, everything in programming could be much less concise if you wanted it to be. Consider addition. It's an operator in your language. Then it's a CPU instruction. Then it's bits going through logic gates. Since it's a common thing to use, the complexity is abstracted away in many places. If you are writing web apps, it makes sense for your web app libraries to abstract the web stuff away like this too.
- DanielBMarkham 17y ago
  I have had the same problem with the challenge as the gp ever since I read it. I'm a bit perplexed at what exactly Paul's point was. So I write a templating module for OCaml that lets me beat or tie the Arc challenge. I compile it and never have to look at it again. It becomes part of my toolkit. What do I have to do in order to win the challenge? Get my module accepted into some standard library? Why would what some language committee decides be important in terms of how expressive the language is? It doesn't make sense to me. All it shows is that Paul controls Arc and has configured it to deliver small answers to questions that he finds important. I'm not sure it says anything about Arc or any other language for that matter. It might say something about functional versus imperative languages, but perhaps we already knew that?
  - pg 17y ago
    I'm a bit perplexed at what exactly Paul's point was. What do I have to do in order to win the challenge? I think the source of your perplexity may be that you're misunderstanding who (or rather what) is being challenged. It's not a contest between people, but between languages. So you don't win it; a language does. The way a language wins is if you can write the program shorter using it plus some standard libraries. The definition of "standard" doesn't have to be exacting; anything short of a library written specifically to win this contest would be ok; so e.g. any library that existed prior to the challenge obviously would be.
    - axod 17y ago
      The distinction between 'program' 'language' 'library' 'framework' is just arbitrary though. Just another vote for 'I have no clue what the point of this is'. The challenge seems to be: * Write a library with helper functions. Like the Arc library. * Now you can write a short program that uses that library to do things. Obviously that's possible in any language, so I don't understand how this measures languages at all. The example in Arc: (defop said req (aform [onlink "click here" (pr "you said: " (arg _ "foo"))] (input "foo") (submit))) Well this is a concise way to sum up what you want to do, but that could just be rewritten in any language of your choice. Then the appropriate libraries written. For example, java: createForm("click here", new Response("you said %foo"), new InputElement("foo"), new SubmitElement()); I think there's more important things to compare in languages. speed, error handling, stability, memory management etc
      - floodyberry 17y ago
        It wasn't supposed to measure anything, it was supposed to impress you with how awesome Arc is.
      - pg 17y ago
        Here's the critical distinction: you can use only whatever's already provided by the language+libraries you use. That's what I did. I didn't go back and add stuff to the Arc libraries to make the answer to the challenge shorter. I just used what was there already. This will be clear to anyone familiar with the source of HN; all the language features used in the Arc version of the challenge are used throughout news.arc.
        axod 17y ago
        Hrmmmm. But I could just write 'arc' for Java, and the above example would fall out. The solution for arc doesn't have anything unique in it that you can't do in other languages just as concisely. So I don't think it says anything at all about the language, it just says how well you designed the interface to helper libraries. >> "all the language features used in the Arc version of the challenge are used throughout news.arc." I don't see any 'language features' in the solution for Arc. It's just functions and parameters. They're not language features, they're helper libraries. They may be well designed good libraries, but that's what they are. The language used is irrelevant. You could have written arc in BASIC and the solution would be the same. Maybe I just don't understand why arc is referred to as a 'language' rather than a framework/library, and why that distinction is important.
  - DougBTX 17y ago
    > Get my module accepted into some standard library? Yes, that is the gist of it. More specifically, the challenge is, "at this point in time, has anyone gotten the appropriate code into a standard library?" As far as the challenge is concerned, we have to take it on faith that when the challenge was posed, it was no more than a coincidence that pg's language supported an example written in a style pg likes.
    - DanielBMarkham 17y ago
      I think I'm getting this. Let me try another bit of questioning to make sure I got it. So let's say I think CSV-file processing is important. If I show doing something useful and common with CSV files in 15-20 symbols with my language of choice would it be fair to challenge other languages to do the same? If I understand you correctly, this all hinges around what libraries you think languages should have by default and how many symbols it takes to get something "common" done using these commonly-available pieces. This is a little too subjective for me, although I'll easily grant that web programming is much more common than CSV-file processing. Instead of relying on the arbitrariness of what components have been built or what various committees have approved, I would amend this to be something like "after an initial bit of programming not to exceed 3 days, how much symbology do I have to piece together to solve various problems in some sort of common domain like web question/response?" Or something like that. Because as a practical matter I'm always taking a bit to ramp up on new pieces of languages anyway and 3 days or so in this context is a nit.
      - DougBTX 17y ago
        Yes, that's how I understand the challenge. And I agree, it is subjective[1]. I think that the most positive way of looking at it is to declare that session storage in a web app and parsing csv files are understood problems which we don't want to get bogged down solving again. Last week I was writing a small web app to browse a 2GB or so data set, which was provided to me variously in xml and csv data files in a zip file. If I could have called: import data_20091201.zip and gotten something useful, I would be all the happier. I can now make that call, but in terms of getting stuff done, I'm judging my programming environment on the availability unzip utilities, xml and csv parsing libraries and database tools. As far as the language itself is concerned, I want to be able to structure my code neatly without worrying about forgotten temp files if the import fails. I see the arc challenge as a proxy for making this sort of judgment, but it does come down to: "Do the people who maintain the language and contribute to its libraries worry about solving the sorts of problems that I would like to solve? And are they successful in making my life easier?" [1] Subjective in the sense that the problem to solve is one that you may or may not care about solving, or may prefer to solve in a way that happens to use more code to make different aspects more explicit.
  - whyme 17y ago
    I agree. The distinction between having a standard library and extending it with a new one is a weak distinction. The only thing it says is that arc handled a specific common function out of the box. What about all the other batteries that are not included in arc vs. language x? If you need to do any one of a hundred normal things that languages do, arc would fall flat on its' face. Try connecting to a database being capable of fetching large result sets, try having robust integration points with a host of common facilities. True pipes, cross platform, concurrency models etc. etc. My point is that any number of languages could offer a dozen challenges that arc would fail, but pg could always add it to his library and declare it standard simply because he's is in control as the authoritative source.
pg 17y ago
The criterion for tests like this is whether you're relying on stuff you'd expect any language already to have, or not. Features fall on a continuum in that respect. You'd expect any language to be able to add two numbers; you couldn't expect a language to have a library for parsing some format you'd just invented; other features fall somewhere between these extremes. I honestly didn't think any of the things I did in the original Arc challenge required features that wouldn't already have existed in a language that had been used for web programming. All it does is ask the user to input something, then show it on another page. It's practically the hello world of stateful web apps. It seemed reasonable to expect any language that had been used for web apps would already have had convenient libraries for doing such basic things.
- wheels 17y ago
  I did a quick Ruby version just to serve a basis for my point: http://pastie.org/750268 http://pastie.org/750268 The reason I posted that was precisely because of the point where Arc shines: no inline HTML. But in practice, I want to avoid putting my presentation logic inline with my programming logic anyway. And I fear that's the problem with the challenge; it seems to be highlighting the wrong kind of simplicity. I could add a few utility functions to make Ruby able to generate that HTML with a tiny amount of code, but I wouldn't ever actually use those functions in a real program. Edit: Out of curiosity, I just implemented a pseudo-concision-obsessive "library" so see how a Ruby version might look: http://pastie.org/750269 http://pastie.org/750269 I'll note that Rails does have things like those that are often used templates. Another edit: Moved code samples to pastie for readability.
  - DougBTX 17y ago
    The other matter of style is whether the order of the code matches the order in which the user interacts with it. The three steps in user experience order: first: a form to accept input, second: a link to click third: a printout of the input Here are the orders used in code: Ruby+sinatra: third, first, second arc version 1: third, second, first (original) arc version 2: second, third, first (May 2009) Haskell+custom: first, second, third Interesting results, I think Haskell wins here. Though technically it fails the challenge (the arc version 2 example fails too) since the supporting library was written after the challenge was considered by the author of the example.

by wheels 17y ago

jrockway 17y ago

But Arc itself is is exactly this "patch of a programming language implementation". Also, everything in programming could be much less concise if you wanted it to be. Consider addition. It's an operator in your language. Then it's a CPU instruction. Then it's bits going through logic gates. Since it's a common thing to use, the complexity is abstracted away in many places. If you are writing web apps, it makes sense for your web app libraries to abstract the web stuff away like this too.

DanielBMarkham 17y ago
I have had the same problem with the challenge as the gp ever since I read it. I'm a bit perplexed at what exactly Paul's point was. So I write a templating module for OCaml that lets me beat or tie the Arc challenge. I compile it and never have to look at it again. It becomes part of my toolkit. What do I have to do in order to win the challenge? Get my module accepted into some standard library? Why would what some language committee decides be important in terms of how expressive the language is? It doesn't make sense to me. All it shows is that Paul controls Arc and has configured it to deliver small answers to questions that he finds important. I'm not sure it says anything about Arc or any other language for that matter. It might say something about functional versus imperative languages, but perhaps we already knew that?
- pg 17y ago
  I'm a bit perplexed at what exactly Paul's point was. What do I have to do in order to win the challenge? I think the source of your perplexity may be that you're misunderstanding who (or rather what) is being challenged. It's not a contest between people, but between languages. So you don't win it; a language does. The way a language wins is if you can write the program shorter using it plus some standard libraries. The definition of "standard" doesn't have to be exacting; anything short of a library written specifically to win this contest would be ok; so e.g. any library that existed prior to the challenge obviously would be.
  - axod 17y ago
    The distinction between 'program' 'language' 'library' 'framework' is just arbitrary though. Just another vote for 'I have no clue what the point of this is'. The challenge seems to be: * Write a library with helper functions. Like the Arc library. * Now you can write a short program that uses that library to do things. Obviously that's possible in any language, so I don't understand how this measures languages at all. The example in Arc: (defop said req (aform [onlink "click here" (pr "you said: " (arg _ "foo"))] (input "foo") (submit))) Well this is a concise way to sum up what you want to do, but that could just be rewritten in any language of your choice. Then the appropriate libraries written. For example, java: createForm("click here", new Response("you said %foo"), new InputElement("foo"), new SubmitElement()); I think there's more important things to compare in languages. speed, error handling, stability, memory management etc
    - floodyberry 17y ago
      It wasn't supposed to measure anything, it was supposed to impress you with how awesome Arc is.
    - pg 17y ago
      Here's the critical distinction: you can use only whatever's already provided by the language+libraries you use. That's what I did. I didn't go back and add stuff to the Arc libraries to make the answer to the challenge shorter. I just used what was there already. This will be clear to anyone familiar with the source of HN; all the language features used in the Arc version of the challenge are used throughout news.arc.
      - axod 17y ago
        Hrmmmm. But I could just write 'arc' for Java, and the above example would fall out. The solution for arc doesn't have anything unique in it that you can't do in other languages just as concisely. So I don't think it says anything at all about the language, it just says how well you designed the interface to helper libraries. >> "all the language features used in the Arc version of the challenge are used throughout news.arc." I don't see any 'language features' in the solution for Arc. It's just functions and parameters. They're not language features, they're helper libraries. They may be well designed good libraries, but that's what they are. The language used is irrelevant. You could have written arc in BASIC and the solution would be the same. Maybe I just don't understand why arc is referred to as a 'language' rather than a framework/library, and why that distinction is important.
- DougBTX 17y ago
  > Get my module accepted into some standard library? Yes, that is the gist of it. More specifically, the challenge is, "at this point in time, has anyone gotten the appropriate code into a standard library?" As far as the challenge is concerned, we have to take it on faith that when the challenge was posed, it was no more than a coincidence that pg's language supported an example written in a style pg likes.
  - DanielBMarkham 17y ago
    I think I'm getting this. Let me try another bit of questioning to make sure I got it. So let's say I think CSV-file processing is important. If I show doing something useful and common with CSV files in 15-20 symbols with my language of choice would it be fair to challenge other languages to do the same? If I understand you correctly, this all hinges around what libraries you think languages should have by default and how many symbols it takes to get something "common" done using these commonly-available pieces. This is a little too subjective for me, although I'll easily grant that web programming is much more common than CSV-file processing. Instead of relying on the arbitrariness of what components have been built or what various committees have approved, I would amend this to be something like "after an initial bit of programming not to exceed 3 days, how much symbology do I have to piece together to solve various problems in some sort of common domain like web question/response?" Or something like that. Because as a practical matter I'm always taking a bit to ramp up on new pieces of languages anyway and 3 days or so in this context is a nit.
    - DougBTX 17y ago
      Yes, that's how I understand the challenge. And I agree, it is subjective[1]. I think that the most positive way of looking at it is to declare that session storage in a web app and parsing csv files are understood problems which we don't want to get bogged down solving again. Last week I was writing a small web app to browse a 2GB or so data set, which was provided to me variously in xml and csv data files in a zip file. If I could have called: import data_20091201.zip and gotten something useful, I would be all the happier. I can now make that call, but in terms of getting stuff done, I'm judging my programming environment on the availability unzip utilities, xml and csv parsing libraries and database tools. As far as the language itself is concerned, I want to be able to structure my code neatly without worrying about forgotten temp files if the import fails. I see the arc challenge as a proxy for making this sort of judgment, but it does come down to: "Do the people who maintain the language and contribute to its libraries worry about solving the sorts of problems that I would like to solve? And are they successful in making my life easier?" [1] Subjective in the sense that the problem to solve is one that you may or may not care about solving, or may prefer to solve in a way that happens to use more code to make different aspects more explicit.
- whyme 17y ago
  I agree. The distinction between having a standard library and extending it with a new one is a weak distinction. The only thing it says is that arc handled a specific common function out of the box. What about all the other batteries that are not included in arc vs. language x? If you need to do any one of a hundred normal things that languages do, arc would fall flat on its' face. Try connecting to a database being capable of fetching large result sets, try having robust integration points with a host of common facilities. True pipes, cross platform, concurrency models etc. etc. My point is that any number of languages could offer a dozen challenges that arc would fail, but pg could always add it to his library and declare it standard simply because he's is in control as the authoritative source.

pg 17y ago

The criterion for tests like this is whether you're relying on stuff you'd expect any language already to have, or not. Features fall on a continuum in that respect. You'd expect any language to be able to add two numbers; you couldn't expect a language to have a library for parsing some format you'd just invented; other features fall somewhere between these extremes. I honestly didn't think any of the things I did in the original Arc challenge required features that wouldn't already have existed in a language that had been used for web programming. All it does is ask the user to input something, then show it on another page. It's practically the hello world of stateful web apps. It seemed reasonable to expect any language that had been used for web apps would already have had convenient libraries for doing such basic things.

wheels 17y ago
I did a quick Ruby version just to serve a basis for my point: http://pastie.org/750268 http://pastie.org/750268 The reason I posted that was precisely because of the point where Arc shines: no inline HTML. But in practice, I want to avoid putting my presentation logic inline with my programming logic anyway. And I fear that's the problem with the challenge; it seems to be highlighting the wrong kind of simplicity. I could add a few utility functions to make Ruby able to generate that HTML with a tiny amount of code, but I wouldn't ever actually use those functions in a real program. Edit: Out of curiosity, I just implemented a pseudo-concision-obsessive "library" so see how a Ruby version might look: http://pastie.org/750269 http://pastie.org/750269 I'll note that Rails does have things like those that are often used templates. Another edit: Moved code samples to pastie for readability.
- DougBTX 17y ago
  The other matter of style is whether the order of the code matches the order in which the user interacts with it. The three steps in user experience order: first: a form to accept input, second: a link to click third: a printout of the input Here are the orders used in code: Ruby+sinatra: third, first, second arc version 1: third, second, first (original) arc version 2: second, third, first (May 2009) Haskell+custom: first, second, third Interesting results, I think Haskell wins here. Though technically it fails the challenge (the arc version 2 example fails too) since the supporting library was written after the challenge was considered by the author of the example.