Profile cover photo
Profile photo
James “X” Nelson
Wise Words Woven With Will Wake Worlds
Wise Words Woven With Will Wake Worlds

James's posts

Post has shared content
Havin' a great time bein' silly with waifu on the beach <3
Couldn't ask for a better partner than +James Nelson during this pregnancy. Goofing around after our bump photo shoot! More photos to come.
Animated Photo

Hey all.

It's been a while since I've posted here, but I have been hard at work on an interesting little project. I've been using a bit of ReactJS at work, and it inspired me to consider how we can get a similar level of simplicity and nice, declarative UI with simple binding to program logic.

With this in mind, I've forked the javaparser project to enhance the java syntax to allow something like this:

Element e = `<MyComponent
addClass=.className { font-weight: bold }

This code is run through the parser, translated into a method call with a plain, escaped (ugly) java string, which a compiler plugin intercepts, looks at the assigned type, says "ah, you want an element, lets run this through our element generator". The generator parses the html-like syntax, generates a complete AST, then hands that AST off to a visitor which generates valid java code.

The final output (currently) looks like this:

Element e = new ElementBuilder(MyComponent.class)
.addClass(injectCss(".className{font-weight: bold}"))
// injectCss injects the css and returns the single classname selector used
.on("click", this::onClick)
.addChild(new ElementBuilder("div")
.addChild(new ElementBuilder("my-element")

While technically effective, this solution is inefficient in that it generates a pile of procedural code that does manual DOM operations instead of leveraging fast things like innerHTML, cloning nodes or HTML templates. Ideas for more optimal generated output are welcome; I have a few ideas, but do not want to derail this post on the many possible maybes.

In addition to this HTML-like syntax, there is also support for json notation for maps, css notation for inline style or whole blocks of style rules, and a twinkle in my eye around using constructs like <if isNotNull=(something)> <conditionally-ui /> </if> to declaratively handle some amount of control flow in the template.

My intention for this is to be able to generate cross-platform UI using a single declarative language, which is why the generator is pluggable. Like GWT.create, it checks expression assignability to choose the correct generator for the expected type. I'm also working on a ui abstraction layer that looks DOM-like, but does not reference any JS Element types in core code. Only the HTML implementation knows that we are using DOM elements, so that an android or even ios implementation can hide the native components behind the abstraction layer so your controller logic is completely ambivalent to the underlying implementation.

In another project, I have a web component generator which can handle injecting shadow DOM (html and css) using HTML templates and node cloning, then expose internal elements to a controller class. My next iteration will marry the two of these to generate a smart controller class for your ui template, but I wanted to post this now to get feedback sooner.

Also, the `multi-line template strings are not standard java,
thus to use them`, you lose all the nice tooling and autocomplete that you are used to. So, to quell these fears, I will mention that the compilation process is multi-stage, and the first pass just translates all template strings to valid (ugly) java strings, and sends them to a method which is registered in a compiler plugin as a magic method. This means that if you can tolerate ugly java strings, you can skip the templating strings, and put valid java strings directly into that magic method, and tie directly into the compiler plugin which will generate the source you want without the original file needing invalid java syntax. An option to load by file will also be provided when I get around to it (to keep the templates external to code, if that's your thing). Finally, if you hate magic of all kinds, a method to do something UI-Binder like with annotations to point to files and the use of GWT.create to tie into standard infrastructure is certainly possible. I won't be bothering, unless there is a lot of interest / community support. Runtime template parsing and ui building, while possible, is not a short term goal. Ideally, because the compiler has the full AST of the parsed source AND the internal javax.model tree AST, we will be able to create smart generators that can completely resolve all inputs at compile time, and obviate the need for any runtime parsing at all.


I'm still a few days away from deploying code that others can download and play with (I need to release a new version to maven central because ....reasons). However, I wanted to share the progress with everyone here to generate ideas and maybe even lure in some beta testers who would like to play with this code.

Questions / comments / criticisms and ideas of all kinds are welcome!

Post has attachment
Places to go on your birthday: La Fortuna, Costa Rica. :-)

Post has shared content
A Last Gift from Ramanujan

Srinivasa Ramanujan is a legend of the mathematics world. The son of a shop clerk in rural India, he taught himself mathematics, primarily out of a book he borrowed from the library. The math that he did started out as rediscovering old results, and then became novel, and ultimately became revolutionary; he is considered to be one of the great minds of mathematical history, someone routinely mentioned in comparison with names like Gauss, Euler, or Einstein.

Ramanujan's work became known beyond his village starting in 1913, when he sent a letter to the British mathematician G. H. Hardy. Ramanujan had been spamming mathematicians with his ideas for a few years, but his early writing in particular tended to be rather impenetrable, of the sort that today I would describe as "proof by proctological extraction:" he would present a result which was definitely true, and you could check that it was true, but it was completely incomprehensible how he got it. But by the time he wrote to Hardy, both his clarity and the strength of his results had improved, and Hardy was simply stunned by what he saw. He immediately invited Ramanujan to come visit him in Cambridge, and the two became lifelong friends. 

Alas, his life was very short: Ramanujan died at age 32 of tuberculosis (or possibly of a liver parasite; recent research suggests this may have been his underlying condition), less than six years after his letter to Hardy.

When we talk about people whose early death was a tremendous loss to humanity, there are few people for whom it's as true as Ramanujan, and a recent discovery in his papers has just underlined why.

This discovery ties together two stories separated by centuries: The "1729" story, and the great mystery of Pierre Fermat's last theorem.

The 1729 story comes from a time that Hardy came to visit Ramanujan when he was ill. In Hardy's words: 

"I remember once going to see him when he was ill at Putney. I had ridden in taxi cab number 1729 and remarked that the number seemed to me rather a dull one, and that I hoped it was not an unfavorable omen. 'No', he replied, 'it is a very interesting number; it is the smallest number expressible as the sum of two cubes in two different ways.'"

This has become the famous Ramanujan story (and in fact, 1729 is known to this day as the Hardy-Ramanujan Number), because it's just so ludicrously Ramanujan: he did have the reputation of being the sort of guy to whom you could mention an arbitrary four-digit number, and he would just happen to know (or maybe figure out on the spot) some profound fact about it, because he was just that much of a badass.

The other story is that of Fermat's Last Theorem. Pierre de Fermat was a 17th-century French mathematician, most famous for a theorem he didn't prove. In 1637, he jotted down a note in the margins of a book he had, about a generalization of the Pythagorean Theorem.

From Pythagoras, we know that the legs and hypotenuse of a right triangle are related by a²+b²=c². We also know that there are plenty of sets of integers that satisfy this relationship -- say, 3, 4, and 5. Fermat asked if this was true for higher powers as well: that is, when n>2, are there any integers a, b, and c such that aⁿ+bⁿ=cⁿ? He claimed that the answer was no, and that "he had a truly marvelous proof of this statement which was, unfortunately, too large to fit in this margin."

The consensus of mathematicians ever since is that Pierre de Fermat was full of shit: he had no such proof, and was bluffing.

In fact, this statement -- known as Fermat's Last Theorem, as his notes were only discovered after his death -- wasn't proven until 1995, when Andrew Wiles finally cracked it. Wiles' success was stunning because he didn't use any of the traditional approaches: instead, he took (and significantly extended) a completely unrelated-seeming branch of mathematics, the theory of elliptic curves, and figured out how to solve this. That theory is also at the heart of much of modern cryptography, not to mention several rather unusual bits of physics. (Including my own former field, string theory)

And so these two stories bring us to what just happened. A few months ago, two historians digging through Ramanujan's papers were amused to find the number 1729 on a sheet of paper: not written out as such, but hidden in the very formula which expresses that special property of the number, 9³+10³=12³+1. 

What turned this from a curiosity into a holy-crap moment was when the rest of the page, and the pages that went with it, suddenly made it clear that Ramanujan hadn't come up with 1729 at random: that property was a side effect of him making an attempt at Fermat's Last Theorem.

What Ramanujan was doing was looking at "almost-solutions" of Fermat's equation: equations of the form aⁿ+bⁿ=cⁿ±1. He had developed an entire mechanism of generating triples like these, and was clearly trying to use this to home in on a way to solve the theorem itself. In fact, the method he was using was precisely the method of elliptic curves which Wiles ended up using to successfully crack the theorem most of a century later.

What makes this completely insane is this: Wiles was taking a previously-separate branch of mathematics and applying it to a new problem.

But the theory of elliptic curves wasn't even invented until the 1940's.

Ramanujan was making significant progress towards solving Fermat's Last Theorem, using the mathematical theory which would in fact prove to be the key to solving it, while making up that entire branch of mathematics sort of in passing.

This is why Ramanujan was considered one of the greatest badasses in the history of mathematics. He didn't know about 1729 because his head was full of random facts; he knew about it because, oh yes, he was in the middle of doing yet another thing that might restructure math, but it didn't really solve the big problem he was aiming at so he just forgot about it in his stack of papers.

I shudder to imagine what our world would be like if Ramanujan had lived a longer life. He alone would probably have pushed much of mathematics ahead by 30 or 40 years.

If you want to know more about elliptic curves, Fermat, and how they're related, the linked article tells more, and links to more still. You can also read an outline of Ramanujan's life at , and about Fermat's Last Theorem (and why it's so important) at .

Post has shared content

Post has attachment
Just a relaxed (working) Sunday at Chez Nelson, featuring Mrs. +Cecillie Nelson and our lovely cat children :-)
Animated Photo

Post has attachment
James Nelson and 1 other was tagged in James Nelson's album.
Animated Photo
Animated Photo
Animated Photo
Animated Photo
Saturday in Mississauga and Waterloo
39 Photos - View album

Post has attachment
Had a very wonderful birthday celebration with Mrs. +Cecillie Nelson at the #TorontoZoo  this weekend!  

Post has shared content
Woohoo! My video from GWT.create is live! :-)

Post has shared content
Probably the coolest new thing coming to the Gwt ecosystem!

Think angular style templating, except the binding is done at compile time so it's far faster than angular, with type safety and the potential for cross-platform code reuse to native Android, iOs and (if JUniversal pans out) Windows Phone.
Wait while more posts are being loaded