I think arc's trying to avoid multiple processes. If you need them this isn't the right tool. But I think you can stretch arc pretty far without needing multiple processes.
"..convenient features like builtin transaction semantics."
To my jaundiced eye a feature that requires a lot of cycles of setup doesn't seem very convenient ;) It may well be impossible to do without, and transaction semantics may be useful because they make your life easier, but they aren't convenient.
It's hard to be a hacker's language with such advanced/complicated/complex features. Arc's approach seems to be, "if it's complicated throw it out." Hackers will find a way to live within its limitations. And we often do.
I agree. I was never intending to use arc for doing so, I was just asking about the rationale of going against scheme and other functional programming languages evolution. Just seeing what others think.
> ... feature that requires a lot of cycles of setup doesn't seem very convenient.
I was referring to crafting an example problem using Arc, to show the value of the feature - not the feature itself. The feature implementation is dead simple and convenient.
> It's hard to be a hacker's language with such advanced/complicated/complex features. Arc's approach seems to be, "if it's complicated throw it out."
Depends on how you view it. I'm not a language junkie, but I value languages that have a good balance between power, efficiency, and usability. Arc provides this. So does Clojure. Clojure has more features. You see power in arc, you understand all of its' minimalistic feature sets. I see feature sets provide power simply because they exist - and they still they have a very low complexity requirement to achieve a given result. (ie . wrapping an update statement in a 'dosync' is pretty much free of any complexity yet you get a lot in return). That, to me, is valuable. That to me is power.
It's funny, I'm starting to notice some rosy glasses around here. No offense and this isn't just from your comment, but I get the impression if a feature gets implemented in arc, then arc users see the power arc provides and say "look how cool arc is - its powerful". Yet if someone says language "x" has a cool feature that arc doesn't have then all of the sudden it's a "framework", "cruft" or extra complexity that's not needed anyway....Really? I don't buy it. These other languages are doing great things too.
> Hackers will find a way to live within its limitations. And we often do.
Honestly - I think arc users live within its limitations simply because there's really no guiding force or buy in from either the author or a large enough community to evolve it's feature sets at even a reasonable pace. That's not to criticize everyone's contributions, but rather a relative experiential comparison.
"not the feature itself. The feature implementation is dead simple and convenient."
But the implementation is irrelevant! What matters is how easy the feature is to use. [Insert rant about how 37signals confuses interface complexity with implementation complexity. Implementations should be complicated. http://www.joelonsoftware.com/items/2010/08/19.html]
---
I don't think I have rose-colored glasses at all. I didn't mean to imply that transactions aren't useful, or that convenience is all. We all use other languages here. My point is this: if you want to get stuff done, don't go dreaming of concurrency and transactional semantics in arc. It's just too hard, PLT's foundations are too crappy from that perspective. It would be a waste of your time.
Arc is a place to experiment on how far we can go with a minimal software stack. I wouldn't use it for other kinds of experiments.
---
Update: Rereading the thread, I suspect I'm saying nothing you don't know, except perhaps that I agree with you. Your core question seems to be, "Why do we not like immutable when PLT seems to like it." To that I have no intelligent response.
Before I worked on improving the port of Arc to PLT 4 (the bit about using MzScheme's mutable pairs to implement Arc lists instead of whacking immutable pairs with pointers), I spent some time looking around to see if there was another runtime I'd want to use instead. Because the Arc runtime is less than a thousand lines of code, it would be easy to move it to something else if it were better, and I wouldn't want to take the time improving the port to PLT 4 if I were going to use something else instead.
PLT has some weirdness such as for example needing to use custodians to forcibly close socket ports. But in terms of a runtime that supports concurrency AND call-with-current-continuation AND dynamic variables ("parameters") that work in the presence of continuations and threads and exceptions AND a rich set of synchronization primitives AND tails calls AND is reliable AND is fast... if there's anything better than PLT, I sure would like to know about it, so that I can start using it!
Have you looked at Termite (that is, Gambit)? It seems to support continuations well - continuations are even serializable (along with ports, threads, etc) - and I think concurrency is handled exceptionally elegantly (built-in message-passing a la Erlang).
I never got many chances to use such exotic features, but I believe the combination of message passing and serializable continuations would allow you to do fun stuff like easily transfer code execution between different computers.
My limited experience suggested it was fast. It's also compilable to C. I suspect tail calls are properly handled - doesn't seem like something Feeley would let slide. I'm not sure about reliability.
I stopped using it because of lack of documentation and poor library support.
I was probably overstating things, and certainly overstating my knowledge of them. I was focusing entirely on message-passing concurrency, like in Erlang. 'Crappy' was a reference not to a specific runtime but to the threads model in general and how errorprone it is.
What do you think of SBCL? I get the sense it is faster. Is that not true?
re message-passing concurrency in PLT, PLT has both message-passing (either synchronous channels or asynchronous buffered channels, your choice) and concurrency built in as a standard part of the language. Second, even if PLT didn't have that, you can easily implement "message-passing concurrency" on top of a threads model.
As for SBCL, I haven't seen a comparison, so I don't know. Common Lisp doesn't have call-with-current-continuation so Arc's ccc wouldn't be fully supported, but I don't know if anyone's Arc programs use full continuations so it may not matter.
I was wondering about runtime quality without reference to arc or specific features.
From what people say Erlang has a really high-performance fine-grained message-passing implementation. PLT has the primitives, but not nearly the same runtime quality. Is that mistaken?
Which means what exactly? Slow? Crashes a lot? Doesn't sparkle?
Do you have a single shred of evidence for these claims, whatever they are? Do those "people"? Or is this just all blabble?
If you actually want to know if Erlang has a faster message-passing implementation than PLT you don't need to compare what I say with what "people" say. Write a program in Erlang and PLT and see which one is faster.
Ok. You seem to be saying PLT is the best thing for everyone, and that nobody should use anything else. I'll just assume something's being lost in translation, and shut up. It's not a very productive topic anyway.
You don't just ask, you ask using words like "babble" and "shred of evidence". Is that necessary? It sounds defensive of PLT. But perhaps you think my argument is poor. So let me try to clarify.
You seem to be saying reputations are irrelevant. They're a shortcut. They're for when the program I'd have to write to test some property would require a week to months of work. If you want to ignore reputations, be my guest. But reputation is how you found out about PLT in the first place. You didn't run some idealized experiment comparing every single platform in existence for precisely the nuanced characteristics of the program you were planning to write.
I hear lots of people online touting Erlang as high performance at hundreds of cores, and highly fault tolerant. Have you not heard this? Do I need to cite chapter and verse for things I assume people are aware of? I don't hear anybody saying similar things for PLT. Am I just not listening in the right places? Feel free to cite evidence yourself.
I use PLT and arc because of programming convenience. I don't spend much time thinking about how good the runtime quality is because it's frankly not that important to me. It doesn't give me much confidence when I see 12 segfaults a day on my readwarp server[1]. So yes, it does 'crash a lot'[2]. In this very thread you're switching away from using immutable cons pairs because they seem to be not working as advertised. Is that not 'evidence'?
You've said things like "if there's anything better than PLT.." so it sounds like you're thinking in terms of an absolute ordering that you can stack language/platform combinations on. Surely the ordering is in the context of your use case. Or would you write the linux kernel in PLT scheme? Based on what you know now? How would you scale news.arc to two servers? I don't care that PLT 'has message passing'; if I wrote something that required lots of machines I know I would switch to Erlang or C, and put up with crappy syntax. You can't have the best programming environment and the best runtime - because no single community focuses equally on both.
I was careless in my phrasing of 'some people'. Sorry. I didn't expect to get pounced on, and I didn't mean for the conversation to get yet more noisy. It takes two to do that.
