Most of the Arc terminology is borrowed from other Lisps, so it's not really a problem with Arc; instead, it's simply that the Lisp culture is very old and has its own way of thinking and doing things. You get used to it.

If you have any questions, please do ask and we'll do our best to answer. Some of us here (including myself) started Arc with almost no Lisp experience, yet over time became quite good.

---

"What are some reusable trail maps that other people have experienced?"

Considering that I'm still learning new things all the time, and that the new things I discover have a tendency to demolish decades-old ways of thinking, I'm not sure there is a nice reusable "just read this and you'll be okay" kind of thing. I do know of at least one good resource for explaining what macros are and why they're awesome, but that's about it. The rest you either have to dig up, ask about, or learn on your own.

---

"How can I learn more about you folk?"

Well, it depends on how much you want to know us. If all you care about is the programming aspect, you can just hang around here and watch what we say and do. You can also ask.

---

"Why is the help button so small to get me to http://arclanguage.org/formatdoc? "

I don't know, that bugs me too. I didn't even know about that link until somebody pointed it out.

---

"Why can't I hover over the language and have it tell me how to refactor my thinking?"

Because good AIs don't exist yet. So it's up to us lowly meat-bags to do the thinking.

---

"How do I ask better questions?"

Everything happens with practice, which takes time and effort. If you really want something and you keep working at it, you'll see improvement. If you don't see improvement, then perhaps your methods are incorrect and you should seek better methods. But keep in mind that some things takes years of hard work, and there may not always be a way to speed it up.

Just focus on improving things bit by bit and after a long period of time, when you look back, you'll see amazing accomplishments. Every journey starts with a single step and all that jazz.

---

"Is there a periodic element of lisp-y things?"

Kinda. Lisps do share some things in common, like S-expressions, macros/vaus, code-is-data-is-code... but the Lisp culture also deeply values individuality and giving programmers more power. So despite some overlap, you tend to see a lot of variance between Lisps, as people try out different things.

---

"Why exactly can't we make improvements again? May I?"

We can't make improvements because pg has been too busy. However, there is a fork of Arc called Anarki, which anybody can change:

https://github.com/arclanguage/anarki

There are also various other forks of Arc, such as Rainbow, Rainbow.js, Jarc, and Arc/Nu:

https://github.com/conanite/rainbow

https://github.com/rocketnia/rainbow-js

http://jarc.sourceforge.net/

https://github.com/Pauan/ar

---

"I believe there needs to be a search engine to help me answer that."

If you want to search for something on the Arc Forum, I've found the best way is to go to google.com, and then do this:

  site:arclanguage.org foo

"Why can't JS just be a Wart?"

Oh man I can go on and on about JS. The answer to your question is pretty long and detailed. If your question is, "why isn't JS better?", well... that's a history lesson that people smarter than me have already gone into:

https://brendaneich.com/2008/04/popularity/

http://www.jwz.org/blog/2010/10/every-day-i-learn-something-...

http://www.jwz.org/blog/2010/10/every-day-i-learn-something-...

For the record, they are working hard on fixing some problems with JS:

https://brendaneich.com/2012/10/harmony-of-dreams-come-true/

But things take time. Especially because they have to worry a lot about backwards compatibility.

Also, even though JS is worse than say, Arc, it is possible to write a compiler that takes some dialect of Lisp and compiles it to JavaScript... for an example of that, see my language Nulan:

http://pauan.github.io/nulan/doc/tutorial.html

https://github.com/Pauan/nulan

Are you talking about making a guide about guides, or a guide specifically to help people to understand Lisp? I'm sure either one is possible, but this particular community should have a much easier time with the Lisp guide than the general guide.

That actually sounds like a pretty good idea: a single consolidated guide to help people understand the Lisp way of doing things. Of course we've written plenty of stuff already (as have people not on the Arc forum), but it's scattered everywhere and isn't really coherent. Something like the "learn you a Haskell for great good" but for Lisp sounds nice. Is that what you're talking about?

---

"you can decide immediately(or within ~10min) if someone's cool."

Even if that's true, that isn't necessarily useful. "Coolness" is arbitrary and cultural. It shifts over time. It isn't necessarily tied to quality. And I think that people who seek coolness tend to produce lower quality stuff. After all, any time and energy spent being cool is time and energy spent not improving in non-cool (but useful) ways. Though I myself am guilty of sometimes doing things for the sake of reputation, I try not to do that.

---

"How exactly did you parse it into such a coherent roadmap so quickly?"

I'm just that kinda person: somebody who's quick to read into things. Unless it's rocketnia doing the talking, then I have a much harder time. :P

---

"Must I fork my own version of Arc to do it? Is there a simpler way?"

"Because I can't tell if `Pauan` is human or not, I'd like to define exactly how `Pauan` arrived at this answer in the community-managed fork of Arc. Is this possible? (yes no)."

If I understand you correctly, you're asking if we could please open-source Pauan (or a subsystem thereof) for the sake of future development and discussion. No. Please don't undermine the voices of people on this forum.

- You're asking an in-depth question about someone in the third person, when they're right here to explain.

- It seems to me you're discriminating on the basis of someone's involuntary implementation details, without any obvious and respectable reason.

- You're suggesting to "define exactly" something which may be an essential secret ingredient in someone's appearance of individuality. As far as I'm concerned, you might as well suggest we zap someone's brain or hound them with paparazzi.

Also, it's time that I leave the Arc Forum. You all are free to follow my projects on GitHub (https://github.com/Pauan) and can e-mail me at pcxunlimited@gmail.com

I had seen that blog post of yours. I also particularly noticed this tweet you retweeted, which aptly summarizes a common theme between your blog and your Arc Forum posts:

https://twitter.com/garrytan/status/341252234878795777

  Founders: What are you doing right now? Is that thing a 10X
  improvement or a 10% improvement? Always work on 10X. Every
  minute counts.

'Paul and Robert' don't come here anymore; we hang out here, but we can't make improvements. We could setup a new site, but the issues so far seem too minor to push us to that.

You seem to be focussed on questions of the form, "Why can't an A be a B?" I ask: Why should it? Different things enrich the world and provide opportunities for future cross-fertilization.

I think what math people obsess about is always reality. The fact that they are obsessing about it at all is a real phenomenon, and we can think about tracing it back to its most immediate cause. That immediate cause is likely to be a very math-like problem in need of a solution. The not-so-math-like problem which inspired that math-like problem may be an awfully long way from where we started searching, but it's still connected.

Some mathematicians (the pure mathematicians) may pursue math-like curiosities without much regard for where they're going. Still, their own intuition and sense of elegance will constrain their discoveries to forms that can come in handy later on. In this case, mathematics acts as a bridge that starts from today's human intuition and elegance and connects to tomorrow's newfound human problems.

Clearly you're looking for an efficient connection, not just any connection. I suspect the only way to find that is to keep yourself in a state of perpetually looking, even as you continue with what you're doing. Be your own JIT compiler--and yet, don't let a JIT compiler be all that you are.