New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Jonathan Allen on Oct 27, 2008
Due to overwhelming customer demand, Anders has "relented" and allowed Optional and Named Parameters in C#. Just like VB, optional parameters are supported by including a default value. And like in VB, required parameters must all appear before any optional parameter.
Named parameters are also supported fully. This allows developers to specify the parameters in any order they see fit. This works with normal as well as optional parameters, one would expect to only see it when dealing with the latter.
When resolving expressions used as arguments, the order is strictly determined by the code making the call irregardless of the order in the function's signature. And though not recommended, this means expressions with side effects can be more or less safely used as arguments.
COM libraries have a bad habit of returning values as type Object. To address this, C# 4 will automatically promote any object returned by COM to the "dynamic" type. As we mentioned in the previous article, this allows late-bound calls on the object just as if the developer had manually written all the necessary reflection code.
The "ref" modifier will no longer be needed for COM calls unless by reference semantics are actually needed.
In the end this means code that used to look like this:
//C# 3
var a = (IFoo) obj.Foo(ref missing, ref missing,
ref missing, ref missing,
ref missing, 5, ref missing,
ref missing, ref missing);
var b = (IBar)a.Bar();
var c = b.Value;
//C# 4
dynamic obj = //some COM or DLR object
var c = obj.Foo(clientId := 5).Bar().Value
There was also a rumor about parameterized properties. We will post an update once we have more information on it.
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Agile Development: A Manager's Roadmap for Success
Five Key Practices to Agile ALM
SCM best practices for multiple processes, releases & distributed teams
I know there's huge demand for some of these features, but I'm wondering from which demographic its coming from. The .NET framework supports (or will support) most languages you'd ever need...
Thus, I can't help but feel that these "demands" come from people who shouldn't even be using C# in the first place. I used to ask for optional/named parameters a lot, but I also have a VB6 background on top of having worked a lot in dynamic environment. C# was more the "purist" language. If C# goes the "kitchen sink" way... which language will be there for purists (and considering the rise in popularity of C#, and the ups and down of Java, it seems like there definately is a market for these "pure" languages).
Right now all I can see, is C# with a bunch of custom FXCop rules to weed out potential messes.
I agree 100%.
I come from an C & IDL background as two different languages for two different purposes. I now see C# growing out into a massive mess (the kitchen sink you're talking about) and that's not a good thing.
Especially with the possibilities to easily interconnect to different .NET assemblies in different languages, I don't understand the need to stick everything in one basket instead of just writing different, smaller, more specialized languages for .NET.
In this fashion, each team/company will only be allowing a subset of C# which will only confuse new developers/teammembers who were used to using the rest.
I guess I'll just watch it and continue pondering.
Not a big need to watch to see what will happen: it happened before, so the outcome is obvious.
Java anyone? It used to be the lean and mean "purist" language. It had very few, very consistant constructs. It -was- missing some (generics), and they were added... but then they felt the need to add everything. What happened? Exactly what you mentionned: people turned to arguably better, specialized languages (Groovy, Scala, etc). Java isn't going away because it IS still good, and it is the cobol of our time (so much done in it), but people aren't happy about it. Thats half the reason .NET was successful in the first place.
No one want a kitchen sink language... C++ was enough. Same thing will happen with C#... someone will build a new language, similar to C#'s root (plus the actually useful extensions, like lambdas and LINQ), and C# will be legacy "so-much-code-already-written-we-cant-throw-it-away" stuff.
Does no one learn from history?
The target demographic is people who need to use COM.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
4 comments
Watch Thread Reply