Arc Forumnew | comments | leaders | submitlogin
5 points by sacado 6106 days ago | link | parent

"As an aside, has Paul Graham shown any enthusiasm for the Anarki changes?"

Obviously not.



3 points by cchooper 6106 days ago | link

I can't blame him. Cutting bloat in the language core is clearly a goal. Nothing should go into the official Arc release unless it has proven its value in real code (which is basically News.YC at the moment).

-----

6 points by sacado 6106 days ago | link

Sure, he has to keep the control over the things. The point is that a few bug fixes (the mkdir problem for example), simple conveniences (see arc.sh) and even trivial optimisations (arc< to name it) available in anarki are of interest even in the official release. I'm not talking about experimental stuff (infix numeric notation, vectors, standalone exe, maybe docstrings, experimental module systems, ...)

But I think the few fixes and conveniences should really be taken into consideration. I can't believe none of them are of interest.

-----

2 points by cchooper 6106 days ago | link

They probably are of interest, but let's not forget he's running a company in his spare time, and 3 releases in about 3 weeks is a pretty good work rate.

Of course, as someone running Arc in Windows, I'd love it if a bit more stuff worked out of the box (e.g. the blog, which didn't work in Arc1 IIRC). That's why I'm probably going to switch to developing on Anarki and then testing it on vanilla Arc afterwards.

-----

3 points by sacado 6106 days ago | link

Note that I don't criticize Paul's attitude there. 3 releases in less than a month is much more than what I expected. He didn't release early, but at least he releases often :) I just meant a few things would deserve a little more consideration, at least in the next few weeks/months ?

-----

3 points by cchooper 6105 days ago | link

I'm hoping things will speed up now that the News.YC code is in.

-----

2 points by jbert 6104 days ago | link

You might increase the chances of stuff getting merged back into PG's arc if you separate the different types of changes into different git branches.

That reduces the burden of code review/merging/demerging on the person you'd like to pull the changes (PG).

e.g. have a bugfix branch containing only "obvious" fixes.

It can be difficult to disentangle a bunch of different changes (what depends on what). That's a barrier to adoption.

-----

3 points by byronsalty 6106 days ago | link

Somebody is reading my mind.

-----