Is Beads is the most reliable language ever devised?

I designed Beads to make robust software that would be as bug free as possible. In my long career I have made every kind of programming error, some of those mistakes have been made tens of thousands of times. After all, isn’t that what programming consists of? The fun part is designing, then there is a the initial work of write the code and typing it into the computer, then the much more tedious phase of correcting mistakes. If programmers made almost no mistakes, the process would be much more enjoyable, and the resulting products would be more reliable.

The first way Beads reduces errors is by being simpler and briefer. Programs are noticeably smaller. Your mileage will vary depending on the language you are coming from, and the size of your project. If you doubt my word, take any of the several example programs we have and try recoding them in your favorite language. In word count it will be possible to match it, but almost impossible to beat, because there is so little “fat” in the Beads language.

Today JavaScript is the #1 language by lines written per year, and as a result, we are in an era of the least reliable software I have seen. JavaScript is a poor language from a reliability point of view, hence the many preprocessors like TypeScript, CoffeeScript, PureScript, and now Beads, which are used to produce web apps by generating JavaScript from a nicer language.

I started from a clean sheet approach, and set out to let the computer catch as many errors as possible, by making Beads a declarative language, where at compile time most errors can be caught. Then I looked at the historical sources of error, such as off-by-one errors, and eliminated them with a clever looping syntax that avoids common mistakes. There is even protection against infinite looping, something that almost no other language has protection for.

Arithmetic is air-tight, and with the universe base type of U and a universal error type of ERR, it means that errors are not concealed as undefined values, but are distinct and trappable immediately. In C and many other languages you create symbolic enumerated values that can be accidentally used in arithmetic. In Beads an enumerated type value cannot be used in arithmetic, which prevents very subtle errors.

Physical units of measure are a major source of error in engineering and scientific computing. Beads has all the common physical units pre-programmed with conversion factors, so you can add 3 kilogram + 2 pound and it will do the arithmetic automatically, and even at runtime units checking is done, thus eliminating this common error.

Another common error that trips up people in Java all the time, is the issue of a NIL pointer. In Beads we use the concept of paths, which can exist before a value is instantiated, thus reducing this type of error to the maximum degree possible.

You have to try Beads to feel how robust and clear your programs can be. If you take an existing program, and recode it into Beads, and I would be glad to help you, you can see the improvements with your own eyes. To give Beads a try, send an email to, and tell us what kinds of programs you like to build. Initially the web target is being supported, but the system is designed to generate iPhone, Android, and desktop applications as well.