Certainly, a number of pragmatic lessons about language design and implementation have emerged over the years of Nickle development. It turns out, for example, to be difficult to give an LALR(1) grammar for such a strong superset of C. Garbage collection turns out to be a huge win over the alternatives: in practice the authors have never observed a problem related to collector performance, and the ease of implementation and the quality of the user experience have been tremendously improved. The principle of least surprise has proven a good guiding principle for the design: the authors as well as novice users seem to be able to use Nickle without deep thought or constant reference to the documentation.
It was also interesting to observe how two people with similar backgrounds and tendencies can have quite different opinions about even broad details of language design. While the authors always largely agreed on where they were going, there was much involved discussion about the best way of getting there.
In particular, the influence of other languages on the Nickle design was complex and varied: both authors learned a lot about a variety of language options and about how to keep a clear head when evaluating and implementing them. Corner cases in existing language features proved to be problematic: Nickle tended to adopt in a piecemeal fashion features that other languages were designed around, and understanding the best methods of fitting these features in usually required a significant effort.
In preparing the initial draft of this paper, the authors wrote:
The degree of meticulousness [involved in finalizing Nickle] is admittedly unusual in a public utility-belt programming language release. However, it should be understood that the authors have refrained from a public release over a 15-year period precisely to reach this level of quality while there was still room to experiment. Following a successful public release, it will become much harder to make major specification or implementation changes. This drives a desire to get it largely right the first time.As public release drew near, it became apparent that a number of significant last-minute changes to the language and the implementation were not only desirable but necessary. To a large degree, however, these changes were intended to articulate the goal quoted above: to get the language as ``right'' as possible before the first public release.