Pointy-haird bosses
-
Personally it's not just the speed increase due to not having to worry about memory management, Unicode issues, cross-laguage issues or a library that isn't broad enough - it's things like reflection that allows improved debugging, error reporting, and development tools; A better base class library so you're not spending as much time reinventing things; cleaner language syntax and the no-memory management and inherent security that mean maintenance, debugging, extensions and getting new developers up to speed on old code that are all faster and easier.
cheers, Chris Maunder
CodeProject.com : C++ MVP
wow ! you have included almost everything in three lines.
Chris Maunder wrote:
maintenance, debugging, extensions and getting new developers up to speed on old code that are all faster and easier.
you can say that again
Omit Needless Words - Strunk, William, Jr.
Vista? Cryptography Next Generation (CNG) here
-
The Grand Negus wrote:
Well, does it?
Yes it does.
The Grand Negus wrote:
If so, how much faster?
2-5 times faster than developing in c++, vb 6.0, foxpro, dbase, pascal, classic asp, java. Its relative to the software you want to compare with. Just drag and drop couple of buttons, textboxes, labels, listview and write some events and you have a form ready, imagine this same thing in c++ or java. You will have to write at least 5-6 times the code to draw these forms, buttons, listview and other stuff.
The Grand Negus wrote:
If not, what good is it?
(4 million members - you) think its good :).
Tarakeshwar Reddy wrote:
Just drag and drop couple of buttons, textboxes, labels, listview and write some events and you have a form ready, imagine this same thing in c++ or java. You will have to write at least 5-6 times the code to draw these forms, buttons, listview and other stuff.
Erm...ever heard of the dialog editor? Seriously, form or dialog design is pretty much the same regardless of whether you write in C#, VB, C++/CLI, C++/MFC or C++/WTL. I'd suggest that the Windows resource file format (.rc) is far more maintainable and less fragile than the .NET .resx format, too. Now if you want your UI to be testable (we've seen the light and now use Test Driven Development[^]), that requires forethought and design regardless of which framework you use - and that of course takes time. :rose:
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
The Grand Negus wrote:
Well, does it? If so, how much faster? If not, what good is it?
I do think that .Net helps me write applications faster. As for "how much", I really have no idea. I really don't care. Why? Because speed of development isn't everything - not even the main thing. As long as I don't write applications significantly slower using .Net than using 'traditional' methods, then I don't have a problem with .Net. So, what .Net does do for me, then? "What good is it?" The benefits of .Net are that it helps me maintain my applications more efficiently, it helps me debug my applications more quickly, it helps me write better applications, it enables me to write applications I couldn't write before, and (most imporantly) significantly adds to my enjoyment of writing applications. The truth is that speed of development is marketing hype. Most marketing hype is about the things that matter to people who buy products, not about the things that matter to people who use them. A lot of products have 'features' that are there to sell them, not for people to use. For example: How many people buy mobile phones with all the latest features and just use them to make calls? How many people buy a video recorder because of all the clever things they can do (like make the tea, clean the toilet etc.), then just use them to watch pre-recorded movies? My Blog: http://allwrong.wordpress.com[^]
-
Where do they come from?:rolleyes: I gave a briefing to my new boss and some staff about what .NET is all about. His response was "I don't understand. I thought .NET would allow you to write applications faster. How can it take six months to write something? Did we make a mistake going this route?" His view of .NET prior to my presentation was that .NET was just another reusable library, plug it in and you have an application.
only two letters away from being an asset
A competent IT professional should realize that there is a vast majority of people out there who do not know or care what .NET is. They are interested in the end product. The nuts and bolts that make up the product is not of most peoples concern or should be. The platform .NET is nothing without a decent understanding of the required objectives. This needs to be effectively communicated to lay people at whichever level this may be. I would not be surprised by your bosses words. It is pure .NET marketing speak that made him think that.
-
The Grand Negus wrote:
Well, does it? If so, how much faster? If not, what good is it?
IMHO, .NET does provide faster coding for Windows based apps than in some other languages, like Java and C++. If you want a comparison, here is one place to check: http://www.qsm.com/FPGearing.html[^] Note that VB.NET (Visual Basic) takes less coding than C#. Both are .NET, but VB is a slightly more productive language. However, given a dev team of Java and C++ developers, .NET would take more time because ofthe learning curve. Given a dev team of VB6 developers who have been using VB6 for OOP (which not all have been doing so), moving to .NET has a much lower learning curve, and would save some time. It takes the opposite of a pointy-haired boss to recognize when .NET would help in the short and long runs, and when it wouldn't.
-
The Grand Negus wrote:
schoolgirls".
Care to explain that remark?
__________________ Bob is my homeboy.
-
Ahh, but see, you can read it. ;)
"We are all repositories for genetically-encoded information that we're all spreading back and forth amongst each other, all the time. We're just lousy with information." - Neal Stephenson
-
The Grand Negus wrote:
Twice as good - yeah, go for it. Three times faster - no doubt! get me one of those. And... Ten times better - ah! now we're talking a whole "order of magnitude"; there's probably something very significant here; don't just get one, study it.
I'm going to redirect this a bit. In my experience, the only single change in application development that made as large a difference as you are suggesting was moving from plain jane C++ IDEs to Delphi 1 back in '94 and Delphi 2 in 95. Since then every environment/language I've used is more incremental baby steps (if it is actually better in any way at all). Of course I haven't written a non-analysis piece of code for the past 4 years and am only using C# and .NET as a gooey wrapper for Fortran (90/95/2003) code that I'm forced to write/modify/update that relies on legacy F77 libraries. Gotta love high tech advanced interplanetary exploration.
-
.NET compared to the way things are done with MFC or 32 bit Windows Programming makes development faster. .NET was a reorganization of all windows "controls" into a logical class hierarchy whose base class is of type 'object.' With 32 bit windows programming it was up to the developer to code the application's message pump and applications also had these long switch-case blocks to test for all the different windows messages they wanted their application to react to. You don't have to do any of that with .NET which means you don't have to remember all the different names for windows messages or what goes in a WParam or LParam of a windows message. .NET also provides help to developers via the CLR. In C++ 32 bit windows programming developers have to remember to deallocate the resources they allocated, in .NET object destruction is taken care of by the garbage collector, .NET provides delegates as a way of registering a method (or function in C++ jargon) with a type so that it is called when a certain object state occurs, and .NET provides properties to allow you to access a type's visible variables. I could on about the benefits that .NET provides. For the sake of brevity you can read more detail about what .NET and the CLR do to help you develop faster, and better, in a book titled "CLR Via C#" by Jeffrey Richter (MS Press). I helped Jeff write the book so I guess I know a bit about the topic. I didn't get a t-chirt for helping but at least I'm mentioned in the acknowledgement section. :O) As for Pointy haired bosses, I would ask them why they committed to the .NET technology without fully understanding what it is; sounds like an impulse decision, albeit the right one. Jamie Haddock
-
Why does coding have to be faster? If we can't take our time what good are our overpriced salaries ;P Seriously though, why does a solution need to be faster to code. How about better running executable, that gives lots of nice debugging info if it crashes? How about widely used, so will be easier to find someone that can understand the code once your gone? How about supported (sorry VB 6 guys it was great while it lasted)? How about a nice IDE (maybe not perfect but pretty nice)? How about that is what Microsoft tells you to use, and you will obey? :laugh:
-
There are quite a few advantages that are day to day. One string type regardless of whether you're working with COM or not. That alone is one large advantage. ADO.NET is a huge improvement over both OLE Db and MFC's Recordset. Event handling is alot better. No more mucking around with sending and posting messages unless you need something outside of what's provided. You still have access to the win32 message pump, but I haven't needed to use it. All of the controls for a given dialog are resident within that dialog's class regardless of whether there are tab controls. Before property sheets and pages were seperate windows and required the use of the message pump or global variables to communicate. Now its all within one place and access to the data... Properties with UI controls makes it quite easier to get data and set data. In win32 you were sending messages with buffers from the heap. In MFC you had their macro mapped members. Code behind ASP.NET pages and webservices all using the same class libraries as the clients makes code usage and sharing alot easier. Not to mention that your app guys can work on the business logic behind the ASP stuff without even needing to be concerned with knowing Web development. This allows sharing skill across environments much easier. Doesn't matter the language they're familiar with either, as the CLR and the CLI handle that. Delegates and events allow mapping to members of your classes to be invoked. A bit of work is required to do this in other environments. Threading is easier to work with. Create a thread, map it to a member and start it. Using the delegate we get a direct mapping to a member of an object without some funky static function work around with the this pointer. We also get the thread pool for small atomic operations that you'd processed in the background. TCP/IP is a lot easier to work with. And its asyncronous support is out of the box. No more messing with the IO completion ports. I can hook up an HTTP channel in about 5 lines of code. Serialization is smoother. Before we had to overload streaming operators and handle the streaming ourselves. Now we label it serializable and use either the binary or soap formatters and grab the stream from there. No more need to worry about packing your structs along page boundries for proper loading. Now with WPF you have access to declarative vector based UI development. I don't know enough about it though to comment further. Except that you'd need to roll your own before. Working with C
-
Why does coding have to be faster? If we can't take our time what good are our overpriced salaries ;P Seriously though, why does a solution need to be faster to code. How about better running executable, that gives lots of nice debugging info if it crashes? How about widely used, so will be easier to find someone that can understand the code once your gone? How about supported (sorry VB 6 guys it was great while it lasted)? How about a nice IDE (maybe not perfect but pretty nice)? How about that is what Microsoft tells you to use, and you will obey? :laugh:
Well, going back a bit, programmers were cheap. Hardware was expensive. Now its the other way around, so managers are looking to control the expensive part. Its cheaper to throw more hardware at a sluggish app than it is to pay the engineer to optimize it. In most cases.
This statement was never false.
-
Well, going back a bit, programmers were cheap. Hardware was expensive. Now its the other way around, so managers are looking to control the expensive part. Its cheaper to throw more hardware at a sluggish app than it is to pay the engineer to optimize it. In most cases.
This statement was never false.
Very true, except for one thing. Since we are writing more web based apps, and in at least Bill Gate's dreamland, among others, everything will end up being web 2.0 apps, most stuff will be running on server side. Servers are very expensive, and require lots of staff to keep them running. So you reduce the front end cost, and increase the back end. It might end up that the net effect is in your favor for these types of apps, I'm not sure. Pushing the cost to the operating side might not be so bad for a start up looking to get a product to market as quick as possible to start a revenue stream. But in the long run, bad news, because your code base might continue to bleed money from you slowly for decades (unless your betting on throwing the code away in a few years and not keeping any legacy code around). This is especially the case with data/web based programs, as your customers aren't buying the extra hardware, you are.
-
Very true, except for one thing. Since we are writing more web based apps, and in at least Bill Gate's dreamland, among others, everything will end up being web 2.0 apps, most stuff will be running on server side. Servers are very expensive, and require lots of staff to keep them running. So you reduce the front end cost, and increase the back end. It might end up that the net effect is in your favor for these types of apps, I'm not sure. Pushing the cost to the operating side might not be so bad for a start up looking to get a product to market as quick as possible to start a revenue stream. But in the long run, bad news, because your code base might continue to bleed money from you slowly for decades (unless your betting on throwing the code away in a few years and not keeping any legacy code around). This is especially the case with data/web based programs, as your customers aren't buying the extra hardware, you are.
The productivity gains are on both the server and client sides. So, what is your point? Its a matter of cost of production verses cost of hardware maintenance. Not about cost of methodology. Moving to .NET we've saved money.
This statement was never false.
-
The Grand Negus wrote:
schoolgirls".
Care to explain that remark?
__________________ Bob is my homeboy.
I'll have a go here I have been in a few situations where a few .NET developers have replaces 6-8 java developers. THe MS platform is quicker but also you can really stuff up if you do not understand software architecture which most java :) devs do. With Linq a wolf in sheeps clothing this is really OO database it will cut a further 30% off dev time but further compound the architectural issues. Boss's and Manager's what can I say unless enough of us give up coding we will never be safe. Even a lot of coders lie and under estimate time to get the opportunity or the project they want, then they do a hack job, which everyone else spends months fixing they call that a technical lead usually. But if it hits the deadline the manager is happy (until he realises he has 3 months of bug fixing and has to rewrite half of it), this has happened the last 4 companies I have worked for exact same pattern. I find after the first screw up though the next time they are hanging on my word for a time estimate not the other guy, but strangely you can't turn that into a pay rise. In fact your boss will want to stop you coding all together and make you into a BA and dumb like him. The only solution I can see is to have architects that are allowed to write code to demonstrate how things should be done or specify carefully to developers with real power and control of the BA's
Solution architect MS-Windows .NET SQL Server / Oracle
-
MONO (and GTK.net if you need a not web UI).
-- You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer
What microsoft has cleverly done with the CLR is made the OS redundant Linux have lost the war and they don't even know it. It is about the tools to build apps given the MS tools are consistent and well integrated they are ahead and building on their lead. Yes it is definitely faster. MS gives you a default standard. Because of the disunity within the Linux open source java camp they will never get there. If mono does its job well in implementing the CLR amd some one Puts a APS.NET compatible web server on Linux it will be all over. The OS is worth nothing platform is irrelevant now. THe CLR was a brilliant technical and business manuevre it is genius and will continue to .NET billions for MS for a long time
Solution architect MS-Windows .NET SQL Server / Oracle
-
There are quite a few advantages that are day to day. One string type regardless of whether you're working with COM or not. That alone is one large advantage. ADO.NET is a huge improvement over both OLE Db and MFC's Recordset. Event handling is alot better. No more mucking around with sending and posting messages unless you need something outside of what's provided. You still have access to the win32 message pump, but I haven't needed to use it. All of the controls for a given dialog are resident within that dialog's class regardless of whether there are tab controls. Before property sheets and pages were seperate windows and required the use of the message pump or global variables to communicate. Now its all within one place and access to the data... Properties with UI controls makes it quite easier to get data and set data. In win32 you were sending messages with buffers from the heap. In MFC you had their macro mapped members. Code behind ASP.NET pages and webservices all using the same class libraries as the clients makes code usage and sharing alot easier. Not to mention that your app guys can work on the business logic behind the ASP stuff without even needing to be concerned with knowing Web development. This allows sharing skill across environments much easier. Doesn't matter the language they're familiar with either, as the CLR and the CLI handle that. Delegates and events allow mapping to members of your classes to be invoked. A bit of work is required to do this in other environments. Threading is easier to work with. Create a thread, map it to a member and start it. Using the delegate we get a direct mapping to a member of an object without some funky static function work around with the this pointer. We also get the thread pool for small atomic operations that you'd processed in the background. TCP/IP is a lot easier to work with. And its asyncronous support is out of the box. No more messing with the IO completion ports. I can hook up an HTTP channel in about 5 lines of code. Serialization is smoother. Before we had to overload streaming operators and handle the streaming ourselves. Now we label it serializable and use either the binary or soap formatters and grab the stream from there. No more need to worry about packing your structs along page boundries for proper loading. Now with WPF you have access to declarative vector based UI development. I don't know enough about it though to comment further. Except that you'd need to roll your own before. Working with C
Thank you very much for this post. Out of the 20+ posts I've read so far (beside the very first starting post) this post has been the only post that should have been posted. I agree with the guy before, this forum spam by 'schoolgirls' leaves alot to be desired. I really aprecaite this post, thank you for your comments/time.
-
The productivity gains are on both the server and client sides. So, what is your point? Its a matter of cost of production verses cost of hardware maintenance. Not about cost of methodology. Moving to .NET we've saved money.
This statement was never false.
I'm not talking about development efficiency. I love .net for little apps I do for that reason. I'll concede that .net blows away most competition for speed of development. So if your making the app for someone else to run on their systems go nuts with .net. A thick client app isn't a good example of what I'm getting at, there you pretty much tell the customer "our app is great but you need a new computer to run it". Video game industry does this all the time. An example of what I'm getting at: Say your Google. You have a great web based app you want everyone to use, say your own office suite. The beauty of it is that the user has to download minimal stuff, and you'll always have the most up to date version on the site. Well you can use quick to code, less optimized programming to do the trick. Or spend time hacking in MFC and compiling native code, tweaking etc. Lets say two scenarios for simplicity. 1) you need twice the resources to do it than a well written program. 2) you can spend twice the resources on the development end. A rough model budget for both scenarios over 9 years: 1) development 20 developers X 70k X 1 yr 1.4 M production: 10 servers X 15 / 3 yrs 1 DBA/sys admin at 80k / yr 1 lacky backup/junior admin 50k/yr 1.62M total = 3.02 M 2) development 10 developers X 70k X 1 yr 700 k production: 20 servers X 15 / 3 yrs 2 DBA/sys admin at 160k / yr 2 lacky backup/ junior admin 100k / yr 3.24M total = 3.94M Looks bad right? I think my scenario is closer to reality than one where you can buy a box and forget it. Plus I haven't included power, and any licensing. What if you need a database on each of the servers, at about ~40k per CPU? Obviously people take more care the more that the extra resources is going to cost them. But my argument is that for todays data intensive apps, especially web based services, it is the operating cost not the development cost you need to worry about. P.S. Microsoft the king of thick client apps is saying soon you'll do everything as a pay for service off the web. If they are saying it, I think concentrating on PC based clients for broad based development paradigms is short sighted. We are going back to expensive (for the company) computing.
-
This is something I have been interested in too. Let me know if you go ahead with it. :) A big problem I saw was working out how to make a fair side-by-side comparisons. Someone who works with C++/MFC everyday will produce a simple windows application faster in MFC then they would .Net only because of lack of exposure to .Net. When I first started using .Net I found myself writing simple utilities in C++/MFC because it was quicker then trying to work out in .Net.