|
What concerns me about .NET is that Microsoft is neglecting increasing the standard conformace of its C++ compiler. For example, partial specialization has been the C++ standard for quite a while. However, MS has been so busy working on .NET and C# that, from what I have heard, they will not be adding it into VC.NET. I like .NET, and think it's a good idea, but I think MS should also improve its products for those who are not corporate developers of distributed applications
|
|
|
|
|
I've been playing around with ASP+ and I've been thinking about how it compares to writing plain ol' ASP. One of the greatest differences is that whereas in ASP you typically write server side VBScript and client side JScript, in ASP+ you write server side anything - C#, VB, Perl, COBOL. Does this mean a typical web developer will need to know a minimum of VB and C#? Similarly, in .NET you can derive your classes from any language, so a C++ developer may be forced to run through aVB code while debugging, which then may drop further into C# and maybe back out into C++ again.
Does this mean we can no longer stay in our comfort zones of knowing only one or two languages?
cheers,
Chris Maunde
|
|
|
|
|
I don't know Chris... but I wouldn't be too comfortable these days if I only had one or two languages under my belt. It seems like more and more companies are making use of multiple languages these days, I suspect for one or more of these reasons:
1. Microsoft currently doesn't support a language that combines the power of C++ with the ease-of-use of VB. C# may change that but it's too early to tell.
2. Visual Studio comes with multiple languages so it's easy to switch from say, VB to FoxPro or viceversa, when the need arises.
I guess what I'm saying is that it's already happening even today: one developer having to know multiple languages. What .NET is really going to do is make developers work with these languages simultaneously in the same project. That will definitely be interesting... although it brings back daunting memories of my days when I had to maintain an executable with had C, C++, and FORTRAN source files. Yipe!
|
|
|
|
|
Hmm - I remember combining C, FORTRAN and Motiff on a Unix system and it was a nightmare. Moving this over to VC++/MFC and Windows 95 was a fun time in my life
I guess I had the impression that the average developer tends to get very comfortable with a single language and will stick to it come Hell or high water (see the poll Are you a programming snob?). I was talking with Shanker the other day and we got onto the subject of working in different languages and environments, and maybe the issue is not the language, but the area of development. There is certainly a fear among some (me included) that by spending a lot of time working with, say, VBSCript you tend to lose your hard fought edge in the VC++/MFC world. Maybe the deeper issue is that some developers simply don't want to work in certain areas. For instance, someone who has no interest in COM components may never see the need for ATL, and someone who detests web development may never have the need or desire to work with VBScript. Maybe this is a contribution to the apparent relunctance to take on new languages. Maybe not - I have no idea but it is kinda interesting.
cheers,
Chris Maunde
|
|
|
|
|
WOW .. I'm a programmer w/ about 3yrs experience ... I've never had a comfort zone of one or two languages .. I've had to learn/hack just about everything language you can think of .. well except for fortran/pascal.. Generation gap?? maybe..
I don't think you can get by knowing one or two languages anymore. Of course if you know C++ fairly well and one 4GL language you can get just about any language quickly ..
jon
|
|
|
|
|
.NET is just another framework. Although, I hope it does take off and become wide spread (which it most likely will) there are still a few pitfalls to the whole .NET future.
1) Whether you like it or not, .NET is designed to be run on Microsoft products, technically speaking it is platform independant. But in reality it is not, because you will gain maximum performance and benefit from using .NET only on Microsoft software.
2) .NET is a new way to program. I think it will lose some support simply because of the new technologies that need to be learned to program the most effectively in the .NET enviroment. I dont want to learn C#. I see no advantage. I do not mind the manual memory managment nor do I mind adding 'break;' to my switch statements. Microsoft is trading power for simplicity and I disagree with that philosophy.
3) .NET will only be succesful if it is adopted by many developers.
4) The whole idea of 'Web Services' is based around fast broadband connections. This is simply not a reality!
.NET will revelotionize programming, for many years to come. I cant wait, can you?
|
|
|
|
|
>> 4) The whole idea of 'Web Services' is based around fast broadband connections. This is simply not a reality! <<
Simply isn't true. A web-service is data without display. Currently we have both melded together in the form of HTML. .NET components will run on the client side and will consume Web Service data, so we are in actual fact reducing the bandwidth requirements.
Even code will be smaller. No longer will we have to download statically linked libraries, or MFC DLLs and other system DLLs. .NET only depends upon the rich services provided by the runtime and so images are smaller and download times are reduced accordingly
|
|
|
|
|
Comments:
1) Don't agree that there's anything in the CLR specification that would cause performance bottlenecks on non-MS platforms, could you give examples ?
2) So .NET is just another framework AND .NET is a new way to program and will revolutionise programming.
It will lose some support because it's going to make programming simpler. Surely you have unmanaged C++ for power and MC++, C# and VB for simplicity.
3) I agree on that one.
4) There's nothing in Web Services that requires a fast broadband connection that I'm aware of. Think of the difference in Web Traffic between a site that makes you navigate through 10 pages to place an order for a shiney new Compaq iPaq (with adverts and bitmaps on each page) and another that sends all the information in one single Web Service call from a (safe) GUI written in WinForms.
Just think if this purchasing application was written by Microsoft, built into Windows and required a site to support a given SOAP protocol.
|
|
|
|
|
Dan,
I agree w/ everything you stated however, I have to disagree w/ #2 .. There are many developers who are VERY excited about C#.
Personally... I could never pass a Java application to anyone without feeling guilty and I NEVER DID.. I'm hoping ( well.. PRAYING !! ) that C# is the answer to Javas problems.
jon
|
|
|
|
|
I think the poll options would be simpler to understand if you changed them to;
o Yes
o Yes
o Yes
o Maybe
o Yes
o No (Bandwidth)
o No (I'm lazy)
... a little weighted, perhaps? Couldn't option seven have been a simple "No"?
|
|
|
|
|
Looking at the number of votes for the penultimate choice, it seems nobody want to be the one who underestimates the potential for future advances
|
|
|
|
|
Yes, You only have to be involved in the IT industry for 1 or 2 years to start to appreciate the leaps in H/ware technology.
Certainly Bandwidth across copperwires is not increasing as fast as processor speed or Disk capacity or Ram Quantitys, But never-the-less it is increasing.
Quite Possibly Bandwidth will increase in BIG leaps rather than a sequence of small leaps. Part of the reason for this is the physical limitations of laying new lines and exchanges.
My Rant for the Day
|
|
|
|
|
Given the amount of time it is going to take Microsoft to change the direction of the elephant (Windows development movement), I think they've outlined a pretty reasonable plan.
In the last 5 years, we've gone from occassional dialup with 14.4k, to dedicated 28.8K, to ISDN, to T1 to full ethernet. I'd imagine within 2 years we'll be at 100mb. Although I can hardly see what we'd do with all that bandwidth, I have this strange idea that my team will *still* be saying that we need more bandwidth
I'm less optimistic about .Net->Wap connectivity. I think Bluetooth and wireless in general will be a flakey, intermittent and low-bandwidth proposition for some time. (and I hate typing URLs into a cell phone).
Personally, I think the .Net stuff rocks. And no I'm not saying that as a someone who sells programming libraries, I'm saying that as a developer who's written hundreds of apps and been amazed and frustrated at how complicated things that should be easy are
|
|
|
|
|
A Couple of my opinons in regards to your post, David
1. Only when Joe - User, buys a T1 Connection as standard can we say that the T1 has arrived.
2. Net is going to be real useful for Appliances,
eg when you buy a good electric pencil sharpener it'll be internet capable. (" Don't ask me why " )
3. Typing URL's into cellphones is absurd, However future cellphones should have better processors that would utilize autocomplete and voice control.
4. Things that are still difficult that should be easy -
Well they could be a lot more difficult.
Regardz
Colin Davie
|
|
|
|
|
Colin,
>>1. Only when Joe - User, buys a T1 Connection as standard can we say that the T1 has arrived.
My CableModem at home usually provides performance superior to a T1 (although sometimes sadly it does not). I think in North America at least always-on broadband internet access is a reality for a signficant percentage of the population.
>>2. Net is going to be real useful for Appliances,
eg when you buy a good electric pencil sharpener it'll be internet capable. (" Don't ask me why " )
After years in this business, it's only just occured to me that "internet appliances" are really things like plug-in network storage, or plug-in web servers. What I'd always thought of as iAppliances are really better described as wireless devices (pads, palmtops, autopc's).
What I'm looking forward to is the fully internet enabled wireless *pencil* that automatically notifies Outlook that it needs to be sharpened, and schedules a time for me to do it
>>3. Typing URL's into cellphones is absurd, However future cellphones should have better processors that would utilize autocomplete and voice control.
I hope so. I have voicedial on my cellphone and all I can say is... I hope the better processors come along soon. Actually the voice recognition stuff happens at the telephone company, not on my phone.
>>4. Things that are still difficult that should be easy -
Well they could be a lot more difficult.
Sometimes that's hard for me to believe. All I need to do to reaffirm my feeling that most things are too complicated is to setup a fresh install of Exchange, or try to debug an ISAPI extension...
|
|
|
|
|
> In the last 5 years, we've gone from occassional dialup
> with 14.4k, to dedicated 28.8K, to ISDN, to T1 to full
> ethernet. I'd imagine within 2 years we'll be at 100mb.
What is this "we" nonsense? Most of the world is still stuck at 28.8! Correction: most of the world doen't even have Internet access: most of the US is at 28.8.
I live in a small city on the west coast. The various telecom providers here cannot tell us when high-bandwidth options will be available. ISDN is the best I can get, and I'll be paying through the nose for it. And when DSL or cable arrives.. yes, once everyone in the neighborhood has it, it will slow to a crawl.
We don't have an infrastructure to move the massive amounts of data required by the .NET nightmare. And nobody is planning one, either.
|
|
|
|
|
Wow.
I don't think I know anyone who has less than ADSL or CableModem (except Chris of course ). I'm not trying to be a snob here, but I didn't think Canada was leading the world in connectivity, but man it appears that I may be wrong.
I think .Net is more about corporate intranets than it is about feeding services via 28.8 modem to home users, and you are right, there are way, way, way too many round-trips required by WebForms to be reasonable over dialup. Even the webservices architecture is going to be pretty pathetic over high latency networks, but that's not stopping companies like IBM and Microsoft from plowing ahead with these initatives.
|
|
|
|
|