Skip Navigation

Coffeehouse Thread

10 posts

Danny Simmons, yet another great guy goes Midori ??

Back to Forum: Coffeehouse
  • User profile image
    felix9

    Danny Simmons is leaving the Entity Framework team

    http://blogs.msdn.com/b/dsimmons/archive/2010/12/02/system-data-objects-dev-guy-becomes-a-compiler-padawan.aspx

    He described his new adventure as this :

    I’m joining an incubation team which is in charge of, among other things, the phoenix project.  Specifically I’ll be working on ahead-of-time compilation for c# in order to solve some really challenging problems in system programming.  One of the things that has come out of the last several years for me is a real love of programming in c#, and this project has the potential to help extend the use of c# into domains where it can’t be used today.

    Smells like the compiler work for the managed operating system to me ...... aka Midori.

  • User profile image
    vesuvius

    I cannot say that I think the entity framework has been a success, as using it makes me feel like peeling off my toenails with tweezers, but it is well worh moving to new things.

    After coding C# or VB or whatever in any company you get bored and usually switch companies for a pay rise and new challenges so it's not that big a deal except for the secret stuff he is working on of course.

  • User profile image
    JoshRoss

    @vesuvius: I can understand your reaction to using the entity framework. From an architectural standpoint, I think the EF is pretty solid. With that said, it is just not fun to use. I wish that I could better express this sentiment. Perhaps it is too perfect, giving rise to the feeling that I am working in a formal aseptic environment, like a hospital-museum hybrid.

    Or maybe, I just have to give it time. I feel better writing software in languages that I am proficient with. There are not too many things that are more stressful than trying to accomplish something, that should be simple, in a language you just don't know well enough.

    -Josh

  • User profile image
    Bass

    Microsoft should have backed NHibernate instead of writing yet another ORM. I can understand the business reason for EF: they are afraid of giving .NET developers skills that would be directly transferable to competitor's technologies. (Hibernate is a Java standard, literally..)

  • User profile image
    blowdart

    , Bass wrote

    Microsoft should have backed NHibernate instead of writing yet another ORM. I can understand the business reason for EF: they are afraid of giving .NET developers skills that would be directly transferable to competitor's technologies. (Hibernate is a Java standard, literally..)

     

    Euch no, NHibernate was so config heavy at the time EF started it was just ugly. Fluent nHibernate was a nice breath of fresh air when it eventually arrived.

  • User profile image
    Bass

     

    , blowdart wrote

    *snip*

     

    Euch no, NHibernate was so config heavy at the time EF started it was just ugly. Fluent nHibernate was a nice breath of fresh air when it eventually arrived.

     

    What are you talking about? You can define all your mappings in a single XML file. That's hardly "config heavy". Fluent NHibernate doesn't eliminate the essential configuration, it just maps the HBM XML to C# code.

    Not to nock Fluent, because hardcoding configuration has some merit in hobbyist projects where you know exactly how the DB should look like before hand.

    It's not something I'd use on a real project. You should never, ever hard code a software application to any specific database schema. That's the point of object/relational mappers in the first place: to decouple the "object" from the "relational". I could care less if I'm working with 500 tables in with exotic key relationships and columns in chinese or 1 giant table. The value of the XML approach is the fact ORM mappings are  configuration.

    With the XML approach you don't have to rebuilt your whole enterprise system just because a column name changed in some database in the field. It's far more maintainable approach in the long run, it's really not even any harder then writing C#, especially if you have the XSD (or better yet, the Hibernate plugin for Eclipse Smiley).

     

  • User profile image
    blowdart

    , Bass wrote

    *snip*

     

    What are you talking about? You can define all your mappings in a single XML file. That's hardly "config heavy". Fluent NHibernate doesn't eliminate the essential configuration, it just maps the HBM XML to C# code.

    Not to nock Fluent, because hardcoding configuration has some merit in hobbyist projects where you know exactly how the DB should look like before hand.

    It's not something I'd use on a real project. You should never, ever hard code a software application to any specific database schema. That's the point of object/relational mappers in the first place: to decouple the "object" from the "relational". I could care less if I'm working with 500 tables in with exotic key relationships and columns in chinese or 1 giant table. The value of the XML approach is the fact ORM mappings are  configuration.

    With the XML approach you don't have to rebuilt your whole enterprise system just because a column name changed in some database in the field. It's far more maintainable approach in the long run, it's really not even any harder then writing C#, especially if you have the XSD (or better yet, the Hibernate plugin for Eclipse Smiley).

     

    Well right now, I'm working on an internal system, which originating from an outsourcing firm, got maintained and sustained by another outsourcing firm, and then ended up with a third.

    The database is a mess. Rather than using sensible many-many link tables someone at some point decided that have a single link table which has entity type columns, and then entity id columns was the best way to go.

    This does not fit with either nhibernate or EF unless you end up hard coding, because nothing understands the sheer stupidity of this huge link table.

    (So I'm hand rolling repositories to have a stable REST API, which will then be used to isolate the front end from the back end as we rewrite both when we get some budget).

     

  • User profile image
    contextfree

    , Bass wrote

    Microsoft should have backed NHibernate instead of writing yet another ORM. I can understand the business reason for EF: they are afraid of giving .NET developers skills that would be directly transferable to competitor's technologies. (Hibernate is a Java standard, literally..)

    This sort of ignores the history of the EF, though. The EF is basically a leftover from the WinFS project and originally they weren't even really thinking of it as primarily an ORM, but rather a way to have a common data model shared between WinFS and some other projects.

  • User profile image
    Bass

    Actually, in the Java world, the "offical" Sun sanctioned ORM for a long time was J2EE Entity Beans. But it never was very popular because it was a pile of crap.

    When it was obvious that basically everyone moved on to Hibernate, Sun basically took Hibernate's API, renamed it to JPA, and called that the new standard.

    That kind of stuff probably won't happen in the .NET community. First of all, no matter how "broken" Java's community process might be, .NET has NO community process at all. Also I generally notice .NET developers will pick up ANY technology that has Microsoft's name on it, no matter how crappy or poorly designed it is. They'll even say stuff that basically amounts to "this is a pile of crap, but it's written by Microsoft, so lets use it!".

    This is not exactly .NET developers fault either. The whole "merit system" Microsoft has in place (eg: the MVP program) ensures the best way to get far is to parrot whatever the army of Microsoft evangelists are saying. That's why somone like Ayende has doesn't have an MVP despite being involved in writing 5+ widely used .NET libraries, and random idiots with obsecure blogs who copy/paste Microsoft press releases are.

    That's why I really think NHibernate or other community ORMs stand no chance in the long run. It's obvious think Microsoft doesn't take the .NET community seriously or even acknoledge their existance. And .NET is so top down command and controlled which makes it even worse. .NET developers are too entralled with with millions (or billions?) of dollars in developer evangelism money being used to push the latest half-baked solution to a problem that has been solved already, better, outside of Microsoft's offices. So crappy technology is allowed to dominate just because of this. It's sad to watch.

    And yes, I was being nice by saying Microsoft has a "business reason" for this. But it's probably actually just typical corporate self-destructive behavior, driven by office politics and job security concerns. It seems the words "code complete" often lead to the words "lay off".

  • User profile image
    exoteric

    , felix9 wrote

    Danny Simmons is leaving the Entity Framework team

    http://blogs.msdn.com/b/dsimmons/archive/2010/12/02/system-data-objects-dev-guy-becomes-a-compiler-padawan.aspx

    He described his new adventure as this :

    I’m joining an incubation team which is in charge of, among other things, the phoenix project.  Specifically I’ll be working on ahead-of-time compilation for c# in order to solve some really challenging problems in system programming.  One of the things that has come out of the last several years for me is a real love of programming in c#, and this project has the potential to help extend the use of c# into domains where it can’t be used today.

    Smells like the compiler work for the managed operating system to me ...... aka Midori.

     

    I really look forward to the day when we get to peek inside this new death star in the works Smiley

    We haven't heard about Phoenix in a long time. The last we heard was from Bartok, right, but I guess Bartok uses Phoenix as the backend compiler.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.