Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
How would you like to view the presentation?
Visual Studio vNext: ALM features for Agile Planning, Team Collaboration
Troubleshoot Java/.NET performance while getting full visibility in production
Automating Error Reporting for .NET Applications
RDBMS to NoSQL: Managing the Transition
Taming HTML5 and JS: High Performance Mobile, WebKit, FireFox Dev Tools @QCon New York
remember that even if you are working for ThoughtWorks you should have a clue about what you are talking about and you should take some time to prepare presentations.
Or any other maintream language (C#, C++). F# is really not mainstream and looks like APL to me. Because of this the examples were useless and the presentation lost much of its interest.
This presentation should be considered harmful. You will end up being more confused than when you started, and it makes many incorrect or misleading statements. I vote that it be removed from InfoQ.
Actually, you can't represent the the general monad type in Java; the type system isn't rich enough to do so. You need higher-kinded types to express the monadic type.
In Scala, the monadic type looks like this:
trait Monad[M[_]] {
def pure[A](a: A): M[A]
def bind[A, X](m: M[A], f: A => M[X]): M[X] //aka return, aka >>=, aka flatMap...
}
See the A => M[X] part? Let's try to construct a monad interface in Java
interface Monad<A> {
public <X> Monad<X> bind(F<A, Monad<X>> function);
}
This doesn't work, because it would you imply you could pass a function returning *any* monad, whereas you must necessarily be able to pass only a function returning the type of monad you're working with. So you can write an interface for specific monads (Maybe shown below), but not the general monad interface.
interface Maybe<A> {
public <X> Maybe<X> bind(F<A, Maybe<X>> function);
}
This interface is fine. Now generalize it to List. There's no common superinterface of these two that can exist, because you can't abstract over the type constructor as we do in the Scala example.
I know from recent experience that trying to give presentations on monads accessible to a broad audience is bloody difficult and frustrating. The problem is twofold; first, the "monad tutorial fallacy" issue of understanding of monads only being arrived at through use of monads is a huge hurdle - it's hard to take on faith that if you start using monads without really understanding how they work (because you must do so, in order to understand them!) will genuinely pay benefits. Second, in order to make good use of them, you've got to be writing code in an environment that supports using them, which means you have to step away from mainstream languages; Java, C++ and C# (which I suppose are the three most commonly used languages that actually support parametric polymorphism) don't support higher-kinded types, and dynamic languages miss a lot of the benefits of using monads simply because being able to reason about a computation via the types are where a lot of the benefits from using monads come from. So you have to go to Scala or F# or Haskell, and then you have to get used to thinking in types, and you have to do all of this without knowing ahead of time what the benefits will really be.
oops, that "//aka return" was supposed to be up a line
From your explanation a Java programmer already gets a better intuitive feel about the concept. I think that for something like this one should not refrain from "adding" the needed features to a language. If you need to be able to pass function around just add this missing feature to Java for the sake of the presentation. Explain the syntax you will use and then proceed with the explanation. Of course this can work only if the parts that are missing are few. If you need to add too much to the language then it becomes useless.
Thank you for your input.
Beautiful language and patterns he's *trying* to explain but he's like a zombie trying to talk about vegetarianism. Kick this asshole out and read this Simon Peyton-Jones paper: research.microsoft.com/en-us/um/people/simonpj/... .
Do you have a personal vendetta with this presenter? Where did you learn to communicate? Regardless of what you think of the presentation and presenter, it is you sir who comes across as the $%#hole. Let me guess, you are an American on East or West Coast? I would bet East...
Get some manners. You come across like a child.
Sorry.
I tend to overreact when Haskell is being misrepresented. And no, I'm not an American. And yes, in this particular one, I looked like a child. Your reply helped me to put myself in perspective.
Thanks, and sorry again.
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Andrew Watson talks about the work of the OMG, where CORBA is alive and well (hint: in your car), UML and UML Profiles vs. custom Modeling languages, DDS and other middleware, and much more.
Sohil Shah discusses creating iPhone and Android enterprise mobile applications based on cloud services using the open source platform OpenMobster.
Paul Sanford presents the transformations supported by data throughout its life cycle, and how that can be better done with Splunk, an engine for monitoring and analyzing machine-generated data.
A common “best practice” for unit tests is to only write a one assertion in each test. I intend to question this advice by showing that multiple assertions per test are both necessary and beneficial.
John Rauser presents the architectural and technological evolution of Amazon retail websites starting with 1994 and ending with adopting Amazon Web Services.
Michael Stal discusses system architecture quality, how to avoid architectural erosion, how to deal with refactoring, and design principles for architecture evolution.
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
9 comments
Watch Thread Reply