Arc: Where are we going?

http://www.arclanguage.org/item?id=8462

by nreece • 18 years ago

69 27 18 years ago

Sounds like the community is not very happy, for various reasons (some valid).

If I were an arclanguage community member reading this and seeing pg's responses, I would not feel better.

The whole situation sounds like a big mess especially considering lisp's history of "community fragmentation and trivially incompatible implementations."

I sincerely hope things get better.

pg4• 18 years ago

What you call fragmentation in the Lisp community I actually consider a sign of health. It was a sign of the vitality of the Lisp community in the 70s and 80s that people keep forking off new dialects. That was actually something I was hoping to encourage more of with Arc.

CL was in my opinion (and in the opinion a lot of Lisp hackers) a disaster in that respect. Before CL, Lisp had evolved rapidly by spawning new dialects. Once CL was established as the standard, this evolution practically stopped.

davidw2• 18 years ago

I've thought about this some, and think it depends on how you define "health". What you describe sounds very healthy in terms of a good place to be for those wanting to hack on cool, new things, to push boundaries, to explore, and so on. However, I am less certain that it makes for a healthy community in terms of one where there are relatively fewer producers of the language, and many consumers, and those consumers want something that "just works" that they can depend on. In that sort of situation, you run into the problem where people get annoyed with the "which one!?" problem described here:

http://journal.dedasys.com/articles/2006/02/18/maximizers-sa...

My gut feeling is that there's a 'right' balance that's hard to find. If you just want to explore and be creative and push the limits, that kind of fragmentation is probably good, or at least not harmful. If you want to create something that people, say, base their businesses on, I think that it is not as positive. People get nervous about picking the 'right' one; beginners are especially confused, because they may not even have acquired the knowledge to decide what is 'right'. Lots of hacking goes into implementations, rather than libraries, and libraries may not work on all implementations, further exacerbating the 'which one' problem, which now involves looking at which libs run where.

Another part of the "problem" is that if you're aiming for "fun and experimentation", you are in a somewhat different (enviable?) position than most programming language creators: you've written about and popularized the language already, and are somewhat famous yourself, guaranteeing Arc a wide audience, something that is probably likely to attract more 'consumer' types than 'creators'. They're the ones who will be grumpy about not having something stable.

herdrick• 18 years ago

Amen. Lisp history is like Chinese history. The 'warring states' period, though lamented as chaotic, was the most innovative time for both. Harmonious unity sounds good but yields stagnation. So three cheers for Arc and Clojure, and Estonia, the Czech Republic, the Liga Nord, the Bloc Québécois and the state of Jefferson.

lacker5• 18 years ago

I predict that Paul will end up abandoning Arc and restarting his quest for the perfect programming language anew. It seems to happen with other successful languages - Python wasn't Guido's first attempt at a programming language, and Ruby wasn't Matz's first attempt at a language. It's hard to change fundamentals once you have already publicized a language and you have working code, and I think some of the fundamentals of Arc will definitely need to be changed. In particular, the distinctions between the different types of iterable objects - strings, arrays, lists - the inability to design your own objects that are also usable in the same ways as the built-in objects, these are pretty key aspects of the more recent programming languages. I could easily be wrong, but I still suspect the 100-year language quest needs a reboot.

Good luck, and I'll keep trying Arc 3 or whatever future stuff there is. I would love a successful language with real macro capability.

pg4• 18 years ago

There wouldn't be any need to make a new language. I can change anything I want in this one. There's very little working code out there; that is in fact probably the main complaint about Arc; and one reason that's so is that I don't want it to be hard to change:

http://www.paulgraham.com/core.html

I'm not deeply committed to the current approach to iteration. But I don't want to switch to something more complicated till I can prove it's a net win. My standard of proof is whether the proposed language change will make the source of a real program shorter. So if you have an idea for a new iteration abstraction that would make some piece of code in news.arc shorter, please show me the source before and after. (You don't have to implement the new abstraction; just show me what code using it would look like.)

lacker5• 18 years ago

I think the non-object-oriented philosophy in Arc is so deeply ingrained it'll be hard to change without starting over.

But really the question is whether any object-oriented philosophy is necessary. My take is, let's say you write a function in Arc that operates on lists. It's recursive using car and cdr. Now ideally, you could also run that function on anything else that is list-like. But in Arc, car only works on lists. Maybe you can fix this without making everything an object, that'd be fine by me.

In practice modern programming languages are tending towards a default dynamic-array-like datastructure that supports both random access and amortized-O(1) append. This is so convenient for hacking programs together, I can't believe the 100-year language won't have this as a very basic part of the system. But Arc doesn't do this. In news.arc you have a very Lisp-list-centric way of programming. But I think for many problems less restrictive datatypes are the most convenient. Hash tables and dynamic arrays need to be just as easy as Lisp lists. This is the Python way, the Ruby way, and I think the way of the 100-year language. But I don't know how to make iteration on any of these look equivalent without making the core of the language be more object oriented.

charcoal• 18 years ago

> There wouldn't be any need to make a new language. I can change anything I want in this one.

> I'm not deeply committed to the current approach to iteration. But I don't want to switch to something more complicated till I can prove it's a net win.

Paul, this doesn't sound right. Prove that a given change is a net win? Since you obviously can change anything you want at any time, why not go ahead and add the features that seem like they might be worth trying out? See what your users do with them. If the changes/additions turn out to be duds, just rip them out in the next version and let a subset of users whine about it. After all, users will whine either way -- may as well take the path that benefits Arc the most, right?

DaniFong• 18 years ago

One thing that seems to be a net win in scientific programming as well as graphics programming is a method to view code that renders sub and subscripts and unicode characters (as in Fortress). This doesn't reduce the number of nodes required, but it does improve readability substantially. Since reading code is often harder than writing it, and since scientific and graphics code is ordinarily extremely hard to read, and improvement to readability helps.

Adding very powerful and general capabilities to syntax, as Fortress does, also reduces the number of nodes required, but I've yet to determine whether the added complexity is worth it.

damienkatz• 18 years ago

> My standard of proof is whether the proposed language change will make the source of a real program shorter

Short != Clear. Brevity is a false economy, I think you are pushing for the wrong goal.

yters3• 18 years ago

This whole attitude of now, now, now, seems very against the hacker ethos. What happened to procrastination and laziness?

jimbokun2• 18 years ago

"This whole attitude of now, now, now, seems very against the hacker ethos."

But perhaps in tune with the entrepreneur ethos?

yters3• 18 years ago

Yes, I think that is a good point.

qwph• 18 years ago

What happened to procrastination and laziness?

To say nothing of impatience and hubris.

hhm• 18 years ago

I think the best answer in the thread is the one by " cchooper", that starts with "Personally, I think the only thing". Search for it, it shows an interesting pov.

vrs• 18 years ago

Link: http://www.arclanguage.org/item?id=8493

yters3• 18 years ago

I like that, the 100 year language is an idea, not an implementation.

arjungmenon• 18 years ago

I personally feel that a language core should be the work of a single person.

Even 2 persons should not work together on a language core. The quantity of communication required if 2 persons work on a single language is so large, that hinders and messes up the development process.

The core set of axioms that form a language are almost fundamental as the laws of nature to that language. Just imagine theory of relativity being developed by several scientists together... almost impossible.

Arc: Where are we going?

Related Stories