 |
|
|
Its not the bloat that puts me off the most, but this doesn't help. Its that standard c++ code is easier to understand, maintain and more intelligent!
|
|
|
|
|
|
|
That instead of more features .NET would focus on the core libraries documentation and better access to hardware, etc, rather than focusing SOLELY on RAD at the expense of documenting there work and making the libraries more usable.
Nothing like an MSDN example that doesn't compile or run correctly on any version of a MS product, ever.
|
|
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: making the libraries more usable.
I wish they'd do more of that, then document it.
Documentation of a troublesome system isn't going to help much.
|
|
|
|
|
|
|
THAT has the perfect size for the client side...
|
|
|
|
|
|
|
Too bad few UI component makers restrict their libraries to support it!
In particuler, Telerik RadControls for WinForms doesn't support it!
Dale Thompson
|
|
|
|
|
|
|
But it lacks a proper kitchen sink...
|
|
|
|
|
|
|
This option is winning by a large margin, and rightly so. As John C notes, the value of .NET comes from having everything and the kitchen sink available to you with one install - target .NET 2.0, you get everything in 2.0 or nothing at all; target .NET 3.5, you get everything in 3.5 or nothing at all. And each major new library (WPF, ASP.NET AJAX, etc.) gets rolled into the next framework release, to where you can develop against it knowing that by the time you deploy, you'll only need to update your framework dependency and be done with it.
Of course, that strategy does lead to bloat. "Framework" has become a misnomer for the .NET libraries; you'd have to be crazy to build something fitting such a frame, with depreciated wings, redundant staircases, and plenty of doors originally intended for future expansion but now opening onto nothing. This monstrosity is a grab-bag of frameworks, libraries, tools, and strategies, and from the look of things will have to continue down this path indefinitely, as new libraries are added in faster than old ones can be removed.
But so what? Harddrive space is cheap, there's no requirement that you load and use the bits you don't need, and any confusion wrought in new users is merely a just punishment for their refusal to properly research the tools that are saving them so much time and effort.
|
|
|
|
|
|
|
If you use .NET where it makes sense - web and controlled environments such as in-house LOB applications, it is not an issue. If you try developing a game with .NET and selling it to general public, you'll get what you asked for 
|
|
|
|
|
|
|
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
|
|
|
|
|
|
|
|
|
|
Super Lloyd wrote: It's also good for game and general public application
Well, try writing and selling a game or Office-style app with .NET and I may believe you
|
|
|
|
|
|
|
How about those 2:
Office App
Nova Mind[^]
I know it's pure .NET I worked there for 2 years!
Commercial Game
AI War by Arcen Games[^].
I can only guess it's a Managed Games as one SlimDX developer[^] was stating on his blog that SlimDX (OpenSource Managed DirectX wrapper) was used for their Game AIWar.
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
|
|
Wow!
|
|
|
|
|
|
|
Hey there, I'm the dev of AI War -- you are correct, it is completely a managed solution. Not only that, but we've got some insane unit counts and a lot of AI crunching that many unmanaged games don't match. I wrote a small article about the sorts of optimizations, etc, that I needed to do to make that happen in a managed environment: Optimizing 30,000+ Ships In Realtime In C#.
That sort of optimization is something that any experienced programmer can do, but the way you optimize a managed application is different from how you optimize an unmanaged one. A lot of managed programmers are not aware of that or don't care, so you get a lot of bloated managed software for this reason -- but it's not indicative of the environment as a whole.
My opinion is that parts of .NET are quite bloated and horrible -- ASP.NET has gone down a particularly bad road in my opinion -- but overall, it's just feature-rich. Even with ASP.NET, they also provide underlying mechanics such as IHttpHandler that are wonderful and efficient, so if you don't like the high-level bloat you can just code your own lower-level solution. That's something I really respect about the .NET libraries in general.
|
|
|
|
|
|
|
|
|
|
Hey, I just went to your Homepage, where you speak of your game.
It seems to sport some good feature and only $20 bucks! I think I'm gonna gave it a try!
There is only one down side, I'm swamped by my pet project to take over the world right now... should I dare gave it some competition, mmm?!?
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
|
|
Hey Lloyd, thanks for the note, glad the game looks interesting to you. We try to provide a good value! There's definitely always too much to do, though, so I know how you feel with that...
|
|
|
|
|
|
|
The size of the .NET framework isn't the problem. It's having all the pieces in a single box that's the problem. There could (read that should) be a core, and several of the most commonly used component sets. Then,
The add-ons and specialties should be broken out as options - and one could code based on that. Keeping to the lowest common denominator if that will do the job, and adding package requirements as they are needed.
There's really no more trouble finding out that the correct add-on parts of the framework are missing than that the framework isn't a new enough version.
It begins to sound much like how .lib's and later, .dll's were set up. Maybe there was a reason for that.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to stop bothering them and just go away?" - Balboos HaGadol
"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
|
|
|
|
|
|
|
Balboos wrote: The add-ons and specialties
What are those?
When I write an application, I want to be able to tell potential users that they need .net 3.5; I don't want to have to specify further things that are required.
And on the users' side, they should know that by installing .net 3.5 they have everything they need.
If I have to start picking and choosing, I'll start to wonder whether or not I got everything. Having everything in one package is better.
|
|
|
|
|
|
|
PIEBALDconsult wrote: Balboos wrote:
The add-ons and specialties
What are those?
Those would (hypothetically) be a separate addition for WPF, or any other similar additions which create a new superset of the previous .NET (vs. simply optimization of code in older version) and could be seen as a separate package (recursive answer).
PIEBALDconsult wrote: If I have to start picking and choosing, I'll start to wonder whether or not I got everything. Having everything in one package is better.
I bid you consider Panty Hose: one-size-fits-all makes the choice easy, but also increases the frequency whereby they get runs and need to be replaced. There is a balance, and (implicit) unchecked growth will cause .NET to eventually collapse under its own weight.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to stop bothering them and just go away?" - Balboos HaGadol
"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
|
|
|
|
|
|
|
Balboos wrote: a new superset
I thought you were talking about subsets.
|
|
|
|
|
|
|
You're catching on.
Each new .NET has (simplistically) two types of changes:
1) Changes to it's current content, which we'll pretend are enhancements to efficiency and bug fixes.
2) Adding of new Features that previously did not exists - frameworks in themselves.
So, the .NET version N.M is the set, and, when one adds to it an altogether new feature, then one can consider it a superset of the previous version.
A superset, therefore, consists of the previous version and the added subsets.
And so, I was saying (in my original post) that the independent addition (i.e, item 2, above) should be kept separate in order to keep the size of .NET under control.
Here - let's change jargon: Think of a .NET core and extensions. An alternative model to all combined into one massive hunk. And as far as convenience of 'knowing' that an installation has the necessary components, I contend that it is fundamentally the same to determine if a particular extension exists or if a particular .NET version exists. Some may disagree with this abstraction.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to stop bothering them and just go away?" - Balboos HaGadol
"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
|
|
|
|
|
|
|
I feel like your argument is somewhat one-sided--it makes sense through a developer's eyes, but even after all of that, the previous poster still has a monumental point: ease of distribution of both the app and the .NET framework. The problem is that the .NET framework isn't really just a framework in the convenient-library-of-functions sense. It's also its own machine that's required in order to run .NET apps on, like the JVM. So I personally would be annoyed that each time I downloaded a .NET app, I'd have to confirm/check/download/install (/restart computer) which components are needed for it to run (I'm assuming your method of breaking up the .NET framework splits it into enough components that I'd have to do this more than just 1-2 times).
Meanwhile, I and everyone else who actually uses the app can merely check which .NET version we have (a very simple calculation that can be done in the head). Chances are that it is already installed on the computer, especially if it's running Vista and up.
Just because something is big it doesn't mean it's automatically bad or disorganized. The component model works for a lot of things for many people, but not for all things nor for everyone.
|
|
|
|
|
|
|
I can see that, except sometimes things (properties, methods) are added to an existing class so the whole new version of the class needs to be distributed.
Of course, a better solution would be if all (or most) built-in .net classes supported polymorphism; so that the V2 class X could merely extend the V1 class X, but apparently Microsoft doesn't see things that way (they don't seem to like polymorphism).
On the other hand, the two versions of the class would need to be in different namespaces, which would mess up they who think that the using directive is a good idea.
"Things would be different if I ran the zoo." -- Dr. Seuss
|
|
|
|
|
|
|
Balboos wrote: The add-ons and specialties should be broken out as options
Yikes! You want to take us firmly back to the 90's and .dll hell days? You'd have every developer have to build a giant install script again that validates against dozens of different libraries and apps that break the minute one or the other critical library is removed or updated on it's own?
No freakin' thank you, that's the nightmare the framework solved.
The whole value of the .net framework is that it assuredly contains everything on every computer that is kept up to date. I don't know if you've ever sold an app publicly and had to maintain and support it but the great strength of the .net framework is that (these days) it's all but guaranteed to be there and to be complete, it eliminates what used to take up the far greatest support resources back in the unmanaged development days with missing bits and pieces everywhere and incompatibly and conflicting versions everywhere.
These days anyone who runs windows update has got what is required guaranteed.
I know this in my bones because our biggest app we sell used to be unmanaged in the 90's and I recall many a wasted hour finding out the customer was missing something or had an incorrect version of something or had installed another app that installed a different version of something, it was hell plain and simply, bad for the user, bad for the developer bad for the support people, just plain bad.
You argue that having all the pieces in the same box is a problem but never state *why* exactly that's a problem, is it simply aesthetics or ...? Because from where I sit that's exactly what's good about it.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
|
|
|
|
|
General 
News 
Question 
Answer 
Joke 
Rant 
Admin 
Suggest a survey
