As an arc developer, I create compliant or not compliant HTML. It's the developer's choice, not the framework's job. That is nice that their are some frameworks out there that always create strictly compliant HTML but it's not necessary for a great web framework. I think a lot of innovations will continue to come from non-compliant hacked web code.
(def f (n) (if (> n 0) (* n (f (- n 1))) 1))(def c (n k) (/ (f n) (f k) (f (- n k))))(def m (i) (let v (map [coerce (trim _ 'both) 'int] (tokens i #\,)) (c (car v) (cadr v))))
or
(def f (n)
(if (> n 0)
(* n (f (- n 1))) 1))
(def c (n k)
(/ (f n) (f k) (f (- n k))))
(def m (i)
(let v
(map [coerce (trim _ 'both) 'int] (tokens i #\,))
(c (car v) (cadr v))))
(m "5, 3")
(m "22, 9")
(m "100, 3")
(m "75, 71")
(m "30, 1")
(m "1, 1")
(m "4, 0")
v 1.0 of code golf choose challenge. 175 bytes passes test cases minimal work to simplify or shorten it.
My experience shows one real application could easily require many, many libs. Yes there are exceptions, don't bother listing them because the rest of the universal code base relies on libraries.
Libraries are both a weakness and strength for lisps. Yes there are libs that do EVERYTHING out there. Each one has a different style and approach. There are no standard methodologies across the libraries. This makes it difficult. Everytime a developer brings in another library they have to figure out how to use it. Versus interfacing with libraries in python, ruby or even Java / C#... everything is much more uniform.
There is a bigger opportunity with small to medium size experimental projects. I think a great example is: http://www.pageonetimes.com/ which is based on PG's news code.
personal-finance-management system
In the past I've implemented front and back-end financial software. I think it's a huge undertaking and best implemented with as many tested and true libraries as you can find. It's absolutely possible in arc, but why use arc when it's not the best choice (for now atleast). Meanwhile there are a number of other areas where the code will not be nearly as library dependent.
a dedicated arc IDE
I think an IDE is a great idea. In my opinion, the way to do it is to use existing IDEs. DrScheme (already works...), Eclipse, SLIME all come to mind. Now before everyone goes nutty thinking we need our own IDE - yeah eventually. But who is going to put in hundreds of hours of time into implementing a new IDE when you could plug into three existing IDEs in a fraction of the time.
I think at this point a completely new IDE would need to incrementally improve on the best IDEs that are out there. VIM, Emacs, Eclipse, XCode, VisualStudio, etc (ya, a decent IDE seems to be one of the few things M$ does right).
I agree that the lack of libs is a real problem. My real world example: I have have a bunch of RSS feeds, and I want to regularly poll those feeds, extract some content, and add it to my site (pageonetimes.com).
Doing it with Arc alone is too much for me - for mysterious reasons get-http.arc isn't working for me. Even if it did, I would have to write my own rss parser. Instead I am using Ruby for this, and grabbing the RSS content, parsing it, and saving the results is about 10 lines of code using standard libraries.
What kind of problems exactly does get-http.arc give you? It's a translation of a piece of Common Lisp code I had written to be able to fetch RSS feeds. The CL version worked well for the task.
In my CL project I thought to parse it manually, but I've abandoned the project after finishing the HTTP part. I've never tried using it, but you could have a look at treeparse in Anarki, if you haven't done already.
I think this would be a fun and useful project for the community and any newcomers. There is already a scheme dialect in the top 5 languages, Guile.
I don't know the best way to begin. Maybe add it to Anarki with a link to the perl code for now. I think it's a huge undertaking and could progress pretty slowly if PG doesn't actively develop arc. But at the same rate it could be really useful to find arc's weaknesses.
Yeah, there is a reason PG chose PLT Scheme. To begin with, coming back to arc will not be difficult. PLT Scheme has a lot of libraries and code samples. And it's mature and portable. The dialect is still actively being used and developed. All good reasons to use it.
Personally I've finished my website in arc, I just need to do one more move to the production web server. I'm going to leave it in arc and update it as the language is updated by PG / Community.
I think anyone looking for another language should consider common lisp and smalltalk. I've been coding in both recently and it's been a pleasure after I familiarized myself (again).
