EliAndrewC


11 points by EliAndrewC over 2 years ago | link | top
cached 6 days ago
I like that "subseq" was renamed to "cut" and that it now takes negative indices.

However, I wish we could say (x 1 -1) instead of (cut x 1 -1). And since x.0.0 expands to (x 0 0) then that would let us say x.1.-1 which is what languages such as Python and Ruby already allow.

I hope that this is coming; I image that Arc's creators don't want to introduce too many changes all at once, so maybe they'll add this after they see how the x.y syntax works out.


10 points by EliAndrewC over 2 years ago | link
cached 23 days ago

7 points by EliAndrewC about 1 year ago | link | top
cached 11 days ago
As with most criticisms of Arc, these complaints are mostly treating Arc as if it was something other than a VERY early release of a language that's still under development. Both the syntax and semantics of Arc are expected to change as new features are considered/added/rejected.

However, it's easy to see why the author would think of Arc as something more than it is, since it was so hyped by so many people online and since it's been under development for so long. Plus, given the length of time that it's been out, most of us expected more progress by now.

Of course, this doesn't excuse the article's shortcomings, but I think there are a couple of valid points buried amidst the specious ones, so I'll respond to them all one at a time:

1. Criticizing Arc for a lack of features is pointless. It's an early release of the language, and there's no reason why more features can't be added later.

2. Paul Graham wrote an entire article on "Why Arc is not especially object-oriented" which links to several other articles by both himself and others discussing the pros and cons of OOP. The lack of namespaces is a valid criticism at the moment, especially since a lack of a namespace mechanism makes it more difficult for people to write and share Arc libraries.

3. Arc hasn't had enough releases for me to care about having access to PG's version control repository.

4. I'm not sold on Test-Driven-Design for software which is expected to radically change numerous times before becoming stable. I generally write tests after I've somewhat stabilized a codebase, and only then do I make any effort to keep my tests up to date. This is a nuanced issue and I respect the TDD arguments, but this certainly doesn't turn me off to such early versions of Arc.

5. This is another complaint about a missing feature. I agree that this feature should exist, but things like this don't sink the language.

6. Unusual version numbering is a deadly sin?

7. PG's stated outlook is that the more common an operation, the less intuitive its name can be. I don't find "no" less intuitive than "not", although I think he has a point about it being silly to abbreviate "print" to "pr" just to save 3 characters.

8. Line numbers is errors is my personal #1 desired feature for Arc, and hopefully this feature will be added soon.

Interestingly, his conclusion is entirely correct: "In short, if you were hoping for a usable and modern dialect of Lisp, then Arc is not the answer, and won't be without a lot of work." Arc will indeed take a lot of work to become modern and usable for most tasks, and I'm disappointed that PG hasn't put out a new release in over 9 months, but I hope that he'll eventually find time to take a more active role in Arc's development.


7 points by EliAndrewC over 2 years ago | link
cached 3 days ago

6 points by EliAndrewC over 2 years ago | link | top
cached 11 days ago
If I were using Python and CherryPy then I'd say something like:

    class Root:
        def form(self):
          return render("form.html")
        
        def link(self, foo):
          cherrypy.session["foo"] = foo
          return render("link.html")
        
        def message(self):
          data = {"foo": cherrypy.session["foo"]}
          return render("message.html", data)
Obviously I'd need to write three templates for the three pages.

This is a neat example, since it shows how terse Arc can be. I'd be interested to see how well this scales to a large site. For example, I normally like keeping my HTML and Python code separate, so that when I have thousands of lines of each, it's easier to sift through it all and find what I'm looking for. However, if my code were consistently this much shorter, then that wouldn't be as necessary.


5 points by EliAndrewC over 2 years ago | link
cached 3 days ago

4 points by EliAndrewC about 1 year ago | link | top
cached 12 days ago
I'd love for PG to spent more time per month on Arc, since to me personally it's probably the most interesting thing he does. I enjoy his essays and think YCombinator has produced some great startups which I sometimes use, but Arc is more interesting to me than either of those things.

With that being said, I knew all along that Arc is an experiment in trying to make a 100 year language, not something that was intended to help me deploy commercial applications as soon as possible. So I've played around with Arc a little and been happy to have the experience.

I'll play around with it more as it gets more advanced and gets more libraries and such. Until then, I'll remain a happy Python programmer and look forward to whatever PG and the rest of the Arc community slowly end up evolving towards.


4 points by EliAndrewC over 2 years ago | link | parent | top
cached 10 days ago
This is a little nit-picky, but the canonical way of checking for the existence of a key in a Python dictionary is

    if "username" in some_dict:
        ...

4 points by EliAndrewC over 2 years ago | link | parent | top
cached 6 days ago
While I agree that this shouldn't be abused, I'm not actually proposing this syntax; Arc already lets you say cut.x.1.3 as an alternative to (cut x 1 3).

I suspect that the only time I'd ever want to chain together several different things with . is when I'm doing list slices. Which is why I'd like the x.1.3 syntax to work, since in my opinion cut.x.1.3 is a lot uglier, perhaps enough that I'd rather not do it.


3 points by EliAndrewC over 2 years ago | link | parent | top
cached 6 days ago
. and , are not very visually distinctive. It'd be like having (x 0) and (x O) both be commonly used.