6 ms·

If you have questions, please ask! Using Arc in real applications has been such an interesting experience that I can barely shut up about how ridiculously fun

by laarc 11y ago

If you have questions, please ask! Using Arc in real applications has been such an interesting experience that I can barely shut up about how ridiculously fun it is. Here are some unfinished notes about what the diffs mean: https://gist.github.com/laarc/a07799e89940dc7c31c9 https://gist.github.com/laarc/a07799e89940dc7c31c9 It's interesting how short the diffs are vs how many features and fixes they deliver.

vessenes 11y ago
I was recently checking out arc, and I do have a question. The arc community seems very small, if I had to guess, it looked like a 'dead' language in terms of community participation. Did I miss it? Are people actively using it? I want to play with it, but I would hesitate to use a language with such a small community for a project that was mission critical.
- laarc 11y ago
  Email me if you run into trouble, and I'll personally help fix any problem you run into. It turns out that if you use arc for something critical, the language itself won't break. The programs written in Arc might contain bugs, but as far as I can tell, the underlying infrastructure is solid. This is going to sound like bullshit, but a couple years ago I wrote a site in Arc and left it running by mistake. It was set up to push hourly backups to Tarnsap, and the site was doing useful things, but I never ended up needing it. Turns out the site continued running for 1.4 years by accident. There weren't any scripts to restart the server on a reboot -- it simply ran for that long. Presumably it halted because Amazon rebooted the micro instance or the account ran out of money. When I checked the logs in Tarsnap, I was pretty amazed to find that it had served 37k requests, almost all of which were automated fuzzers. I hadn't launched the site; it just happened to be using an obscure URL. The site had a bit of dynamic functionality, so it wasn't merely a static site. But I hadn't written it cleverly or carefully. Arc is what carried the site for those 16 months, not me. As for the community: correct, but I intend to change that. If the growth exponent flips from negative to positive, it won't be small for very long. In the meantime, though, they're some of the nicest and most helpful people ever, so feel free to post whenever you get stuck, or shoot me a message.
  - vessenes 11y ago
    Thank you! That's about as nice an offer as I'd want to get on the internet. :)
voltagex_ 11y ago
The only Arc application I know of is HN - can you show any other examples? As a non-Lisp programmer, can you sell the benefits of Arc to me?
- laarc 11y ago
  Mmhm! But not without confusing the hell out of everyone. But who cares? It's fun! I should start by clarifying that I'm not associated with Arc in any way. Everything that I show should be thought of as an eager derivative, at best. But for several months a colleague and I have been working on a derivative, which we've been calling laarc, which incorporates a few additions that make it a bit easier to write programs with. Here's a debugger similar to pdb.set_trace(), for example: http://i.imgur.com/WWKa4kw.png http://i.imgur.com/WWKa4kw.png Except when it breaks, it shows a list of the values of all the local variables. It's really useful for stepping through macro expansions and understanding them, because there's no longer any mystery when something breaks. Laarc isn't anywhere near ready yet, so it's too early to know whether it'll be useful generally, but the goal is to discover a way to make programming feel like a Tesla. So, what are the benefits? Well, here's an example of a real-world program. It's all pimply and has a few hacks in it, but on the other hand, you can get a gist of how it might look: https://github.com/laarc/monki/blob/master/main.l https://github.com/laarc/monki/blob/master/main.l Note that this was made two days ago, and I've been working very fast. So it's pretty rough. The program (monki) is essentially "cp for git", and while it works, it's not quite finished. Monki is Yet Another alternative to git subtrees / submodules; think of it like "cp for git". `monki clone voltagex/foo foo` would create a clone of that repo into the subdir "foo". But that subdir can be within one of your existing repositories. Here's the scenario it's useful for: https://github.com/tlbtlbtlb/startuptools https://github.com/tlbtlbtlb/startuptools This requires an installation of tlbcore (https://github.com/tlbtlbtlb/tlbcore https://github.com/tlbtlbtlb/tlbcore) symlinked to this directory. With monki, you'd just type `monki clone tlbtlbtlb/tlbcore tlbcore` from within a clone of startuptools, and then you'd commit the result. Monki takes care of pulling updates, so that whenever tlbcore changes, startuptools would also get the new stuff. But you can `monki clone` a specific commit instead, if you want to pin to a "known working" version. Anyway, that monki business was the result of trying to answer "What's a simple way where I can share code between all my repositories, pull in updates as I make them, and not have to worry too much?" And it was a good chance to exercise... Lumen! Confused yet? Ok, so Arc runs on Racket. So did Laarc. Then we had the good fortune to hear about Lumen: https://github.com/sctb/lumen https://github.com/sctb/lumen It's a Lisp that compiles to either Javascript or Lua. It literally exhibits the same behavior whether you're running via luajit, node, or the browser. Since LuaJIT's FFI is awesome, that makes it incredibly easy to interface with existing C libraries using Lumen. Just look how beautiful his postgres bindings are! https://github.com/sctb/motor/blob/master/pq.l https://github.com/sctb/motor/blob/master/pq.l That should catch anyone's attention -- the FFI is literally "copy paste some C declarations and you're done." I want to take that further. In Lumen, it's already possible to interface with node libraries or with lua libraries as-needed. What if we extend it to work with python and go libs as easily as it works with C? You might end up with a language that could do any given task very easily, because you'd simply use whatever library happens to be convenient regardless of whether it's a C lib, a node package, or a Ruby gem. So why have I been yakking about Lumen? Because it seems like it offers a bunch of interesting benefits as a runtime. I've been porting Laarc from Racket to it, slowly. It's extremely early, but here's an early version of the compiler: https://github.com/laarc/lumen-arc/blob/master/arc.l https://github.com/laarc/lumen-arc/blob/master/arc.l ... It's essentially ac.scm. I wanted to make it match as closely as possible, both because ac.scm is a good answer to "What's a good way to write a lisp compiler in a lisp language?" and because it's dangerous to assume you can write from scratch something that a smart team has been thinking about and working on for 13 years. Sooo... That's a whirlwind tour of stuff that's not even ready to tour. On the plus side, the plan is to get an in-browser repl running soon (arc can already run in the browser, so it's a matter of coaxing CodeMirror into submission). There's a server running Lumen over at http://arc.lol:9999 http://arc.lol:9999 which does absolutely nothing useful yet. The plan is to get a REPL up and to dub it "Arc dot tiefighter" since "lol" obviously looks like a tie fighter.
nathancahill 11y ago
I've found (for stable software), that most features and fixes are really short. I think it's a sign of code maturity.
147 11y ago
Other than Paul Graham's essay, I'd love to have more resources on bottom-up vs top-down design. Especially if it were more concrete.
- mahmud 11y ago
  Paul Graham wrote a seminal Common Lisp book specially for this. On Lisp www.paulgraham.com/onlisp.html
skissane 11y ago
Given we already have so many dialects of Lisp, what value does Arc offer that they do not? Why should I choose to learn/use Arc, as opposed to (say) Scheme or Common Lisp or Clojure?
- laarc 11y ago
  A brief laundry list: - Arc embraces macros. - You can redefine anything. (assign + -) (+ 3 4) evaluates to -1. Not only are you an equal partner to the language, but the language is short enough to carry in your head. - Green threads. Here's a snippet from Laarc which does hot code reloading: (thread (on-err autoerr (fn () (while autoload* (sleep 0.25) (autoreload))))) It says "When an error happens, call the 'autoerr' function. Every 0.25 sec, check whether any source has changed, and reload it if so." But green threads make it so easy to do that in parallel. I never once had to worry about synchronization issues in the case of the autoreloader. - There's no FFI for Arc. However, I'm in the process of porting Arc from Racket to Lumen, which has a very interesting FFI thanks to LuaJIT: https://github.com/sctb/motor/blob/master/motor.l https://github.com/sctb/motor/blob/master/motor.l It's literally "copy-paste these C declarations. Now you can call those C functions." It quite simply rocks. If you're interested in Arc, consider Lumen as well. https://github.com/sctb/lumen https://github.com/sctb/lumen It has many similarities to Arc, like a powerful macro system, and has some interesting distinctions, like keyword arguments and the FFI facilities.
  - mveety 11y ago
    Yeah lumen's ffi is fantastic. It's really simple and clear compared to like CFFI or so. Seeing that ported to/implemented on CL would be really cool.
akkartik 11y ago
Arc1, arc2 and arc3 are available at https://github.com/arclanguage/anarki/commits/official https://github.com/arclanguage/anarki/commits/official

by laarc 11y ago

vessenes 11y ago

I was recently checking out arc, and I do have a question. The arc community seems very small, if I had to guess, it looked like a 'dead' language in terms of community participation. Did I miss it? Are people actively using it? I want to play with it, but I would hesitate to use a language with such a small community for a project that was mission critical.

laarc 11y ago
Email me if you run into trouble, and I'll personally help fix any problem you run into. It turns out that if you use arc for something critical, the language itself won't break. The programs written in Arc might contain bugs, but as far as I can tell, the underlying infrastructure is solid. This is going to sound like bullshit, but a couple years ago I wrote a site in Arc and left it running by mistake. It was set up to push hourly backups to Tarnsap, and the site was doing useful things, but I never ended up needing it. Turns out the site continued running for 1.4 years by accident. There weren't any scripts to restart the server on a reboot -- it simply ran for that long. Presumably it halted because Amazon rebooted the micro instance or the account ran out of money. When I checked the logs in Tarsnap, I was pretty amazed to find that it had served 37k requests, almost all of which were automated fuzzers. I hadn't launched the site; it just happened to be using an obscure URL. The site had a bit of dynamic functionality, so it wasn't merely a static site. But I hadn't written it cleverly or carefully. Arc is what carried the site for those 16 months, not me. As for the community: correct, but I intend to change that. If the growth exponent flips from negative to positive, it won't be small for very long. In the meantime, though, they're some of the nicest and most helpful people ever, so feel free to post whenever you get stuck, or shoot me a message.
- vessenes 11y ago
  Thank you! That's about as nice an offer as I'd want to get on the internet. :)

voltagex_ 11y ago

The only Arc application I know of is HN - can you show any other examples? As a non-Lisp programmer, can you sell the benefits of Arc to me?

laarc 11y ago
Mmhm! But not without confusing the hell out of everyone. But who cares? It's fun! I should start by clarifying that I'm not associated with Arc in any way. Everything that I show should be thought of as an eager derivative, at best. But for several months a colleague and I have been working on a derivative, which we've been calling laarc, which incorporates a few additions that make it a bit easier to write programs with. Here's a debugger similar to pdb.set_trace(), for example: http://i.imgur.com/WWKa4kw.png http://i.imgur.com/WWKa4kw.png Except when it breaks, it shows a list of the values of all the local variables. It's really useful for stepping through macro expansions and understanding them, because there's no longer any mystery when something breaks. Laarc isn't anywhere near ready yet, so it's too early to know whether it'll be useful generally, but the goal is to discover a way to make programming feel like a Tesla. So, what are the benefits? Well, here's an example of a real-world program. It's all pimply and has a few hacks in it, but on the other hand, you can get a gist of how it might look: https://github.com/laarc/monki/blob/master/main.l https://github.com/laarc/monki/blob/master/main.l Note that this was made two days ago, and I've been working very fast. So it's pretty rough. The program (monki) is essentially "cp for git", and while it works, it's not quite finished. Monki is Yet Another alternative to git subtrees / submodules; think of it like "cp for git". `monki clone voltagex/foo foo` would create a clone of that repo into the subdir "foo". But that subdir can be within one of your existing repositories. Here's the scenario it's useful for: https://github.com/tlbtlbtlb/startuptools https://github.com/tlbtlbtlb/startuptools This requires an installation of tlbcore (https://github.com/tlbtlbtlb/tlbcore https://github.com/tlbtlbtlb/tlbcore) symlinked to this directory. With monki, you'd just type `monki clone tlbtlbtlb/tlbcore tlbcore` from within a clone of startuptools, and then you'd commit the result. Monki takes care of pulling updates, so that whenever tlbcore changes, startuptools would also get the new stuff. But you can `monki clone` a specific commit instead, if you want to pin to a "known working" version. Anyway, that monki business was the result of trying to answer "What's a simple way where I can share code between all my repositories, pull in updates as I make them, and not have to worry too much?" And it was a good chance to exercise... Lumen! Confused yet? Ok, so Arc runs on Racket. So did Laarc. Then we had the good fortune to hear about Lumen: https://github.com/sctb/lumen https://github.com/sctb/lumen It's a Lisp that compiles to either Javascript or Lua. It literally exhibits the same behavior whether you're running via luajit, node, or the browser. Since LuaJIT's FFI is awesome, that makes it incredibly easy to interface with existing C libraries using Lumen. Just look how beautiful his postgres bindings are! https://github.com/sctb/motor/blob/master/pq.l https://github.com/sctb/motor/blob/master/pq.l That should catch anyone's attention -- the FFI is literally "copy paste some C declarations and you're done." I want to take that further. In Lumen, it's already possible to interface with node libraries or with lua libraries as-needed. What if we extend it to work with python and go libs as easily as it works with C? You might end up with a language that could do any given task very easily, because you'd simply use whatever library happens to be convenient regardless of whether it's a C lib, a node package, or a Ruby gem. So why have I been yakking about Lumen? Because it seems like it offers a bunch of interesting benefits as a runtime. I've been porting Laarc from Racket to it, slowly. It's extremely early, but here's an early version of the compiler: https://github.com/laarc/lumen-arc/blob/master/arc.l https://github.com/laarc/lumen-arc/blob/master/arc.l ... It's essentially ac.scm. I wanted to make it match as closely as possible, both because ac.scm is a good answer to "What's a good way to write a lisp compiler in a lisp language?" and because it's dangerous to assume you can write from scratch something that a smart team has been thinking about and working on for 13 years. Sooo... That's a whirlwind tour of stuff that's not even ready to tour. On the plus side, the plan is to get an in-browser repl running soon (arc can already run in the browser, so it's a matter of coaxing CodeMirror into submission). There's a server running Lumen over at http://arc.lol:9999 http://arc.lol:9999 which does absolutely nothing useful yet. The plan is to get a REPL up and to dub it "Arc dot tiefighter" since "lol" obviously looks like a tie fighter.

nathancahill 11y ago

I've found (for stable software), that most features and fixes are really short. I think it's a sign of code maturity.

147 11y ago

Other than Paul Graham's essay, I'd love to have more resources on bottom-up vs top-down design. Especially if it were more concrete.

mahmud 11y ago
Paul Graham wrote a seminal Common Lisp book specially for this. On Lisp www.paulgraham.com/onlisp.html

skissane 11y ago

Given we already have so many dialects of Lisp, what value does Arc offer that they do not? Why should I choose to learn/use Arc, as opposed to (say) Scheme or Common Lisp or Clojure?

laarc 11y ago
A brief laundry list: - Arc embraces macros. - You can redefine anything. (assign + -) (+ 3 4) evaluates to -1. Not only are you an equal partner to the language, but the language is short enough to carry in your head. - Green threads. Here's a snippet from Laarc which does hot code reloading: (thread (on-err autoerr (fn () (while autoload* (sleep 0.25) (autoreload))))) It says "When an error happens, call the 'autoerr' function. Every 0.25 sec, check whether any source has changed, and reload it if so." But green threads make it so easy to do that in parallel. I never once had to worry about synchronization issues in the case of the autoreloader. - There's no FFI for Arc. However, I'm in the process of porting Arc from Racket to Lumen, which has a very interesting FFI thanks to LuaJIT: https://github.com/sctb/motor/blob/master/motor.l https://github.com/sctb/motor/blob/master/motor.l It's literally "copy-paste these C declarations. Now you can call those C functions." It quite simply rocks. If you're interested in Arc, consider Lumen as well. https://github.com/sctb/lumen https://github.com/sctb/lumen It has many similarities to Arc, like a powerful macro system, and has some interesting distinctions, like keyword arguments and the FFI facilities.
- mveety 11y ago
  Yeah lumen's ffi is fantastic. It's really simple and clear compared to like CFFI or so. Seeing that ported to/implemented on CL would be really cool.

akkartik 11y ago

Arc1, arc2 and arc3 are available at https://github.com/arclanguage/anarki/commits/official https://github.com/arclanguage/anarki/commits/official