Arc Forumnew | comments | leaders | submitlogin
Why we should build a seaside/rails/merb/django/whatever inspired framework.
3 points by eduardo-bellani 5872 days ago | 10 comments
Hey there. I think the LISP world would benefit more from a framework that is simple, easily deployable and suitable for RAD than from a new dialect (but I applaud ARC's concept and objectives, they are truly wonderful). But I'm thinking on this from a perspective of adoption and perception of the LISP world from the outside (I'm a ruby programmer that usually works on rails). I do think that the LISP community fails to see the complexity that derives from their choice of configuration instead of convention. It is great to have all this power and all, but there should be a gentler approach to the language, and a good way would be a framework that would "just work", and would provide an application without much hassle. From what I know, there are 2 main web development frameworks in LISP http://common-lisp.net/project/cl-weblocks/ http://common-lisp.net/project/ucw/ Both fall really short on this list: http://blog.lostlake.org/index.php?/archives/16-Web-Framework-Manifesto.html What do you guys think?


2 points by cchooper 5872 days ago | link

Although current Lisp frameworks leave a lot to be desired, I'm not sure copying the other frameworks is a good idea either. They all seem to have serious flaws, and despite trying to make things easy, they are all seriously overcomplicated.

As for 'convention over configuration', I think this is a bit of a fraud. Rails simply turns the file system into a configuration file and provides scripts for modifying it (e.g. scripts to create a new project, add a model, add a controller etc.) How is this any different to creating a configuration file to hold the information and then providing scripts to write it for you? The real question should be: why do we need all this complication in the first place? With Arc you can create a simple web app in a few lines of code. You can even use features from the app server with almost zero configuration or convention. That, I think, is the way forward.

-----

1 point by sacado 5869 days ago | link

I could not agree more. Arc's web development model is the best I ever found. You can really make apps as fast as what Rails or Django offer, without being limited to CRUD applications or being stuck in an official way of thinking : in Rails, if your table is called pets, then your class MUST be called Pet (don't even think about not using classes), that's convention. If you have other conventions or if, in your mother tongue, the plural of "cheval" is "chevaux", well, too bad for you. Oh, or you can reconfigure the whole thing, of course...

Well, maybe a few functions providing a "preconfigured" framework for CRUD applications would be interesting. We would have all the benefits.

-----

5 points by lojic 5869 days ago | link

You can really make apps as fast as what Rails or Django offer

I find this quite hard to believe. I've been developing Ruby/Rails web applications for over 2 years, and while I like the idea of Arc and would love to be as productive in a Lisp as I am in Ruby/Rails, that is not reality yet because of the libraries.

The toy example pg put up way back when did show off Arc, but once you add real world requirements, Arc comes up a little lacking.

  * scalability of not requiring session affinity
  * database libraries
  * regular expressions
  * Rails *huge* library
It's trivial (takes one line) to have a class with a name different than the table:

  class MyPet < ActiveRecord::Base
    set_table_name 'pets'
    ...
  end
You can turn off pluralization in one line.

I hardly consider those minor changes to be reconfiguring the whole thing. You may want to actually develop some non-trivial applications with Ruby/Rails before comparing to Arc.

-----

3 points by sacado 5869 days ago | link

> "I find this quite hard to believe. I've been developing Ruby/Rails web applications for over 2 years, and while I like the idea of Arc and would love to be as productive in a Lisp as I am in Ruby/Rails, that is not reality yet because of the libraries.

> The toy example pg put up way back when did show off Arc, but once you add real world requirements, Arc comes up a little lacking."

Oh, you are totally right about that. That's why I reimplemented the Arc web server in Lua. Now, I have libraries too (even if Lua isn't the richest language in this regard, at least communicating with the outside world is damn easy -- that's the language's goal). I think I'll try to write a small CRUD framework to see what can be done.

> "It's trivial (takes one line) to have a class with a name different than the table [...] You can turn off pluralization in one line.

> I hardly consider those minor changes to be reconfiguring the whole thing."

Ok, that was a little exageration. But to me it feels like bad design : why didn't they default to "the table has the same name as the class" ? That's simpler, easier to implement (no exceptions to take care of) and foreign-language friendly.

> "You may want to actually develop some non-trivial applications with Ruby/Rails before comparing to Arc."

I did it. It's especially when the application starts to be non-trivial that I hate having to fight with Rails designers' points of view to make my stuff work. On the opposite, with Arc/Luarc, the more my application grow, the better its design feels, because I have to make explicit things I considered implicit / subject to change in the previous versions.

That is probably only my own vision, but with the Arc model, I can see my applications becoming more mature and stable, while with the Rails model, I see them getting more and more patched, with more and more bureaucracy to make everything work.

Of course, it is still better than with, say, PHP, where it is bureaucracy and patches all the way down (that could be a motto : "PHP : patches all the way down").

-----

2 points by lojic 5872 days ago | link

How do you think either a new Lisp dialect such as Arc, or a new Lisp web development framework, can improve on Ruby/Rails for typical web development tasks?

-----

2 points by cchooper 5872 days ago | link

Arc already does some things better than Rails. Consider the difference in effort between creating the Arc "hello world" application and the Rails one.

-----

2 points by eduardo-bellani 5872 days ago | link

No man, that is not the point. What I'm arguing for is that the lisp community, not only arc (I've posted this here because people here seem to share this point of view) would benefit from a RAD oriented framework that embraces the convention over configuration philosophy. Exactly how would it improve is beyond my current level of skill, both in ruby or in lisp mate. Hugs

-----

1 point by eduardo-bellani 5871 days ago | link

Well, first of all I'm not saying copying, but be inspired by. And the "trying to make things easy" thing is not to be underestimated man, just look at ruby. 10 years ago nobody ever heard of the language besides the japanese academic community.

Seaside for instance, is inspiring a lot of good programmers on learning smalltalk, which has the same 'only for academia' aura that LISP has.

As for the 'convention over configuration' fraud, I disagree with you mate. Rails enforces a way to think, which is not a bad thing. The filesystem is a configuration file, but one that is pre configured, and to change the behavior of rails you have to dig in, thus enforcing the "rails way".

Those restrictions breed creativity and speed, because they leave less room to be distracted by any details that are not the building of your app out.

-----

1 point by cchooper 5871 days ago | link

I agree that frameworks should make things easy, but 'convention over configuration' doesn't do that. It just calls configuration by another name. If being hard to configure is a virtue, then I can show you lots of frameworks that do that ;)

-----

1 point by eduardo-bellani 5870 days ago | link

The point is that there is a default config mate. So there is a "way" of the framework, so the majority of people who don't want to configure nothing, won't have to. That does make it harder to the minority, but those are probably already experienced enough to don't mind the pain.

-----