Arc Forum | Two brief ideas

Arc Forum

	Two brief ideas
	4 points by ivankirigin 6117 days ago \| 14 comments
	1. Programs that can call libraries already written are much shorter than those that have to write them. For example, the arc challenge could just have easily been "going to the url /capture uses a webcam to capture an image and if recognized, sends the user to a secure area". Perhaps the webcam capture code and face recognition software would be shorter in Arc. But they don't exist. Yet. In that sense, there are "high level languages" and "high level frameworks". Ideally, you're using a high level language with many advanced frameworks available. 2. Are shorter programs always easier to read? If not, the implications for groups larger than 1 are pretty big. Those familiar with lisp (not me) would be good judges: how long would it take you to understand the code base for Hacker News?

8 points by pg 6117 days ago | link

1. I deliberately used only features all web app libs would already have.

2. My hypothesis is that shorter (in the codetree sense) programs are easier for the author to read, and in exploratory programming the author is the most important audience.

-----

4 points by kennytilton 6116 days ago | link

Regarding number two, after I started using syntax coloring editors for my Common Lisp I noticed that the blue stuff (the language keywords) was surprisingly scant. ie, Most of the text consisted of my own variables and operator names. This (I guess) is especially true of functional languages and maybe also because I never miss achance to hide boilerplate with macros. So in conclusion my fellow Archers, I think real world code you write will be as long as you want it to be. No one forces you to pick short names or use the chaining:thing.

-----

1 point by mdemare 6116 days ago | link

I know very few web frameworks which have Arc's style of implementing user actions, and for good reasons: either you've got a huge memory leak, or links have an expiry date. (I got a deadlink-error while clicking on reply...)

-----

3 points by ivankirigin 6116 days ago | link

I have a hypothesis about bloating memory: it will stop mattering soon. Solid-state non-volatile storage at RAM speeds on a fast bus will allow for terabytes of memory -- and increase with the unimpeded Moore's Law of storage. I know of at least one company, FusionIO, offering this as a product already.

If you can store all but the largest databases in memory, why not use a web framework that doesn't bother with a "real" DB like MySQL? But clearly, I'm talking about memory hungry systems generally, and not memory leaks.

-----

1 point by pg 6116 days ago | link

You can set an explicit expiration or have the links gced fifo. I used the latter in the example (and the reply form), but for something more critical (like YC funding applications) I'd add an explicit expiration. It's only one more token.

-----

1 point by ivankirigin 6117 days ago | link

1. It's a toy problem, I get it. But how much information is conveyed?

I suppose you could call any library from any language with enough leg work, but it is easier and shorter in the same language. Python talks to C very easily, and there is an IMMENSE number of C libraries. OpenCV is an excellent, open-source computer vision toolkit that already have python bindings. My point is that the programmers using a language will benefit greatly from a community of people building tools that can easily be used in that language.

2. At times, making things explicit is easier to read. After I finish my current project, I'll learn Arc and see. It's just really nice sometimes to say

  if aPythonDictionary.has_key("username"):
    ...

-----

4 points by EliAndrewC 6116 days ago | link

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:
        ...

-----

1 point by bayareaguy 6116 days ago | link

Even since this started to work, I still prefer some_dict.has_key("username") because then if an ordinary string accidently found its way into some_dict I'd get a runtime error instead of a silent logic bug.

-----

1 point by ivankirigin 6116 days ago | link

Yah, and I usually just try to grab it, with a default value. Both these options are fine:

  some_dict.get("username", "default")

  try:
    u = some_dict["username"]
  except KeyError:
    # long error case code if needed

-----

1 point by akkartik 6116 days ago | link

Gahd, I can never remember that.

-----

1 point by greatness 6116 days ago | link

Are you suggesting:

  (if (arctable "username") ... )

is somehow difficult to read? (arguable, this is an arctable and not a dictionary which is closer to an associated-list. If it were an associated-list you'd be able to do it as either:

  (if (assoc "username" arc-alist) ... )

  (if (alref arc-alist "username") ... )

I'd hardly call any of these difficult to understand; though perhaps assoc would make more sense if the list were the first parameter and the key the second like the alref works. i.e.

  (assoc list key)

rather than:

  (assoc key list)

Because at the minute alref and assoc are not conforming to the same standards, which make them rather awkward to use.

-----

1 point by ivankirigin 6116 days ago | link

I'm not suggesting anything about a language I don't know :)

But, the point about explicitness stands, as there is not something similar to "has_key" in the syntax in your examples.

-----

1 point by greatness 6116 days ago | link

True, but the returns are more useful (assuming has_key returns T if it has the key. I am unfamiliar with python I'm afraid).

If the current syntax is difficult to memorize, you could always write a simple function which abstracts it away into something you're more familiar with:

  (def haskey (ls key) (alref ls key))

Then you can use it:

  (if (haskey mylist "username") ... )

-----

3 points by chandler 6116 days ago | link

Regarding question two:

I've been pleasantly surprised by how easy it is to read the arc code; and this is without ever starting the interpreter (the 350/372 lag is a killer for me, as I have quite a few apps written for 372). As a bit of background, I'm pretty familiar with scheme itself, and I tend to use mzscheme (both for its wealth of libraries and cross-platform stability). I've also written a fair share of elisp over the years, and can dork my way through other peoples CL code.

At a superficial level, I like the combination of lisp-1 and t/nil; if it manages to avoid scheme's overboard strictness, all the better ( (cdr ()) throws an exception, rather than returning (); substrings, indexing, etc all need to be exact, or an error is thrown). I also really like the if-over-cond replacement.

One thing I've found is that the terseness and paren reduction make it easy to use Arc (the language) to sketch out functions in (say) html edit boxes and paper; I definitely like the "feel" of the written code. As an example, yesterday I found myself sketching out a clojure-style generic function interface, to describe (e.g.) the Arc + operater within Arc itself:

  ;; defg(eneric), this is a "switching" function:
  (defg + args
    (if (no args)                  'zero
        (all 'num (map type args)) 'nums
                                    (type:car args)))

  ;; defa(dd-method), this defines specialized functions:
  (defa + 'zero () 0)
  (defa + 'nums args (apply num-plus args))
  (defa + 'table args (apply merge-tables args))
  (defa + 'default args (apply concat (map str args)))

The Arc language itself seems to lend itself to impromptu sketches like the above, without having to necessarily fire up emacs for paren-counting and fuzzy-complete.

-----