gedit Integration

We now have gedit integration for JS++. The gedit plugin provides full syntax highlighting support, including support for highlighting invalid keywords. The JS++ plugin for gedit is more accurate than the default JavaScript plugin that ships with gedit for highlighting JavaScript (especially for regular expression syntax highlighting).

gedit

The feature for highlighting invalid keywords is useful if you come from a background like Java and expect the exact same syntax and aren’t quite aware of the subtle differences. For instance, class inheritance in JS++ uses a syntax similar to C++ and C#:

class Foo : Bar {}

If you accidentally use extends, you’ll be notified immediately:

gedit error

The gedit plugin will be distributed with the next version of JS++. If you want to download the gedit plugin early, you can download it from GitHub.

JS++ for GitHub Atom Editor

JS++ is now available for GitHub’s Atom text and code editor. Atom integration will be packaged into the next release of JS++; however, if you wish to download immediately, please download the code from the GitHub repository.

GitHub Atom

Installation is a simple 3-step process:

1. Navigate to the Atom packages directory.

On Windows:
%USERPROFILE%\.atom\packages

On Mac/Linux:
~/.atom/packages

2. Copy the “language-js-plus-plus” folder into the Atom packages folder.
3. Restart Atom. Done!

As usual, we remain committed to maximum integration across IDEs and editors, and we’ve repeatedly proven our ability to execute in this respect.

JS++ UltraEdit Integration

JS++ is now fully supported in UltraEdit. The UltraEdit wordfile can be downloaded from GitHub.

Syntax highlighting, code folding, and more are supported in UltraEdit. The UltraEdit wordfile will be distributed with the next release of JS++. At Onux, we are fully committed to maximum editor & IDE integration. Within the span of two weeks, we integrated JS++ into three of the most popular editors: Sublime Text, Notepad++, and vim. We now have support for UltraEdit and there is still more to come!

UltraEdit 1
UltraEdit 2

Sublime Text Integration for JS++

Sublime Text now fully supports JS++. Editor integration is provided and tested for both Sublime Text 2 and 3. JS++ support for Sublime Text extends to the whole nine yards: syntax highlighting, code folding, build system integration with error locations and navigation, symbol navigation, documentation generator support, and more.

Sublime Text Build System
sublime-text-symbols

As with all the previous editor integrations, the JS++ Sublime Text integration will be distributed with the next version of JS++. We want to re-state Onux’s full commitment to providing maximum editor and IDE integration. In the past two weeks alone, we have provided full editor integrations for three of the most popular code editors.

You can download the Sublime Text plugin from GitHub.

vim Syntax Highlighting for JS++

The popular vim text editor for *nix systems now supports JS++ syntax highlighting. You can download the code from GitHub.

vim

Just like the Notepad++ plugin, the vim plugin supports extra goodies like TODO comment highlighting and documentation generator comments. The vim plugin will also be included into the next release of JS++. At Onux, we remain committed to maximum editor & IDE integration for JS++.

Visit the GitHub repository to download the free vim plugin.

Announcing Notepad++ Support for JS++

Notepad++ now fully supports the JS++ programming language with syntax highlighting, code folding, etc. The free plugin, available on GitHub, also provides a few extra goodies like recognizing TODO comments and documentation generator comments.

Notepad++

The Notepad++ plugin will be packaged into the next release of JS++, and we are working to deliver maximum tooling for JS++ – beginning with editor & IDE support.

Visit the GitHub repository to download the JS++ Notepad++ plugin.

JS++ Goes Into Public Beta!

Today, we are proud to announce JS++ v.0.4.1 Early Access Preview. Along with this release, JS++ is officially going into public beta.

With JS++ v.0.4.1, you get a fully “typed” JavaScript superset which leverages the patent-pending JS++ type system. Here’s what’s new:

  • Array types, including jagged arrays (arrays of arrays)
  • Callback types
  • Major parser fixes. No more parser ambiguity bugs.
  • external type for parameters to explicitly mark parameters as the Unified External Type
  • Character literals
  • All integral suffixes have been implemented
  • Removed ECMAScript’s Automatic Semicolon Insertion (ASI)
  • Bug fixes
  • New samples: drag & drop examples and jQuery animation
  • New tutorials

This release was about solidifying JS++ and fixing as many bugs as possible so that we would have a rock-solid typed JavaScript superset. To this end, the major bug fixes are actually in the parser which should be 100% attributed to our team member, Anton, who has had full responsibility over the JS++ parser since the beginning of the year. The parser was completely re-done and is now stable and very well-tested with over 3,000 test cases and 184,000 assertions.

The next release will see new keywords being added such as final, inline, and foreach.

From here, we will be working to deliver object-oriented programming (OOP) with classes and modules. This will “complete” the JS++ type system. Interesting things are on the horizon for JS++!

Optional Types: ‘null’ without NullPointerException

Optional (nullable) types will be coming to JS++. This usually stokes fears of null pointer dereferencing. For example, in Java, this is known as a “NullPointerException”.

In fact, Turing Award winner Tony Hoare calls it his billion-dollar mistake:

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

However, it’s possible to have nulls in a language without ever having NullPointerExceptions.

void doStuff(Foo foo) {
    foo.bar(); // Error, potentially null
}

In the above example, foo can be either an instance of Foo or null at runtime. This creates the potential for dereferencing a null pointer. This is an easy fix though – we just check that foo is not null:

void doStuff(Foo foo) {
    if (foo != null) {
        foo.bar();
    }
}

By checking that foo is not null, we can guarantee foo is at least an instance of class Foo – thus making it very straightforward for us to check that the bar method exists. This is a process known as type refinement. What’s interesting is that the compiler is able to actually ensure you’ve made the check before you ever run your program. It achieves this by examining the control and data flow. This is cutting-edge research known as flow-sensitive type systems.

In addition, by examining the control and data flow, if we can ascertain that null was never passed into the doStuff function, type refinement would not need to occur, and you would not need to check for null. Thus, this code – with no null check – will still pass a compile:

void doStuff(Foo foo) {
    foo.bar();
}

doStuff(new Foo());

On the other hand, as soon as you introduce null, you need to check for null too:

// Attempt 1
void doStuff(Foo foo) {
    foo.bar(); // Error, 'foo' can be 'null'
}

doStuff(new Foo()); // ok
doStuff(null);      // now we need a null check
// Attempt 2
void doStuff(Foo foo) {
    if (foo != null) { // do the 'null' check so the code compiles
        foo.bar();
    }
}

doStuff(new Foo()); // ok
doStuff(null);      // ok

null is a first-class type in the JS++ type system so, combined with JS++’s sound type system, JS++ is able to categorically determine that you’ve checked foo is non-null without ever executing any code.

Design Notes: void and undefined

JS++ replaces the “void” keyword as a type annotation rather than being like JavaScript which dictates that “void” is a keyword used to evaluate an expression and always returns undefined. This doesn’t serve much practical purpose. You can accomplish the same effect in many other ways:

// Original
var a = void foo();

// Equivalent to:
var b = (foo(), undefined);
var c = (function(){ foo(); })();
// ... etc

Furthermore, “void” is very rarely used in real-world JavaScript. This is why I always say it takes an experienced JavaScript programmer to design a JavaScript superset. It takes someone with deep experience in JavaScript to identify this in order to make such a breaking change with confidence. If you’re introducing a breaking change, make sure it’s just breaking the 1% and not the 99%.

The enlightened few will use void 0 in place of undefined because the ECMAScript 3 standard defines undefined as a global property that can be defined!

JS++, on the other hand, makes undefined a keyword. void is then used as a type which represents both null and undefined.

Finally, there have been informal plans for a JS to JS++ translator. This will handle those few instances where void 0 is used to mean undefined and such. These cases are easy to parse and identify, and it makes introducing such a breaking change fathomable.

Design Notes: ‘const’

JS++ does not implement a const keyword. This was a design decision.

For instance, consider the following ECMAScript 6 code:

const x = {};
// Adding a new property, not "constant" at all
x.foo = 1;
// Changing the value of an existing property; once again, not "constant"
x.foo = 2;

x.foo; // 2

The variable x is declared as a constant using the const keyword. However, it very clearly is not constant (e.g. mathematical constants, which are typically our first exposure to constants). Where references are concerned, const does not actually create a “constant” and should thus be regarded as either a misnomer, and, in a worst case, should be disallowed as a matter of best practice in order to discourage semantic confusion and – consequently – bugs.

The situation is bad enough that Brendan Eich, the creator of JavaScript, even retweeted a blog post about this confusion:

es6-const

Instead, JS++ uses the final keyword. final prevents any further assignments to a variable; in other words, this is the last and “final” assignment. Thus, while the reference can be modified, the actual variable is still referring to that same reference. It was a final reference, and the reference we were referring to cannot be changed. Simple semantics and functionally identical, but it can go a long way in complex projects.

You never know if you’ll have a team member that doesn’t know the nuances of const, and – going back to semantic confusion – naturally assumes it works a certain way without looking it up and researching it. This is a common problem with JavaScript, where a lot of developers assumed it would be like C/C++ or Java and, thus, did not spend too much (if any) time learning it properly. Personally, I was guilty of much of the same in my early days. const being introduced into the official language specification did not take this behavioral issue into account and risks exacerbating the problem. (ASIDE: Issues like this, while minor and seemingly innocuous on the surface, can create exponentially many problems in larger applications and forced the hand for JS++ to break away from the ECMAScript specification – among a host of other problems.)

Yes, languages like C++ get away with using const. However, it can be argued that it’s so deeply embedded into the language in special ways it almost forces programmers to read the documentation and learn about it in depth (see: “const correctness” in C++). When you see:

const int *const ptr = &x;

You begin to realize that there is more to const in C++ than you may have figured out through a pure dictionary definition. This is not so when you see this:

const x = {};

The latter example (in JavaScript) does not encourage you to read the documentation or best practices. When we make assumptions that we “just know,” it can be dangerous.

We made a design decision based on experience and observation in the hope that final will be better because it doesn’t necessarily encourage the “I just know what it does” attitude. When it does, they should already be familiar with how it works from Java – a correct, consistent, non-confusing, and – most importantly – safe expectation.