Arc Forumnew | comments | leaders | submit | ivankirigin's commentslogin
3 points by ivankirigin 6137 days ago | link | parent | on: Two brief ideas

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 ivankirigin 6138 days ago | link | parent | on: Two brief ideas

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 6138 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 6138 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 6138 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 6138 days ago | link

Gahd, I can never remember that.

-----

1 point by greatness 6138 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 6138 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 6137 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") ... )

-----