|
This wasn't about the article at all. This was about the editor choosing that article as "news".
"News" is something that actually happened, or something that is really going on. Like "Microsoft threw away C#".
The article was a blog entry about author's thoughts of how things could be. That cannot be news.
|
|
|
|
|
Last I checked general news sources also contain things like political opinion pieces. I'd say this is fairly equivalent.
|
|
|
|
|
Should this even be posted in the News Section?
Could someone please move it to the Lounge (at least), or to the Oblivion (at best)?
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.
|
|
|
|
|
|
it IS a spam dedicated email 
|
|
|
|
|
the.komplikator@gmail.com wrote: This represents noob thoughts by an unexperienced programmer (if at all).
You really don't know who he is do you?? You might want to do a little research. You may find out that he's got far more experience than you think, possibly even putting YOU to shame.
And I happen to think he's right. Namespaces ARE an obsolete concept. I find that future development is going to rely more and more heavily on package managers of more than one type to add organized functionality to dev environments and projects.
For example, in the past, IDEs like Visual Studio are generic, allowing you to build projects of all types, but treating each project type more or less the same, with monolithic designers built into the IDE. This approach limits your ability to write code because you're stuck using the built in capabilities that don't extend beyond their base functionality.
But, what if you could completely customize your development environment specifically for the project you're working on? Swapping out designers, tools, and frameworks for different sets and different capabilities on a project-by-project basis?
This treats the IDE as part of the project, instead of having the IDE being a generic tool that just works on the project.
THAT's where developement is headed and what Bertrand is talking about. Instead of shipping large monolithic frameworks that are trying to be all encompassing for all kinds of project types, the notion that something like the .NET Framework should be broken up into MUCH smaller frameworks and added into projects on an as-required basis as packages. This has the effect of eliminating, or at the very least, greatly reducing the need for namespaces.
|
|
|
|
|
Well, first of all, that's NOT NEWS, as I pointed out.
But, regarding your topic...
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.
.Net already IS broken down to little pieces. They are called assemblies. U know "add reference..."? That is pretty much what you do when you "add [smaller framework] into projects on an as-required basis as packages". And then when you build your project, only those assemblies are used and deployed.
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.
This looks like some people (and I'm not pointing fingers now!) are pushing some obviously rather unpolished technologies and reinventing the wheel, instead of using whatever's already at hand. Or at least accepting years and years of theoretical and practical research that's been put into constructing useful concepts.
|
|
|
|
|
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.
Sorry to break it to you, but that's just wrong. For instance, I want to swap monitors with a WPF application at runtime - well, I've got to drop down to the Win32 API. Oh wait, I also want to use GIS functionality, well I have to go third party or roll my own. Ah, how about AJAX calls from the browser? Oh wait, that's JavaScript.
The point that was being made in the article is that there are alternatives. Namespaces are a useful feature for a framework such as .NET, but we are where we are with .NET because of legacy code. How different would it be if it was written now?
|
|
|
|
|
Yes, but .Net still has a way for you to do whatever you want. Many language-frameworks exist that do not let you do that at all. Sometimes you realize that a lot too late.
Pete O'Hanlon wrote: The point that was being made in the article is that there are alternatives. Namespaces are a useful feature for a framework such as .NET, but we are where we are with .NET because of legacy code. How different would it be if it was written now?
I don't think it would be much different. Framework itself encompasses some basic computer/OS functionality. It could be upgraded, but not much different.
On the other side, C#, VB and F# are languages that define how we can use that functionality. Microsoft keeps upgrading both the framework and languages with new features. They are a product of over 40 years of object oriented programming theory and practice. Namespaces included 
Sure, it COULD be different, but wouldn't that then simply be a new language altogether?
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
