|
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 [^]
|
|
|
|
|
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.
Care to explain yourself here?
An expert is somebody who learns more and more about less and less, until he knows absolutely everything about nothing.
|
|
|
|
|
Navin wrote:
Care to explain yourself here?
Sure:
I wrote:
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?
Point 3: When considering whether apps built with the .NET framework are ready for end-user use, I don't see how what other developers are doing is relevant to this discussion. It is important if you want a job programming .NET. It is important if you want to sell tools to developers developing in .NET. But it is not important to your mother what percentage of developers are programming in .NET. The question to them is only whether the particular app they are considering does the job.
Point 4: This has even less bearing for the user than does point 3. They don't see the code for the web apps and they don't execute it. It doesn't apply here.
Point 5: The end user does not care about how well your code is obfuscated. They want features, security, reliability, etc. Developers care, you care, but end users don't. Granted there may be a few punks trying to steal your software, but they are the minority by far.
Point 1: This is the biggest obstacle for users to use programs written in .NET, but it is minor. One of my favorite programs is NewsGator and happens to be written in .NET. They have the best download solution for dealing with non-technical end users that I have seen. Take a look at this page:
http://www.newsgator.com/downloads.aspx[^]
When I visit there, I get:
You appear to have the Microsoft .NET Framework installed. We recommend you use the following download links: ...
Their website determines which version (if any) of the .NET framework you have installed and recommends the course of action. To me, this sufficiently solves the missing or out of date framework issues. Beyond this, it's only a matter of time until everyone has the .NET framework. And that time is <= Longhorn's adoption date.
Point 2: See Point 1.
Regards,
Michael
Michael Kennedy
Partner, Software Engineer
United Binary, LLC
Index of my code project articles [^]
|
|
|
|
|
I'll give you 3 and 5.
4 is impoortant precicely for the reasons you say. It doesn't matter to a user if a Web app was written with .NET or not, becuase it won't affect them. A user will be affected, though, if a desktop was written with .NET.
For points 1 and 2, the URL you sent I actually consider a pretty bad way of handling it. For one, it doesn't work in Mozilla. Mozilla is slowly gaining traction... so discounting it completely is a bad idea. And it appears that the download with .NET is too small - which probably means it's not a full download, it's probably one of those installers that has to download a bunch of stuff while it installs... so telling the user it's only 2 meg is a bit deceiving. And it remains to be seen whether it will correctly do version checking and identify whether or not the *right* version of the .NET framework is installed.
There will be a day when these aren't issues... I am guessing around 2008, when Longhorn and .NET version 2.0 are out and widespread.
An expert is somebody who learns more and more about less and less, until he knows absolutely everything about nothing.
|
|
|
|
|
Regarding point 4, all code can be disassembled -- be it native code or IL, and therefore potentially cracked or algorithms stolen. Despite all MS's efforts to make people register Windows XP, there exist cracked versions of that. Despite all the efforts of the gaming community, cracks come out within a matter of days for the most popular (and most well "protected") games. There is no perfect way to protect software for PCs. (If there is a perfect way, let me know... I could use it )
|
|
|
|
|
While I agree with most of your points,
Michael Kennedy wrote:
NET will run on the current hardware and operating systems of most [Windows] users.
About 80% of the my company's users are using Windows 95 on a Pentium 1 75Mhz with 32Mb of memory. Just thought you'd like to know.
"if you vote me down, I shall become more powerful than you can possibly imagine" - Michael P. Butler.
|
|
|
|
|
According to Microsoft your workstations don't exist anymore. Just thought you'd like to know.
|
|
|
|
|
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!