.NET thoughts | The Coffeehouse

spivonious

Having used .NET professionally for about two years now, I'm beginning to wonder if Microsoft has lost sight of the initial goals of the platform and are now just throwing in everything bu the kitchen sink.

Do you think there are too many libraries in the Framework? Are you confused by the multitude of options for something as straightforward as data access (ADO.NET, LINQ to SQL, Entities, roll your own)?

Or do you welcome the addition of every new thing, as more options make you more productive? Are you glad that you no longer have to write much "boilerplate" code for common tasks?

W3bbo
The Master of Baiters

Data access in .NET is fairly straight-forward: ADO.NET is the underlying layer, everything else is built on top of that, though I'll agree ADO.NET Entities and DLinq has been mismanaged (and I'll be sticking with NHibernate for now).

I'm more concerned with the state of IPC and web services in .NET.

Dr Herbie
Horses for courses

Part of the original attraction of C# for me was the uncluttered feel of the language. As we move forwards it does seem to get bloated, but most of the new stuff does seem to be there for a valid purpose (like the 'var' keyword which I hate to see people using unnecessarily is needed for LINQ to be usable).

I guess it's the price of progress ...

Herbie

figuerres
???

by and large i feel they have done very well.

yes there are "warts" but it's hard to grow this kind of thing without a few mistakes along the way.

as for the number of things / classes / namespaces - focus... learn to just focus on the namespaces that do a given job ....

most of the rest you can ignore and just get the job done.

in C or in any framework that covers this much area you find the issue of which way / which library etc...

yes even in C it happens at times , like console input, there are at least 3 or 4 ways to handle input... often more dpending on which compiler you use.

sysrpl

In addition to the data frameworks. there are other framework piles on top of other piles on top of other piles ... WPF/WinForms/Silverlight/WebForms/WPK, Sockets/.NET Remoting/WCF/MSMQ/Sync Framework/Sharepoint, WIC/GDI+/Managed DX/XNA, ... Direct X Media/Direct Show/VfW/Media Foundation ...

vesuvius
Das Glasperlenspiel

In reply to figuerres

#Oct 16th @ 7:38 AM

I could not have put it better myself. The framework is huge because it can do a lot of things, whether client side, server or distributed.

Learning C# or Visual Vasic is really the easy part. Knowing the libraries is a whole other thing. I have recently worked on a feature that others had implmented poorly by focussing on reinventing the wheel, by writing lots of C# code. It made the developers feel as if they were smart and a reproductive organ the size of a leg.

I waded in with a lower level, hardly used API, that resulted in a cleaner object model, and oodles less code.

As Carl Franklin and Richard Campbell would put it "better know a framework!"

vesuvius
Das Glasperlenspiel

In reply to sysrpl

#Oct 16th @ 8:05 AM

Choice isn't a bad thing a lot of the time. Granted it is difficult to associate a given project with a .NET technology if you are new, but I can assemble my application like lego now, by choosing the technology that suits. This usually means being patient. Had I choosen workflow foundation for example, where would I be now, if I had to re-write my application because WF has been re-written in .NET 4.0?

exoteric
I : Next<I>

In reply to Dr Herbie

#Oct 16th @ 7:30 AM

Now we have two things in the mix here. Language and Framework.

The C# language has evolved but when looking at my C# programs, they have become simpler as a result. The compiler becomes more complex, the programs become simpler. That's the way the trade-off should be and how it is. The common denominator for both C# and the BCL is that over time it could use refactoring. Unfortunately you can't really remove anything from C# - you'd have to spawn off a new C#. And something doesn't become more powerful by limiting it - although reasoning about it becomes easier. But what you can do is reinventing C# with a cleaner syntax and semantics later on (a new language for the masses, now cleaner than ever - especially in these parallel times we live in).

In effect language refactoring is done in a pure fashion - the old language is not mutated, it may be extended but not changed as such, so a new language has to be spun off. Now the BCL is not really a "framework" rather a framework of frameworks, with some type sharing, especially for core types, of course. But refactoring: yep, refactoring is necessary. Microsoft does it all the time. Sometimes with strategic foresight, sometimes not.

Bertrand Meyer has written about creating a "theory for an application" and the same is obviously more crucial for frameworks. For Eiffel this thinking is very clear as both the libraries and the language itself are superbly harmonious and clean and it have a very high-level of abstraction and granuality, albeit with multiple-inheritance - although it has now also gained very powerful lambda support. I believe its much more powerful than what C# has and the core libraries are also contain much finer granularity than what you see with the BCL collections for example.

sysrpl

In reply to vesuvius

#Oct 16th @ 10:06 AM

Working with all the frameworks would not be so bad if the documentation system didn't suck so bad.

Here is how bad it is from a documentation point of view ... way, way too many steps to get what you want ... trying to discern what type is X coord given by a MouseOver MouseEventArgs parameter using the help system.

From the MSDN Document Explorer: Type "MouseEventArgs class" in the edit labeled "Look for", press return -> Returns the wrong one -> Choose the class namespace from index results window at the bottom (SystemWindows.Forms or System.Windows.Input) -> Choose System.Windows.Input -> Brings us to class MouseEventArgs class overview -> Click members -> MouseEventArgs members -> Click GetPosition method -> MouseEventArgs.GetPosition method which returns Point -> Click Point -> Brings us to Point structure -> Click members -> Point structure members -> Click property X -> Point.X property = public double X { get; set; }

Oh, X is type double. I thought it might be float. I better remember that from now on because I don't ever want to have to navigate the help like that ever again.

vesuvius
Das Glasperlenspiel

In reply to sysrpl

#Oct 16th @ 10:30 AM

Documentation is always an issue, whether it is Microsoft, the company you work for, or whatever. No-one seems to have the time.

MSDN is not the best thing since sliced bread, but the developer network and its forums and blogs etc, mean if you are trying to solve a general purpose programming problem, information is almost always available

CreamFilling512

I haven't really moved beyond C#/.NET 2.0 yet, largely because no one wants to be the first dev to double the working set by taking a dependency on Linq or WPF or whatever.

sysrpl

In reply to CreamFilling512

#Oct 16th @ 11:31 AM

The problem isn't with the content of the documentation, it is with the structure. They can write mounds of all the best help text in the world, but if their help system puts it all together archaically, in the end much of their work is wasted.

If you look back to the early to mid 1990s, when Microsoft didn't autogenerate their documentation from source code classes, the quaility of the help was considerably better. Microsoft used to have a small army of tech writers working with their brains to gather technical information. They collectively used their English college degrees to create guided and informative treatise on subjects for the developer community.

Example here

Now their underlying APIs and frameworks are more numerous, but also more nuanced. This creates the need for better documentation. Unforunately web forums and google have been abused as a panacea to cure this problem. They really don't compare to a good reference document.

spivonious

In reply to sysrpl

#Oct 16th @ 10:30 AM

I agree the documentation is pretty bad, but it's a lot better than most. The only one I've found easier to use was the 1.4 era Javadocs, although they are similar in approach.

What started me thinking about this was that I added a piece to one of our VB6 apps. I basically mimicked the DataAdapter class in ADO.NET but connected it to ADO objects instead of ADO.NET objects. It worked like a charm and only took me an hour or so to code the functionality I needed. Coding it myself also gave me the bonus of understanding exactly how it works. Even after two years of using ADO.NET I still don't know all of the ins and outs, and they keep throwing in new methods I feel I should be learning (Entity framework, linq to sql, etc.) not to mention the 3rd party frameworks everyone loves (e.g. nHibernate).

sysrpl

In reply to spivonious

#Oct 16th @ 12:21 PM

You forgot Xaf Wink

CreamFilling512

Who needs documentation when you've got .NET Reflector? Smiley

joechung

In reply to CreamFilling512

#Oct 16th @ 4:09 PM

Who needs compilation when you can interpret code?

I'm not confused by the multitude of libraries in the .NET framework. I welcome the addition of new ones. My only beef is that they bundle everything with everything else, making the unused pieces of the framework an enormous albatross at deployment time. The solution to the problem of package management is not to make one huge package. That should be "an" option but not the "only" option.

Ion Todirel
buuu

In reply to sysrpl

#Oct 16th @ 8:05 AM

WPF is not on top of Windows Forms

sysrpl

In reply to Ion Todirel

#Oct 16th @ 6:00 PM

Do you really work for Microsoft, and is English your second language?

Bass
www.spreadfirefox.com/5years/

In reply to joechung

#Oct 16th @ 4:34 PM

It seems Mono in Ubuntu/Debian is split into many dozens of packages, it might be possible to do the same with .NET proper in the future.

punkouter

going back to the original question.

> I'm beginning to wonder if Microsoft has lost sight of the initial goals of the platform ...

so what is the original goal of the framework? the way i see it, the original goal of .net framework is to provide a framework (libraries and tools) for development on windows platform which are easy to use. back then before .net framework, windows developers have to work with c++. c++ offers a lot of power but it is very easy for developers to make mistakes. mistakes that may affect the whole operating system. .net framework lowers the difficulty and complexity developing on windows platform.

> Do you think there are too many libraries in the Framework? Are you confused by the multitude of options for something as straightforward as data access (ADO.NET, LINQ to SQL, Entities, roll your own)?

well, like i said above. the goal is to provide a framework for windows development. and windows is a huge operating system that provides everything. so... that can't be avoided. there are some libraries that are attacking the same (or similar) problem. but i guess there is no one ideal solution for all problems. all the libraries are attacking a problem from different angles. i think it is always nice to be able to choose between solutions rather than being forced to use one and only one.

if you changed the name of '.net framework' to 'windows framework' than probably, it will make more sense.

littleguru
<3 Seattle

Most of the stuff in .NET is optional. You could get away with very little and still write nice applications. But it is really nice to know that there are these frameworks to which you could reach out to enjoy some more flexiblity.

What I love about .NET is that even though there are so many classes the naming stood somehow consistent.

spivonious

In reply to sysrpl

#Oct 16th @ 9:29 PM

*deleted*

exoteric
I : Next<I>

In reply to littleguru

#Oct 16th @ 11:20 PM

Well, even if the BCL is well-factored, you still need to distribute everything. It would be interesting if the .Net Framework redistributable could be made granular almost down to single namespaces (assuming one namespace per framework). Actually: Visual Studio would analyze your solution for dependencies and, using another tool, would generate a redistributable for this - in two flavors: an online redistributable which would download and install the pieces needed and an offline redistributable installer which would contain all the pieces needed. But we now have these client profiles so there some work going on in that space. (@sysrpl: be nice)

AndyC

In reply to exoteric

#Oct 18th @ 12:00 PM

exoteric said:
It would be interesting if the .Net Framework redistributable could be made granular almost down to single namespaces

But imagine what that would look like when you're trying to pitch it to a customer. It's one thing to say you need ".NET Framework 3.5 SP1", but quite another to give a long list of framework namespaces and expect a customer to work with that.

exoteric
I : Next<I>

In reply to AndyC

#Oct 18th @ 12:15 PM

Not a problem because the output would be just one installer (or an installer configuration file). The customer doesn't need to think about technicalities.