Arc Forumnew | comments | leaders | submitlogin
5 points by stefano 5940 days ago | link | parent

Namspaces are essential. I think that a real, actively developed implementation, not just a prototype as Arc2.tar, would stop the reimplementation culture. That culture is quite spread in the lisp world in general, and it's not totally bad because it let you compare and try different approches. We shouldn't stop doing something just because it has already been done, because sometimes innovation comes from re-inveting the wheel in a different manner. That said, a standard implementations where the majority of the efforts goes is essential. Summing up, I think we need:

1) Module system.

2) Real (not a prototype), actively developed implementation.

3) Work hard.

4) Have the time to work hard. This is what open source projects usually miss, for obvious reasons.

Since we miss the time to work on an implementation from scratch, we should leverage existing platforms, like clojure did with the java platform. rainbow already does this using java, and I'm trying to do it for the Parrot platform.



2 points by misuba 5939 days ago | link

After I posted the question above a little voice in the back of my head started saying "wait... aren't we in the language design phase? Doesn't Arc ultimately just have a messaging problem, in that I am still thinking more in Being Popular terms than Hundred Year Language terms, despite knowing that it isn't really appropriate?"

So I guess what I'm saying is I agree with you? ... Yeah! (I especially think the focus on building on VMs is a great one right now. One language that could sit on the JVM, Parrot, and/or the CLR or DLR would be a pretty strong win (see also fandev.org).)

-----

1 point by bOR_ 5939 days ago | link

mmm. http://www.heise-online.co.uk/open/Shuttleworth-Python-needs...

I can imagine as a language founder you'd hate remarks like the one above, where other people tell you that in order for your language to remain popular, you have to address these and these and these points.

What would excite me most (but I'm somewhere at the bottom of the food chain when it comes to language design) is that different new and old ideas for implementation of certain language features can be tried in arc.. so.. if we want to be able to load modules, what kind of options do we have to design a loading system.. and what about arc gives us new / better options to design a module system that other languages did not have, and thus could not consider as an option.

-----