It's interesting to me that languages are still a bit primitive in their seeming indifference to modern software development methodologies.
People often talk about the "next" big languages, and bring up points such as speed, blending of functional/imperative idioms, cross-platform support, etc. But though a lot of this is good, important work it's also very much rehashing old ground. What I think instead we will begin to see within the next decade or so are languages which take the lessons of modern software development practices to heart.
For example, consider modular compilers and the ability to perform source control merges at not just the plain-text line-by-line level but at the parse tree level.
Or, languages designed with refactoring and IDE auto-completion/intelli-sense in mind rather than as a bolt-on after-thought.
Or, more to the point, languages which are designed around the ideas of TDD, BDD, and mocking. To where mocking falls out of the language naturally and effortlessly, or where TDD is as simple and intuitive as REPL. Instead of as it is today, where a lot of this work seems like fighting uphill.
totally agreed; there is an abundance of research in the academic literature from the past 15 years that still have not been properly commercialized. technology transfer between academia and industry is often a slow and bumpy process, but eventually the good ideas will find their way into the mainstream, i think
(i don't know why you got down-voted for this comment; i just voted you back up)
Mocking seems to me to be a perfect example. Of how obvious it is that we are fighting against the flow with so many of our tools and we are merely lacking the advances in language design which embrace these use cases at their heart. It seems very similar to the clumsy, piece-meal attempts at procedural programming through the use of various macros and such-like in the early era of programming, and later of the attempts at object orientation through various techniques and conventions. But none of those efforts were able to fully exploit the potential of procedural programming or object orientation.
You can't just bolt such fundamental shifts in programming idiom and practice onto existing languages and expect to achieve maximum potency. It often takes new languages, which have internalized the "paradigm shift", to fully achieve the potential of transformative development methodologies.
No amount of assembler macros can be as elegant or as effective in facilitating procedural programming as the C language, for example. Similarly, you aren't going to create Python within C unless you already have the idea of Python to work with.
I suspect that these aspects (mocking and unit testing especially) will become ingrained in future languages to degrees we can hardly imagine. I suspect that unit testing will be as much a part of many future languages as loops, assertions, and methods are today, and that running unit tests will be such an integral part of the build process that it will take explaining to describe how it's even possible for them to be apart.
Unfortunately, I think too many language designers are too satisfied with the current state of affairs and don't see the future in these terms.
I use Moq and enjoy it. I previously used NMock a little bit, and it was a big pain. The reasons Moq is cool, when compared with other such frameworks, include:
1) The mock setup routines use a clever and increasingly common hack involving expression trees (lambdas) to remain strongly typed, which fits nicely with the rest of the language.
mockObject.SetupGet(ob => ob.prop).Returns(42);
2) You can easily mock out a chain of property accesses with just one call, rather than having to set up a bunch of intermediate objects.
3) It doesn't matter what order the mocked methods are called in; in many ways it's more like a dynamic stub generator than a traditional mock object framework. Some people probably think this is a bad idea; those people can use another library. I like this mode, I think it makes it a lot easier to start using. And for testing libraries, that's possibly the most important part.
If you are looking at mocking in .Net, make sure that the framework you select can easily mock properties and delegates as well as simple method calls. I don't believe they all do!
There are two types of mocking frameworks for .NET. Most, like NMock, Moq, Rhino Mocks are written in managed code and cannot mock static, sealed or private methods. On the other hand Typemock Isolator, Telerick JustMock and Microsoft Moles are using the .NET Profiler API (using that requires some unmanaged code). The last 3 can even mock stuff from mscorlib, like DateTime.Now.
People often talk about the "next" big languages, and bring up points such as speed, blending of functional/imperative idioms, cross-platform support, etc. But though a lot of this is good, important work it's also very much rehashing old ground. What I think instead we will begin to see within the next decade or so are languages which take the lessons of modern software development practices to heart.
For example, consider modular compilers and the ability to perform source control merges at not just the plain-text line-by-line level but at the parse tree level.
Or, languages designed with refactoring and IDE auto-completion/intelli-sense in mind rather than as a bolt-on after-thought.
Or, more to the point, languages which are designed around the ideas of TDD, BDD, and mocking. To where mocking falls out of the language naturally and effortlessly, or where TDD is as simple and intuitive as REPL. Instead of as it is today, where a lot of this work seems like fighting uphill.