I just attended the deep dive into Apex session featuring Adam Gross, Simon Fell and Craig Weissman. Craig's the designer of the Apex language and platform and Simon's the architect of the API we all know and love. There was a lot of details about the new language that I'm sure will be covered in elaborate technical detail by other bloggers. In this post I will try to describe the philosophy of the new language as I understood it, and spill some notes I took.

The Apex language was designed from the start as a platform targetted at internal, as well as external developers. It was designed to make make data manipulation tasks easy to do so that you can get some quick wins easily. It also has enough flexibility that we will eventually develop the Salesforce application on Apex. This is not very far fetched - new features like PRM are built on our existing API.

Apex is very safe and conservative in how it handles code. The code is managed, or governed so that it doesn't have any repurcussions beyond what it's supposed to. The language and the "compiler" are very strict about what they will execute.

Here's my barely-edited notes from the session:
Craig:
Declarative application development is our bread and butter. This works well and we've gotten far with it.

However, real applications require real code. We can lean on, and build on  the declarative stuff for many things, but if we really want to get to no-software (no servers to run), we need to be able to run code on our servers.

Apex is similar to PLSQL in persistent connections, compile time type checking, stored procedures. Apex makes it very easy to do data manipulation.

Adam:
The goal with apex is about binding code to the events. Goes over the keynote demo yesterday and describes the steps in code processing.

1. Discrete pieces of code written in Apex
2. Runs natively on the server; more powerful
3. Interacts with the UI via buttons, events etc
4. Java-like syntax
5. Language scope similar to stored procedures
6. Compiled and strongly typed - very rich error messages
7. Transactional

Craig:
The basic actions are all api calls. The reason this works is because we plug into the api at the level below the soap/xml layer. In other words what happens when you execute and Apex statement is the same as what happens when you make an API call, but without the overhead of internet transports.

Adam:
Invoking Apex - via a trigger, scoped to a UI event/ bound/ workflow event, or by invoking via API. Triggers work across interfaces - UI/API

Simon:
When you write a package in Apex, you can expose it as a first class web service. If you scope a method as web-accessible, instead of just public, the class becomes a web service. WSDL's are generated automatically. (I think this is super awesome, and Steve Andersen, who was sitting next to me is really impressed at this point)

Adam demos a hello world app that demonstrates triggers.

Craig:
Namespacing in Apex - namespace.package.methodname

Adam:
What makes apex special: multi-tenancy! Shared code execution layer

Craig:
We're not compiling Java classes. We have a VM. Apex is interpreted. When you save a package, we check type and syntax rigorously (''compiling'). We watch every execution and it's built into the runtime. Code is "compiled" against a version of the Apex VM and runs without modifications across upgrades.

Apex code is governed. It has built-in functional testing.  You can scope a method as test, and you can invoke all tests through a new verb. When you write code, you can write your own tests by scoping a method as a test.

---
Overall, I think this is a very exciting development, and I felt the same vibe from the people in the room.