Pointy-haird bosses
-
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.
-
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.
I'm very new to coding. I do not have any experience with either VB6 or C++. I've had classes in VB.NET and C# so I'm starting from scratch. :) I seems to me that whether someone is faster in one coding language than another would determine if it is faster for them to do a project or not. For someone just starting, like me, it would take longer to code a program than someone who has done it for years. :( (Just my two cents worth.):cool: Progress is made by two types of people. Those who know it can be done, and those who don't.