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 Abel Avram on Mar 27, 2009
In this interview made by InfoQ’s Sadek Drobi, Don Syme, a Senior Researcher at Microsoft Research, answers questions mostly on F#, but also on functional programming, C# generics, type classes in Haskell, similarities between F# and Scala.
Watch: Don Syme Answering Questions on F#, C#, Haskell and Scala (47 min.)
Syme is provoked to talk about why Haskell did not end up as a .NET language even though it was seriously considered to be implemented on .NET at one time. He also talks extensively about F#, some of the decision made internally and their reasons, why some features entered in while others were left out. Among others, he explains what asynchronous workflows are and the intent to add dynamic features to a future version of the language.
Syme also expresses his opinion on Haskell’s type classes, talks about similarities/differences between F# and Scala, C# generics, and general functional programming topics.
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Why NoSQL? A primer on Managing the Transition from RDBMS to NoSQL
Case Study: IBM's Agile Transformation
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
It really explains a lot of things.
Excellent interview!
While the interview is interesting, I feel quite strange a strong F# influence has been completely forgotten here: OCaml, as F# has sometimes been described like OCaml with the addition of .NET Framework libraries.
Read OCaml influence here.
This being said, I agree that F# power comes from the fact different programming paradigms are mixed into a single language, so that, if one does not fit for the targeted task, the others could fit. Multiple-programming-paradigms languages are raising, and IMHO it's a good news, because they are more helpful; and it would change infinite debates like "my functional language versus your OO language", because both paradigms would be into the same language: these debates would go into another level.
Dominique
www.jroller.com/dmdevito
it would change infinite debates like "my functional language versus your OO language", because both paradigms would be into the same language
I don't believe in that. Can you imagine a language that supports both laziness and strictness equally well, type classes with all of the extensions, module system of ML, Lisp-style macros, both static and dynamic typing, a standard object-oriented system with both interfaces and mixins and Lisp-style multimethods? Both does and doesn't allow programmers to reassign variables? And both does (like Haskell) and doesn't (like everything else) have a separate type for non-referential-transparent functions? And then there is Prolog, which is something completely different. And some experimental languages like Agda with (as far as I understand) a programmable type-checker...
Oh and you forgot about Elephant2000 :)
I agree with you Dimitry and that is why I like languages like Haskell, Smaltalk, Forth, Lisp because I can think of them as a coherent and consistent set of concepts. Yet languages like F# and Scala might help people getting into Polyglot and multi paradigm programming :)
it would change infinite debates like "my functional language versus your OO language", because both paradigms would be into the same language
I don't believe in that. Can you imagine a language that supports both laziness and strictness equally well, type classes with all of the extensions, module system of ML, Lisp-style macros, both static and dynamic typing, a standard object-oriented system with both interfaces and mixins and Lisp-style multimethods? Both does and doesn't allow programmers to reassign variables? And both does (like Haskell) and doesn't (like everything else) have a separate type for non-referential-transparent functions? And then there is Prolog, which is something completely different. And some experimental languages like Agda with (as far as I understand) a programmable type-checker...
Well, I didn't want to say that with one ultimate language we would solve all debates, or whatever.
I wanted to say it's time to experiment, to cross old sterile frontiers, to change ever-during debates... while mixing programming paradigms into one language;
- With a functional-only language, most programmers are reluctant to do OO.
- With an OO-only language, most programmers face functional features as toy features or not-ready-for-mainstream features.
With multi-paradigm language (but not the ultimate one, of course), things would change and IMHO developers are going to be less reluctant to cross the chasm, as using a multi-paradigm language, the price is to change, from one paradigm to another one, would be little.
It would be nice to be able to create F# lambda in C# code. :)
let's say you do (x,y) => x+y in C# than you could do (x,y) -> (F# code here)
i'm sure it would be relatively easy to implement and support this in C# 5..
and it would push the use of F# a lot where there's a big need to manipulate data in complex ways...
of course, refactoring tool could extract that lambda to send to an F# class, and link the C# code in one swoop if you ever need to go deeper in F# with classes and all..
Anyway, F# is powerful but the syntax is very different of C#, compared to scala vs java and also java is old so there's a big need for scala but C# 5 have already a lot of functional tools so there is really not a lot to push F# against C# on the market..
The best would be to mix both so that people can code small simple F# lambdas first before going with more complex F# programming.
Also it would push people to learn the interoperability limits and corresponding types of both languages.
the support for all this is already there but it might not make everyone happy.
my 2 cents.. :)
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.
7 comments
Watch Thread Reply