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 Ian Roughley on Jan 24, 2008
Concept programming started in 2000 as a private project in Hewlett Packard (HP) by Christophe de Dinechin, and is a way to
Cope with the increasing complexity in software by offering a new way to look at how software is conceived and created
In many ways, concept programming is solving the same problems as Domain Specific Languages. However the approaches are different. Rather than using a specific programming language, Christophe is creating XL - a general programming language. The reasons for doing this appear in an article for the RegDeveloper where he states:
The limitation with existing notations was that it was hard to find ways to add elegant extensions to them. You can extend languages like Lisp and its derivatives - but the problem is to get the extensions to look the way you want them to
Furthermore, the article goes on to explain
One of the intriguing aspects of XL is it has no fixed keywords - relying on what Dinechin describes as "shape": "XL does not use keywords - only a single syntax which can parse just about anything. The look of it is standard, it relies on a very small number of parse trees and instead of keywords it is based on the shape of the parse tree. This means you can play with it and experiment by adding things to it quickly."In a presentation by Christophe de Dinechin, he expands on the article, arguing that even simple problems are hard to implement in todays programming languages.
There is a gap between:
- Concepts, in your head
- Representations of concepts, in the code
Concept Programming is all about this gap
He continues on to say (that concept programming will)
Make the code “look like” the concept
- Similarity in structure, behavior, locality
- Principle of least surprise
Along with the concept, Christophe defines some pseudo-metrics. These are highly subjective and not easily measurable, but they do provide a way to communicate information. The pseudo-metrics he outlines are:
Syntactic Noise
- Form that doesn’t map to the problem space
Semantic Noise
- Meaning that doesn’t map to the problem space
Bandwidth
- How much of the problem space is covered?
Signal/Noise Ratio
- How much code actually deals with real problems?
To learn more about XL and concept programming, the XL project can be found at http://xlr.sourceforge.net.
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.
1 comment
Watch Thread Reply