Arc Forumnew | comments | leaders | submitlogin
I did it again. Another incomplete Arc implementation. (github.com)
9 points by stefano 5673 days ago | 9 comments


6 points by stefano 5673 days ago | link

I keep saying in this forum that we need to concentrate on language design and on writing libraries. I keep saying to myself that I should work on applications or at least on some useful library. I keep writing half-working implementations. Here's my second attempt. Arc on parrot.

-----

4 points by misuba 5671 days ago | link

What do you think would be helpful for taking Arc away from a culture of reimplementation, and closer to a culture that supports writing libraries?

I'm thinking a clean (to the point of using syntaxy bits that are currently in use for other things) and simple-as-possible namespacing and packaging system would help a little. But maybe I'm wrong.

-----

5 points by stefano 5671 days ago | link

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 5670 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_ 5670 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.

-----

2 points by almkglor 5671 days ago | link

I agree: a good package system would make it easier to (1) write libraries and (2) ensure that libraries don't cause spooky action on other libraries.

-----

2 points by sacado 5672 days ago | link

Aah, writing partial implementations of Arc. I can understand that...

-----

2 points by drcode 5672 days ago | link

That is cool though... I keep thinking about how neat it would be to get arc running on Google App Engine, assuming that ever moves to a parrot-based Python...

-----

3 points by bOR_ 5672 days ago | link

but you're having fun with it, right? =). That is important too.

-----