Ask HN: Have you created a programming language and why?

Since 2013, I have been leading the creation of Envision, an in-house domain-specific language, intended for data processing, reporting, forecasting and optimization for supply chains and logistics. Small intro here: http://www.lokad.com/envision-more-technical-overview

Why ? Between 2008 and 2013, Lokad provided a data forecasting API : send us your sales history and we'll respond with a good sales forecast for each product. This didn't work because:

- most customers don't have the know-how or infrastructure to clean up their sales history (for instance, by setting up adequate SQL queries when exporting data to our services), and instead either sent us garbage data, which led to garbage results and therefore lost us customers, or they cleaned up the data manually in Excel, which prevented us from being a permanent, automated step in their supply chain processes, and therefore lost us customers.

- most customers don't care about knowing the future, they care about knowing how much they have to order from their suppliers. These decisions can certainly be optimized if you have a good model of what the future looks like, but that involves even more knowledge about the customer's business and even more data (expected margins for products, current stock levels, minimum order quantities for various suppliers, etc).

Most of our sucesses in this early period were premium customers for which we could afford to write and run custom C# code that did the initial data cleanup and pre-processing, and then used the forecasts to generate a list of actual business decisions.

As you might guess, C# is not the best language for this. It costs too much to write, deploy, maintain and run. We examined the various candidates available at the time and decided to write our own language, with the following characteristics:

- 100% online, no local setup needed

- excellent static analysis to detect issues ahead of time (no type errors, null references, off-by-one or out-of-bounds errors, join arity surprises, etc)

- good high-level guarantees (no infinite loops, no accidentally quadratic operations, fully transactional behaviour)

- fast enough without manual optimization

- predictable performance (small changes in the input data should not cause major changes in execution speed)

- handle the "hard developer stuff" behind the scenes (multi-threading, memory management, error recovery, caching intermediate results to make REPL faster, etc)

- our various high-performance black boxes (such as demand forecasting) are available as functions in the language

- a small, well-designed (supply chain) standard library

Some great submissions here, nothing as nice from me, but I guess there is something to learn from most people.

I have created many in my life, non of them open source (yet; the one I am chewing on now will be I think), most of them toys, the most successful one really niche and those same successful ones embarrassingly crappy. I wrote a PHP before PHP (in Perl as well, guess it was meant to happen :) and it made me a lot of money being able to write dynamic web applications without much of the plumbing at the time. I wrote a bunch of 4GLs for finance and web CRUD applications, all sold as addons to our CMS early 2000s. After that I wrote a lot of toy languages which I meant to put on github some time but I don't think they are of interest to anyone anymore by now. I write, for my own sanity, Forths when I do embedded work, assembly work and/or work that doesn't allow me to have interactivity for development.

They 'why' is easy; the feeling that things are just not as efficient as they can be and the drive to do something about that. That will never leave me and it did give me a lot of competitive advantage over the years. Mostly in the end I end up with something that, after postmortem, would've been easier with Lisp. If I surpass that point in my life, I succeeded.

I've created a few interpreted languages over the years: 1) A C and Lisp hybrid called "Frame" that was an expert system development language; it looked like C but ran like Lisp, with functional programming like code modification capabilities. Created over an 18 month period around 1988, with lots of statistical and 3D rendering capabilities. For proof of concept, it had an accounting system built with it, which generated 3D cash flow animations for analysis purposes. After that I wrote a bunch of "agent AIs" with it as back then AI was all about actors and agents. 2) At Philips Media during the early 90's I wrote the ASLAN documentary production language, which enabled a team of people to create Ken Burns style documentaries. This was a "distributed language" with different people operating in different roles having different syntax for their portion of the overall documentary being created. Audio people, video editors, screenwriters, other coders, graphic artists, and 'builders' all had their scripts that when combined and executed, would produce a ISO disc image that was a "cut" of the documentary. I ended up being the production engineer for 13 documentaries, which we repeated in 8 languages. Philips also sold ASLAN to other production companies, which I then supported their use. 3) At Sennari Games, under contract to EA, I wrote the front end UI and control language for all the Tiger Woods PGA golf titles. This was maybe '94? It was the first Tiger Woods Golf, which was then ported all over the place. When I checked back 10 years later, they were still using it for golf game front end UIs.

I seem to make mini-languages quite a bit now. I operate as an integrator between logical systems of complex software. I've found mini-languages, often nothing more than a macro text replacement engine, is all that is needed to enable fluid integration between vastly different technologies. The KISS principal 1000%.

Love inform7, thanks!

Wow, that is really neat. Dealing with JavaScript is one of the reasons I try to avoid front end work. Python, however, has wonderful syntax. I am bookmarking that page for future use. Thanks.