Arc Forumnew | comments | leaders | submitlogin
8 points by pg 6117 days ago | link | parent

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 6117 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 6117 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")
or

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

-----

1 point by akkartik 6117 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) ... )
or

  (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") ... )

-----