Blaise FAQ

I hope the following FAQ is sufficient to satisfy people's curiosity. If you have any questions that aren't answered here, please e-mail me at .

What is Blaise?

Blaise is a programming language inside my head (read: vaporware). It is a Lisp dialect that borrows ideas from other languages. Effectively Blaise is a yet another attempt to "fix" Lisp.

Why another programming language?

Because none of the existing Lisp dialects that I am aware of satisfy my needs. Additionally I'm always looking for fun ways to learn new things. Designing a Lisp dialect and writing a compiler for it is as good a way as any. Trying to "fix" Lisp is probably hopeless, but it's fun to try anyway.

What advantages will Blaise have over Common Lisp or Scheme?

Here are some ideas that are floating in my head. More will be added to the list as time passes.

• A wide range of libraries. I'm currently investigating ways to take advantage of a huge pool of open source library code available in other languages. One possibility is designing a facade for Blaise that will make it compatible with Python APIs. Another way is to create specific facades tailored to each library.
• A strict specification and a set of primitives for easy interoperation with other languages.
• A facade grammar that can be freely mixed with s-expressions for an easier transition from mainstream languages.
• Heavy use of generic functions on all types to allow for a more friendly set of APIs.
• An optional type checker with a powerful, extensible, dependent type system that borrows ideas from Epigram and Qi.

What advantages will Blaise have over mainstream languages like Java or C#?

I don't think it's possible to describe an intense feeling of suffocation Lisp programmers feel when forced to use Java. The single benefit of Lisp is expressiveness and productivity beyond your wildest dreams.

Why work on Blaise instead of working on Paul Graham's Arc?

I received quite a few emails about this. There is a number of reasons.

• If Paul wanted others to participate in the development process of Arc he'd make the project open source. At the moment Arc is simply not a community effort: there is no public wiki, no mailing list, no issue/wishlist tracker. I'll gladly e-mail Paul my design ideas that he might find useful, but I can't really help beyond that.
• Arc and Blaise seem to have different goals. Paul wants to make Arc a perfect language in and of itself; he doesn't want to design it for anyone in particular. Effectively Arc is a medium for expressing ideas. Blaise's goal isn't nearly as ambitious: the idea is to design a language that would ease the transition of mainstream programmers to Lisp and would be useable for real world projects the moment it's released. Additionally Blaise is largely an educational effort; I want to write a compiler others can learn from. The design goals are just too different.

What is the current status of Blaise?

As I said earlier, Blaise is vaporware. In the near future I will start publishing design and philosophy documents for the language, standard libraries, and implementation. After I am satisfied with the preliminary version of these documents I will start working on an implementation.

What is the purpose of making this page if Blaise is nothing but vaporware?

I've written a few Blaise interpreters that I wasn't happy with. Making this page will force me to create good design documents that will be peer reviewed. This is exactly what I was missing when I was doing this work in private. Additionally, quite a few people expressed interest in seeing this information when I was discussing the interpreters on public forums.

Who asked all these questions?

No one, unless explicitly specified otherwise (I wonder what percentage of frequently asked questions on the web were actually asked by visitors). Sometimes it's easier to organize information into an FAQ rather than a more conventional form. I took the liberty of using this approach here and it seems to have worked fairly well.