Arc Forumnew | comments | leaders | submitlogin
1 point by rocketnia 5496 days ago | link | parent

Well, there are a lot of good languages on your list. Just about the only one I don't feel like voting for is C#. :-p So do you have any more criteria/goals/uses to speak of that could narrow it down?


1 point by thaddeus 5496 days ago | link

yup (and prioritized):

  * great documentation & write ups.
  * feature rich well supported libraries (i.e. database connections, vector graphics libraries etc..)
  * macOSX and Linux support.
  * active community of users at all levels. 
  * low overhead (I like that arc is a dynamic language, has type inference, and lexical scope)

-----

1 point by thaddeus 5496 days ago | link

As for goals/uses... really I just want options. Ideally in the future I can interface between arc and this/these languages. This way if arc is not a good fit for doing some thing then I can use another language to do that part.

-----

5 points by aw 5496 days ago | link

Work backwards.

First there's some thing that I want to do.

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.

-----