logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

Why-am-I-working-in-private.md (7352B)


  1. ---
  2. title: Why am I building a programming language in private?
  3. date: 2022-03-13
  4. outputs: [html, gemtext]
  5. ---
  6. As many readers are aware, I have been working on designing and implementing a
  7. systems programming language. This weekend, I've been writing a PNG file decoder
  8. in it, and over the past week, I have been working on a simple kernel with it as
  9. well. I'm very pleased with our progress so far — I recently remarked that
  10. this language feels like the language I always wanted, and that's mission
  11. accomplished by any definition I care to consider.
  12. I started the project on December 27th, 2019, just over two years ago, and I
  13. have kept it in a semi-private state since. Though I have not given its name in
  14. public, the git repos, mailing lists, and bug trackers use sourcehut's
  15. "unlisted" state, so anyone who knows the URL can see them. The website is also
  16. public, though its domain name is also undisclosed, and it is full of
  17. documentation, tutorials, and resources for developers. People can find the
  18. language if they want to, though at this stage the community only welcomes
  19. contributors, not users or onlookers. News of the project nominally spreads by
  20. word of mouth and with calls-to-action on this blog, and to date a total of 30
  21. people have worked on it over the course of 3,029 commits. It is a major,
  22. large-scale project, secret though it may be.
  23. And, though we've invested a ton of work into this project together, it remains
  24. as-of-yet unfinished. There is no major software written in our language, though
  25. several efforts are underway. Several of our key goals have yet to be merged
  26. upstream, such as date/time support, TLS, and regular expressions, though,
  27. again, these efforts are well underway. Until we have major useful projects
  28. written in our language, we cannot be confident in our design, and efforts in
  29. these respects do a great deal to inform us regarding any changes which might be
  30. necessary. And some changes are already in the pipeline: we have plans to make
  31. several major revisions to the language and standard library design, which are
  32. certain to require changes in downstream software.
  33. When our community is small and private, these changes are fairly easy to reckon
  34. with. Almost everyone who is developing a project based on our language is also
  35. someone who has worked on the compiler or standard library. Often, the person
  36. who implements a breaking change will also send patches to various downstreams
  37. updating them to be compatible with this change, *for every extant software
  38. project written in the language*. This is a task which can be undertaken by one
  39. person. We all understand the need for these changes, participate in the
  40. discussions and review the implementations, and have the expertise necessary to
  41. make the appropriate changes to our projects.
  42. Moreover, all of these people are also understanding of the in-development
  43. nature of the project. All users of our language are equipped with the knowledge
  44. that they are expected to help fix the bugs they identify, and with the skills
  45. and expertise necessary to follow-up on this fact. We don't have to think about
  46. users who stumble upon the project, spend a few hours trying to use it, then
  47. encounter an under-developed part of the language and run out of enthusiasm. We
  48. still lack DWARF support, so debugging is a chore. Sometimes the compiler
  49. segfaults or aborts without printing a useful error message. It's a
  50. work-in-progress, after all. These kinds of problems can discourage new learners
  51. very fast, and often requires the developers to offer some of their precious
  52. bandwidth to provide expert assistance. With the semi-private model, there are,
  53. at any given time, a very small number of people involved who are new to the
  54. language and require more hands-on support to help them through their problems.
  55. A new programming language is a major undertaking. We're building one with an
  56. explicit emphasis on simplicity and we're still not done after two years. When
  57. most people hear about the project for the first time, I don't want them to find
  58. a half-completed language which they will fail to apply to their problem because
  59. it's not fleshed out for their use-case. The initial release will have
  60. comprehensive documentation, a detailed specification, and stability guarantees,
  61. so it can be picked up and used in production by curious users on day one. I
  62. want to fast-forward to the phase where people study it to learn how to apply it
  63. to their problems, rather than to learn *if they can* apply it to their
  64. problems.
  65. Even though it is under development in private, this project is both "free
  66. software" and "open source", according to my strict understanding of those terms
  67. as defined by the FSF and OSI. "Open source" does not mean that the project has
  68. a public face. The compiler is GPL 3.0 licensed, the standard library is MPL
  69. 2.0, and the specification is CC-BY-ND (the latter is notably less free, albeit
  70. for good reasons), and these details are what matter. Every person who has
  71. worked on the project, and every person who stumbles upon it, possesses the
  72. right to lift the veil of secrecy and share it with the world. The reason they
  73. don't is because I asked them not to, and we maintain a mutual understanding
  74. regarding the need for privacy.
  75. On a few occasions, someone has discovered the project and taken it upon
  76. themselves to share it in public places, including Hacker News, Lemmy, and
  77. 4chan. While this is well within your rights, I ask you to respect our wishes
  78. and allow us to develop this project in peace. I know that many readers are
  79. excited to try it out, but please give us some time and space to ensure that you
  80. are presented with a robust product. At the moment, we anticipate going public
  81. early next year. Thank you for your patience.
  82. Thank you for taking the time to read my thoughts as well. I welcome your
  83. thoughts and opinions on the subject: [my inbox is always open][0]. If you
  84. disagree, I would appreciate it if you reached out to me to discuss it before
  85. posting about the project online. And, if you want to get involved, here is a
  86. list of things we could use help with — email me to volunteer if you have
  87. both the time and expertise necessary:
  88. [0]: mailto:sir@cmpwn.com
  89. - Cryptography
  90. - Ports for new architectures or operating systems
  91. - Image & pixel formats/conversions
  92. - SQL database adapters
  93. - Signal handling
  94. - JSON parsing & encoding
  95. - Compression and decompression
  96. - Archive formats
  97. If you definitely don't want to wait for the language to go public, volunteering
  98. in one of our focus areas is the best way to get involved. Get in touch! If not,
  99. then the release will come around sooner than you think. We're depending on your
  100. patience and trust.
  101. ---
  102. *Update 2022-03-14*
  103. This blog post immediately generated detailed discussions on Hacker News and
  104. Lobsters in which people posted the language's website and started tearing into
  105. everything they don't like about it.
  106. It's not done yet, and the current state of the language is not representative
  107. of the project goals. This post was not a marketing stunt. It was a heartfelt
  108. appeal to your better nature.
  109. You know, I have a lot on my plate. All of it adds up to a lot of stress. I had
  110. hoped that you would help relieve some of that stress by taking me seriously
  111. when I explained my motivations and asked nicely for you to leave us be. I was
  112. wrong.