|
the.komplikator@gmail.com wrote: Microsoft .NET Framework is an all-in-one generic framework. It encompasses all
functionality you could ever need on a computer and even further. Ever. No
matter what kind of project you are making.
Uhh, where in the Hell did you get THAT from?? No, it doesn't encompass everything. It tries to supply a lot of functionality that is common to all types of projects, but it does not cover everything.
the.komplikator@gmail.com wrote: .Net already IS broken down to little pieces. They are called assemblies
Yes they are, but do you need to deply ALL the assemblies in the .NET Framework with every project type?? Is every project going to use every assembly in the .NET Framework?? No. Namespaces help keep all the assemblies oraganized into large related collections, most decending from the System or Microsoft namespaces. That's completely unneccessary. The root namespace for a collection of functionality should be the assembly itself, not the entire framework. In most cases, that greatly reduces the height of the namespace tree to one or two levels.
the.komplikator@gmail.com wrote: So, now you have an enormous bunch of code deployed to you by default. Imagine
if there were no namespaces. Then, get some source code that was made by someone
else. And then build some reusable library. Hey, that's a bunch of code that has
no programmatic organization. Wow! That's useful.
Actually, we already have examples of this. Ever hear of the Entity Framework? NUnit?Each has a very small namespace tree. Is it REALLY required?? No. Today, namespaces only exist to avoid name collisions, not really for functionality or organizational reasons. What are the chances a namespace tree in a library is going to have two classes with the same name?? Virtually zero.
Yes, namespaces still offer functionality organization, but is it really necessary to write code?? No, it's not. I dare you to give me a single compelling reason from a developers perspective to justify the existance of namespaces in a library. Sure, from the library developers point of view, it's nice because you can keep your functionality seperated and organized for that developer.
But, from the consuming developers point of view, it's more crap I have to type at the top of my code files to get VS to do the name resolution for me so I don't have to type out complete namespace paths for every frickin' object type. I just want to reference EntityFramework.dll and that's it. All the classes in that .DLL should now available to me under a single "namespace" called "EntityFramework". I don't want a 3 or 4 level deep tree.
On top of that, now I just have to deploy EntityFramework.dll to get the functionality instead of having it baked into a 300MB .NET Framework I have to deploy.
the.komplikator@gmail.com wrote: This looks like some people (and I'm not pointing fingers now!) are pushing some
obviously rather unpolished technologies and reinventing the wheel
What?! EVERY technology and paradigm at v1.0 is unpolished! Do you think the HTTP 1.0 spec was a chrome plated masterpiece when it was released?? Hell no! Everything, from specifications to implementations to paradigms are all unpolished trial-and-error works at v1.0. Everything evolves over time with use to see what works and what doesn't.
Having no namespaces is just another example of a "Hey, try this and see what happens" idea.
|
|
|
|
|
Dave Kreskowiak wrote: Uhh, where in the Hell did you get THAT from?? No, it doesn't encompass everything. It tries to supply a lot of functionality that is common to all types of projects, but it does not cover everything.
Yes, it doesn't provide neural network capabilities, does it? Well, Microsoft's task was to create framework that exposes OS to the developer, not to read his/her thoughts. Custom libraries do that.
Dave Kreskowiak wrote: That's completely unneccessary. The root namespace for a collection of functionality should be the assembly itself, not the entire framework. In most cases, that greatly reduces the height of the namespace tree to one or two levels.
Each namespace system has two dimensions: 1) where is the "framework" code located (framework namespace) and 2) where is your code located (your class namespace). Therefore, if you really feel like your code should access assembly code without "using" directive, you could place your code into the same namespace in which assembly code resides. You could, but you shouldn't.
Dave Kreskowiak wrote: Actually, we already have examples of this. Ever hear of the Entity Framework? NUnit?Each has a very small namespace tree. Is it REALLY required?? No. Today, namespaces only exist to avoid name collisions, not really for functionality or organizational reasons. What are the chances a namespace tree in a library is going to have two classes with the same name?? Virtually zero.
Well, as far as I remember, Entity framework has a small namespace tree because most of it's functionality was implemented using extension methods and such evil trickery
Dave Kreskowiak wrote: Yes, namespaces still offer functionality organization, but is it really necessary to write code?? No, it's not. I dare you to give me a single compelling reason from a developers perspective to justify the existance of namespaces in a library. Sure, from the library developers point of view, it's nice because you can keep your functionality seperated and organized for that developer.
Well, if you develop a project that has similar functionality on different places, you would probably want some code reusability. Whenever "similar" is not similar enough, you want to change the reused code. The proper way of code reusability (by teachings of classical OOP) is to inherit the code, and then change inherited behaviour. That means you will have to either 1) change the name of your derived class so it doesn't conflict with base class' name, or 2) put it in another namespace. Another example is when on one place in same project you have "Person" entity that contains data and maybe some logic, but on another place you also want a "Person" entity with different data, and a different logic. Therefore, you organize your project into namespaces, so one namespace doesn't "bother" you when you're working on another.
Dave Kreskowiak wrote: On top of that, now I just have to deploy EntityFramework.dll to get the functionality instead of having it baked into a 300MB .NET Framework I have to deploy.
Yes, but maybe you don't have to. It is most likely already there. In that case you have to deploy only custom libraries.
Whatever framework you use, you will have to deploy it, because not a single framework is deployed with OS (except .Net in some cases).
Dave Kreskowiak wrote: What?! EVERY technology and paradigm at v1.0 is unpolished! Do you think the HTTP 1.0 spec was a chrome plated masterpiece when it was released?? Hell no! Everything, from specifications to implementations to paradigms are all unpolished trial-and-error works at v1.0. Everything evolves over time with use to see what works and what doesn't.
HTTP 1.0 was practically first-of-its-kind. Therefore it wasn't reinventing the wheel. Namespaces in OOP exist for over 40 years, and all of a sudden they're obsolete and unnecessary? Namespaces are part of OOP, which has been very well tested, and trillion times proven useful. So it's useless if most of the time people don't use it?
modified 6-Sep-12 3:56am.
|
|
|
|
|
Now that everyones opinion is out on the table and you stopped attacking someone with their own opinion, have a nice life.
|
|
|
|
|
I am the newsletter editor.
I do read the posts.
I thought this post offered an interesting point of view. I knew people were likely to disagree and, hopefully, spark some constructive discussion.
Thanks for your feedback and continued contribution to the community.
Director of Content Development, The Code Project
|
|
|
|
|
Terrence Dorsey wrote: I am the newsletter editor.
And you're doing a good job
Terrence Dorsey wrote: Thanks for your contribution to the community
Don't wanna nitpick, but was there any?
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
Quote: And you're doing a good job
Thank you.
And if you enjoy the Daily Insider, you might enjoy signing up for the Web Developer and Mobile Developer newsletters as well. You'll get to enjoy my good taste and wit 7 times a week!
See the Newsletter tab in your account settings for details.
Director of Content Development, The Code Project
|
|
|
|
|
Terrence Dorsey wrote: And if you enjoy the Daily Insider, you might enjoy signing up for the Web Developer and Mobile Developer
Done long long ago, as I'm interested in them and they are my primary fields of work / expertise
Full-fledged Java/.NET lover, full-fledged PHP hater.
Full-fledged Google/Microsoft lover, full-fledged Apple hater.
Full-fledged Skype lover, full-fledged YM hater.
|
|
|
|
|
Andrei, feel free to send me feedback on the industry-specific newsletters - what you find useful, what you'd like to see. I'm still fine-tuning the coverage and open to suggestions.
Actually, that offer is open to anybody. I love constructive feedback on the newsletter content.
Director of Content Development, The Code Project
|
|
|
|
|
Hate to see me trying to find my way arround without using folders in my project. Get too many files in a folder and I spend too much time trying to find a file.
|
|
|
|
|
This should be a reply to the post, not its own thread.
|
|
|
|
|
PIEBALDconsult wrote:
This should be a reply to the post, not its own thread. Vigorous nod of head.
Can the powers that be wave a magic wand, please? This misplaced post is offending my OCD.
/ravi
|
|
|
|
|
Summary: HTML5 promises great things for smartphone developers, but is yet to deliver in full. That leaves developers with a tricky choice: to build for openness or go with what works now.
More?[^]
|
|
|
|
|
I think Microsoft if making a massive mistake with HTML5. Not to say that it does not have potential, but Silverlight is better technology, and many of the issues with HTML 5 in the mobile front are also valid in the desktop front. I think that HTML5 could be a windows killer, which is not neccessarily bad since if the move to HTML5 is successful, why do I need Windows if everything runs HTML5. Save me some money, and maybe virus issues.
|
|
|
|
|
I agree. Silverlight is a fantastic product. I am amazed by what can be accomplished by the technology. It's bigger brother WPF also has my undivided attention. With Windows 8 and Metro on our heals I cant wait.
I have to admit, I do struggle with html and javascript so I guess until I really get used to them I cant give an informed opinion. I originally was a web developer and whilst I have enough to get by I find less and less interest in the markup. I think the browser compatibility issues nailed the coffin for me.
|
|
|
|
|
There are truly real reasons to stay with basic HTML (or HTML5) for compatiblity. Silverlight will only work if the browser supports it.
|
|
|
|
|
Agreed. I know the reasons for and against and know that Silverlight is limited on mobile platforms. That's why I guess the uptake has not been as grand as once thought. The mobile market is massive and getting bigger and if no one supports it then why use it. However, It is a great product and one I like very much.
|
|
|
|
|
Only exception in Windows Phone, and that is apparently a success because they did not use Window compact/mobile/whatever (Microsoft windows team really screwed around with this product). Silverlight worked extremely well. Maybe should just get rid of windows and use silverlight instead, has some advantages.
|
|
|
|
|
would be an idea.
|
|
|
|
|
Silverlight is a great developer platform. It's a great framework (.NET + Linq is unbeatable.) And it's got a great, well-designed language in C#. You can build great things with it. I did.
But it doesn't matter, Silverlight is dying. (Or more precisely, it will lie stagnant until its end of life.) It's dying because it doesn't run on mobile, and doesn't run on non-MS platforms. (Barring perhaps SL on MacOS.)
I've come to realize that in the past few years, that what matters more than greatness is reach. Even though Silverlight + C# is a better combination than HTML5 + JavaScript, it doesn't matter; HTML + JS is the lowest common denominator, giving it broader reach.
Your daughter has a mobile phone. That guy out in the African bush has a mobile phone. Every one of us in the western world carries one around in our pockets. Having software run on that is important, and Silverlight doesn't, and that's why it's dying.
|
|
|
|
|
I'll bet that Silverlight will be alive as long as Desktop and ERP are.
I don't recon the Mobile App hype will last much longer / be very economic for much longer as competition is getting massive. Finding a new and unique user app that can go out to almost everyone that carries a phone won't be possible for much longer...
When the dust settles WinForms / WPF / Silverlight / ERP / Java will still be there and will still be as strong as ever...
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
Following that line of reasoning, every possible application for desktops has already been written as well. Or has it?
|
|
|
|
|
Sometimes I think that Business keeps evolving and LOB apps have to follow / lead, as an LOB developer that is my sanity anchor
I've spent many years customizing 'international' apps (like ERP modules) to the local market, and writing new ones. I do feel that sooner or later everything will be available 'off the shelve', but I'm sure the developers have felt that way over the last few decades...
____________________________________________________________
Be brave little warrior, be VERY brave
|
|
|
|
|
From a consumer point of view, mobile does make silverlight a touchy subject. That said, LOB applications are powerful and Silverlight has a strong backing from businesses. The financial sector for example, has taken this technology and have really gained strong data visualization and functionality from this. I think (and hope) this tech will be around for a while. If not im out of a job
|
|
|
|
|
Judah Himango wrote: Every one of us in the western world carries one around in our pockets.
*cough*cough*cough*
Wanna bet?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Actually Silverlight is not a developer platform, Visual Studio is. As to Silverlight dying, well, WinForms has been dying for years. Microsoft has put little into WinForms since the initial release of .NET. Maybe a little work in 2003, but basically very little. HTML5 is a cripple, suffering with its start of life as HTML. There are many things we have that are horrible, and we suffer, like the QWERTY keyboard, ethernet, Intel microprocessors, etc...
|
|
|
|
|