Slightly amusing

So, I decided to write a parser . Silly me, I know. So if I am going to do this, I need to do it properly. So I am going to try and develop it using test driven approach and documenting the whole process in this blog as I go. This is the first article in the series of articles where I try to establish basics and bootstrap a project. First things first. To write a parser, you need to know at least some basics of the theory.  Some of things you need to know at least on the basic levels is the basic theory and terminology around  formal grammars ,  Chomsky hierarchy  of formal grammars and basics of automata theory . You don't have to become an expert (I am certainly not at this point), but the terms and concepts from these theoretical disciplines will crop up here and there and it There is a lot of literature out there about Earley parsers . Some of it even readable for mere mortal developers not used to the academic vernacular. The initial set of source info...

So, I've been interested in parsers for a while. There are plenty of opportunities to use a parser in our every day jobs, but for some reason, it does not happen very often.  Most of the time, when some task presents us that requires us to recognize some user input, we almost instinctively reach for regular expressions. Regular expressions are a very powerful tool, to be sure. Maybe even too powerful. With all the fancy additions like non-capturing lookahead and back references — regular expressions have become legendary source of obfuscation and subtle bugs in user input verification.  Over the years, I've tried my hand with various parser generator and combinator libraries (ANTLR, JavaCC, JParsec to name the few) and hand-rolled my own in couple of instances. Most of the time when using parser generators, I've felt like I am invoking this big machinery just to get something simple up. And then there's specific parsing technology quirks that I just have to know...

Have you ever seen or used this pattern of code: I've seen the above code and many variations of this pattern scattered all over the various java code bases I've read and it has always nagged me that although we have had the power of generics and the associated type-safety guarantees available at our fingertips for a long time now, this type of general registries of key-value pairs still involve this type of cast-heavy boilerplate. It stroke me then how often I have I seen just this pattern appear and re-appear so many times that I have all but stopped thinking about it.- "Of course, if you need an extensible registry of values, you use a Map of key-value pairs (or a Dictionary )" . And usually you either engineer your registry around same type of objects or you throw the generic typesafety out with a proverbial bathwater and map your keys (usually of the type String ) to values of type, well .. Object . Would'nt it be nice if we could actually ma...

I am slowly but firmly falling in love with the functional approach to programming. I know, it is not a silver bullet and it cant solve all of your problems, but there are aspects of functional style programming that I am beginning to appreciate more and more. Take for example Monads. There is a whole lot of talk about monads, monoids and whatnot floating around the intertubes, and through all that almost hard core mathematical chatter that is sometimes quite hard to see what one can benefit from using such a convoluted concept. Specially you get this question a lot when talking to Java programmers. Functional style programming can feel quite awkward in Java, with all the character noise inner classes bring with them, but sometimes it is not all that bad. Some of the functional style concept I've been exploring lately is what Haskell calls the Maybe monad . (Scala has it in it's Option class) Essentially, the Maybe class is all about entirely elliminating null refer...

I've been playing around with a crazy idea of recreating Eclipse JDT tooling with XText. While it does sound a fair bit more than a little crazy, it appeals to me for few reasons: It would give me great opportunity to learn XText and test it in a non-trivial setting. It would give me great opportunity to learn more about Java the language. Having Java source code parsed into a well defined EMF structure opens up JDT to all the  goodness of EMF tooling that has been developed over these past years. It seems like an interesting idea. I wonder if I actually get around to giving it a try...

Ever needed to perform some computation in another thread, and the return the result. Typically what you do is you create a Runnable, where you perform this computation, run it in the separate thread, wait for it to complete and then somehow get the value out of that runnable and return it to the caller. In SWT, this type of pattern is quite common when you need access to some widget values from outside of Display thread: Nothing really revolutionary in this piece of code — Since the only safe way to ask text of the widget is to ask it from the display thread, I am invoking syncExec on the text widget's display. To access the text field itself from the anonymous runnable, I have to declare it final . Also, to be able to return the value I need to write it to a local variable retValue , which needs to be declared final as well so that I could reference it from the inner anonymous class run method body. In order to be able to write to the retVal , I also need to declare...

After some time of observing he progress of e4 application framework development and reading some fine high level documentation and fidgeting with some of its samples and creating few toy projects, I decided to dive in at the deep end so to speak and try it out with somewhat more serious and concrete project. I am trying to implement a proof-of concept of an application that among other things needs at startup dynamically create a set of windows (one per each monitor) and go full screen with all of them. Reading the implementation of  E4Application (I must admit it is quite an interesting and educational excercise in itself) I found that I need to define a "Lifecycle handler" and intercept "processAdditions" lifecycle event to dynamically create new windows after the model has been loaded. At first I was struck by an apparent problem where I needed an access to a Display instance. At first I simply tried and to add it as an argument to my processAdditions ...

I was just hacking the other day our somewhat horrible hairball of an ant build to try to mold it to my understanding of how a build should work when I had a sort of an epiphany about why on earth I dislike Ant so much. Apart from the syntax (and I think it is universally agreed by now, that XML is a horrible, horrible language for scripting like tasks), what hit me is that while ant is okay for simple one-shot single project builds, it really falls on it's knees as soon as you start building complex modularized systems where you need some sort of dependency management. Now, before I go on, I must mention that I have heard of alternatives like make, Maven , Buckminster , b3 and the ilk, but I really don't know much about any of those (well, by the time I started to write this piece, I had taken a peek at Buckminster). I am not really what you would call a "build person" - I'm using Ant, because it's what comes with most of the projects I've been invol...

Optional iterators right now... Monads in terms of Java has been the topic that has caught my attention of late and while some of the articles out there have almost managed to penetrate my rather thick skull — I can almost see the potential benefits I can reap in terms of being able to design clean and easy to use apis — I still feel I am missing some crucial piece of information before the whole puzzle starts to make sense... Oh well — maybe it's best to simply let it settle and let these ideas mature a little in my head (I am sometimes slow, like this). Meanwhile I am getting kind of tired of all the boilerplate I have to write to get around potential NPE traps with this new and shiny for iteration syntax introduced in Java 5. Not that there is a lot to write, but it is kind of tedious and introduces something, that even has a nice buzzing name for it — "accidental complexity" into otherwise quite straightforward application logic.