|
I believe Heath started a new job at Microsoft within the last week or two. I'm sure he'll be back on the boards once he settles in.
Charlie
if(!curlies){ return; }
|
|
|
|
|
Because it actually not ready for MASSES. It's ready for WEB (ASP.NET + WS) only.
But absolutely not ready for WIN, espesially data-management. ADO.NET is VERY slow and complex (IMHO). Just see on BORLAND's Delphi (<=7.0). It contains THREE built-in (!) variants to work with data: BDE, dbExpress ("disconnected") and ADO. I can use what I like. No limitations. Also Delphi contains "DataModule" - I don't need to reinvent wheel each time!
I need CONNECTED mode in ADO.NET. It's usefull for Win-development.
DataSet is very slow with large amount of data (especially multi-table dataset with relations) because it does know anything about indexes. I don't want to load ALL data into client's memory because not all client's PCs has >256MB RAM (usualy 32-64).
Nothing more in my head for a while.
|
|
|
|
|
BlackTigerAP wrote:
DataSet is very slow with large amount of data (especially multi-table dataset with relations) because it does know anything about indexes. I don't want to load ALL data into client's memory because not all client's PCs has >256MB RAM (usualy 32-64).
I'm nbot disagreeing with your point about ADO.NET but if you find DataSets slow then remember what they are essentially providing... Disconnected data access in the form of an IMDB... can you show me a better solution for that these days??? Datasets shoudl only be used when you need this functionality IMHO.
Regards,
Brian Dela 
http://www.briandela.com IE 6 required.
http://www.briandela.com/pictures Now with a pictures section 
http://www.briandela.com/rss/newsrss.xml RSS Feed
|
|
|
|
|
AK wrote:
I guess there are just too many new people trying to learn .net and they can't figure it out. So far there are no valid points against .net
Well, since everyone else is being exceptionally polite towards you, i'll be the one to speak the truth:
This is the single most idiotic post i've read all day. It even beat out the post asking about CSS in the suggestions forum. My hat is off to you, sir, for you have an obvious talent in this area. Have you considered a job doing phone support?
.NET will be ready for the masses when it is installed on the masses machines. This is the only criterion, and has always been so. If all your customers meet this requirement, then more power to you - but don't presume to speak for anyone else.
You're one microscopic cog
in his catastrophic plan...
|
|
|
|
|
Shog9 wrote:
My hat is off to you, sir, for you have an obvious talent in this area.
I'm a stranger to sarcasm. 
Shog9 wrote:
Have you considered a job doing phone support?
Maybe he should try VB?
Aaron Eldreth
TheCollective4.com
My Articles
I hereby boycott this poll. Really....
- Leppie
|
|
|
|
|
With an increasing number of embedded devices, conserving resources such as processor and memory become vital to the viability of these products. The .NET [compact] framework can't handle the constraints of embedded devices while still providing robust functionality. And as the masses move to more and more embedded applications the .NET framework will lose it's attractiveness to true software engineers.
.NET is great for writing business applications but that's about it. Adding in the fact that many embedded devices also have depenedencies on deterministic behavior, or even moreso, executing on RTOSes. We don't use .NET at my company because of these reasons. Not that native Win32 apps provide RTOS capabilities or 100% deterministic behavior, but it's far better than what the .NET framework can provide. And in my case it's good enough.
Until MS fixes the C++ extensions for .NET, there's little chance of us moving to .NET. With thousands of lines of native C++ code, moving to the .NET model doesn't make any sense. Executing code via the CLR or native code should be a compiler switch handled by the compiler transparent to the developer. .NET has a long ways to go.
|
|
|
|
|
You bring up great points about embedded systems. Especially since for now, .NET implies Windows, which probably means a nice royalty for any embedded device shipped with .NET.
Maybe the Mono guys are working on an embedded version, that would be pretty cool. But since Mono as a whole is in beta or maybe alpha, I think you'd have to be ludicrous to ship Mono in an embedded device at this stage... 
An expert is somebody who learns more and more about less and less, until he knows absolutely everything about nothing.
|
|
|
|
|
In my solid opinion Microsoft .NET is a best thing from
developed by Microsoft. About two years ago I had a bad
thoughts about .NET. I'd changed my opinion only after
careful study .NET. I absolutely sure that Microsoft .NET
has perfect future.
Now I remembered my colleagues that say that assembler is
a very good language before FORTRAN and database because
they don't believe that third-party libraries are goods.
After then another colleagues said that FORTRAN is the best
language (it seems that I was agree with it  ) and said that C is bad. The same story with C and C++.
It is impossible to stop the progress.
It will time when another technology replace .NET.
May be it will be near artificial intelligence...
But now .NET is really the best (at least in my opinion )
|
|
|
|
|
Try Delphi
|
|
|
|
|
|
Of course NOT! Delphi for Win32 (7.0)!
The last good Delphi! Rest in peace *normal* Delphi.
|
|
|
|
|
I prefer Borland C++ Builder (and Borland C# Builder ).
But Microsoft .NET - more deeply.
|
|
|
|
|
I think .NET as an application framework is brilliant.
It's fast and a great platform to dev on. All the work that is being done to bring it to *nix is good too.
My only issue is Visual Studio .NET which I feel has too many issues.
Big statement, so here are a few of the pains (in no order):
- goto definition doesn't work for overloads (still broke in Whidbey)
- debug points jump to wrong files if you have files with the same name in a solution
- can't build to a single output folder
- Winform user controls can go missing
- Winform Forms can fail to render in the IDE
If VS2005 fixes these issues without adding any other problems, then great.
But, my team loses more time because of VS, than we do for any other reason.
Cheers,
Simon
sig ::
"Don't try to be like Jackie. There is only one Jackie.... Study computers instead.", Jackie Chan on career choices.
article :: animation mechanics in SVG blog:: brokenkeyboards
"It'll be a cold day in Hell when I do VB.NET...", Chris Maunder
|
|
|
|
|
|
The sentiment that I have picked up from ppl locally is that if a service pack gets shipped soon, then it will be more than welcome.
The issue I suppose, is that there really isn't a serious competitor to VS.
Perhaps if there was, things may be different.
Hopefully, every bug that gets logged with PSS (I've logged about a dozen on VS), will be used to better the product.
Cheers,
Simon
sig ::
"Don't try to be like Jackie. There is only one Jackie.... Study computers instead.", Jackie Chan on career choices.
article :: animation mechanics in SVG blog:: brokenkeyboards
"It'll be a cold day in Hell when I do VB.NET...", Chris Maunder
|
|
|
|
|
I completely agree with you – the IDE is the downfall of .Net !
We have wasted endless hours, redoing work, because of controls that go missing in Winforms and the "locked DLL" issue. We have even had an issue, where all the controls on a form looses their position and moves to some arb location – not even 0,0, somewhere into the negatives and then we had an issue where every now and then , when you build , all the controls on the form looses the value that was assigned to their text property. This problem became so bad, that we wrote a little application, that makes a copy of every .cs file, whenever it changes, so that we can open a functional file and copy all the work that we have lost from it.
Then there is the Intellisense engine that goes hay-wired and looses enums every now and then. Only way to fix this is to close the IDE and kill all the DLL’s and PDB’s.
Sure, the IDE works great for an solution that contains 2 or 3 projects, but any bigger than that all these anomalies start to occur. I am pretty sure that whoever wrote the
"picture and fax" viewer, was involved in the VS.Net IDE project.
Holding thumbs that most of these issues will be addressed in VS2005.
|
|
|
|
|
|
Just to clarify, I don't *hate* VS at all. I just feel that there are too many limitations / issues with a product that is in its 2nd release.
It's becoming more and more difficult to evangelise the product as more and more developers start to dig deep into the features.
SharpDevelop is fantastic! But without debugging I can't see myself using it in production.
Cheers,
Simon
sig ::
"Don't try to be like Jackie. There is only one Jackie.... Study computers instead.", Jackie Chan on career choices.
article :: animation mechanics in SVG blog:: brokenkeyboards
"It'll be a cold day in Hell when I do VB.NET...", Chris Maunder
|
|
|
|
|
First, I do not see what VS.NET has to do with .NET being ready for the masses as it is not part of .NET!
I personally love the new IDE. The only problems I have with it is the limited HTML editor, but I am sure that will get better. The bugs I can live with as I have done with every other IDE I have used in the last two decades.
Rocky <><
www.HintsAndTips.com
www.MyQuickPoll.com - 2004 Election poll is #33
www.GotTheAnswerToSpam.com
"We plan for the future, we learn from the past, we live life in the present!"
|
|
|
|
|
As a developer, I have volumes of in-house and 3rd-party libraries written for VC++/MFC. They do everything I would ever need them to and then some. What does .NET have to offer that I don't already have? Why would I want to re-write everything from scratch just to use .NET? How will it make my applications better? I have yet to hear a sound reason. Buffer-overruns? Well if you followed an actual SW development process you would catch 95% of these in unit-test, another 4.99% in integration, and the last .01% in system test. If someone could present a sound basis for me to build desktop apps in .NET, I may consider changing my position.
~Nitron.
ññòòïðïðB A
start
|
|
|
|
|
Hi,
I would say that if you can't see a reason, then don't use it. If you are happy with your current development process then stick with it.
We find that .net offers amazing flexibilty in our development of our web app and windows forms development tools. Other than garbage collection, we have a massive speed up in the development and testing of our products, we have an easy to use and manageable api through the asp.net and .net framework that we like to use. Not everyone wants to develop in C++/MFC, so how would you go about quickly making a library that worked in c#, vb.net etc. with .net you can create any component to work with any language that supports the clr.
You have implied that you catch 100% of all your memory leaks, I doubt that you can and have But I can't say that the managed framework does either, but it makes our jobs a hell of a lot easier and quicker; and from our analysis we produce better end products.
Finally, why would you have to rewrite everything, although I have not used COM interop extensivly I presume most of your 3rd party libraries are COM based and therefore can also be used in .net without any/much modifiaction.
But anyway, If you are happy with what you are using and you can produce good solid work stay with what suits you and your company.
|
|
|
|
|
Amen brotha
|
|
|
|
|
I totally agree! Some of us have been doing C/C++ for a long time and don't need to be protected from ourselves and neutered.
onwards and upwards...
|
|
|
|
|
Um... C++ is the most powerful of the .NET-capable languages. You can make all the same mistakes and wonderful hacks that you could before, plus do some cool new things. (i.e. C++ with .NET adds more complication, so if your argument is against protection and simplicity, you should move toward C++ and .NET because it is more capable.)
And how is it that being "protected" has even become part of the argument? I've seen very few people listing that as the reason to choose .NET. When they do border on the "protection" idea, the benefit is not protection from memory leaks, but speed of development. Everyone knows that developing faster is a good thing (for many different reasons).
John
"You said a whole sentence with no words in it, and I understood you!" -- my wife as she cries about slowly becoming a geek.
|
|
|
|
|
Absolutely, .NET is ready for the masses.
I wanted to respond to some of the posts below, but there are so many that I take issue with that I figured a new thread is the proper place for my comments.
The deciding factor is not any of the following:- Are users are willing to download a 23 MB installer?
- Are they are willing to update their existing .NET runtime with a newer one?
- What percent of developers are using .NET to build applications?
- What percent of .NET applications are web based vs. windows based?
- Is obfuscation sufficient to protect your intellectual property?
These are all interesting and important questions to consider before developing your next killer app in .NET or betting your career on .NET. But they don’t have any real bearing on whether .NET is ready for the masses in general.
These are some of the factors that I think should be taken into account.
Are applications built with .NET:- As rich in features and user experience as applications built with other APIs?
- Sufficiently high performance compared to other APIs?
- As easy to develop as with other comparable APIs?
- Able to run on current hardware and software?
- As secure as other applications built with comparable APIs?
- As reliable as other applications built with comparable APIs?
Let me elaborate on these points.
Point 1: This is the most important question when it comes to end users, i.e. the masses. Does you mother care about what percentage of enterprise developers are using .NET? Is she still holding out until that percentage tops 40%? I doubt it.
Point 2: This isn’t far from the top of end users wishes. They want an application which is not sluggish. I’ll grant you that .NET apps can start slow on older computers or on first run, but once they are going, they are sufficiently fast if well written.
Point 3: Any company selling applications has to make money or perish. Since a large component of their cost is developers’ time to build the application, the longer it takes to build the application the more it will cost the end user. That is, I’m contending that retail price is proportional to development cost. And thus, more productive APIs such as .NET should result in less expensive applications.
Point 4: .NET will run on the current hardware and operating systems of most [Windows] users. Granted they may have to download the .NET framework, but how did they get the application in the first place?
Point 5: There is no contest here as compared to say Win32. Can you say buffer overrun? Not in .NET.
Point 6: See point 5.
Michael Kennedy
Partner, Software Engineer
United Binary, LLC
Index of my code project articles [^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
and I would love to meet the "programmers" on the dev team. The points mentioned by Simon are valid since I've had the same (AND *MANY* OTHER) issues with VS and VSS.
but I refuse to stay quiet about this horrible product any longer!