Delivering ongoing value

infoblog » Delivering ongoing value

infoblog » Delivering ongoing value — Wed, 25 Mar 2009 13:11:42 GMT

PingBack from http://blog.a-foton.ru/index.php/2009/03/25/delivering-ongoing-value/

re: Delivering ongoing value

Baoci — Thu, 26 Mar 2009 21:21:58 GMT

What does it mean value?

From what I can see, JIT is still generating dead slowest code on the planet.

WinForms fixes for page faults, GDI+ and more are simply left as is.

WinForms DataGrid still uses the slowest text rendering on the planet.

WPF and Silverlight are even heavier than WinForms ( no wonder they are unusable for any serious latency-sensitive app).

Why?

Is the sole reason of MS to ignore and leave things unfixed, and deliberately slow?

And then provide more value with new value that is even slower and more page-fault generating and RAM eating?

Guys, people are seeing through this game for a long, long time now

Proporcionando valor constante

Blog de Soma en español — Fri, 27 Mar 2009 06:35:09 GMT

Publicación del inglés original : Miércoles, 25 de marzo de 2009 a las 1:02 PST por Somasegar Hace poco

re: Delivering ongoing value

Matt Gibbs — Fri, 27 Mar 2009 17:19:29 GMT

Hello Baoci,

My team works on several of the areas you reference. I'd like to get some more info about the WinForms rendering and JIT code-gen issues you are seeing. Please contact me at mattgi@ms and we can help investigate.

re: Delivering ongoing value

tg — Fri, 27 Mar 2009 19:39:03 GMT

Where's the Entity Framework???? Are you guys really committed to this or not? I'm getting the feeling that this will become ObjectSpaces 2.0, or WinFS, or L2S, or you get the point (I hope).....

We need a solid ORM solution for .Net!!!!!

re: Delivering ongoing value

tg — Fri, 27 Mar 2009 19:39:15 GMT

Where's the Entity Framework???? Are you guys really committed to this or not? I'm getting the feeling that this will become ObjectSpaces 2.0, or WinFS, or L2S, or you get the point (I hope).....

We need a solid ORM solution for .Net!!!!!

A nova geração Y

Arquitetura em Pauta — Sat, 28 Mar 2009 19:22:48 GMT

Nos EUA estão chamando de geração Y a primeira geração a viver o mundo conectado. Hoje eles/elas têm

re: Delivering ongoing value

Jason Wilcox — Sun, 29 Mar 2009 02:56:25 GMT

Hey tg,

We are absolutely committed to the Entity Framework and shipped the first version as part of VS 2008 SP1 and .Net FX 35 SP1. This post highlights new capabilities above and beyond what we did in VS 2008 SP1 and .NET FX 3.5 SP1 (which is where we shipped the Entity Framework).

For the upcoming release, we’ve made some significant additions to the Entity Framework that we will ship as part of .NET FX 4.0:

• POCO : Support for Plain Old CLR Objects. Developers will be able to write their own classes that work with the Entity Framework without need for implementing special interfaces or deriving from specific base classes.

• Lazy Load : True lazy loading abilities

• Foreign Keys : Working with our partners in ASP.NET we are implementing Foreign Key based associations that will improve the experience with ASP.NET and MVC

• Model-First : Support to define a model and generate a database from it

• Stored Procedures: Increased capability for flexible stored procedure mappings and scenarios

• Singularization / Pluralization: A default experience in our tools

• N-Tier : Improved APIs helping developers to build n-tier apps directly on top of EF or with a framework like .NET RIA Services

• Customizable Code-Generation: T4 templates for code-gen. Our tooling experience uses WF to define the tooling steps. These two improvements give developers and ISV’s a wide range of opportunities for extending and customizing the platform.

For more information on the road map you can visit the Entity Framework Design Blog. You might also want to check out improvements we made to ADO.NET Data Services at ADO.NET Data Services team blog.

Jason

(Data Programability)

re: Delivering ongoing value

ricom — Mon, 30 Mar 2009 07:35:48 GMT

Hi Baoci,

I wanted to thank you for your frank comment and I'd like the opportunity to talk to you more specifically about where you think we could do more for performance.

I encourage you to read my blog as well http://blogs.msdn.com/ricom and to write me

ricom (at) microsoft.com

[I broke that up to try to dodge some spam bots please replace the (at) with @ like usual. ]

If that doesn't work you can use my blog links to send me email too.

re: Delivering ongoing value

Somasegar — Tue, 31 Mar 2009 01:31:25 GMT

Hi,

I realized that I had missed the Enterprise Library work from the list. So, I added it to the "Guidance" section in this blog post.

-somasegar

Soma Provides Catalog of Development Tools

US ISV Developer Evangelism Team — Tue, 31 Mar 2009 20:01:56 GMT

S. Somasegar, Senior Vice President Developer Division, has provided a catalog of developer tools that

re: Delivering ongoing value

Mark Gordon — Wed, 01 Apr 2009 06:49:04 GMT

Hi There Soma,

You forgot to list the obvious short comings of each technology as that level of detail would also help us. To give you some ideas where to begin - how about lack of XMAL debugger and a carousel control in WPF - class browser in visual studio is useless - inability to subclass UI controls - no UI designers in MVC amongst other things - and the most obvious mental wizardary a missing data centric language.

The funny part is even with all these tools Visual Studio is still 'NOT' able to generate an application as fast, efficently or less lines of code as Visual Studio 6.0. Keep up the good work, at this rate you will be spinning a bloated version of assembly as the next technology breakthrough.

Here is a thought give us back Visual Studio 6.0 or at a minimum Visual FoxPro to appease those of us that just want to get our work done and realize there is more to life then debugging a million lines blend generated xmal with snoop. Then keep Visual Studio around for programmers that enjoy writting massive amounts of code, learning bloated frameworks, 6 different data access methods that all suck and being on a constant learning curve. This way everyone will be happy.

re: Delivering ongoing value

Nestro — Wed, 01 Apr 2009 18:26:21 GMT

I found your blog from Mark Gordon's facebook. Visual Studio it isn't a good product. With no rapid application development features or command and function based language it's not productive to use and performs very poorly. Visual FoxPro was much better for developing database applications. Visual FoxPro should continue to be enhanced for programmers that don't like using Visual Studio and .NET.

Please add

Greg — Wed, 01 Apr 2009 18:28:10 GMT

Please add:

- Code refactoring for TSQL stored procedures

- Code reformatting for TSQL stored procedures

- C# refactoring - Push local variable to innermost scope it is used

- C# compiler messages - List methods that could be made static

- C# compiler messages - list unreferenced global variables, class level variables, local varaibles, methods, classes, assemblies

- C# refactoring - remove unused references

- C# refactoring - removed/comment out unused functions, variables, constants

- C# compiler message - list methods that are public which could be made private

- C# compiler - option strict to prevent dynamic variables/variant data types

- C# tools - find duplicate code like the symian or java based tools have

- C# refactoring - convert property to class level variable (i.e., reverse of the existing refactoring)

- C# tools - show reference hiearchy in application and BCL (to let us see if a .NET framework class is being used in only one place. We want to minimize the number of BCL classes used in our applications to lower risk and reduce maintenance/support costs)

- C# tools - A MS supported tool convert code from VB.Net to C# or C# to VB.

- C# linker/project properties - option to compile and statically link an application so that it has 1 executable file and only needs the .NET framework to run.

- VS setting - don't auto checkout source code from VSS when it is modified (follow subversion/CVS/RCS model).

- VS setting - make color scheme available for project window, settings winndow, etc like it is available for the source code editor (i.e., I want a high contrast lime green/light blue text on black background).

- VS reports project - fix bug where the XML for the RDL gets out of synch with what you do in the designer/reports properties page. Changing/removing parameters will sometimes not remove the ones you removoed in the GUI. Same goes for changes made to the data source.

Visual Studio in comparision of Visual Foxpro 9

David A. — Fri, 03 Apr 2009 00:46:00 GMT

I also found your blog from Mark Gordon's facebook.

I have been working with VFP from the FoxBase + ages.

This tools allowed me to work with OS: MS-DOS, SCO Xenix in multiuser, networking with Network Netware, and of course with Windows. All with the same compiled file.

VFP is a tool very focused to work with databases, in my case, it is the kind of software I have been developing all my life.

I can't understand why MS leave VFP, and force us to use a tool with a lot of complexity, very poor accessibility to databases, forcing us to use SQL Server if we like something callable as "integrated". Of course, nothing to say about creating reports.

Seriusly, VS GUI is about 3 or 4 times more slower in my machine than the VFP9 GUI, a lot pageframes, slow windows, etc.

VS have not a command line with the power of VFP.It really need it. I must have a testing winform and compile it each time if I like to do some test.

VS is not intuitive. The help file is not optimized, it made me lost a lot of time.

In the 2009 year, I think I do not need to think how creating a variable can affect the system... It is the work of the language.

The compiler and the GUI can't do it better/rushmore?

A thing who make my crazy, is telling the compiler the variable type definitions.

Intellisense is not an excuse. Who think is "logical" define an object like:

UseDefaultCredentialsService service = new UseDefaultCredentialsService();service.UseDefaultCredentials = true;

Nobody hate write the same UseDefaultCredentialsService two times in the same line? Really it is mandatory? The compiler can't be more intuitive with writing it only one time?

I can run an application in VFP9, developed in FoxBase+ 20 years ago without touching a line of code. Can you do it with an app developed for the first NET framework? Compatibility is very important with big projects, with a long life of the product developed.

I think VSNET need to be more thin, simple, allowing applications to run in others OS (read Apple OSX, Linux, Android, SUN, etc). What is the reason to have a complex CLR if the app only works in Windows? And why you must compile different versions to run Windows 32 or 64 bits? The CLR should do this work.

I would like to run my application in the cheapper machine, the oldest, and the newest, not only in the newest and fastest. My customer is not a geek, is a office worker, they do not change the PC until it fall, they don't need a mainframe.

re: Delivering ongoing value

Russell — Fri, 03 Apr 2009 06:44:28 GMT

Mark is gaining a following, here are my two cents.

The capabilities of new technology may have improved with Visual Studio - .NET but product quality has fallen off the map.

1) missing key elements

2) dismal performance

3) countless stability problems

4) buggy

5) too much code

Seems every 6 months there is a new framework released or .NET this or that. MS is running around like a chicken with it’s head cut off unaware how to address the problems. By throwing new technology at the situation is not improving matters. Linq-To-Sql is already dead while ADO EF IMHO isn't far behind. It’s too complex, more importantly a data mapping based solution isn't required for most applications. This will be another technology *failure*.

To take a truly *GREAT* development tools like Visual FoxPro that has stood the test of time (an accomplishment not many MS products have done) and disown it is *foolish*. This product should continue to be developed!

re: Delivering ongoing value

Mark Gordon — Fri, 03 Apr 2009 19:21:03 GMT

Hi Soma and Jason,

I just checked in to see if I was getting flamed and actually read through the prior comments this time. I would be still laughing at your comment, Jason, about Microsoft's commitment to Linq To Entities if it wasn't so pathetic!

It is unbelieveable that N-TIER design patterns has been around since the COM days and you just now are trying to figure how to patch Linq to accomplish this! What is the plan here Soma in 10 years reintroduce debugging and subclassing UI controls in WPF (if this technology lasts that long) perhaps a useable class browser. Are you hoping everyone will have forgotten by then about Visual Studio 6.0 and Visual FoxPro 3.0 which has these capabilities so people will say man this cool stuff when you introduce them at Mix19! Curious just how many years is visual studio and .bloat planning on setting programming back? Based on my calculations given we are back to hand coding a UI with MVC, no meaningful debugging in WPF (before you argue think data binding) and lack of any real N-TIER support in Linq this is probably sitting around the late 80's?

If I recall correctly, I believe in May 2007, yes not even 2 years Scott Gu, was hyping and spinning LINQ-TO-SQL as the next greatest database access bloat (I meant framework) released by Microsoft and that didn't even last two years! Now here you are hyping Linq to Entities as Microsoft greatest "FAD" database access technology. I haven't even wasted the time to mess with it so I can't say if it is good or not. I can say that given your number of data access failures history is not on your side.

The only thing good about killing LINQ-TO-SQL is hopefully the VS communities are getting a feel for the complete disregard and arrogance Soma and Microsoft has already shown the Visual Basic and Visual FoxPro communities. Along with their pattern of killing technology that actually works, do I really need to mention that tools!

Have a great weekend

.Mark

re: Delivering ongoing value

Sam — Sun, 05 Apr 2009 17:42:06 GMT

Jason, Soma,

EF has a learning curve. It still does not support many useful and required features. Further, promoting it along with several other ways of accessing data is confusing. Leaving developers to make decisions about which one to choose for a particular project is also not productive. While I'm not in favor of re-introducing FoxPro (and VB), it would be a serious mistake if you guys do not make up your mind and focus on getting out 1 technique that is easy to use and works for n-tier applications as well as simple non n-tier applications.

Promote a "Data Access Foundation" that can be used with web, rich client, windows and any other type of application supporting several architectures with ease of use.

re: Delivering ongoing value

David A. — Mon, 06 Apr 2009 23:06:39 GMT

I can do more things, quickly, with VFP9 accessing databases and creating forms than with VS C#. C# is as teduious as strong.

I can understand MS do not think VFP is a priority for them (never was), but to maintain the amount of developers who do and DID applications with it, they could make a 64 bits compiled version. We do not need more tables size (it should be interesting), it is more important to have an OLEDB driver "compiled" with 64 bits, and VFP9 also compiled in 64 bits.

Something as simple as it, could give us a reason to watch M$ with better eyes.

For me, developing with C#, is like comming back to the Basic for CP/M. It make me feel like when those far years I needed to work with tables and their index files.

re: Delivering ongoing value

Graham — Wed, 08 Apr 2009 16:09:50 GMT

Agree with pretty much all the above.

The 'new' asp.net IDE based on Frontpage has set usability back years. (my 2c)

Try to get something working and working right before releasing so much dross that it just confuses the picture.

The vast majority of developers don't want to reinvent the wheel every day, which is what I feel I'm doing now.

Years ago, it was said Cobol programmers would be out of a job, because the new 4D languages would put the development of simple apps and reports into the hands of the users.

MS is trying its hardest to ensure THAT never happens; in fact some of it is getting beyond some journeyman developers.

If I'd wanted to work in a low level language, I'd have learnt assembler.

C# is tedious.

re: Delivering ongoing value

Adrian — Thu, 09 Apr 2009 09:58:32 GMT

Thank the lord for MS!

C# is a vast improvement to the pain of programming in C++ which (at the time) was a language I enjoyed for it's power, flexibility and low-levelness. Once I learnt C# however it seemed I was constantly writing code in C++ that already existed in C#.

The Visual Studio IDE is an evolution not of FrontPage but of the original VC++ 6 IDE (I'm sure the core shell is still partially unmanaged C++ code) and the ability to write comprehensive add-ins to the IDE gives it both power and in certain cases instabilities - this is the price of an environment that is more functional than notepad and a huge step forward.

C# is certainly a RAD language - I created a prototype Windows Service yesterday afternoon that is functionally complete (needs configurability and event logging) - it would have taken much, much longer to develop in C++ and even longer to test!

I can't comment on VFP - I've always used SQL Server and/or Oracle and as a rule I don't touch anything VB if I can possibly help it...

I don't understand the issues of bloated software - it's simply a matter of where you put the division. If the .NET Framework is part of the OS then programs are smaller. If you use the native code generator then they work just as quickly as a native C++ app plus I would argue they will always work faster than a VB app... In every case you could say the fact you have to install Windows before you can use an application is the biggest case of bloated code ever but here we are all in the same boat whether we are using Mac OS or Linux - there will always be a need for some kind of bootstrap.

Finally we need access to different data-access technologies. Not to be confusing (although of course - it is) but because there is no universial solution that works for all cases - unless of course - you want bloated code! LINQ-to-Entities and LINQ-to-SQL are designed to fulfil different scenarios - it is your job as a developer to pick the right path for the job at hand. You wouldn't use a DataSet for every data access problem and I don't expect you would use EF for every problem either.

In short - roll on VS2010 - I want to see the next generation of the parallel framework (hopefully unified with CCR) because writing parallel code is so hard - I can do it now but it was a truely painful experience! :-)