Re^3: Take the Arc Challenge

I can agree that you want a brief and plastic language for exploratory programming. I wonder, though, what happens when it's time for the garage project to move to the data center. I'm guessing that one would have to migrate code out of Arc into a language with more features. So I wonder which is faster...

Write quickly in Arc, rewrite in a better language later.
Write more slowly in a better language to begin with.

That's if I accept the premise that exploration in Arc would be faster than exploration elsewhere. I tend to think that any benefits in Arc could be put into (or found in) something on CPAN, and I wouldn't need to learn another language.

It may be that the exploration, done quickly in Arc, would take too long in a mature language. In that case, I think the programmer still has to be mindful of when the project has reached Arc's limits and needs to move on.

Comment on Re^3: Take the Arc Challenge

Replies are listed 'Best First'.
Re^4: Take the Arc Challenge by mr_mischief (Monsignor) on Feb 05, 2008 at 17:28 UTC
I think in the specific case of Paul Graham and his biggest fans/followers, one would go from Arc to Scheme or Common Lisp. Neither would be a big leap, and Arc is in fact implemented over MzScheme using many of its facilities directly. I'd think of prototyping in Arc for another Lisp dialect much as I'd think of prototyping in Perl with small, dirty, somewhat slower pure Perl modules to rewrite later to clean, modular, fast XS-based modules. It's much the same language and easy to move from one to another, but you're looking at exploiting different sets of strengths at different times. I might also compare it to prototyping in Perl 5 with Moose or prototyping under Pugs for programs meant to be targeted later to native Perl 6. I think the exploratory programming idea itself fits some programmers better than others. A proof of concept or quick prototype can be very useful to try design ideas and figure out what functions go where. Fitting the whole application together the "right" way can take a few tries for some people. If you already know exactly how your application will fit together and only have to implement it, then exploratory programming would probably be a waste of time.	[reply]

Replies are listed 'Best First'.

Re^4: Take the Arc Challenge
by mr_mischief (Monsignor) on Feb 05, 2008 at 17:28 UTC

I'd think of prototyping in Arc for another Lisp dialect much as I'd think of prototyping in Perl with small, dirty, somewhat slower pure Perl modules to rewrite later to clean, modular, fast XS-based modules. It's much the same language and easy to move from one to another, but you're looking at exploiting different sets of strengths at different times. I might also compare it to prototyping in Perl 5 with Moose or prototyping under Pugs for programs meant to be targeted later to native Perl 6.

I think the exploratory programming idea itself fits some programmers better than others. A proof of concept or quick prototype can be very useful to try design ideas and figure out what functions go where. Fitting the whole application together the "right" way can take a few tries for some people. If you already know exactly how your application will fit together and only have to implement it, then exploratory programming would probably be a waste of time.

[reply]