As some of you probably know I started programming in Arc. While I still plan to code in Arc, I would like to get familiar with other languages as well. Since my day job is not anything related to coding I don't need to steer over to the the obvious c# or java choices for resume propping. The following list is just off the top of my head. As a note I'm not really the kind of person that wants to do the math to map data bytes to memory blocks or to the like. I'm interested in high level languages.
I'd probably look for something very different from Arc -- something at least partly complementary. However, I don't know what that would be. What language would at least somewhat complement Arc but not be a low-level language like C?
I wouldn't recommend Ruby because I was not happy with the state of their docs and it didn't seem different enough from Perl or Python to warrant a major effort.
I wouldn't recommend Perl, because Perl is mostly for getting stuff done. If you want to get things done, use Perl, but if you want to learn a language for the intellectual gratification of learning something new, Perl might not be the best for that.
Java is mostly a verbose Python, so I wouldn't recommend that either.
Python works well enough. Not terribly interesting, imo.
Erlang seems pretty heavily focused on concurrency, so unless you need that I probably wouldn't specifically recommend Erlang.
I've heard Lua is simple and tiny. That might be interesting.
I've started haskell. I chose haskell because it appears there is a good balance between performance/documentation/libraries. I already know one language that can be slow, so I think learning a language that's blazing fast will balance the mix. And although Python/Ruby have better docs/libraries - they are much slower than even scheme/arc. Erlang docs are horrific. IMHO.
You came to pretty much the same conclusions I did. I'll probably try out Haskell too. It fits nicely with the kind of side-effect-free-even-to-the-point-of-monads-and-arrows programming I try to do in other languages anyway, and the main thing keeping me away from it has been a perception that it had a really slow implementation.
What I had ended up voting for in the poll though was Clojure. I figure it's lenient about types, it's very reliably cross-platform ('cause of all the business interest in maintaining Java), it has better documentation than Erlang, it can still communicate with C and Erlang (as pretty much any language can, apparently), and beyond that, it has a language-level focus on communicating with other JVM code, which should give you good access to lots of other well-worked-on codebases. As far as I can tell, once you've got access to C and JVM libraries, Python libraries are the next gold mine, but I don't know how to access those libraries except through Python somehow (like through system calls or something), so it didn't affect my decision. (Incidentally, for many of the same reasons I recommend Clojure, I'm hooked on Groovy, but I did consciously try not to let my own criteria make a difference.)
In any case, yeah, now that I see it as fast, Haskell looks great. :-p
I wonder if it's possible to build the beautiful arc syntax as a layer upon haskell. Probably not doable ~ macro's/expansion and all, but still - would be awesome.
Liskell sounds very close to what you're thinking about. Also, the "Write Yourself a Scheme in 48 Hours" Haskell tutorial might interest you. I think this is a pretty popular train of thought. ^_^
That's actually where I'm starting with Haskell. It turns out Haskell is a much more natural home for Blade (my pet lisplike) than any of the other languages I've tried: JavaScript, Groovy, Arc, and Blade itself (with an intent to port/bootstrap it). It's almost scary!
Good point. Although I didn't stipulate this in my original post I kinda assumed no matter what language I pick I will have to continue increasing my js knowledge to continue building web apps. I already do already use js and jquery often.
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.
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?
* 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)
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.
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.
Just curious, what don't you like about Lua? (I think I read that they use 1-based (instead of 0-based) array indexing. That seems like it might be annoying.)
Lua looks good to me. I was trying to see the performance benchmark from the shootout link, but it's down. I'm pretty sure I put Lua along with python. Docs/libraries are great, but is on the slower side. Lua is on my list to learn :)
You have the impression I plan to stop working with/on arc, which is not the case.
The whole point of the FFI is to interface with other languages and such... so I would then need to know the other languages to make further use of the FFI.
I don't know why I would want to write a packaging system, but assuming we're referring to the same kind of packaging... I probably wouldn't use arc when many well developed solutions in other languages already exist.
Actually, you've presented Factor's hello world as though it were a file. They have a REPL, too -- they call it the listener, though. You can either use the GUI version it comes with or from the command line do
The syntax is aesthetically pleasing in an important way: it's very consistent. While postfix might not look "right" at first, it belies an incredibly simple parsing algorithm -- one that allows for easy definitions of the words like USE: and IN: and even :.
I presumed that without "USE: io" that "Hello World" was not
being sent to the standard output where as my arc/haskell examples actually were. i.e. With arc I could load/run a file/script with (pr "Hello World") and it would output "Hello World", but with Factor?...
I just went to each language site and looked for the Hello World examples. It may be that Factor could do a better job advertising AND that I need to spend more than 5 minutes looking :)
Yikes, editing race-conditions. I'll fork this off into a different reply.
I presumed that without "USE: io" that "Hello World" was not being sent to the standard output
Actually, that line's like an import statement in Haskell. I would say it's like load in Arc, but that's not really true; USE: and import have to do with module systems, which Arc doesn't have. If you're already familiar with modules, you can skip this stupid explanation, but...
Basically, modules let you structure your functions into different places so that they don't mess with each other. As a silly example, maybe you write a text adventure in Arc and name a function get, as in (get 'ye-flask). But Arc already defines a function called get, as in (map (get 'a) list-of-hash-tables). You want to be able to use both of them at the same time, but would rather not rename your new function. If Arc had modules, you could qualify the function name with the name of the module in which it's defined. Something like
But when you don't want to use Arc's get, you could still overwrite it with the text adventure's get and not need to prefix it with the module name.
This is a vast oversimplification, of course, but that's essentially what they do. So, in languages like Factor, all the I/O routines are in a module called "io". In the io library is a function called print. If you don't need to print things, you don't need to USE: io, which helps keep the "surface area" of your code small.
i.e. With arc I could load/run a file/script with (pr "Hello World") and it would output "Hello World", but with Factor?...
Because Arc doesn't separate anything into modules, you don't need to import things like pr since it's already there by default. The reason the Haskell code in my other reply could do without the import is that putStrLn is similarly defined in Haskell by default: it's in the so-called "standard prelude". That's what the Prelude> prompt tells you in GHCi. You can import other libraries in GHCi, and the prompt will tell you what you're using:
It may be that Factor could do a better job advertising
True. After all, transliterating the Factor example to Haskell looks something like
module Main where
import System.IO (putStrLn)
hello :: IO ()
hello = putStrLn "Hello world"
main = hello
Of course, in Haskell you would just write
module Main where
main = putStrLn "Hello world"
My point here is that the Factor code doesn't do any real magic. When you give it a chance, the syntax is quite powerful.
It's really neither here nor there: picking a language and getting at least somewhat comfortable with it is going to be better than endlessly deliberating. They all have their merits (even bad languages!).
