[BruceIV]

Most programming languages do an initial period of internal development before a public release.

When I started on the project ~3 years ago, it took me about 2 weeks to work around the (then current) set of compiler bugs to make a 100-line benchmark program -- naturally a public release at that point would not have been fruitful. Today our compiler generally works, and we're looking forward to making a public release once we get a couple more features stabilized.

[kodablah]

I think there is a difference between working on something in public and a public release. I'm always skeptical of the claims that things can't be done transparently because it's not open to input yet. Those things are orthogonal. You don't have to work in secret just to avoid some of the issues with publicity. Granted I know it happens often, I just don't think it needs to be that way.

[Retra]

If you want to work on something in public, you potentially have to write public-facing prose. You have to explain what the project is, where to find stuff, who to contact, documentation... set up a website, wrangle newcomers, commenters, press, etc. For a research project, that's a lot of work to do by people with limited time/budget for something that hasn't even been demonstrated to work.

Basically, day 1 transparency either requires a budget or misplaced priorities.

[kiriakasis]

i think it is more like "you can only make a first impression once"