4 posts • joined Monday 9th October 2006 11:28 GMT
Nice to see.
I'm a contractor.
This is what we are for. You should use us as short term replacements for missing skills while you bring existing staff up to speed, or as short term placeholders while you find suitable staff to fill a spot permanently.
Sure, in tight job markets you might hang on to a decent contractor for the longer term, but at times like this it's only prudent to thoroughly trim the contractors before you consider letting the full timers go.
Not that I have a problem with it if a company wants to hang on to me in these circumstances - but it doesn't strike me as a sound business sense and it's nice to see Google yet again doing the right thing (doubtless Orlowski can put a sinister slant on it though).
Vested interest much?
So a man whose "repair business" presumably makes money from battery replacements and the like is the go-to man for comments on EU legislation? I smell a press release recycled as news.
Take a look at the internals of Hibernate and you'll see that they rely on a very substantial number of additional libraries.
It's not driven by the availability of more comprehensive standardisation efforts, since Hibernate was entirely unblessed by any standard (on the contrary, it has inspired many of the new features of the EJB3 specification).
No, framework creation is a bootstrapping problem. Sun made an incredibly good call when they made the *standard* J2SE class library so vast. With such a bulk of basic functionality already provided for you, it's easy to build upon it. The first generation of tools, bells, and gizmos, were basic library additions (log4j, dom4j and the like) - and these made extensive use of the standard libraries. They also provided an obvious starting point for future standardisation efforts.
With these gaps filled and de facto standard libraries added to the actual standard ones, it became practical to build substantial frameworks without having to reinvent a dozen new types of wheel in the process.
This ecosystem is what was missing - no substantial universally available set of library functionality for C++ existed. Instead dozens of platform specific or commercially restricted packages became available.
The creator of a new C++ framework must either roll together all of the basic functionality from scratch, or necessarily restrict the available audience to those who are able or prepared to accept their preferred subset of libraries.
Which is why I'm an ex C++ programmer, and a current Java developer.