Re: N3.js 0.2.0: now with browser support

On 04.12.13 12:37, Ruben Verborgh wrote:

Hi Ruben,

> But it even starts before that: I use JSHint to ensure that all code
> (main and test) conforms to my own rules. I'm pretty strict about
> that, even enforcing stylistic things such as proper indentation
> [2]. I have a pre-commit hook that a) runs JSHint and b) executes
> unit tests. I cannot commit if either fails.

that's cool, do you share that somewhere?

> Testing-wise, I have the same attitude as with backups: a file that
> is not backed up is lost. Hence, a feature that is not tested is
> lost. That said, always remember Dijkstra when you test: “Program
> testing can be used to show the presence of bugs, but never to show
> their absence.” I create tests that verify desired functionality,
> emphasizing the highlighting of likely bugs.

I fully see that, unfortunately I'm not the fastest when it comes to
learn languages. JS was and is quite hard for me to learn (not sure why,
Perl/PHP was and is a no brainer for example). The whole test driven
development stuff scares me as well as I lack the experience of how to
start with tests, confuses me more than JS itself ;)

> indicator whether it works or not [8]. Honestly, never rely on
> opening a browser manually for browser tests. You won't do it, and
> things will break. In addition to browserify, which generates "heavy
> code", I also have a custom build script that excludes Node-specific
> things. In my library, this means Streams. I purposely build Streams
> as a layer around my code [9] for performance (!) and compatibility.

wow impressive with the tests in testling, didn't think of that.
Browserfy is pretty crazy too :) But I see your argument with heavy
libraries and Streams are not always needed.

> And the most crucial thing: discipline. Never be tempted to write bad
> code. Think maintainability, not short-term wins. Everybody can make
> complex things. Few can make complex things simple. I care a lot
> about aesthetics in my code, because beautiful code can be managed
> better [10].

I mentioned hat I started to use your N3 Lexer code for a SPARQL lexer.
I tried a lot of other stuff before but didn't get very far. With your
code I was able to create a basic SPARQL lexer within a few hours and as
I said I'm not the fastest JS coder. Which means I found your code very
easy to understand and well commented, which is not very common in the
JS world IMHO. BTW would you mind to have a look on what I did and give
me a feedback? Can put it on Github.

The next step is to create an AST from this based on Crockfords Top Down
Operator Precedence article [1].

I hope I manage to create a generic JavaScript SPARQL parser which could
be shared among projects. My goal is to implement SPIN [2] in
JavaScript. Austin did some stuff [3] in that direction but he said that
he is not very happy with the generated SPARQL parser based on PEG.

[1]: http://javascript.crockford.com/tdop/tdop.html
[2]: http://spinrdf.org/
[3]: https://github.com/Acubed/sparql-spin-js3

regards

Adrian

-- 
Adrian Gschwend
@ netlabs.org

ktk [a t] netlabs.org
-------
Open Source Project
http://www.netlabs.org