Arc Forumnew | comments | leaders | submit | mattjones's commentslogin
3 points by mattjones 4382 days ago | link | parent | on: Arc2.tar

This is really great stuff. Although I haven't done any serious Arc hacking yet, it's already had a big impact on how I code in Ruby. news.arc will be a great source of ideas.

BTW, does anyone have any deployments planned? Does it make sense to deploy production sites using news.arc, or is keeping up with Arc's evolution at this stage too much of a challenge?

I imagine it would be OK if you don't need to keep up with changes.


5 points by cooldude127 4382 days ago | link

well considering the real live sites and hacker news are deployed with news.arc, i would say you can deploy a real live site with it.


3 points by mattjones 4382 days ago | link

It's more a question of the stability of the language specification. I don't doubt the code is solid enough for production sites; it's just that keeping up with Arc's evolution might be difficult. But as I pointed out, you might not need to do that. (I edited the original comment to be more clear.)


10 points by mattjones 4388 days ago | link | parent | on: Templating language or MVC-style arc?

It depends what you mean by templating language. Arc already provides a means to create different reusable layouts and wrap output in them. The HTML-generating macros act a lot like templates. You can see how they work in the blog example that comes with Arc.

I actually much prefer Arc's method. Templates of the traditional variety are just so clumsy. It's hard to build abstractions using them; it's hard to document what you're doing with them (what local variables does this partial template require?); they end up being scattered around in a gazillion files the names and locations of which are hard to remember; and the coupling among templates and various other parts of the framework makes it really hard to test them in a REPL.

In Arc, just use functions. You'll have better abstractions, better testability, and better organization. A function that generates one line of HTML will just be a function in a library of functions rather than a tiny template in its own file.


4 points by tel 4388 days ago | link

Of course, that means that any designer has to be fluent in Arc's libraries as well.

Not to suggest that Arc's method is anything short of perfect for what Arc does, but a big benefit of MVC is how separation of logic and presentation reflects separation in personnel.


4 points by gnaritas 4387 days ago | link

The seperation of logic and presentation doesn't belong between code and HTML, it belongs between HTML and CSS. HTML is best controlled and generated programatically. Arc does it right, Rails does it wrong.


4 points by KirinDave 4387 days ago | link

I'm not sure what your professional experience making websites is, but mine has shown me time and time again that making good looking sites is an iterative process full of workarounds for real-world considerations.

The method you're suggesting would make it excruciating to converge on a good design with any real designer. Look at the markup any good looking and well-implemented web page (especially one with dynamic content), and you'll see a huge amount of extra tag work to accommodate the real world of cross-and-backwards-compatibility between browsers, CSS limitations, browser quirks, and other concerns that people making professional sites require.

If every one of these changes and workarounds required changes to the code, which would require my time instead of the designer's time?

The Rails way is just copying a method that nearly every web toolkit uses, and they use it for a reason. Arc's way may be cleaner, but without a templating language it will be at a disadvantage.


3 points by vrk 4387 days ago | link

I agree with both points of view!

- If you get the layout, including both how it should look and how things should work, from an external source, or if there is substantial external input, use templates. It will save time and headache.

- If you are just about the only one responsible for the layout but support skins (for lack of a better word; the CSS part), use the HTML tag functions and macros embedded in Arc.

Since Arc is at this point targeted for exploratory programming, the former is an unlikely case.

What I would like to see, though, is a templating engine akin to HTML::Template [1] in Perl 5. It has the minimum of control structures and extra syntax on top of standard HTML, just enough to make it possible to use the template for dynamic content. All templating frameworks suffer from the same fault, though: they define a new but severely restricted embedded language that's mixed in an unpleasant way with the HTML source. The language embedded in Arc is a much cleaner way to do things.



2 points by tel 4387 days ago | link


Complex designed websites are pretty much impossible using Arc's current library. Well, unless you're a programmer/designer with a high pain threshold.

When Arc is no longer classified by whatever greek letter comes before alpha, it might be worth investing into a nice way to separate out some MVC/MTV/VH1/&c.


5 points by mattjones 4389 days ago | link | parent | on: Automatic .arc reloading in background

This is actually a really useful feature. The Ramaze Ruby framework does this by default and I like it a lot.

One thing that makes it even more convenient is automatically detecting what files to reload. Ramaze does it by using Ruby's $LOADED_FEATURES and $LOAD_PATH variables. You can get the same conveniece with Arc with a simple modification to arc.arc:

    (= loaded-files* nil)  ; added
    (def load (file)
      (w/infile f file
        (whilet e (read f)
          (eval e)))
      (= loaded-files* (adjoin file loaded-files*)))  ; added
Now you can just use loaded-files* in your reload-check function.


3 points by byronsalty 4386 days ago | link

Nice. I was trying to think of an easy way to do this.

In order to not have to muck with the internals of load itself I wonder if you could wrap the saving path name functionality but then call the original load. Maybe this would be some new synatx / ability to add to the language? Of course this is just aspects which I thought Lisp could do so - I'm probably missing something.


1 point by cooldude127 4386 days ago | link

that is very cool.


5 points by mattjones 4392 days ago | link | parent | on: Problems with min

You would do

    (apply min (map abs '(-1 -2)))


3 points by vrk 4392 days ago | link

Thank you. Just shows how little I have really programmed in Lisp...


2 points by mattjones 4392 days ago | link | parent | on: Traversal

What about calling the macro w/trav and the rfn trav:

   (def bst-elts (b)
    (accum a (w/trav b [trav _!l] [a _!d] [trav _!r])))
or some other such convention where the macro name predicts the name of the recursive function?


3 points by mattjones 4392 days ago | link | parent | on: Traversal

I think this is a good abstraction. Brevity is important since the amount of logic being abstracted away isn't very much, and I think this achieves it.

You could do the same thing using just one lambda:

    (def bst-elts (b)
      (accum a (trav b (fn (x)
                           (self x!l)
                           (a x!d)
                           (self x!r)))))
That works fine and in some situations (with more complicated logic) it might be better. But the shorter version is compelling to me because brevity is so important in this case.


3 points by mattjones 4394 days ago | link | parent | on: New version

What if x.y!z expanded to ((x y) z)? Then if x were '(1 2 (3 4) 5), x.2!1 would give you 4. If (x 1 3) did work like cut, then you could do x.1.3!1!1, which would also give 4 in this case.


5 points by mattjones 4395 days ago | link | parent | on: New version

The . and ! syntax is really handy.

I noticed chaining doesn't work for .:

    arc> (= l '(1 2 (3 4) 5))
    (1 2 (3 4) 5)
    arc> l.2
    (3 4)
    arc> l.2.1
    (3 4)
rather than 4. Another thought ... could ranges be expressed a la Ruby?

    arc> (= l '(1 2 3 4 5))
    (1 2 3 4 5)
    arc> l.1..4
    (2 3 4 5)


5 points by sjs 4394 days ago | link

Multiple dots pass multiple params to the initial function. To chain you have to group w/ parens.

  arc> (= l '(1 2 (3 4) 5))
  (1 2 (3 4) 5)
  arc> l.2.1
  (3 4)
  arc> (l.2 1)
That 2nd last one translates to (l 2 1), which as you found acts like (l 2).


3 points by mattjones 4394 days ago | link

Yep, thanks. It would be cool if there were an abbreviation for that, since it's fairly common. Eg l.2%1 (% randomly chosen) => ((l 2) 1). Some may say that goes too far toward a parentheses alternative for all sorts of things, but on the other hand data structure access is one of the clumsier parts of Lisp.

The present semantics of . make sense though.


2 points by andreyf 4394 days ago | link

Maybe 'l' is not the best letter for that variable?


Seconded. Reading the source code is a lot of fun. It's well organized and really makes the case for Arc's approach to HTML. I know I'm a convert; having stuff in so many separate files, MVC style, feels like sludge compared to this. Even if you do have to start breaking things into separate files as the app gets more complex, being able to start out like this is a serious gain.


1 point by mattjones 4401 days ago | link | parent | on: Arc date function error?

Thanks. I looked manually for a post on this issue but didn't find it. It's easy enough for me to just fix my copy of the function for now.