Our great sponsors
-
Scrawl-canvas
Responsive, interactive and more accessible HTML5 canvas elements. Scrawl-canvas is a JavaScript library designed to make using the HTML5 canvas element easier, and more fun
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I've never written a programming language. I have built a number of constructed languages[1] over the past few decades, which is an equally selfish (and thankless) task.
Less tangentially, I've worked for the past 8 years on building a HTML5 canvas library in Javascript[2]. I don't ever see people talking about JS libraries in terms of computer language design but I think, in a way, that is effectively what a (good) library is doing: building new, sometimes more developer-friendly, ways of conceptualising and creating programs that do stuff using novel APIs, syntax, state, etc.
There's a lot in the OP that resonates with my experience:
- "once you design a programming language you fall down a rabbit hole" - I've lost 8 years of my life to my project; but I've also gained 8 years of learning skills and insights that do translate to my everyday work as a frontend developer. For instance, almost all of my knowledge about accessibility comes from trying out many (many) different approaches to making the canvas element more accessible.
- "You keep adding new features that are really cool" - Guilty! My library doesn't need an integrated reaction-diffusion engine, but somehow it's acquired one along the way. Similar story with the reduced palette filter which, while a lot of fun to build and play with, remains too slow for use in production eg dithering live-stream video.
- "It also affects your communication with the rest of the programming community" - Because of the need for speedy calculations, I've developed an approach to programming Javascript which tends to avoid slower functionality. This sometimes leads to me writing code that could/should be written in a clearer, more concise and understandable way: 99% of JS code doesn't need to be super-fast, just fast enough!
[1] - for example, this one: https://gevey.rikweb.org.uk/
[2] - Scrawl-canvas - https://github.com/KaliedaRik/Scrawl-canvas
> It's funny/interesting that an 1kloc implementation of minimal self hosting Go exist
Does it? That's not the technique Go introduced, they started by rebuilding Go from earlier versions written in C - but in fact the bootstrapping process may change soon, see https://github.com/golang/go/issues/44505
I'll take the bait and provide evidence on why you should write a programming language.
First, it's technically very difficult, but you will gain deeper insight into the art of the craft. So, if you are a TC chaser or career minded person, then spending half a year writing a language will help you master the coding aspect of the game. I've started many languages since I started college, and each one was instructional. (I'm now 40 and an early retiree)
Second, it's fun.
Third, it may turn into something new. If some people don't write a new programming language, then we are stuck with what we have. This advice basically admits that the status quo is good enough.
The authors saying that the language, as a project, is a lifetime appointment? Well, this reveals everything. I believe if you want to do a programming language, then you must be willing to invest at least a decade or two.
So, here, I am at forty preparing to launch a SaaS around a language that I designed ( http://www.adama-lang.org/ ). The kicker, I believe, is that a project like this requires wandering the desert alone for quite a while.
I'm preparing to launch, and I just started to load test my shiny new production cluster. Low and behold, it sucks. Fortunately, I have a tremendous number of dashboards and isolated it to how I'm interacting with RDS. I've got my work cut out for me which I'll write about.
However, I have a potentially interesting business precisely because I evolved a language which solved a niche use-case. The number of problems that I have had to solve up to this point is not for the faint of heart. Life and reality are harsh mistress.
So, maybe, yes, you can save yourself some heartache by not writing a language. Perhaps, a better way to think or phase this is "Writing a programming language is a lonely affair that will most likely end in tragedy after a long death march".
We are in a golden age for new languages.
You have https://microsoft.github.io/language-server-protocol/ for doing the integration between IDE and your parser.
Also, https://highlightjs.org/ which lets you broadcast your code in a pretty way.
I do however feel that your QoL will depend on whether or not you make a compiler or a translator. The key benefit of a translator is that you can co-opt the host language's standard runtime and debugger.
We are in a golden age for new languages.
You have https://microsoft.github.io/language-server-protocol/ for doing the integration between IDE and your parser.
Also, https://highlightjs.org/ which lets you broadcast your code in a pretty way.
I do however feel that your QoL will depend on whether or not you make a compiler or a translator. The key benefit of a translator is that you can co-opt the host language's standard runtime and debugger.