About the Project

The JBISC project was started in the fall of 2007. The goal was simple. Create a programming language for every day use, similar to Perl, Ruby, Python and so on. Just like many other projects out there, JBISC is another attempt at programming language fame and glory.

Why, you might ask. Why create yet another programming language, when there are so many to choose from already? The answer to that question is twofold. Creating a programming language requires knowledge normally unseen by Joe Hacker. When using a programming language you take lots of basic things for granted. Things like variables for instance, or functions. Knowing how, and maybe even more importantly, why things work the way they do makes you a better programmer. The best way of finding these things out is to create a programming language yourself. The other major reason is because it's fun. Simple as that.

JBISC will be purely study material for the next few years. Because it's primarily a scientific endeavor, documentation is the actual product. The project will already be successful if a complete, workable language specification is produced. Of course a proof of concept interpreter will be written to ensure feasibility of the specification.

Language Goals

To make sure the language has any chance of gaining popularity at some point, some goals have to be set out. The following short list of goals describes the project's vision, direction and general rules of thumb.

• Simplicity
  The language should stay simple. With a small amount of syntax a Turing complete language can be built. Adding syntax makes languages easier to write, but harder to master. JBISC will try to minimize the amount of syntax, and reuse existing syntax in a logical way instead of adding new syntax to solve new problems. A good example of how things can get terribly out of hand is C++. Another aspect of simplicity is the very basic premise of only one way of doing things. There's simply no point in having five ways of traversing arrays, other than appealing to developers too lazy to adapt. Forcing a uniform way of doing things helps the language gain readability, and indirectly helps developers to be more productive. Of course this also slims down the preprocessor, which makes a JIT compiler an even more viable option.
• Openness
  The language specification and implementation will both be available under free software licences. The CCPL-BY-SA and the GPL, respectively.
• Portability
  The low level system calls made by the JBISC virtual machine shall adhere POSIX standards as provided by The Open Group. Exceptions have to be made for certain operating systems, but these exceptions should be invisible for the JBISC developer. Filesystems will not be abstracted.
• Extendibility
  The interpreter will be able to be extended by third party modules, only adding types to the JBISC language. Since all types will be classes, module functionality will reside in the methods of those types.
• Limit scaffolding
  This kind of relates to the simplicity goal. Many languages use language syntax characters on places where there's no need for it. For example, the parenthesis around a conditional statement between the "if" keyword and the body in C-like languages is completely unnecessary. There's only need for a separator between the conditional statement and the body. Python is a language which has taken this to the extreme level and traded the ability to avoid block syntax against free indentation. JBISC won't go that far, because block syntax can be reused to solve other problems. The goal behind the limitation of scaffolding is to enable the programming language to mimic written language, which in turn adds to the readability and thus maintainability of the code.
• No memory management and cleanup hassle
  JBISC will not bother the developers with memory management. This is pretty much mandatory since Java. It lowers the amount of possible programming errors and vastly simplifies development. This does indirectly limit the language from running natively, making JBISC dependant on a virtual machine, which implements the memory management and cleanup functionality.
• Both fixed and dynamic typing
  Fixed types have been used by programming languages since long before most of you were born. Fixed typing can be used for a lot of useful things like defining interfaces and protocols at a low level. They do add typecasting problems which slow down development. Dynamically typed languages aim to fix that, while sacrificing the useful bits. Truly dynamic typing does not exist. Every dynamically typed language uses fixed types internally at some level. Making types inherently dynamic will cause problems at some point. While some languages accept these problems and offer ways around them, JBISC will not. JBISC will use dynamic types by default, but will offer type checking and fixed types also. Types can be both user defined and discovered at declaration.
• Full OOP support
  The entire language will be object oriented, with a few minor exceptions. Basic types like integers, strings and arrays are limited in their OOPness, since their implementations will be fixed. Every integer will be an instance of the integer class, and so on. Even functions are instances of a virtual class describing the arguments. Type checking, as previously mentioned, will essentially be a "is this an instance of 'type'" kind of check. The great thing about having only objects is the extendibility. To use the integer example again, the integer class can be extended into an imaginary number by adding a second value to that class. JBISC will be purely object oriented, meaning it will have support for all of the common object oriented functionality. The language will add runtime support for acquiring object contents.
• Limited AOP support
  With aspect oriented programming back in the spotlights, JBISC will happily jump on the bandwagon. The language will not be a real AOP language, but will have some AspectJ-like support for AOP. It will be able to add triggers on user defined function calls without editing them.
• Scope stacking
  JBISC will try to simplify scoping by making scopes stackable. Access is only granted into parent scopes.
• Named namespaces
  Namespaces will essentially behave like prefixes, and can be called outside of the namespace by calling the namespace by it's name. Unlike scopes, namespaces do not restrict access. Also, namespaces will be objects which can be passed around freely.
• Blocks of code are also objects
  A block of code, in C-like languages the code between '{' and '}', will behave like an object. It's basically putting every block into a function and making the entire function scope static. This will enable developers to freely pass around little blocks of programming logic while preserving the state. These objects of code are usually called closures. Both Lisp and Ruby, among others, successfully implement this technique.
• Useful debugging support
  There will be syntax provided to add debugging symbols to the code in order to supply the user with additional information next to the currently executed line of code and the state of the virtual machine. This should further simplify debugging without abusing the standard output.
• Extensive multi threading and multi host support
  Adding features like atomic blocks, inter process messaging, automated locking of shared memory blocks, execution queues and groupable locks, parallel programming should become a lot easier. JBISC will also support the offloading of jobs to other JBISC processes, even to processes on other hosts across a network.

Project Status

At this moment a first language specification is being written, discarded, rewritten, lost, updated and translated. When the product of this process adheres to the guidelines stated above, it will be published and (hopefully) reviewed.

Since collaboration in creating language syntax is prone to heavy discussion, the first draft is being written in a classic non-public way, using face to face peer reviews and purist ranting sessions.

Who develops JBISC?

JBISC is the brainchild of this Dutch software engineer. Several people have already expressed their ideas about modern programming languages. Your ideas, of course, are always welcome.