Sunday, September 20, 2009

those redundant brackets :)

this or similar fragment of code :
val a="Hello"
println a
for (i<-args data-blogger-escaped-blockquote="" data-blogger-escaped-i="" data-blogger-escaped-println="">will produce the following error from Scala 2.7.5 compiler:
error: illegal start of simple expression
for (
- which is an example of wrongly reported problem.
The real issue here not with for (which is fine) but with the fact that println argument is not in brackets, and there is no semicolon ending the string. Therefore, the compiler apparently tries to look ahead finding if there is more to add to this string, finds something it doesn't get, and reports an error.

Putting the brackets around the arguments in first println:
val a="Hello"
println (a)
for (i<-args data-blogger-escaped-blockquote="" data-blogger-escaped-i="" data-blogger-escaped-println="">solves it :)

Sunday, September 13, 2009

Found a remarkable piece in The C++ Standard Library of Nicolai M. Josuttis (very useful book, by the way) in the beginning of the chapter dedicated to valarrays:
The valarray classes were not designed very well. In fact, nobody tried to determine whether the final specification worked. This happened because nobody felt "responsible" for these classes. The people who introduced valarrays to the C++ standard library left the committee a long time before the standard was finished. For example, to use valarrays, you often need some inconvenient and time-consuming type conversions...
How many bells did it ring to you, dear software development experts? And we are talking about C++ standard here :) (More revelations about design flaws and omissions could be found in the chapters about the other Standard C++ library components, - bitsets,for example).

By the way, the book has been written 10 years ago and it's still relevant because not many things have changed there. The work to introduce a better C++ standard is going anything but quick.

This probably explains, at least partially, at least to me, why younger folks are turning to the other languages (I mean Java-based crowd) which are largely feedback-driven, with the ability to adapt and/or evolve quickly, and which don't have a gloomy committee overseeing the Grand Design in the authoritative way...