You nailed it.

2 days ago, felix9 wrote

or, crazier, WPF have many concepts that not 'native' to the runtime and languages, we have to use complex API to access them, can we build a DSL that use them natually ? like declare and access Dependency Property or Attached Property like native ones ? access Routed Event ? access or write Binding Expressions ? walk through the Layout Tree ? interleaving XAML ? like Razor ???

great idea. actually, I guess XAML was supposed to be a DSL itself, it's just trapped within cumbersome XML syntax ...

IMO, we don't need any more gargantuan frameworks like WPF or WCF - which I do like but I think within them there's "a much smaller and cleaner" programming model "struggling to get out". We do need more features like LINQ, dynamic support, or async that help simplify, unify, bring order to the other stuff that's already there. 

About the UI - the new extensions system kinda brings the limitations of the current UI model to the fore. A lot of the extensions I like (by themselves) add things to the context menu that are individually useful, but taken together they bloat the context menu to the point where it's unusable. I think there's a question of whether the UI structure scales well enough to handle all the capabilities the program now has, and maybe they should consider a rethink similar to what the Office team did that resulted in the Ribbon (which is not to say that they should copy the ribbon itself!) Although the VS2010 Productivity Power Tools are a good start for a UI rethink (if only they wouldn't crash the IDE all the time ...)

3 hours ago, 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.

Jul 20, 2010 at 6:01 AM, jaimer wrote

After making IE9 available in the desktop, the browser will make it onto the phone .. but I can't disclose the timeline on how soon after we release because we don't yet know it, rest assured we do want to have HTML5 in the phone and will do our best to get it in as soon as we can;   we will have to see how schedules align next year.

I think you not only need to invest in the browser, but you probably need to rethink how IE development is managed between desktop and mobile. It doesn't make sense anymore for the IE team to be part of the desktop Windows division, develop for Windows, and only later port to mobile (how I understand it to work currently, correct me if I'm wrong). Mobile should be a priority from the beginning. If anything mobile IE is a lot more important than desktop IE as there are plenty of other browsers on desktop Windows, while Windows Phone, being a minority platform, benefits more from access to a rich standards-based application base to protect against everyone getting locked in to iPhone or Android-exclusive apps.

when will we get this on C9? 

However, the GWT (and for F#, WebSharper) approach of compiling languages to JS itself is interesting. I'm worried that, because JS is designed to be a high-level language rather than a compiler target, it may not work as well for the latter purpose. At least, compilers targeting JS still seem to be a lot rarer than compilers targeting other platforms, which makes me wonder why. But I haven't given it serious thought, actually one of my plans for the near future is to look into this more (and delve more into studying compilers in general).