Rogach on Scala

It turned out that spreading type annotations throughout all the code in all places where options are requested is not a good idea. And, of course, it is prone to errors - who likes those type annotations? When using such option parsing libraries, users usually end up creating a big object with fields corresponding to each option: object Conf { var apples:Int = 0 var bananas:Int = 0 } // ... parsing options ... Conf.apples = parser.getOption("option name", ...) Conf.bananas = parser.getOption("other option name", ...) Sure, this works, and usually flexible enough - but why would anybody want to create such boilerplate? And by the way, nobody likes var's in their code :) So in Scallop , I needed to cut down that unnecessary repetition. There are several ways: Create a compiler plugin. The most powerful option. And the least enjoyable - even given the ease of installing a compiler plugin using sbt, I doubt that anybody will install compiler p

Command line interfaces have been with us almost as long as computers themselves - first cli's were created  in early 1960s , only two decades later than first general purpose computer was presented ( in 1946 ). From that old times command line and command line interfaces became trusted and loyal friends of the programmer. Fast forward to modern times. Now, half a century later, graphical user interfaces seem to be triumphing over all other interfaces. GUI evangelists love to present pretty charts, which demonstrate that CLI's are dying. But is CLI really dead or planning to die? No way, of course. The whole UNIX philosopy is built around small, orthogonal utilities, each doing its small piece of work perfectly (think wc, cat, find, bash pipes). And, obviously, this effect is almost impossible to achieve using pretty graphical systems with lots of buttons, checkboxes, sliders, knobs and what-not. The "almost" part of that statement is what keeps the m