Arc Forumnew | comments | leaders | submit | jonnytran's commentslogin
2 points by jonnytran 5528 days ago | link | parent | on: Call graph for news.arc [pdf]

Thank you for making this reduced graph. I'm all for visualization, but the full call graph seemed to show nothing except how useless a full call graph is.

-----

1 point by chris_l 5528 days ago | link

Yeah, that dawned on me after posting it... :)

-----

1 point by jonnytran 5528 days ago | link | parent | on: Macro Patterns

Good point. "Around" is a concept used a lot in aspect-oriented programming. But I suspect that even fewer people are familiar with AOP or "around" than with macros or resource management.

-----

4 points by jonnytran 5564 days ago | link | parent | on: Ask Arc: does code have to be text?

andreyf, I completely agree with you. How people write code in a language is -- from a user experience perspective -- part of the language in a very real sense. I've written about this before. http://plpatterns.com/post/37655849/1-2-n

Using symbols like ¬ and λ is a start. Paredit is even better. But I think programmers are stuck in the mindset that source code has to come from an ASCII text file. If you truly get the idea that code is just data, there's no reason why your "IDE" shouldn't be integrated with the language and provide a higher-level representation of the data you're editing. Also, depending on the task, you may want to view different aspects of your code. You can think of your source as the model in an MVC where multiple views and editing styles for the same data-structure are possible.

Once you view your code simply as data, all sorts of possibilities open up. The so-called Source Code In Database site has tons of examples of these features. http://mindprod.com/project/scid.html

One very big inspiration for me has been Subtext. You just have to watch the demo; I can't explain it. http://subtextual.org/subtext2.html

-----

1 point by jonnytran 5564 days ago | link | parent | on: Ask Arc: does code have to be text?

No, I think what people are getting at is... why does program source have to be represented by only ASCII text? After all, if code is data, an IDE is just a data editor, where that data happens to be code.

I think it has been shown many times throughout history that notation matters. In fact, the entire concept of Arc is based on this principle. Otherwise, Common Lisp would be suitable.

-----

1 point by justsomeone 5558 days ago | link

Why does it have to be ASCII? No reason, The simplest answer may just be that the language writer feels that adding UTF-8, or UTF-16, support would be a waste of their time, or is below them. As for programming IN the language, it becomes a matter of what is easy for the programmer to type. In a way, this whole thing is a matter of deciding what is the lowest common denominator that one wants to support.

-----

5 points by jonnytran 5710 days ago | link | parent | on: What can't LISP do?

Types. Specifically, things like the "prime type" in Qi http://programmingkungfuqi.blogspot.com/2006/04/qi-and-magic...

Sure, Qi was implemented in CL, but that doesn't mean Lisp isn't blub compared to Qi. Think Greenspun's Tenth Rule, but instead of C and Lisp, Lisp and Qi respectively.

(Too bad I'm posting 11 days late... I would have liked to have heard a rebuttal.)

-----

4 points by jonnytran 5886 days ago | link | parent | on: Binary Search Trees in Arc

You know... there's another amazing new Lisp that is getting better by the day and flying under the radar.

Clojure version of BSTs: http://paste.lisp.org/display/55915

"The Clojure version is shorter, is in an enumerable namespace, and has a lazy bst/seq function that interoperates with the rest of Clojure."

I didn't do the node count myself, but it is fewer lines.

-----

5 points by pg 5886 days ago | link

The Clojure version is shorter

It doesn't look to me like it's obviously shorter. I haven't tried counting nodes in both either, but in nonwhitespace chars, which should be a reasonable approximation of nodes in two languages so similar, the Arc version is slightly shorter: 755 chars vs 774.

-----