New Hammer

The joy of a new hammer. Everything looks like a nail!

Been working with Google V8 i.e. JavaScript for integration professionally for a while now, and I'm getting more and more convinced that JavaScript should be the target for Dawn, rather than Java.

JavaScript and Dawn are both prototype based, so I could probably piggyback of a lot of functionality there. V8 let's me execute outside of browser, and I was going to implement a JavaScript version at some stage anyhow.

Unfortunately BNFT is implemented in Java, and I have no desire to implement it in JavaScript (right now). So I might have to live with a first version of Dawn which requires Java to compile and V8 to run.

Actually it might be even better than that since BNFT would have to be implemented in Dawn anyhow - so if Dawn comes together nicely I may be able to skip the JavaScript version entirely. The downside of all this is that a trimmed environment will probably only exist on my machine until I get there. But if the alternative is no release of Dawn, I guess Ill have to live with it.

Still holds..

Ah - deadlines.

My self imposed "Speak - or be forever quiet" deadline is slowly creeping in on me.

Busy with my new work, there is a shred of fear that I might not get there.

Only a shred though, since I can easily fake it and make a 0.0001 version release of something remotely Dawnish.

Well, since BNFT is in a stable version, it should actually not be that big an issue to churn out a version of Dawn (!!). Im currently following Erik Meijers Haskell lectures, and finding many similarities although only on the conceptual level. Like Haskell Dawn's core functionality is small, and most of the "meat" is in the library. Interestingly enough one of Haskells envy points for OO is the "." notation - which Dawn embraces and provides override for - the REAL innovation in Dawn.

This should serve as more of a carrot for me, since Dawn may illustrate a method for improving libraries - and I would like to see Haskell take that road using the pure functional paradigm.

I was trying to explain Dawn to a relatively green programmer the other day, and I illustrated it by saying that whereas Haskell provides a pull notion (lazy, functions) Dawn tries to do the same with a push notion. The point was wasted though since he didn't know Haskell :-)

BNFT V1.01 - now with Mac scripts

An update to the BNFT packet.

A small bug crept in, causing the last char of the input to be ignored, was fixed.

All examples now have both .bat and .command files for running them both on Windows and Mac.

Enjoy!

Immutability

Immutability is also a big buzzword in these days along with all the functional buzz - guess they are sort of related. As stated earlier I'm not opposed to functional and other approaches, I'm just wary that all the paradigms are not solving anything - I mean they are mostly trying to keep data consistent and thus not deal with inconsistencies, but my point is that there will always be an outside, a side effected world where inconsistencies cannot be avoided.
Therefore I'm (with Dawn) investigating patterns to deal with inconsistency, instead of trying to design my way around it.
Needless to say that parts of the world WILL have to be transacted and consistent, but a general pattern that can deal with inconsistency can also deal with consistency.

BNFT V1.00 released

The BNFT tool have been released!!

I managed to put up examples, and a small snippet of documentation although there are a lot of specialities and things to be aware of.

Anyhow, BNFT is a tool I'm gonna use to create Dawn - in its first unoptimized guise, and BNFT is also instrumental to the claim that Dawn is syntax agnostic. BFNT will provide the tools to convert to and from the individual flavors on syntax. One thing missing is python style blocks, but I have the design clear for parsing pythonic blocks, which means that programmer will be able to choose between "{" & "}", "BEGIN" & "END", pythonic style blocks or a fourth block style.

BNFT is also a great testbed for DSL, or a tool for extracting structured information from textual logs or other sources.

BNFT V1.00

Commments, bugreports, usages are all wellcome.

BNFT part 1 done

Ah, small steps

The "biggest" advantage of being a lazy programmer is that programming tasks gets designed to a minimum of programming. I have spent some time trying to port it from C++ to Java, which proved to be a b*st*rd (inglorious or not). At some stage I thought about how I usually implement parsers very quickly and decided to try from scratch.

Turned out that 3 hrs was enough for mocking the parsing part up (while trying to use only simple java, so it would port easily to other langauges).

So what remains is the execution part, for which I have designed an even simpler and speedier design that the original. By "accident" I came up with a lazy evaluation scheme, which should be pretty efficient, considering what the original tool did, with an abundance of stacks of strings (which was the ports biggest problem).

Now I will build a tree to do the second level parsing, which while traversion will build a second tree, where I call the an eval function to get the result in the end.

This means that the parsing itself will not be optimized, but putting together the answer will only take the "correct" path into consideration. Should be simple and nifty.

Hopefully I will soon have time to implement the last part so I can release it.

Exceptions revisited

Exceptions are another of those constructs that puts the power with the designer/implemeter instead of the user. The designer decides to throw the exception - now the user HAS to handle it by hook or crook.

To reverse the power the current exceptions style mechanism has to be remove. As stated earlier Dawn does not have return value, values are propagated forward through calls. Thus is it easy to signal errors by calling forward through an output. The user can ignore it, which puts the responsibility on the implementer to make sure that the component lives with faults without terminating or crashing.

The user can decide to pipe this error output into a logger, or reinstate the exception mechanism by terminating the scope (for which I have to find a graceful mechanism, break is not my favorite keyword).

This will lead to fault oblivious software, where faults in functionality will be faults in functionality only - not the mess today where faults in functionality can lead to application crashes, which makes a fault more serious than necessary.

This is also why null is NOT a big mistake - its just the handling thats the mistake i.e. the crash. Just be oblivious to it, and grace is reinstated.

What? Faulty software? Ah, you still live in the world where you think software can be without faults..