A good way to learn programming is to write a program that does one very simple thing, such as displaying a message. Then read and learn a little more about programming, and add to your program, or write a new program, so that it does a little more:
learn -> do -> learn -> do -> learn -> do ...
You don't have to either trust or distrust things you read because you can immediately test what they have to say.
For example, if someone were to say that to write a Javascript program that adds two numbers, you can go the address bar in your web browser (the box that normally has a web address like "http://arclanguage.org/), and type in:
javascript:alert(3+4)
you don't have to believe them or not believe them, you can try it for yourself.
Or, if you read in the Arc tutorial that typing in
(+ 1 2)
will display "3", you can go try it for yourself.
You can try Arc without installing anything on your computer, as palsecam has Arc running on a web page for you: http://dabuttonfactory.com:8080/
If you'd like to run Arc on your computer, feel free to ask for help if you run into any trouble installing it (Arc is new so it isn't as easy to install as some other languages).
Then I look for libraries or API's that will do that thing for me.
If there are several options, I look for one which seems to be the most practical and straightforward implementation.
These days when I go through this process I most often end up with a library or API written for Perl, Python, Ruby, or Java.
What I would suggest is learning enough of each of these languages so that you can make library calls. Which is pretty easy to do; you don't need to learn a lot to do that.
Then how much you need to program in that language vs. Arc usually comes down to efficiency. Each call from Arc to the other language involves a round-trip of some sort; so if you're doing something in a loop then you'll often want to push the code to do that loop into the other language. So you may end learning more of the other language as you translate some parts of your Arc code into the other language.
That's actually not a bad idea. Server side languages are fundamentally equivalent in the sense that what one can do another can do, though it may be easier or more fun in one language or another. Javascript lets you program the user interface in the browser. Check out http://jquery.com/ for a useful Javascript client-side library.
That's a clever idea, I think I probably would use a macro that let me check a value against a series of expressions (perhaps using some form of currying). I don't think I'd call it "case" though :-)
I've got a macro like that, which I call 'test. The problem with combining that and 'case is distinguishing functions and constants before the cases are eval'ed.
Then there's the language itself... would it be helpful for people who only speak Chinese to be able to program using Chinese words instead of "for", "map", "list", "if", "and", "let" and so on?
Waiters in Paris generally assume I'm an English-speaking tourist (a reasonable bet), and hand me the translated English menu. They mean well, but "Preserved Duck with Potatoes Fried in Duck Grease" doesn't sound anything like the delicious meal it usually is. I fear a translated programming language might have the same icky feel. And it would be a lot harder to share code if keywords were translated. But the tutorial ... yay.
I'm sure that Arc will always be better in the original. But to deny someone the pleasure of programming in Arc merely because they don't speak English seems... cruel :-)
I sometimes use lists as compound keys, so I need a version of case that lets me compare against literal lists (whether it gets called "case" as it is in Arc now or something else).
However I don't use Anarki, so it doesn't matter to me whether you push it there.
It may not matter to you, but IMO it matters to the community (what little of it there is) that anarki and arc not break compatibility in such a simple case as this.
With the fix, I have to do that. Without the fix, I can keep my code brief. For what it's worth, I like the fix better, but then I don't expect to write (aif (coerce (readline) 'cons) ...) much either.
