There's an old anarki library you can use to download a webpage. The library can be seen here: http://github.com/nex3/arc/tree/arc2.master/lib/http-get/. However - I once used that library for my personal market scanner (downloads data for tens of thousands of stocks) and found it to be fragile. My suggestion is to use the 'system' command (http://files.arcfn.com/doc/os.html) in order to call 'curl' or 'wget'. See http://curl.haxx.se/ or http://www.gnu.org/software/wget/. These utilities auto-download the webpage for you.

3. You will then need to 'readfile', see http://files.arcfn.com/doc/io.html

4. You'll need to edit the data, then re-serve the page, in which case you use 'defop' (http://files.arcfn.com/doc/srv.html) or you can write the file out to your static directory.

Hmmm... I also found the old related post and there was also another error: "PLT Scheme virtual machine has run out of memory; aborting Aborted"

http://arclanguage.org/item?id=11899

I know the nginx comments add a little confusion to the post (as I wasn't sure at the time what was going on), but I don't think Apache vs. nginx was the problem.

With arc, the language syntax and base libraries are awesome, but you scratch your head more often, wondering" well how the hell am I supposed to do that. " And these problems/features are not small roadblocks... For example, if I need to use Arc connecting to oracle? - good luck, it's not going to happen.

Thanks for the offer. I think real database connections to arc could only improve the adoption + user happiness levels, but I will suggest connecting to oracle was just an example for the point I was trying to make.

What I am suggesting is not new or even surprising. Arc has no depth for libraries. Rich solved this problem right from the get-go by having tight integration with java. Arc would have had similar success had it done the same thing - too bad really. And dropping into Scheme just doesn't cut it.

I'm suggesting users of arc will google things like 'arc oracle', or even 'scheme oracle' which returns jack. With Arc you get Nada for google answers + you get unanswered posts such as these.

http://arclanguage.org/item?id=10839

However google 'clojure oracle':

http://en.wikibooks.org/wiki/Clojure_Programming/Examples/JD....

step-by-step recipes to connect to a myriad of databases. This was made possible through Clojures tight integration with java. Clojure can import java libraries with 1 simple import statement.

Let's not forget that Clojure is a newer language than Arc - correct?

Now, I'm just looking at the title of the thread "Effort to make it easy to use in production?", and thinking - yeah, I can understand, that's why I moved over to Clojure and its too bad Arc didn't do this.

Sure I'm no expert in the programming language industry, but if I were to come up with a new spiffy language I'd rather do what Rich did. Arc could have been built atop the jvm - correct? It was just easier not to, considering arc was not about being practical, it was about attaining some elusive mystical idealized syntax that will be practical in, possibly, a hundred years from now.

The JVM naturally has the advantage that it's easy to call Java libraries, but it has the disadvantage that it has no built-in support for tail call optimization or continuations. Since it's not particularly difficult to make use of libraries running in a different process, it would be easy enough for me to use Java libraries from an Arc implemented in Racket if I wanted to, and so I had no compelling reason to write ar on top of the JVM.

There is a long history of languages written for people who want to use the JVM but who also want to be able to use a less terrible language than Java: Jython, Groovy, Clojure, etc. Since Clojure is a particularly nice language, it didn't surprise me that it rapidly gained popularity among people who want to use the JVM.

For any particular project that I may be working on, there are a mix of features that I need for that project. If I were working on a project that primarily needed to call Java libraries and I didn't need the features unique to Arc, I would most likely use Clojure myself (or Rainbow or Jarc, if it turned out that one of those were suitable to my project). If I were working on a project where the features of Arc were important and I also needed to call some Java libraries, I'd likely write it in Arc calling out to Java libraries.

Since this is a forum for Arc, I answer questions primarily from the perspective of Arc. Since typically a hundred people will browse a forum for each person posting, I primarily answer questions for the majority reading. For example, if someone makes a statement that is wrong, I will say that they are wrong, so that someone else reading the forum isn't left with incorrect facts.

When someone complains about Arc, I tend to suspect that either there's something they want, or else they just feel like complaining. People wanting things is useful. If someone actually wants X and says so, and we come up with a solution for them, then we also help the hundred other people who want that thing as well. Other the other hand, and I'm not saying that anyone has actually done this, but if someone were to sit at a computer and type in a complaint that other people haven't done the work to make Arc a popular language faster than some other language has become popular, that doesn't strike me as being particularly useful.

I'm not against complaining. Complaining is often a useful first step towards finding a solution. However, while I'm not trying to pass judgement, I am trying to discern whether someone is complaining because they just want to complain or because they want a solution.

Sure, if you have spent hundreds of hours doing low level hacking between racket<->arc you can suggest these things are not all that hard, but the reality is that many of these feature-x's are just not going to happen.

Chances are that mainstream features are not a priority for the members here... And that's my message to the OP: go use Clojure or something having the features you want. I say this from 2 years of following arc, the arc forum and its members. There are probably a dozen submissions/comments about db connects and FFI, yet to this day nothing works.

> "If you like the Arc, then instead of complaining that other people aren't figuring out what you'd want to use for you, why not take the time to help and describe what you would need in a db connection library and FFI?"

I'm thinking if you re-read the thread starting from my first comment (http://arclanguage.org/item?id=14539), you'll hopefully come to understand that I haven't been complaining, but rather I have been defending/substantiating my suggestions and thoughts.

As for why I don't take time to describe some spec, well because I'm not asking for anything and I've chosen to spend the bulk of my time learning Clojure and building applications. I guess you could say I take my own advice.

> "If you want some love on the forum, there's an easy way to get that:make a useful contribution."

Or, you could add a page to the wiki describing the ways that Clojure is better than Arc.

Since then, Jarc's actually added Rainbow compatibility functions, so you might be able to get away with writing code just for Rainbow without leaving Jarc too far behind. Rainbow's faster, but Jarc has a more straightforward implementation.

Because working with arc is more enjoyable than working with scheme.

;=

I think you're assuming that people here only use Arc. I for example spend 99% of my programming time in Clojure. And still, in many respects, arc is better than other languages. For example, I think arc is perfect (syntax wise) for being an embeddable language. An end user of my app can easily become familiar with Arc, which is not the case for scheme or clojure. It's certainly both easier and more enjoyable to use than scheme is.

There's also a time/money/productivity argument to be made as well. I will not elaborate, suffice to say Arc wins this one hands down.

Short version:

This. Very this. I think Arc's smallness is a Good Thing.

---

Long version (do I have too much spare time on my hands...?):

The funny thing is, when I first started programming in Arc, I had almost no Lisp experience, and almost no functional programming experience either. Sure, I knew lambdas and closures (due to my JavaScript experience), but I didn't write my JavaScript in a very functional style. I kinda sorta understood the concept behind recursion, but when I tried to read a program written in recursive style, I didn't understand it and my brain hurt.

Yet, I was able to start writing programs in Arc... and anytime I had a question like, "I wonder how that function works", I could just look in arc.arc and see for myself. Despite all the limitations described above, I didn't have a very hard time learning Arc. After a short while (maybe 2 days or so), I had even started to get into the "rhythm" of Arc, reading and understanding code by it's context, rather than having to parse each individual node. I even forced myself to learn to read recursion a bit better.

I thought this was astonishing. Being able to pick up and quickly learn and use a language and paradigm that I had almost no experience with, just by reading the language itself. It was like how a baby learns to speak a language, except I'm not a baby, so I don't have that magical ability anymore. I didn't have that experience with Python. I could pick up and use Python because it was similar to JavaScript (both tend to emphasize imperative/procedural style), but I'm still constantly looking up how to do things in the Python documentation...

And then there's Racket. Racket has a large amount of documentation, and they even have a search engine to trawl through it and find what you want. Yet I still have a hard time figuring out what a function does, even though they give me what parameters the function expects, what value the function returns, a brief description of what the function does, and sometimes even examples!

I find Arc easier to learn and use, despite (or perhaps because of?) it's philosophy that "code is the spec". In a sense, I think being smaller is better for exploratory programming. Having a nice, robust, stable language with tons of well-written big libraries is great for writing robust programs. But I think a lot of that just gets in the way when you want to fool around and experiment.

In that situation, I think you're better off axiomitizing things as much as possible. Lisp does that by (over?)emphasizing lists, and then having a bunch of functions that operate on lists. You can then go in later and change the datatype to a hash table or whatever, once the program is in a more complete state.

It's easier to add things, than it is to take things away. Lua wins not because it can do everything, but because it's small, and smallness is good in embedded languages. I think Arc wins for a similar reason: it's small. I think it'd be a lot harder to evolve that kind of smallness in an existing language, compared to starting with a clean slate.

Oh yeah, maybe it would help if you thought of Arc as being more of a thin skin on top of an existing language (like Scheme). This is actually true in pgArc, Anarki, and ar, because they let you access the underlying Racket functions. So you get the niceness of Arc by default, but you can tap into Racket's libraries when you need to.

I also plan to eventually do the same thing with Arubic... allowing Arc programs to import and use Python libraries. And if I recall correctly, jarc and rainbow also let you call into Java's libraries. And then wart, which I assume lets you call CL functions.

This is just what I get from reading a bunch of his post, code comments and articles. It's probably a good idea to read pg's articles from years ago during the initial design phase to get an understanding of what choices were made and why.

for example:

http://paulgraham.com/ilc03.html

"much easier to learn"

These are my reasons in a nutshell.

I've always liked the philosophy of programming in whatever language was most suitable to the task, and everywhere I looked indicated that lisps emphasized that philosophy. It made sense, since s-expressions seemed pretty ideal as a way to use a single generic parser to handle all kinds of custom languages.

As I was looking into it, I read about Paul Graham's plans for Arc and liked the idea of a lisp with that kind of open-to-the-programmer philosophy (and avoidance of extraneous parentheses). And then I found out Arc existed, and I gradually made my way over to Arc from Groovy.

If:

a) you're running a web application on top of Arc, and

b) you have some very long pages that are taking a long time to render, and

c) it's a page that you actually want to be able display to your users

...then there are less drastic alternatives to kicking the page off the front page:

- you can increase caching (at the cost of the displayed page being a bit more out of date)

- break the page up into parts and add "next" and "prev" links

All speculation of course. I'm just suggesting that, often, there are simple reasons for the choices made behind these kinds of decisions.

All the ideas you list are great ideas. It's funny though, even I spent a bunch of time writing a blogging platform and I still have not bothered to put paging into the listings. I figure at my current rate of posts, it will take me a year before I'll need to worry about it. There are things we should do, in our ideal world, and then there's what we need to do relative to all other things. So, again, I suggest that maybe the reasons for these kinds decisions can often be much simpler than we think. There's not always some elusive statistical computation with all kinds attention and detail poured into them.

[edit1] ignore the below point... point format tricked me up reading on my ultra small screen :)

I don't fully understand what this point has to do with anything:

- provide a runnable example (http://awwx.posterous.com/share-your-problems-with-runnable-...) of your problem on the forum and get help

I like the work you did, but how does this fit into the discussion or your comment? It seems out of place.

[edit2] Also I used to like the fact that this forum allowed for editing within the first hour. I could correct my mistakes before, I figured, anyone had time to even read them, lol... but, that's not working anymore and trying to respond to changing posts kinda sucks.

I get the sense you believe that it's a huge waste of time a nothing more than a money pit for legal expenses. I believe if they went away then the openness that we are experiencing in this day and age would dry up.

When a house craftsman comes to my house and builds me a stairwell, I can't take his work and re-sell it. If I could, then he would quickly go out of business.

Indirectly, by having a more consistent legal system. As I said, I believe pretty strongly in property rights, and I believe IP is inconsistent with property rights. Debate about either of those things is probably way off topic for the Arc Forum, even more so than it would be for Hacker News.

As for the rest of your arguments, they're all of the form "there are unfortunate consequences". I can take each one of them and argue that it wouldn't be as bad as you think--sometimes because it'd be bad for some people for a while, but people would adapt and we'd all probably be better off at the end of it--as is usually the case with technological revolutions. I could explain myself in more detail and give examples, and in fact I began to do so, but, again, this is probably not the place for such a debate. Suffice to say that I have reasons for my opinions; I've done a lot of reading, thinking, and arguing on the subject (with myself, with the things I read, and with friends); and in an extended debate, you'd probably concede that at least my reasoning made sense even if you didn't agree with some of my premises.

There are, generally speaking, two types of people who visit this forum. The first, type-A let's call them, are hardcore hackers, like yourself(ves), who are interested in the language design and the underbelly mechanics of language assembly. Then there are people, like myself, whom are only interested in using the language to build applications.

When I read: > "Arc would be a better solution for my problem if it had...", "It's more rare for this to be followed up by an actual runnable implementation of the feature." I will suggest the two types of people represent the divide within the pattern you're recognizing and I will going to even further to suggest this is not a bad thing. I would like to encourage more type-B user engagement - even, if only, so that I am not all alone :)

While I don't have the time or inclination to understand the full content/depth within these type-A posts, I do try to learn what I can even if only at a surface level. I really do enjoy reading these posts and do appreciate them so I hope they don't go to a back channel as akkartik has mentioned a possibility for.

Furthermore, I would like to highlight some of the points aw's message that I feel are really important (and with my interpretation):

* Inline comments are not the best way to present your ideas. I've struggled assembling all the bits and pieces and knowledge requirements from prior posts/threads. The order alone messes everything up and I simply do not have the time to do the paper chase.

* Writing an external blog post will likely force you to present a fuller picture, with its surrounding context, to an audience that can't always be on top of things.

I added an "Arc Wish List" page to the wiki: https://sites.google.com/site/arclanguagewiki/wish-list It's currently empty :-) Perhaps some type-B users would like to fill in some things they'd like implemented? ^_^

I took a break to write a blogging platform from scratch that includes my own custom markdown.

I even posted my first arc topic here: http://blackstag.com/blog.posting?id=2. I then quickly discovered the auto spam bots are moving from the arc forum to my blog site every night. So I took another break, lol, just to put some spam management code in. I'm glad had read enough of pg's code to implement some good techniques similar to news.arc.

Now I'm ready to do more blogging - I hope. I've accumulated a list of 9 or 10 posts and I plan to get some arc stuff in there as well.

> JavaScript allows arbitrary expressions in switch statements

That's right... looks like it was the test data I was thinking of, which isn't entirely relevant, given you can accomplish the same thing in the end.

> Why make the common case difficult?

  switch (true) {
  case true:
      console.log(1);
  case true:
      console.log(2);
  case true:
      console.log(3);
      break;
  case true:
      console.log(4);
  }

  switch (true) {
  case true:
      console.log(1);
      continue;
  case true:
      console.log(2);
      continue;
  case true:
      console.log(3);
  case true:
      console.log(4);
  }

In fact, in my years and years of programming in JavaScript, I have used if/else blocks many many times (some of which could have been switch statements), and only wanted fallthru a handful of times. I think allowing fallthru is fine, but it should be made explicit, rather than implicit.

The only possible argument I can think of in favor of implicit fallthru is using a switch inside a `for` loop:

  for (var i = 0; i < array.length; i += 1) {
      switch (array[i]) {
      case "foo":
          continue;
      }
  }

Arc and Javascript case functions are not expected to do the same thing. JS does not allow expressions for input arguments while Arc can. And that break; statement is a feature that some would say Arc lacks. ie, what if you want your case statement to fall through? - now Javascript is golden and one could say Arc is lacking.

I also don't believe developers, generally speaking, prefer if/else chains over switch/case statements as they are different tools intended for different purposes.

They both are not perfect, both are missing features that the other could benefit from.

  switch (true) {
  case 5 > 1:
      console.log("5 > 1");
      break;
  }

On the contrary, switch should not have a break statement! It should have a fallthru; or continue; statement. Why make the common case difficult? This should be uncontroversial... it's been well established that switch's design is poor, and they should have made it explicit fallthru (like with a continue statement) rather than implicit.

As for Arc "lacking" fallthru... can't you implement that with continuations? That would be the equivalent of explicit fallthru.

---

I think that's because the above semantics correspond more directly to assembly language, which I imagine was done because "switch" was defined back when that was either important or just not seen to be bad. (Perhaps I'm just making that up, though.) Here's how a switch statement would look in x64 assembly:

  switch:
        ;put desired thing in rax, let's say
  case_1:
        cmp rax, val_1
        jne case_2      ;jump if not equal
        <case 1 code>
  case_2:
        cmp rax, val_2
        jne case_3
        <case 2 code>
  case_3:
        cmp rax, val_2
        jne done
        <case 3 code>
  done:
        <whatever>

  switch:
        ;put desired thing in rax, let's say
  case_1:
        cmp rax, val_1
        jne case_2      ;jump if not equal
        <case 1 code>
        jmp done        ;jump.
  case_2:
        cmp rax, val_2
        jne case_3
        <case 2 code>
        jmp done
  case_3:
        cmp rax, val_2
        jne done
        <case 3 code>
  done:
        <whatever>