Actually, i think you will find that the fundamental design is essentially the same these days.
Every app I write now uses the .net framework. The other day I wrote an app for one of the tech support guys in half a day that would have taken me a week in MFC. The app is going to less susceptable to bugs than an MFC equivelent, and the code is far more secure. Thats why people use it.
The idea behind .net is that you can install multiple versions of the framework, and they will all work alongside each other. You could not do that with DLL's.
As for dot net, there is 1.0, 1.1 and 2.0. With vista comes 3.0, but that is pretty much 2.0 with WCF and WPF rolled in.
The code behind maybe different, but the model is essentially the same. Both are managed languages, both compile to an intermediate language, both are JIT compiled at runtime.
.net is robust in the same sense as java. Sure you can write unsafe code (in fact MS even use the term unsafe in the languages) but then you are being plain mad.
Cripple and Slow? You quite clearly have never used it in a commercial environment. I do, in an enterprise environment, and I can assure you it not cripple and slow.
Microsoft love people like me because we spend money on their products. I don't buy the MS marketing, I buy the products because I can develop in a shorter timeframe and my code is a lot more robust. In a commercial environment that means a lot, the business gets what they want on time, I get paid and they then give me more work because I can deliver. Its pretty simple.
Sorry, I meant Win32. However in saying that, when Borland dropped OWL they began paying MS a licence fee to use MFC. I have not touched Borland for some time now, so I don't really know what the deal is these days.
I did just knock back a job that involved Borland C++ however. Also knocked back a Delphi job too, both in preference for a job doing enterprise .net systems.
Unfortunately, .NET doesn't completely do away with DLL hell. For most of the assemblies, you only get "coarse" versioning. 1.0 and 1.1 are "different" but 1.1 and 1.1 SP1 are "the same". This has caused problems where MS has changed the way things work with a service pack, with the resulting application breakage.
--
Michael Brown
Add michael@ to emboss.co.nz - My inbox is always open
Java runs in a safe and secure "sandbox" it cannot gain access to anything you don't give it access to. It is safe by design... that said, I don't write Java, or C#... I prefer the embedded world.
I never found that to be true. I have found that Microsoft's applications tend to confound my efforts to write good software. I would much rather work with opensource.
The problem as I see it, is MiracleSlop has such a monopoly on seats in the computer world that finding opensource work is difficult. It is worth the effort, though, as it is so much easier and more reliable.
Crap , crap and double crap. .NET is not the same in the background.
Typical young coder.. I've been around the barn far longer than you think. I feel sorry for people like you getting lead down that dark path.
Yeah i know, it's pretty simple. MS loves simple users. glad you finally admitted it.
Borland has never implemented any of MFC in any of the produces to the end user. I don't know where you got this information from but it's clearly incorrect. Borland has there own set of class libraries that simply sprang from the early days of OWL. they call it the VCL now. VCL = Visual Control Library.
Don't feel bad, you did them a favor by not letting them hire you.
Yes i am , i'm also a MS VC++, VS , user. write code for Windows Mobile etc.. I've been in the field sense the day's of punch card computers and have fallow the product line's of Borland, MS, Symantic, Watcom to say a few. Now that we're done with our pissing contest, go back to your slow .NET MS controlled applications. and hope you have fun writing slow bloated code. Just think, since you're suck a good MS customer, maybe they won't make you wait for months to fix a crash/serious bug that arises in your code due to a frame work error that only MS can fix.
--
"I\'m never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5
The path to finacial success. Its funny how when people lose an argument they resort to insulting people.
Ahh, remember when Borland dropped OWL, they licenced MFC? Remeber that there was some condition regarding the approval that prevented Borland from continuing with MFC? It was about this time that everyone stopped using broland products. VCL is completely different.
Its funny how when people lose an argument they resort to insulting people.
Excellent, you must be very successful in your job.
I still cant see where you get slow and bloated from. You really should spend some time using .net, you will be surprised.
Hasn't happened to me yet, and I have been using .net for 4 years now.
IIRC, Borland licenced MFC around the time of C++ 5. It was only included for compatibility reasons so that you could compile your MFC apps with BC++, and it didn't always work 100% (due to the dependence of MFC on MSVC undocumented extensions). OWL was still very much the focus of BC++ 5.
BCB was the next product in line, and this used VCL instead of OWL. OWL wasn't dropped until BCB5, though it was (like MFC) included only for compiling older projects with the newer compiler. MFC compatibility is included all the way through the BCB line AFAIK, though it's for compiling only. You can't use the designer to make MFC GUIs.
There was a big debate a couple of years ago in one of the borland NG's about when/why/how Borland "lost" the C++ market. Their marketshare had dropped substantially long before BCB was released, or OWL was ditched for that matter. The basic problem was versions 4 and 5 of BC++ were pretty bad (especially the IDE), and OWL was simply not being updated and fixed very quickly. While they picked up some new people with the VCL (though more with Delphi than BCB) they'd lost their momentum in the C++ market, and with MS's aggressive pushing of MSVC (and later poaching of a significant number of key Borland developers) it was pretty much impossible to come back again.
[...]
You've never tried running a .NET application on a machine with 512MB of RAM, I guess? :)
Cold start times for .NET applications are terrible. Even a simple winforms "Hello World" takes somewhere between 15-25 seconds (depending on the phase of the moon) to start where the CLR isn't already loaded (for example, after a reboot, or if you have 512 MB of RAM as the CLR files fall out of the cache pretty quickly). Warm start times are better, though still in the order of 3-4 seconds. Compared to, say, firefox, which cold-starts in a bit under 10 seconds and warm-starts basically instantly. While this isn't a problem for applications that run all the time, it prevents .NET from being used for small utility applications - I don't want to wait for 3 or so seconds while calc or notepad starts, for example. Similarly, meory usage is terrible for .NET apps - a "Hello World" takes up around 7MB of RAM.
As MS forces more and more .NET stuff on people, these problems wil become less significant since the framework will always be loaded - it's not really a nice solution, though, as all that means is that you've got bloat loaded all the time (taking up space that could be used for better purposes), not just when you run an app that needs it.
Performance-wise, it's a bit hard to compare. For complex FP stuff , .NET is slower (at least on K7 Athlons and P4's), no questions there. It depends on the exact algorithm, but I've typically seen anything from a 20% to a 100% increase in computation time required. CPU-intensive stuff in general is slower, but most of the tests I've done are FP-based things so I can't give a decent range for other types. For I/O intensive stuff such as throwing files through sockets, most of the time is spent outside the application, so although the application may only be operating at half the speed of a native app it doesn't really matter. I could go on and on ... basically, CLR is significantly slower than C++ code compiled to native code, but unless your application is CPU-bound in your code, it doesn't matter a whole lot.
The biggest problem I've found is that, although you can code a .NET to be fast, it's not encouraged. A lot of the things that make .NET development easy also make the resulting application slow. The end result of this is things like ATI's CCC - massive memory use, slow startup times, laggy interface, etc etc. While I know that CCC is not representitive of a "good" .NET app, it is representitive of a vast majority of .NET apps.
While I can't say I've run into a problem that *can't* be worked around, some bugs (mainly in the 1.0 and 1.1 era) have required significant and/or ugly workarounds (which had to be developed using trial and error). One of the things I love about Borland's VCL is that you get the source code, which means you can easily trace into the VCL and see where something is going wrong. This makes it much easier to develop workarounds compared to developing them for .NET where if you tell MS "{x} doesn't work correctly" you just get the response "don't do {x}, and it may be fixed in a future service pack". At which point, if doing {x} is important to your code, you have to start the tedious process of black-box debugging the framework. Reflector can help a bit if you've narrowed it down, but it's still nowhere as nice as being able to trace into the code.
--
Michael Brown
Add michael@ to emboss.co.nz - My inbox is always open
Sorry, I screwed up once again :( I meant to write that MFC licence condition was valid only if Borland dropped OWL. That was some time ago now, I cant really remember what happened.
Most of our customers run 512mb ram (on PC's supplied by us).
Ok, so the lowest CPU speed I have app's running on is around 2GHz. These are AU$400 PC's shipped with 512mb RAM, running XPSP2. I have never seen one take more than a few seconds to load the framework, even after a reboot. BTW, there is tonnes of information out there on how to reduce cold start times of app's. In fact MSDN mag did an article on such not so long ago.
Hardware is cheap, development time is quick, results are relatively robust (you can still write bad code). The whole idea with .net and java is that you sacrifice some resources for the huge benefits gained from safe, secure and reliable code.
Fair point. I don't do FP stuff. Things such as casting classes to binary buffers can be slow, but by marshalling to unmanaged and back it is real fast. What's great about that is the marshaller will not let you exceed the bounds of the array. You cant overrun a buffer. Big plus. Does not matter how bad you code, you cant do it. It won't let you. This is just one of the benefits. I challenge anyone to tell me that they have not had a buffer overrun, even if it was found before production.
I wonder what agent uses. Currently in my process list (Sysinternals) I have Agent at 10MB, followed by explorer(Win GUI shell) at 13MB, and Visual Studio 2005 at 40Mb. SO I wonder what language agent is written in? I have seen C++ app's (Borland and MS) that have been more bloated than C# app's.
Maybe that's where I differ. I don't want the source code. I don't care about it. The last thing I want to do is spend time learning my way through some library. I just don't have time. My experiences with .net have been good. What I cant do with it, I can do with Interop, and its rare that I need to go there. This is especially so with .net
All I really care about is giving the business what it wants, and if I can do that, on time with a product that does not have bugs, then I keep the business happy. If I keep the business happy I get rewarded, both financially and with more work.
Initially this was the case, which is why it took so long for BC++ to become MFC compatible (Watcom, Symantic, etc had MFC support years before Borland). MS finally relented and allowed Borland to use both - I have no idea why. Presumably money was involved somewhere.
[...]
Are you sure that you're actually testing a "cold boot" scenario? For example, if you use ATI graphics drivers, the framework gets loaded during boot. The warm and cold start times are about the same on my main computer because of this (and somewhere around 1-1.5 seconds due to better hardware). The times I mentioned above are on my "clean test" machine, an XP1700 with
512 MB RAM. This is a cleaner machine than most when it comes to stuff in RAM, since I'm only testing a single app at a time (more or less just XP + .NET frameworks). On another machine that I use (P4 ~2GHz, 512 MB RAM, but with lots of junk loaded like a virus scanner, firewall, web/email clients, etc ) I observe similar or worse times - worse because when I exit a .NET application the framework tends to fall out of the cache pretty quickly as memory is tight. Resulting in times closer to cold starts than warm starts.
Yes, there are things you can do to improve cold (and warm) start times ... but these times are for a "Hello World" app, which doesn't leave many options for improvement.
[...]
Safe and secure, maybe, but reliable? Allowing people to be sloppy when coding is just asking for reliability issues further down the line. The "ideal" language (IMO) should be strictly typed (no magic float-to-int conversions for you!), require explicit memory allocation and deallocation (with a garbage collector there solely to slap you if you forget) and allow you to get your hands dirty and bit-bash if you want to. Ideally it should also treat fundamental types as fundamental types - an integer is an integer, not an object. Basically, make the programmer think about what (s)he is writing, not just spew out a whole lot of code and make random changes until it works. Unfortunately, the trend seems to be away from every one of these aspects and towards allowing - even encouraging - poor programming practices. While in the short term this may seem like a good solution, 5 years down the line you'll end up with millions of lines of poorly written code just held together by comments such as "I don't know why the following line is needed but things break if it's removed".
/me gets off his soapbox :)
[...]
I can't recall the last time I had a buffer overrun in any of my Delphi code. I have had the odd one when mixing Delphi and inline assembler (the overflow in the assembler part), but assembler is assembler and those things happen :) In my C++ code, I've had the odd one in parts which I've been aggressively optimizing (as in "we need to squeeze more performance out of this procedure, new is slowing us down, so lets coalesce all the unrelated new calls into a single malloc and bitbash some things around" aggressive) but not AFAICR in "normal" code. In these cases, a managed language would have prevented the buffer overflows simply by not allowing me to optimize so aggressively. Not exactly a plus in that case.
The reason for this IMO is that I've always been quite conscious of buffer overruns and the like, coming from an assembly and software security background. Of course, I can't say I've never had one - my memory doesn't go back far enough, and I'm pretty certain that when I was starting programming I overflowed a few buffers (either accidentally or on purpose ...). Defensive programming beats a safety net any day of the week - a (prevented) buffer overflow in a .NET application usually results in the application crashing or being terminated. While this is better than a buffer overflow, it's better still that the app figures out beforehand that the buffer is too small and handles it gracefully. Additionally, most C/C++ compilers now support buffer overflow detection with guard words. While this results in guaranteed termination of the program (rather than possible recovery with an exception), the result is not all that different to an exception firing where you did not anticipate it happening.
As far as I can tell, it uses MSVC (and wxWindows for the gui). It's a combination of C and C++. Though this is just from a quick glance through the executable using notepad - it may be being crafty :)
Heh, Explorer on this computer is at 17 MB - tis what you get when you don't log off for 9 days ... Biggest memory users at the moment are Opera (103 MB), Delphi 7 (35 MB), OE (31 MB). However, I wouldn't consider Opera bloated - I've got about 25 tabs open across 2 windows, and then the cached renderings for the previous page, plus cached files ... Delphi and OE are also quite "busy", and the memory is being put to good use. The award for bloat (being defined as memory used for no good purpose) on my computer goes to the annoying ATI tray icon that just won't go away. It's currently using up 7 MB to display an icon in the tray that if I double-click on it starts up CCC.
[...]
I'm coming somewhat from the same direction but with different experiences ... I don't have time to be trying to second-guess what's happening inside a library. If an application isn't behaving as it should, there's either a bug in my code or a bug in the library (or very occasionally a bug in the compiler). Maybe I've just been unlucky with hitting lots of .NET framework bugs, but I'm pretty sure I've spent more time in the last couple of years trying to isolate and work around .NET bugs than I've spent tracing through the VCL source code (and it's not due to spending a lack of time with VCL). Since I've written quite a few Delphi components I already knew (or had to know) what a typical VCL component looks and acts like. Since the VCL follows the same rules as the components I write, tracing through it is pretty easy.
[...]
--
Michael Brown
Add michael@ to emboss.co.nz - My inbox is always open
True enough, although when that happens it's an easy way to know that the piece of software is crap and you shouldn't bother using it if at all possible!
What do you think of Python (with, say, wxPython for the GUI) vs, say, C#?
Yeah... I understand peoples' frustration with needing all the various version of the framework on their PCs, but at least they do appear to have eliminated "DLL Hell."
To be honest, i have never looked at python. I probably never will either, as I have just taken a consultancy role at a 100% MS shop! However, I have hearld lots about it, and I will endeavour to have a look in my onw time, maybe when I buy my Mac.
IIRC the boxes i am using have an onboard video compliments of intel.
All my testing is done on clean installs. A PC that you use for dev is always going to be bloated with crap, and any app you run on it is going to be slow. Same for running CAD apps.
However, I do have a few .net applications that i do run on my dev machine for support reasons, some of which are quite big, and the start times of all of those are quite good to. Mind you, I am going to go and test cold start times of those now!!
If you are doing .net dev, its worth reading this MSDN mag article.
formatting link
There are some other good ones around too.
You will always get programmers that write bad code, in any language. .net and java are helping the cause by taking care of that aspect as much as possible.
BTW: WCF was microsofts benchmark test for using c# internally. WCF was written completely in managed code. Its only a matter of time before your PC will have to run the .net framework as MS ramps up internal development in .net. It would be interesting to know if Vista uses any .net framework, because I cant see it load. Vista starts pretty quickly too, and .net apps seem to boot fast on vista.
Python is a programming language, not an alternative monopolistic software vendor who throws their toys out of the pram when they can't bully and control someone (in this case, they don't like Java because they can't force it to be windows-only - thus they made .net). The point of using Python is that it is a good choice of language for many projects - it is faster and easier to work with for many types of code, as it is higher level, interpreted, dynamically typed, has direct support for constructs such as dictionaries and lists, and has a vast selection of library modules.
If you really insist on using .net, rather than a proper cross-platform toolkit, then look at Iron Python - it is effectively Python#.
Ahh, these are the types or rants that make me lose interest in the 'open source' community. Cant you just talk about the language with out throwing in the 'MS sucks because I don't like them' part. It is completely irrelevant. I don't give a f*ck about MS, nor the fact that they are a monopoly. I give a f*ck about how _I_ can make money, and what tools/languages will make _ME_ money. If using MS tools and languages means I can continue making AU$80-100/ hour, then I will continue using them. ALternatively, If using Python can make me that kind of money on a regular basis, then I will use it. To be honest though, I have never seen a job advertised for python.
Sounds like any other language. What interests me is how robust the language is. I am not a big fan of dynamically types languages, I prefer strongly typed. How does it benefit me, and the business who is paying me to develop there applications?
I don't insist on using .net. I insist on making money. If it cant make me money, then I wont use. What I will do is make a note of it, and probably have a play with it when I have time. That way I can make an informed judgment for myself.
Why? Types are a relic from when programming consisted of smearing bits over hardware. If you program C#, you should be way past fretting over what internal representation things have.
Not that Python lacks types - they just work differently.
Python is I.M.O. very easy to use so you can do more with it in less time (i.e finish the work in one week and then use the next two on to more important jobs such as working out how to kill the armoured guy in FEAR using only the pistol).
In terms of language, Python is object oriented, but you do not have to use objects. There are exceptions, you do not have to use them. In many ways opposite the whip and bondage of Java. PERL and Python are logical opposites, PERL have infinately many ways of doing the same task, in Python the one or two obvious ways is normally the most effective method. (C# is most similar to Python).
Python delivers the cross-platform portability that Java lacks: wxWidgets f.x. (GUI library), behaves native, look native and feels native on windows or Linux (KDE, Fluxbox, Gnome, whatever). I tend to write Python stuff on my windows XP laptop and deploy it to Linux later with no trouble - the only pain was when wxWidgets changed naming standard between versions, there was a skew from Linux to Win XP and my app broke on the move.
Most often Python is used as "thin glue" like the floor-levelling goo one uses before tiling: Making up a sane interface between disparate processes. That's why you do not see it so much "advertised", it's hidden in the infrastructure. Lenovo PC's ship with it for some purpose along that.
The core Python license is very generous: You can build a product with the interpreter and your code and sell it as your product (licenses on add-on's might vary).
Anyway:
formatting link
- it's here! It installs/runs on windows (and uninstall even works also).
Use the right tool for the job - I use windows and linux, closed source and open source, according to the requirements. If you read a little further, I'm suggesting you look at the MS-sponsored version of Python running mainly on MS-based .net.
However, before I use a tool, I look at what it is, where it came from, why it exists, and where it is going. When I look at .net, I am not impressed - for my own work, I'd prefer something more open and more flexible, which is going to work now and in the future on many systems. I don't like being at the mercy of a single vendor with a terrible track record if I can avoid it. It might be a different matter if I were paid by the hour for the work I do - people paid to service computers see their unreliability as a benefit.
I don't claim that "MS sucks because I don't like them", I don't like them because they use a variety of illegal and unethical methods to gain control over people and organisations, causing vast financial cost to those people and to the detriment of the quality of software and computers, and destroying healthy competition. I put up with MS software when I have to, and I'll happily give them credit when it is due (windows is not nearly as unreliable as some claim, if it is treated appropriately) - but I'll not choose MS solutions without good reason.
I've told you briefly why I like it. If you want a cost analysis and business case for using it, ask someone selling Python services, or try it out yourself. And no, it is not "like any other language" - but it certainly has similarities to other languages. It is somewhat like Ruby, and has a certain amount of overlap with Perl (although Python is much more readable).
I offered the suggestion of Python in that spirit - look at it yourself, and see what you think.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.