My background starts with 8bit machine code in the 70's with runtime basic, Pascal ( the bases for .NET) C, C++, VB, Java. I even spent 5 yrs on the Microsoft Campus in the MSDN group consulting. lets starts with simple hello world. first you have the OS interface layer then you have the framworks to present the Hello world to the user. Now in C this compiles down to about 1K in C++ you jump to 10K because of the string overhead of a class. to use .Net on any system the User will have a few gigabytes of frame work loaded on their system. and memory. Java runtime is not as large as the .Net framwork. to me Size of the frame work translates to the bloat of memory use. I won't even get into swapping of code sections due to this bloat.
so the ease of .Net requires a lot more user memory to use than Java. not to mention the security holes in MS Object framework they keep patching. back in the early 2000 I started the trek you are on and ended up with Ofbiz framework. This is because it does not have the bloat that even Java classes have. Unlike .NET I don't have to wait for an ugrade or patch to fix what I find are problems. Note: be thankful for the documentation that is now available. When I started with ofbiz you had to read the code to find out anything. MikeBranch sent the following on 6/24/2011 6:49 PM: > Coming from a .NET background (but quickly recovering!), it's very > frustrating for me to have to wade through discussions about specifications > and standards, Java data types vs .NET data types, this protocol is better > than that protocol because it only uses 547 bytes instead of 613 bytes, etc. > etc. etc. Now, I have a master's degree in software engineering, so it's not > that I don't understand that stuff. It's just that I shouldn't have to. > > When I write a .NET program to make SOAP calls to Salesforce, it just works. > I don't even have to worry about what version of SOAP I'm using (or they're > using). I have no idea what kind of web servers, database, programming > language, or operating system Salesforce is using. And I don't care, because > everything just works. > > My point is this: If you want to improve adoption of any open source > platform or technology, it wouldn't hurt to shorten the list of things that > newcomers (like me) need to figure out. If I have to drill down through 17 > layers of libraries, protocols, specifications, etc., then eventually my > brain is going to overflow and I'll just go work on something else where I > can make just as much money with fewer headaches (and fewer things that > might break for my clients). In the case of OFBiz, which I think is very > cool, when I get to the word "SOAP" that should be the end. I should be able > to say "OK, that's just SOAP. I get it. Now I'll go learn how to build a UI > or something." I guess I'm really talking about a change in attitude, where > it's not assumed that the application developer needs to understand every > line of code right down to the kernel. >
