I personally think Arc is a fantastic way to learn Lisp:
#1 Arc is minimal. This makes it a lot easier to learn, because it has so few axioms.
#2 Arc heavily emphasizes recursion, and recursion is fundamental to computing in general. So it's important to understand recursion.
#4 Arc's macros are simple enough that it's easy to fully understand how they work.
Arc is basically a stripped down minimal Scheme with Common Lisp unhygienic macros. It shouldn't be hard to convert the Scheme code in SICP into Arc.
As to whether Arc would be a good first programming language in general... I don't know. I suspect that if you take two programmers, one learns a functional language first, and the other learns an imperative language first, that they would have radically different mindsets.
Because of the recent surge of parallelism, functional languages have a significant advantage, because immutability and purity give both increased correctness and performance compared to mutability. So I don't think it's a bad idea to learn a more functional language like Arc first.
I tend to learn best by creating things, and seeing as I already know HTML and CSS, a language that would allow me to dive right in by creating web apps would be great.
There's also the fact that if someone asked me why I chose Arc over any other Lisp, I wouldn't really know what to say. I like the sound of your philosophy, but at the moment I don't really have the knowledge to understand how Arc is different from other Lisps (other than by being very minimal).
Maybe once I've got some practical experience and a good grasp of the basic concepts behind Lisp and macros, I might start learning Arc, and be able to appreciate it for what it is.
You're right, Clojure is not a bad choice either, in my opinion. It's even more heavily functional than Arc, so it's an excellent way to ease into functional programming. There are certain things I really dislike about Clojure, but on the other hand there are some things I absolutely love about it. I think it gets a lot of things right.
I think Arc is a better language for learning Lisp, but you are correct that Clojure would be better for writing actual applications that do things. Solving actual problems with actual applications can give you a lot of motivation, and motivation is important when learning anything.
The reason I use arc: I can't seem to stop. Before arc I tried to learn common lisp and scheme, but they required me to be persistent, and I kept falling off the wagon. With arc, I didn't need to be persistent. That was the concrete, tangible benefit of minimalism for me: the entire experience seemed to cater to me. There were fewer things that were like, "this may seem overly complex, but there's good reason for it, you'll understand when you gain experience." That argument is almost always a rationalization for accidental complexity (https://en.wikipedia.org/wiki/Accidental_complexity), in my experience.
Eventually I grew more fluent with common lisp and racket as well. You're right that they're more grown-up, and sometimes one needs something grown-up and industrial-strength. But arc was the gateway drug, and I can't seem to outgrow it.
I said this in another thread: "What really got me into arc was writing programs in one split window with the friggin compiler for my language in the other." (http://arclanguage.org/item?id=18954) That's really valuable, because to get really good at programming requires breaking out of every box other programmers create for you. Yes it's more immediately valuable to learn to use a few platforms or libraries. But understanding how they work, the design decisions and tradeoffs that are common to all platforms, that gives you superpowers in the long term.
In fairness, all my experiences predate clojure, which may well have all the same benefits. Several people have switched to it from arc in the past. I'd love to hear about your experiences after you try it out. I haven't much experience with it, though I've heard that the boxes it creates are harder to break out of (https://plus.google.com/110981030061712822816/posts/KaSKeg4v...)
I'm curious what docs you looked at that seemed to require familiarity with lisp. Feedback most appreciated.
These docs (https://arclanguage.github.io/ref/) are the ones I was talking about. I haven't read much, but there's no mention of parentheses anywhere. Also, there are symbols in circles to the left of concepts, e.g. F ! ? M, but no explanation of what they mean.
Generally, the docs seem rather terse to me; there's a lot of stuff that only makes sense now, after reading (http://aphyr.com/posts/301). "Clojure from the ground up" does start slowly, but by the end of Chapter 4, I really understood the idea of recursion and representing code as a tree, something that I don't think I could have got from the Arc docs.
One big difference is that Arc is very minimal, while Common Lisp has lots of libraries and a large standard library. In Arc, you'll end up writing a lot of stuff yourself. But because Arc tends to be more concise than Common Lisp, this can be fun rather than frustrating.
In large part because Arc is so minimal, it only really has two compound data structures: cons cells and mutable key/value dictionaries.
With a bit of effort, it's possible to use Racket libraries and Racket data structures. It's easier to do this in Arc/Nu and Anarki, compared to Arc 3.1.
Arc also does not have a module system, so name collisions are a very real possibility. If your code base is small this isn't a problem, but it does make it a bit trickier to use libraries written by other people.
Another difference is that Arc takes after Scheme, so it has tail-call optimization and full first-class continuations. Recursion is quite common.
Like Scheme, Arc has a single namespace for both functions and variables, unlike Common Lisp which has separate namespaces.
Arc intentionally makes no promises of backwards-compatibility: new versions of Arc might be radically different and completely break your code. Common Lisp, on the other hand, tends to be very stable, and cares a lot about backwards-compat.
Essentially, you can think of Arc as being very similar to Scheme, but much more minimal and concise, and with Common Lisp style unhygienic macros.
"Immutable-js Map Transient" means an Immutable-js Map that uses "withMutations" for extra speed.
I also want to test out ClojureScript's data structures, but I haven't gotten around to it yet.
In addition, notice that according to those benchmark numbers, you can create 20 empty AVL trees, then insert 100 keys into each AVL tree (for a total of 2,000 insert operations)... once per millisecond. In this case, worrying about the performance cost of immutability is a huge premature optimization.
(I'm not directing this at anybody in particular, in fact I am the kind of person that does premature optimization, so these numbers help with my own personal fears about performance.)
I'll test the performance of unsorted arrays soon and post the results here.
How disappointing. Mori (which uses ClojureScript's data structures) was either the same as Immutable-js, or significantly worse. In the end, AVL trees win by a large margin for small to medium dictionaries, while Immutable-js performs better for large (> 100 keys) dictionaries.
Get/insert/remove 1 key:
Immutable AVL Tree x 37,909,434 ops/sec ±0.37% (101 runs sampled)
Immutable-js Map x 19,492,874 ops/sec ±0.15% (101 runs sampled)
Mori Hash Map x 2,306,565 ops/sec ±0.74% (96 runs sampled)
Mori Sorted Map x 13,424,409 ops/sec ±0.51% (97 runs sampled)
Immutable AVL Tree x 6,257,569 ops/sec ±0.43% (99 runs sampled)
Immutable-js Map x 2,111,085 ops/sec ±1.07% (91 runs sampled)
Mori Hash Map x 1,553,193 ops/sec ±0.77% (93 runs sampled)
Mori Sorted Map x 3,785,671 ops/sec ±0.43% (96 runs sampled)
Immutable AVL Tree x 3,426,260 ops/sec ±1.38% (97 runs sampled)
Immutable-js Map x 1,415,893 ops/sec ±0.41% (96 runs sampled)
Mori Hash Map x 699,113 ops/sec ±0.40% (98 runs sampled)
Mori Sorted Map x 1,550,116 ops/sec ±1.54% (100 runs sampled)
Get/insert/remove 10 keys:
Immutable AVL Tree x 21,954,005 ops/sec ±0.81% (98 runs sampled)
Immutable-js Map x 17,236,706 ops/sec ±1.02% (99 runs sampled)
Mori Hash Map x 2,474,120 ops/sec ±0.77% (95 runs sampled)
Mori Sorted Map x 911,264 ops/sec ±0.41% (100 runs sampled)
Immutable AVL Tree x 399,700 ops/sec ±0.15% (97 runs sampled)
Immutable-js Map x 218,274 ops/sec ±0.63% (98 runs sampled)
Mori Hash Map x 150,978 ops/sec ±0.74% (96 runs sampled)
Mori Sorted Map x 73,598 ops/sec ±0.68% (98 runs sampled)
Immutable AVL Tree x 135,120 ops/sec ±0.76% (99 runs sampled)
Immutable-js Map x 100,893 ops/sec ±0.20% (97 runs sampled)
Mori Hash Map x 74,750 ops/sec ±10.95% (96 runs sampled)
Mori Sorted Map x 42,696 ops/sec ±0.45% (99 runs sampled)
Get/insert/remove 100 keys:
Immutable AVL Tree x 6,467,149 ops/sec ±0.38% (93 runs sampled)
Immutable-js Map x 14,233,214 ops/sec ±1.05% (96 runs sampled)
Mori Hash Map x 2,513,928 ops/sec ±1.24% (98 runs sampled)
Mori Sorted Map x 384,132 ops/sec ±0.53% (98 runs sampled)
Immutable AVL Tree x 19,760 ops/sec ±0.52% (100 runs sampled)
Immutable-js Map x 12,798 ops/sec ±0.26% (100 runs sampled)
Mori Hash Map x 10,619 ops/sec ±2.59% (93 runs sampled)
Mori Sorted Map x 3,078 ops/sec ±1.49% (98 runs sampled)
Immutable AVL Tree x 6,420 ops/sec ±0.51% (101 runs sampled)
Immutable-js Map x 6,204 ops/sec ±0.20% (99 runs sampled)
Mori Hash Map x 5,394 ops/sec ±0.81% (93 runs sampled)
Mori Sorted Map x 1,757 ops/sec ±0.51% (100 runs sampled)
So, today I learned that cons cells, despite having O(n) behavior, are really fast. They outperform mutable JS arrays at random inserts!
It's only once you get up to ~100 elements that AVL trees start to outperform cons cells. A good optimization would be to use cons cells for small lists, and then automatically switch to AVL trees once the list grows to be a certain size.
It includes algorithms for getting/inserting/removing an element at a particular index (in the case of arrays), and code for getting/inserting/removing an element in sorted order (for dictionaries and sets).
* : Adding in sorted arrays shouldn't be hard, but I haven't had any need for them yet.
It seems the problem with Anarki is that Arc's lists are terminated with the symbol 'nil rather than Racket's null. So you have to convert from Arc lists to Racket lists (and back again). Here is the relevant code:
"There are lots of words in the wiki that I don't understand."
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.
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:
"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:
"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:
The best way for me to use the update box is to rewrite what I'm saying more clearly. Now I understand.
I just vomited every exciting idea I could. How exactly did you parse it into such a coherent roadmap so quickly?
Most people think of the map of software ideas as a flat map instead of a cube or sphere-like structure. What is the smallest possible technical / distributed guide to help me navigate this map a little more quickly?
"They ought to have a gentler guide to show them that. It (might be) automatable, but at first it ought to be distributed. You folk obviously have lots of experiences doing things. Could this guide be possible?"
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?"
Yes. And as I mentioned, people have already done so. I personally recommend Arc/Nu, though Anarki should work fine too. Also, since the Arc source code is provided, you can of course modify your local copy as well.
I'd like to build myself the smallest possible technical guide. Most people think about software as a map. It's really a sphere. They ought to have a gentler guide to show them that. It (might be) automatable, but at first it ought to be distributed. You folk obviously have lots of experiences doing things. Could this guide be possible?
It seems like the best way for me to use this thread is just as a place to ask myself better questions. You folk are incredibly effective guides as well though. I would love it if you chimed in whenever you liked :-)
I'm sorry to do this since you edited your post, but here's what your post looked like when I first saw it. I cast a downvote, and I want to clarify why I did that.
"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.
If you're conducting some kind of experiment in the design of cultural conventions, I (for one) don't yet understand and trust you well enough to play along. Would you mind introducing yourself in a more boring way for a while?
gladly. see hugomelo.com. Know what, I'll paste it here for you
About :: Archives :: Subscribe
How To Become An Apprentice Developer
As an experiment in self-education, I deferred admission from university to teach myself how to code. I moved to San Francisco and took a nine week coding bootcamp. After that, I interviewed for three weeks and got four job offers and a contract offer on the forth week. I took a position as Carbon Five’s first apprentice. It’s been an amazing ride and the hardest thing I’ve ever done. Here’s what I learned.
Start With Hustle
App Academy had a full shower, a couch, and a Whole Foods nearby. So I lived at the office to get my burn rate down to about $20 / day for those two months. After App Academy, I crashed in the living room of a garage converted into two rooms at a Palo Alto hacker house. During the job hunt, I had ecstatic times where people were competing over me, and I got that hit of validation. I also had disheartening days where I didn’t know where I was going to live, doubting myself, and being universally rejected.
These experiences forced me to get clear on my motivations. On your journey, you must be able to take action and adapt, to do whatever it takes. Most people are unwilling to do this. That’s what’ll make you stand out from every other resume when you approach. This kind of hustle is the foundation.
On the last day of App Academy, demo day, a bunch of companies came in to speed-date interview us. They were all nice, and a few were promising, but I didn’t get any leads out of it. My interviews came from networking: strategically meeting the right people.
I started off with going to interesting meet ups. I wanted to surround myself with smart, cool engineers and entrepreneurs with the power to make hiring decisions. With this in mind, there are lots of meet ups that were a waste of my time. ‘Networking’ events empirically sucked. Events where I’m volunteering and teaching someone else, or someone’s teaching me something were really awesome and useful.
At interesting meet ups, I focused on connecting with cool people. I started off trying to sell myself to everyone. But approaching people in this value-sucking way was awkward and ineffective for me. Connecting with cool people was much more natural.
Most smart engineers and entrepreneurs that I met were disarmingly humble. I couldn’t pick them out of a crowd at first glance because they weren’t talking about themselves. The key to meeting interesting people was to become interested in others. This made it easy to separate people who were building cool stuff from people who were bored and boring.
So you’ve gone to cool meet ups, met cool people, you’ve got a ton of business cards and lukewarm contacts.
Creepy ‘entrepreneurs’, boring monotone developers, and independent recruiting companies were the biggest waste of my time. Avoid them like zombies. Strategically, relentlessly follow up with the right people.
Give yourself a personal advantage by focusing on going from a high noise environment to a low noise environment. Think of it like a funnel. There’s a lot of noise in a cold email through a jobs page, less noise at a meet up, less noise at a private party, less noise through a warm introduction, less noise through a phone call, and undivided attention through grabbing coffee.
I much rather preferred that I meet someone in person. I don’t have any credentials, so I don’t look good on paper. Pushed for in-person, informal chats over coffee over phone screens. Push for building test-apps over algorithm brain teasers.
Master Interview Strategies
After in-person coding interviews, I asked people what they were looking for. Here’s what they said:
My ability to communicate concisely.
How well I can break down one big problem into many small, well-organized problems.
My ability to code.
How fun it is to teach me.
To these ends, pairing was the most valuable thing I did at App Academy. It taught me how to communicate clearly, how to share a keyboard, and how to be wrong and learn. The after-hour talks that Ned gave on algorithms turned out to be most of the CS theory I’d need to solve interview problems. I took some notes here.
Before I started using these, I wasted a lot of time early on with companies that either didn’t want to or weren’t able to hire junior developers. These questions give me most of what I needed to know.
Early stage startups usually don’t have the resources to train a junior developer. I talked to a lot of startups where: “Hugo, you’re a kick-ass guy. But our lead dev doesn’t have enough time to divert the focus to mentor you.” I got this over and over again from really early startups.
Large companies were inundated with candidates, and I was passed along to anonymous HR recruiters that expected credentials, and I was filtered out.
Large companies and two man startups were a waste of my time. I got a ton of rejections early on because I was talking to the wrong people. Then I changed focus to companies that were both able and willing to hire on growth. The middle turned out to be my sweet spot.
Sell Yourself On Growth
There are three ways to sell yourself: 1. Input. What degrees and accolades do you have? 2. Output. How much can you produce right now? 3. Growth. How fast do you learn?
I had a special situation. I just got out of high school with no previous work experience and no credentials. But, I have the advantage: I started coding in June 2012 with the intent of becoming a professional. As a junior developer, my trajectory was more impressive than my skill set.
I sold myself on growth - my ability to learn fast.
I focused on my CV, and made my github my resume. I ignored most requirements on job pages. If I could solve the problems that position was aiming for, I applied.
I experimented with these things. I didn’t know how people would react. It turned out that nobody cared. All of my offers came from either unposted jobs or jobs I wasn’t ‘qualified’ for on paper. When I tried to compete on input, I lost. When I tried competing on output, I got more attention, but I still lost. The people that made me offers said that my trajectory and enthusiasm were what won them over.
Focus On Learning
For a hungry junior developer, your ability to learn fast and efficiently is your most valuable asset. If you can meet your basic needs, learning is a more valuable asset than a marginally higher salary.
Choose a place where you’re going to be surrounded by developers better than you that you can learn from.
If you can do this, you’ll absorb a tremendous amount in a short amount of time. This will make you exponentially more valuable as a developer.
That’s what it means to become an apprentice.
Yeah I saw those and remember thinking they were nothing like his writings here.
Last night he started email-bombing me and others all sorts of irrelevant statements about google support, venture capital and whatnot. From midnight to 3am yesterday I received 27 emails from him. (I haven't read them all.)
Founders: What are you doing right now? Is that thing a 10X
improvement or a 10% improvement? Always work on 10X. Every
This kind of mindset can be encouraging, but it seems like it's causing you negative stress. If so, I hope you can set aside some extra time for other things you like to do, even if they feel unproductive. I don't know if those things will be remotely on-topic for Arc Forum, but feel free to bring them up if they are. :)
You're completely right. I was wrong (and sleepy). This was distress, not positive straining. I did get carried away. I've set aside lots of time for Yoga, climbing, riding my (Xootr)scooter, and Jiu Jitsu. But man am I still excited :)
Also: Wore google glass at Fluent Conf. Coolest thing I've seen so far methinks.