Coffeehouse Thread

53 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Erik Meijer: Microsoft completely messed it up (with .NET)

Back to Forum: Coffeehouse
  • User profile image
    felix9

     Watch the first 2 minutes and hear Erik Meijer's rant Smiley

  • User profile image
    Sven Groot

    The video is private.

  • User profile image
    Bas

    I can watch it embedded in the post though. Too bad I don't have the time. Anybody want to recap the gist of his rant?

  • User profile image
    Bass

    He's basically saying that Microsoft has been a bad sponsor of .NET and praising Xamarin and the open source dev community in general for moving it forward.

  • User profile image
    Minh

    lol and he called Ballmer a shampoo salesman... also, when did Erik leave MS? that slipped under my radar

  • User profile image
    Bass

    It's actually a pretty good talk overall though. It's about reactive programming and using push data sources instead of traditional querying.

  • User profile image
    Richard.Hein

    He rips on relational databases more than anything.

  • User profile image
    Jim Young

    , Richard.Hein wrote

    He rips on relational databases more than anything.

    Typical pattern. Developers hate databases. DBA's hate programmers.

  • User profile image
    DeathBy​VisualStudio

    It's interesting to see the differences of opinion from developers of different divisions in Microsoft. Some folks want everything wrapped up tight around Windows and others want things more open and extensible (i.e. like SL).

    I'll never forget talking to that group program manager at Build 2011 who specifically said SL was a mistake and they were correcting it. What group did he come from? Windows of course.

    I hope the next CEO can bring a more shared vision, preferably more on the open side.

    If we all believed in unicorns and fairies the world would be a better place.
    Last modified
  • User profile image
    Bass

    , Jim Young wrote

    *snip*

    Typical pattern. Developers hate databases. DBA's hate programmers.

    Oh he doesn't like DBAs at all. The guy is quite brilliant, he was an architect of LINQ and the "Reactive Framework". He implied that DBAs are smelly old fat people that pretty much only exist because SQL databases are horrible. I share this opinion, expect sometimes they aren't smelly old fat people (but fair enough, they usually are).

    I've also thought for many years that DBs are the weakest link in most development projects, and the complexity of trying to hide all the stupid SQL calls (these "enterprise ORMs") just make the problem worse. And yeah you have this pointless separation between pub/sub style events/messages and persistent data, when in reality they ought to be handled with the same code because they are doing the exact same thing in the end of the day, providing your code with input and output.

    He apparently had little control over what actual vocabulary will be used in LINQ. While at Microsoft he fought so that it would have had the same vocabulary functional languages use but ultimately he failed in this. Big take away: I didn't realize that IEnumerable.Select is simply the map operation all along (and named that way almost universally in every language on the planet "but in .NET, we decided to call it select instead because f**k you, that's why").

  • User profile image
    cbae

    , Bass wrote

    *snip*

    Big take away: I didn't realize that IEnumerable.Select is simply the map operation all along (and named that way almost universally in every language on the planet "but in .NET, we decided to call it select instead because f**k you, that's why").

    It was probably more like: "Because it looks more like embedded SQL. Oh, and f*ck you as well."

  • User profile image
    Richard.Hein

    , Bass wrote

    *snip*

    Oh he doesn't like DBAs at all. The guy is quite brilliant, he was an architect of LINQ and the "Reactive Framework". He implied that DBAs are smelly old fat people that pretty much only exist because SQL databases are horrible. I share this opinion, expect sometimes they aren't smelly old fat people (but fair enough, they usually are).

    I've also thought for many years that DBs are the weakest link in most development projects, and the complexity of trying to hide all the stupid SQL calls (these "enterprise ORMs") just make the problem worse. And yeah you have this pointless separation between pub/sub style events/messages and persistent data, when in reality they ought to be handled with the same code because they are doing the exact same thing in the end of the day, providing your code with input and output.

    He apparently had little control over what actual vocabulary will be used in LINQ. While at Microsoft he fought so that it would have had the same vocabulary functional languages use but ultimately he failed in this. Big take away: I didn't realize that IEnumerable.Select is simply the map operation all along (and named that way almost universally in every language on the planet "but in .NET, we decided to call it select instead because f**k you, that's why").

    @Bass: Yup ... I agree with everything you just wrote.  Erik was on the SQL Server team, as well, if there's any doubt about his credentials.  Smiley  There's something very important Erik points out about relational algebra - it is not actually based on set theory at all.  That's surprising to me and I feel like I should have known that.  If it's not sound mathematically, then no wonder it has problems. If I had any doubt, I am convinced now.

  • User profile image
    Richard.Hein

    , cbae wrote

    *snip*

    It was probably more like: "Because it looks more like embedded SQL. Oh, and f*ck you as well."

    Yeah, and this is part of the problem.  LINQ was sold initially as a database query language more than anything, and it still hasn't broken through some people's doubt about LINQ, due to thinking it is just an ORM or that it's generating poorly performing SQL and so no LINQ allowed.  Rx has taken until this year or so for it to be really adopted a lot because of the misunderstanding about the real utility and real nature of LINQ - that it's all about functional programming and the use of monads in composing software.  That is to say, people confuse the concrete implementations with the abstraction and miss the big picture.

  • User profile image
    RealBboy360

    linq on objects is slow.

    I agree ORMs are terrible though.  It's one of my main philosophies in PMS Programming. 

  • User profile image
    Jim Young

    , Bass wrote

    *snip*

    I've also thought for many years that DBs are the weakest link in most development projects, and the complexity of trying to hide all the stupid SQL calls (these "enterprise ORMs") just make the problem worse. 

    Funny, in all the big projects I've worked on the database was the one island of sanity and stability. Chaos was in the realm of the developers.

  • User profile image
    exoteric

    To counter-balance this thread a little...

    Well even though functional programmers realized the connection to functional operators when they first saw the LINQ syntax (at least select is map and where is filter) the adapted naming could have helped popularize LINQ because it then looks more than SQL. I don't know if that's true but some irony it would be if that now makes it stand out as different among a family of "LINQ-like" implementations. These are just names though.

    Also, does SQL have to be based on sets to be sound? (Order Theory?)

  • User profile image
    magicalclick

    I disagree with Relational DB complaints. We use it because it works and it is friendly to Excel users. And the data is raw, so, it is easier to figure out what is wrong when the result isn't expected.

    I once tried a Object Oriented DB, it doesn't support many-to-many relationship, so, I kind of just fake it with one-to-many and another one-to-many in opposite direction. The traversal got all whacked up and I spends hours and hours wondering why I have some strange bugs. It turns out the DB software never bothered to tell me one-to-many and another one-to-many in opposite direction would cause such unexpected whacked behavior. And because there is no way to view the raw data, I was at mercy of their crappy design.

    What I learned from the experience is, while relational DB is dumb, but, it is great that it is dumb. If one row got corrupted, it isn't too hard to fix them. If one reference in object oriented DB got corrupted, it is exceptionally hard to re-link them because the data isn't store in simple tables and simple IDs.

    While not easy to program and not as performing as other approaches, relational DB is still the easies to maintain in terms of keeping data in a human manageable way. Persistent data is best to be kept in dumb structure because they don't have the luxury of changing data structures as frequent as transient data in a software. For some extreme cases, like Stock Exchange, where performance is exceptionally important, SQL wouldn't be a good fit. But, for most company, I think SQL is still the best in terms of keeping storing data in simple tables.

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    RealBboy360

    , magicalclick wrote

    I disagree with Relational DB complaints. We use it because it works and it is friendly to Excel users. And the data is raw, so, it is easier to figure out what is wrong when the result isn't expected.

    I once tried a Object Oriented DB, it doesn't support many-to-many relationship, so, I kind of just fake it with one-to-many and another one-to-many in opposite direction. The traversal got all whacked up and I spends hours and hours wondering why I have some strange bugs. It turns out the DB software never bothered to tell me one-to-many and another one-to-many in opposite direction would cause such unexpected whacked behavior. And because there is no way to view the raw data, I was at mercy of their crappy design.

    What I learned from the experience is, while relational DB is dumb, but, it is great that it is dumb. If one row got corrupted, it isn't too hard to fix them. If one reference in object oriented DB got corrupted, it is exceptionally hard to re-link them because the data isn't store in simple tables and simple IDs.

    While not easy to program and not as performing as other approaches, relational DB is still the easies to maintain in terms of keeping data in a human manageable way. Persistent data is best to be kept in dumb structure because they don't have the luxury of changing data structures as frequent as transient data in a software. For some extreme cases, like Stock Exchange, where performance is exceptionally important, SQL wouldn't be a good fit. But, for most company, I think SQL is still the best in terms of keeping storing data in simple tables.

    this

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.