- All too often, people seem to come up with dreadful implementations of IoC that either exposed all of their application to the container or they used some sort of “God object” container to handle injection into every part of the application.
- The way to avoid the above problem was given the rather insulting term “Poor Man’s DI”, which was unhelpful as it naturally discouraged those learning about DI from using it.
During early 2013, I was indulging myself in a “thought experiment” language: Lapsang. One such thought experiment was around the idea of whether a language could sensibly support the concept of not throwing exceptions for petty, unexceptional, reasons. Continue reading “Introducing Succinc<T> — functional additions to C#”
ISuccess<T>interface. As I explained in a previous post though, by itself that interface isn’t much use. C# lacks the ability to define constraints on an implementation of
ISuccess<T>, save through comments. The idea behind it was that an implementation should throw an exception if its
Valueis read when
Successis false, but there is no way to guarantee that an implementation will exhibit this behaviour. This bugs me.
Unrelated to SuccincT, I’m a fan of defining data objects via interfaces, rather than concrete types. By “data object”, I mean any object that encapsulates a set of values. These might be used to avoid multiple parameters to a method or constructor, or to return a complex data set from a method. Data objects need not be immutable or serializable; they just need to be simple to use without causing problems when it comes to testing. As I like to encapsulate data, I like the setters of data objects to be internal, which does cause problems with testing. Thus why I like to use interfaces: the test class can define its own implementation, rather than having to fight against encapsulation. However, for every interface I create, I have to create at least one class too. This adds needless code to projects, which also bugs me.
These two things – wanting interfaces to define a more detailed contract and wanting to avoid having to write data object classes that can be 100% inferred from the interface – set me thinking: could I create some way of extending interfaces and avoiding writing data object classes? Continue reading “Some thoughts on expanding SuccincT to provide richer interface contracts and auto-generated data classes”
This is a historic post, which I felt needed updating to reflect my current position.
Whilst I still feel that NCrunch is expensive, I feel that price now needs to be put into context. In the three years since writing this, I’m been waiting for an alternative to appear, at a more reasonable cost. The obvious candidate would be JetBrain’s dotCover. That latter product has improved greatly over the last couple of years, and is much cheaper (ReSharper Ultimate, which includes ReSharper, dotCover and other tools costs $957 over three years, versus $577 for just NCrunch over the same period). However, dotCover still doesn’t run your unit tests in the background as you type. It only runs on a build.
Because of this, and despite its high price, I now both have a licence of NCrunch for myself and have budgeted for buying licences for the rest of my team during 2016. It’s expensive, but I’ve reluctantly concluded it’s a justified expense.
Around a year ago, I restarted developing using C#. I’d used it a few years previously, but hadn’t really looked at it for more than four years. One of the big changes I noticed was with free libraries and tools. When of the things that used to frustrate me with the .NET world was that it was affected by the Windows “charge for everything” mentality. In recent years though, that has changed and free, community-driven, tools and libraries are now plentiful.
Another big change has been the change in attitudes to testing. Four years ago, many developers didn’t know about test driven development (TDD), much less use it. This of course applied across the industry, not just with .NET. I discovered though that – thanks to Remco Mulder – C# had probably the best unit testing tool ever: NCrunch, which was free whilst in beta. Continue reading “NCrunch: or how to ruin a product with greedy pricing”
Now I should make it clear that until recently, I regarded myself as a C# and ActionScript programmer. I’m new to Java. This isn’t strictly true, as I used Java back in its Java 1.1 days, but its changed so much since those days (and I’d forgotten most of it anyway), that in practice I’m a Java newbie. As a result, I naturally judge Java against C# (and to a far lesser extent, against ActionScript).
C# owes its existence to Java. Languages prior to Java may have had garbage collection, reference types rather than pointers, bytecodes, just-in-time compilation etc, but Java bought these technologies into the mainstream. As it came after Java, C# was able to adopt all the good points of Java, and scrap the bad stuff (the getter and setter mess of Java is replaced with elegant properties for example). Whether it did this successfully or not is a matter of opinion of course. From my point of therefore, Java automatically deserves respect, but it doesn’t deserve automatic authority. People grow old and wise, but also grow set in their ways. Programming languages appear to do the same.
Despite its seniority, Java has some clear advantages over C#. Breaking to labels is a glaring omission in C#, which Java has. C# requires the use of the evil-incarnate “goto” to simulate breaking to labels. Also the XML mess that is documentation comments in C# is pure farce compared with the simple elegance of Javadoc. Java has a whole raft of deficiencies though, and the two biggest ones are the lack of anonymous functions (let alone closures) and the lack of properties. Both have been proposed for Java 7, but – according to Sun’s presentation yesterday – neither will now appear. On a lesser note, Java 7 will not support operator overloading either, so string comparisons will remain using the grossly messy .equals() method to compare string value. This is a minor issue in comparison with properties and closures.
Why are anonymous functions/ closures and properties such a big deal? Both can be worked around in Java. Properties are after all just a neater way of doing getters and setters and people have come up with bodge simulations of delegates for Java. The big deal is that these are basic features of modern languages. Even the somewhat “noddy” scripting language, ActionScript, manages to implement both. Every other JVM-based language that I know of – JRuby, Jython, Groovy and Scala – all support closures.
Java is old and is becoming set in its ways. Language developers always run into problems with balancing feature advancements with avoiding breaking legacy code and Java is no exception. Perhaps we need to accept that closures and properties will never come to Java as it is just too difficult to implement both neatly, without breaking backward compatibility in too big a way. If this is the case, then perhaps Java 7 should be the last version of Java and it ought to be retired and replaced with a younger, more adaptable language.Whether the growth in alternative JVM languages is a sign that people are already moving on from Java to newer languages is difficult to judge. JRuby, Jython, Groovy and Scala are all dynamic languages. Dynamic languages have seen a general resurgence in popularity recently. What is needed though is a static language replacement to Java. One that can seamlessly interact with legacy Java code, whilst supporting modern programming principles such as closures, operator overloading, properties etc, along with support for dynamic types (without being inherently dynamic), functional language principals such as currying and lambda expressions.
The more astute of you may spot where I’m heading here. Just as C# was born of Java, so perhaps we need a new version of Java, born of C#. Being a English tea addict, who is pretty indifferent to coffee, I propose (not very seriously) that we call it Lapsang. C# itself is starting to get old, and many of the new features – such as extension methods – have been implemented in an inelegant manner to avoid the backward compatibility issues that new keywords bring. So just as C# took Java’s good bits and added more of its own, Lapsang could take C#’s good bits, add a few new bits of its own (build concurrency into the core of the language for example) and give the JVM another 10+ years of life.
Java proberly is a dying language and it risks taking the JVM with it. If Sun (or IBM perhaps, if they buy Sun) bite the bullet and retire it as the prime JVM language, then there is no reason why the JVM cannot thrive and grow for many more years.