Lisp as Blub
damienkatz.net
damienkatz.net
To say that Arc is not concerned with brevity or expressiveness is simply ridiculous.
For the record, I think the way Erlang supports functional programming isn't particularly elegant and I think having Prolog-like syntax without Prolog-like semantics is silly.
Yes. Yes! I'm not the only one thinking it then!
I think the Erlang process model is brilliant but it really took on the ugliness of the Prolog syntax without attaining the full benefits of the Prolog logical semantics.
That said, a few small changes to the erlang grammar could go a long way towards fixing it (changing separators to terminators, etc). Once you get more familiar with Erlang, you go from writing ugly cascading ifs on multiple conditions to simple clean case statements on tuples. You learn when to use function-clause matching vs. internal matching, etc.
Unification can be very useful in solving some problems. Backtracking is also useful but sometimes gets in the way. Procedural code can be used to do anything that any language can do and students are more familiar with it. So I think Erlang is an interesting addition to languages. And that's without considering it's more practical aspects, e.g., multiprocessing, failover capability, etc.
Nor is Prolog syntax particularly ugly. A problem is that it is too simple, so simple that novices can become confused. Brna, Boulay and Pain discuss why Prolog is difficult in the book:
"Learning to Build and Comprehend Complex Information Structures: Prolog as a Case Study" http://www.amazon.com/Learning-Comprehend-Complex-Informatio...
See the review there by Randall Heltzerman titled "The Most Unlikely Book Ever to be Published".
Also, if you prefer to use Lisp syntax in Erlang you can use LFE (http://groups.google.com/group/erlang-questions/browse_threa...).
Without making any sort of general claim, I notice that what I learn in one session of erlang is very easily lost/forgotten. It's like perl in this respect.
And don't tell me the people who object to erlang syntax haven't tried it :) (I say that about people who object to python's indentation) I've tried it. It's extremely hard to keep in one's head, and takes simply too long to become part of 'muscle memory'.
Anyway, pointers to get started would be most appreciated. It's probably counterproductive to my interests to criticize while I ask for help :)
Hard to say whether this post is deliberate linkbait or just overeagerness to see this as evidence confirming a pre-existing bias. Probably a little of both.
Unless of course Patrick is generating requests that perform functionality, like logging in, up/down voting etc... Then the idea is totally moot since you'd be hitting a much larger cross-section of functionality.
I don't really know Arc and it's intimidating making suggestions knowing the caliber of people looking at the issue; but I figured sometimes an opinion from someone who isn't intimately familiar with the code can be at least a little helpful. If not, feel free to ignore this post completely =D
But you say it likes it's a bad thing. Do you think I don't have a valid point? Are you not debugging a memory leak in a production Lisp app?
With Lisp you can put together a site in a few hours. But how many days must later be spent debugging issues like this? Will this time spent debugging be counted against your productivity gains you attribute to Lisp?
This is exactly the sort of problem Erlang has nailed down. And it requires a whole new thinking about program structure. Is it possible you don't see the problems with Lisp because you can't imagine there is a fundamentally better way?
But, you're confusing the actual application with the Lisp implementation. Arc (and Mzscheme for that matter) are not as mature as Erlang's 20 years (or whatever). If this was running on a more mature Lisp system, I don't think we'd be discussing the same thing.
Having said that, it is still not a language issue, since we have systems such as Termite/Gambit Scheme [http://toute.ca].
Why don't you wait till you have more data before wasting all our time with stuff like this? What's the rush?
I used the opportunity of your reliability failure to make a larger point about reliable software. I admit was deliberately provocative and terse in the posting, but I have futher clarified things in the comments. I thought about writing a long, detailed, well balance article about this. But that wasn't going to happen, I don't have the time. But then I thought why not just write what I think, but not everything I think? So I did.
Sorry, I might be completely wrong about the source of your problems, I am definitely theorizing as to what you are seeing and I don't think I've implied otherwise. But I will say these are the sorts of things that crop up again and again in Java and other GC'd mutable state languages.
Good luck debugging the problem.
Your argument construction is not very reliable either. You're basing "large points about reliable software" on... on what exactly? You can't overgeneralize like that, at least not while remaining convincing.
I manage state via relational databases, and haven't had to deal with any memory-leak bugs. I even found it easy to prevent leaking of database connections.
Mutation is definitely optional. A lot of people even still count Lisp dialects among the functional languages.
http://damienkatz.net/2007/12/erlang_vm_crash.html :
"So the Erlang VM died suddenly with a failed memory allocation. This is actually quite okay [...] However, the Erlang VM didn't restart automatically. Apparently we need to configure something for that to happen, only we can't figure out how to make it work. The documentation is either wrong, confusing or the feature is buggy. This is the kind of stuff we keep hitting in Erlang. It's fantastically productive for many tasks, but using some of the built-in libraries and features can be a huge time sink. (inets and xmerl immediately spring to mind)."
But Erlang to me isn't as much about programmer productivity as it is about reliability. But when building highly reliable systems, of course it's a big productivity boost.
I should point out we've abandoned xmerl (and xml altogether), and things have been much simpler since. We are in the process of moving off the inets http server to mochiweb. Hopefully that will also go smoothly.
But an arbitrary bug in an arbitrary Lisp program is nothing even remotely like sufficient proof for such a statement, unless you are trying to claim that Erlang programs are inherintly bug-free, regardless of how they were implemented...?