performance (6705) programming (6378) tech (4423) coding (2001) languages (487) programming languages (109) compilers (30) cpus (27)
Working on a programming language is one of the most challenging and open ended design spaces that I have ever tried to operate in, both for existing and brand new languages. There are very few bounds or constraints on the solution space to help guide and direct my thinking. Everything is ambiguous and open ended with endless possibilities. It sounds great to me… until I need to make progress. Then… not so much....
Welcome everyone to my first “real” blog. =] To set some initial expectations, not all of these posts will be of super high quality published material. Often, I plan to use them for random musings and thoughts which I might have posted somewhere like Hachyderm, but required a bit more text or formatting than makes sense in toot or tweet. Plus, I’d like a forum outside of the bad bird site and more accessible than Mastodon....
Improving the user-facing Carbon Explorer output Note: This is the first of two guest blog posts from Carbon’s Google-Summer-of-Code contributors this year. Carbon Explorer is a prototype interpreter for Carbon whose primary purpose is to act as a clear executable specification of the language. It can also be used as a platform for prototyping and validating changes to the language. Its intended audience is people working on the design of Carbon, and it is not intended for real-world Carbon programming on a