Frequently Asked Questions (FAQ)
Before we announced Avail to the world on April 28, 2014, we had no idea what questions would be asked frequently. Sure, we came up with some, and some of our guesses were even correct. But we wanted to use a data-driven approach to writing our FAQ. So we erred on the side of caution, and waited for compelling reasons to believe that certain questions would, in fact, be asked frequently.
Thanks to the mind-bogglingly successful proliferation of the announcement, and the lively discussions that ensued, we now have a pretty good idea about what people are asking — and how we should respond.
| Question | Short Answer |
|---|---|
| Who is Avail for? | You, if you want it to be. |
| Why did we build Avail? | Because it didn't exist already. |
| Is Avail natural language programming? | No. |
| Does Avail require English language proficiency? | Yes, and so do its competitors. |
| Why does Avail use so much Unicode? | Because it's international, relevant, and pretty. |
Why isn't feature X supported? |
Because you didn't build it yet. |
Long Answers
Who is Avail for?
At the risk of being facetious, Avail is for people who want to use Avail, just like Java is for people who want to use Java, and Haskell is for people who want to use Haskell. These is no question that, at the present time, these other programming languages, and most other programming languages that you have ever used or heard of, are more capable than Avail. They are faster, they are more reliable, they are better documented, they have larger ecosystems, and so on. If you are developing mission-critical software, then there is absolutely no question that you should use some other system — any other system — to build your product.
At this very minute, Avail is for enthusiasts who want to experiment with an emerging technology that offers clean semantics and unprecedented expressiveness. It is for people who want to write statically-typed, syntactically-appropriate, semantically-rich domain-specific languages without having to sacrifice immutable values, imperative flow control, exception handling, type polymorphism, multiple dispatch, parallel computing, or anything else in order to do so.
Avail is for people who know where they want to go, who don't need to get there today, and who would prefer blazing a new trail to the future rather than taking the many well-trodden roads that brought them to the present — but still do not go where they want to go.
Why did we build Avail?
Because we love programming, but prefer accomplishing ambitious tasks to being frustrated and disappointed with the programming languages that are available to us.
We analyzed the design decisions that went into established, successful programming languages. We found one thing in common among them: they excel at doing the things that they were specifically designed to do — and everything else is painful. Why? Because the designers wanted to produce viable artifacts within their productive lifetimes, so that people could use them while they were still important and relevant. Hats off to every single one of them. Without their compromises, the state of the art today would be appalling. Maybe we'd still be using punchcards, who knows?
But all the same, we believe that these pioneers sacrificed the future for the sake of the present, so that they could build and deliver tools while they were still needed. They saved themselves person-years of effort by choosing pragmatic designs that cut corners, and as a result we the programmers have spent person-centuries writing boilerplate, working around permanent design defects, contorting our code into preposterous shapes, and screaming in desperation whenever we realized that we just couldn't get there from here. How long did it take Java to get proper lexical closures? About 19 years. That's a long time to wait for something that is considered a sine qua non by many developers.
We knew that we weren't going to get what we wanted out of programming if we waited for someone else to build it, so we rolled up our sleeves and got to work. Avail may have taken 20 years to build, but from your point of view, they are years that have already been spent. They are not years that you have to wait.
Is Avail natural language programming?
The articulate programming paradigm espoused by Avail is not about writing programs in natural language. I cannot be more explicit about this: programs should not be written using natural language. I ask the court, who on earth wants to write code like this?
If your reaction is, "Ulch! Gag me with a planet!", then you had exactly the same reaction that I did — except that I had to firm up my guts enough to actually write the damned thing, whereas you hopefully got to laugh at my hapless straw man.
This example has clearly been taken to its absurd, ham-fisted extreme, and there are certainly less horrible ways to implement the quadratic formula using natural language. But every solution that uses natural language is going to have a similar bouquet of horribleness, because natural language is exceptionally poorly suited to mathematical discourse. There is a huge mismatch between the problem domain and the solution domain. Natural language is the wrong language for the job.
With a few more planned updates to our compiler, like macros (methods that run on phrases to produce phrases), we could actually write something like the silliness above. But a real Avail implementation would look more like this:[1]
This is anything but natural language, as I'm sure you'll agree. It lacks the lovely typesetting that you would see in a textbook, but this is unmistakably the quadratic formula that you learned in primary school.
Avail provides you the tools necessary to use the language that is appropriate for the task at hand — for any task, not just a half-dozen tasks that the language designers targeted. This is what articulate programming is all about.
It just so happens that articulate programming often employs pidgins of natural language, because there are very many contexts in which it is actually quite useful. Consider the following official Avail example, which implements a short choosable path story based on the British sci-fi comedy franchise, Red Dwarf:
I consider this a very strong recommendation for an English pidgin — in the context of building a choosable path story, this is definitely the way to go.
Does Avail require English language proficiency?
Today it does, yes. The standard library is written using English keywords, and all of the Stacks documentation is English. The compiler's error messages are also English, as are the user interface elements of the workbench. This is basically the same situation for every other programming language that has ever existed: the core tools are written for English speakers. English currently enjoys the privilege of being the lingua franca of computer programming, so keywords are basically always English words or portmanteaux.
Given Avail's extreme support for Unicode and fluid syntax, however, it will be very easy to build modules in other languages. Not just modules that contain words and phrases in other languages, but modules that do not contain English at all. While it is very nice to have a lingua franca for programming, it would be equally nice to teach your children how to program without first teaching them a complicated and irregular foreign language — such as English, if you are one of the estimated 6.3 billion people who don't speak it as a first language, or one of the 5.5 billion people who don't speak it at all.
Why does Avail use so much Unicode?
Avail aims to reduce the mismatch between conventional typesetting and programming. Programming languages traditionally center around ASCII. They may allow Unicode characters in string literals, comments, or identifiers, but they typically shy away from Unicode operator characters. I will venture that this is probably because of the specter of APL and its notorious special keyboards.
This is very unfortunate, because there are many modern editors, keyboard drivers, visual character maps, and so forth that have excellent support for Unicode display and composition. The Unicode standard attempts, quite admirably and successfully, to map all useful characters from past and present human orthographies, natural or specialized, into a single character set. This is obviously the right substrate for expressing concepts in math, science, and language. Because Unicode has code points for so many characters that succinctly capture useful metaphors, we agonized over the mental hue and cry that we imagined arising from programmers and then embraced Unicode anyway.
To those of you who despise, um, characters… please let me direct your attention to the Convenient ASCII module that is delivered as part of the standard library. It contains the beginnings of an effort to provide ASCII renames of all Unicode methods. We haven't done a lot of work on this module yet, so this is definitely an area that could use volunteers.
Our long-term plan for Convenient ASCII is not to pollute our beautiful source code with silly ASCII approximations, but rather to provide the basis for a large suite of source-altering macros that enable a programmer to type ASCII expressions that are promptly and automatically translated into their sexy true (Unicode) selves by our upcoming integrated development environment.
Why isn't feature X supported?
First, make sure that your feature really isn't supported yet. Avail is brand new, and still woefully under-documented, so it is perfectly fair if you can't tell whether the feature you are looking for is supported. Most of the domain-specific features that you would expect to obtain from a third-party library, like a statistics package or a NoSQL database connector, are probably not available — yet.
But Avail is an open-source language with great core features. If you would like to use Avail, and you would also like to use feature X, then there is a very good chance that it can already be built using the existing core features and standard library. Please contact us if you would like our assistance, or at least guidance, in building an awesome library.
Feel free to fork the [https://github.com/AvailLang/Avail] repository. If you extend Avail in interesting directions or just plain fix bugs, we would love to get a pull request to review and merge!
[1] I told a little white lie with this code example. Right now, our message syntax does not support digits, so you'd actually have to replace 2 with an underscore and insert two : 2's type between the definitions of a and b. This restriction will be removed in an upcoming development milestone; using digits in method names turns out to be quite useful, actually.
[2] In fact, you cannot register for an account at this time. Accounts are for the Avail team and contributors. If you would like to become an active contributor, then please read the community page and follow the instructions there.
| Return to Documentation |
