No, sorry, this discussion has probably gone on far past it's usefulness, but I don't think you are getting my point. An OS is an OS, not a framework. A library is a library, not a framework. Your definition of a framework would encompass just about any software system. While that may be logical for your argument, it bends the definition of a framework to the breaking point.
There have been OSs for the last 50 or so years and there have been libraries for a great many years as well. Frameworks are much more recent and generally include certain features such as default behavior, IOC, extensibility, etc. In a typical non-framework application, when your program receives control via main(), the entire remaining logic flow is pretty much up to you. This is not so within a framework. In the first place, most frameworks (at least the ones I've used) don't call main(). Instead the framework invokes a function within your C code, usually via callbacks and expect your code to return certain values (and sometimes within certain time constraints). Generally, your application consists of callback routines which are invoked by the framework. This is very different from a standard C program which begins at main().
You are entitled to your own opinions of course, but not your own facts. While there are certainly many grey areas between what may be considered a library and what may be considered a framework, and there are many libraries that may call themselves frameworks when in fact they are libraries, frameworks are not the same thing as libraries and OSs are certainly not frameworks. QT is a framework, the linux kernel is not.
Well I'm sorry if my similar responses to 5 other similar comments irritated you but I can't always judge the level of technical understanding of all commenters.
However, to cut to the chase, even though there is no "universal" definition, IMO the commenter that posted the response that started this, something akin to "you call a library, a framework calls you" basically had it right, although as often happens on/., it got completely picked apart. I wouldn't consider (nor would any knowledgeable C programmer I know) the C standard library a framework, regardless of how many machine instructions are executed prior to beginning execution of your logic. That has nothing to do with it anyway. A framework attempts to enforce a predefined way of doing things. In many cases, applications that are invoked via a framework really become extensions or features of that framework, but the core logic is driven by the framework. A library on the other hand is simply a collection of routines that can be called by your applications. What goes on at the machine level really has very little to do with the distinction.
By your description of what constitutes a framework, every single program, regardless of whether it's C, assembler or brainf&ck, is part of a framework because one or more machine instructions gets executed before your main() entry point. I guess we should alert the standards committee that the name needs to be changed to the "C standard framework".
My point is, no program just pops out of nowhere on your machine and begins running. There is always some set of instructions that get executed to prepare for your program to run. However, main() is, and always has been the entry point for a normal "C" program. How this entry point gets invoked is irrelevant (or at least "should" be for the sake of portability). To argue otherwise is purely pedantic.
Their reasons for preferring C over C++ are equally applicable to "C-vs-assembly language" so I don't understand why they use C....anybody?
Portability and productivity are the first things that come to my mind.
(Be aware that any answer you give will be instantly reworked to fit "C++ vs. C" so you'll lose by default...)
And quite rightly so. Some problem spaces are best suited for assembler, some better suited for C, others more suited for C++ and still others for Java/C#, etc. It boils down to the best tool for the job (with technical considerations as well as programmer availability, expense, etc. all factors to be considered).
In general, this is true. In most cases crt0 (containing the _start entry point) is placed before the main() function and performs the initialization you are referring to. However, while this is the default way, it not a requirement. Most C compilers include the source code to crt0 so that developers can write their own initialization code or none at all if not required. If your C code does not call any library routines, no other initialization may be needed (depending on the OS or embedded environment). In fact, it is usually possible (e.g. the -mno-crt0 switch for gcc) to tell the linker to not link the crt0 code and you can instead set the entry point directly to your C code entry point (doesn't necessarily even have to be main).
I could argue corner cases for just about any technique, including self-modifying code, but I wouldn't want to recommend that as a standard programming practice that all programmers should use.
In general, your right, but this is not true in all cases. In some embedded environments the crt0 object module (the module that contains the _start entry point) is just a stub if the code does not call any library routines because the ROM monitor performs all initialization of the hardware, registers, etc.
In that case the same would hold true for an assembler program. The OS has to interpret the shell command, load the program from disk, start up a process, initialize the registers, etc. before calling the entry point. In fact the only environment I can think of where your entry point would be the first thing executed would be if your code was in ROM and the entry point was set to the processor's reset vector (used to be 0xFFFFFFF0 on x86 - not sure if that still holds true with today's processors).
I suppose in most cases this is true, but what crt0 does is very much platform dependent. I don't think of this as initializing the runtime "library" (although if your code calls stdlib routines it does do that as well) because what it is essentially doing is setting up the stack space, initializing the registers (possibly initializing the hardware); basically doing the housekeeping that an assembler program would have to do anyway on startup. In some embedded environments, crt0 is just a stub that does nothing because the ROM monitor establishes the runtime enviroment (stack pointers, hardware initialization, etc). In these cases (unless your C code does calls any runtime library routines, no runtime library code is included at all in the final executable. Most implementations of crt0 are actually inline code that is simply placed "in front" of the C "main" function so it doesn't really "call" the main function but either falls through to it or executes a jump to it.
Wow. I find it incredible in 2011 that this is even being debated. I suppose next you'll be arguing that using "goto"s is how we should all be programming.
Sure, there are problem spaces where the efficiencies of straight "C-style" procedural programming are warranted just like there are problem spaces where C is too inefficient and assembler is warranted, but for the vast majority of problem spaces the ability to abstract away the details is absolutely necessary to achieve a reasonably maintainable application, which, at least as I read it, is how the term "superior" is being applied here.
Companies can spend $$$ on highly trained programmers squeezing every bit of performance out of the existing hardware by optimizing low-level code, or they can spend (usually less) $$$ on increasing the performance of the hardware by another 5 or 10% to compensate for the overhead of supporting a less efficient, but easier to maintain OO implementation. Given the ever increasing hardware performance relative to cost trend, most companies opt for the latter.
What? Where are you getting your information. If you examine the assembly code generated from a C program (/FAs option for VisualStudio, -S option for gcc, etc), you'll see that the entry point to the program is exactly at "main". Any C runtime initialization is performed when/if it's needed. In fact, if your program does not link in any C runtime calls, the executable will contain no "runtime" at all. This is no different than if you had coded the program in assembler and named the your entry procedure "_main" and set the entry point for the linker to "_main".
No, I was pointing out that having to manage memory manually can easily lead to less reliable software. Having the runtime manage memory allocation/deallocation, while not completely eliminating the need to worry about memory over consumption entirely, leads to more reliable software and increases productivity. You can disagree all you want, but almost all modern languages today incorporate automatic memory management. Objective-C is now incorporating it,.Net languages have always had it. Even most C/C++ compilers now support managed memory, which is just another way of tacking the same issue that has plagued C and C++ from their inception. There is a reason for this trend toward automatic memory management and it's not just because it allows idiots to become programmers. Even though it does take away some the bullets that idiot programmers have to shoot themselves in the foot with, it's main reason for being is that it makes software development more productive and reliable.
No matter how good a C/C++ programmer you may be, you are still fallible and the slightest mistake with pointer or memory allocations can lead to a crash of the software. Worse than crashes, which can usually be easily debugged, corrupted memory may go completely undetected. In high transaction volume business software errors can cost real $$$, so data integrity is of utmost importance. In C/C++ you have no way to be 100% sure this will not occur unless the program is trivially small.
Finally, what you are calling memory leaks in Java are not memory leaks at all. A memory leak (as often happens in C/C++ programs) is when a pointer to a block of allocated memory is changed, but the memory is not deallocated, resulting in memory that is no longer addressable. This cannot happen in Java since, once an object is no longer referenced, it is removed by the garbage collector. It is absolutely possible to chew up memory in Java by allocating objects and never allowing them to be garbage collected (because they are still referenced in the code) and obviously you can cause a NPE. The difference between these problems in Java and C/C++ is that these conditions are relatively easy to detect and correct in pure Java. I say "pure" Java because once you venture in JNI or some of the Android APIs all bets are off because the JVM is no longer managing resources.
It's not about "about how the internals of hardware works and how their code actually runs!!". Most of my customers don't give a damn whether I can look at a hex dump of some machine code and recite the mnemonic instructions they represent from memory, they just want the code to work, and work reliably.
Just because I can write assembly code that would kick your C-code's ass in terms of performance (and believe me, I can) doesn't mean my customers who are paying me by the hour want me to take the time to write everything in assembler. No, they want me to produce quality code that performs well, is reliable and I can get done quickly and within budget. Unless they specifically want me to write the code in C or C++ (or assembler), I can be much more productive in Java, that's just a fact. It's not because I don't understand C/C++ or pointers or manual memory management, I've logged many years doing exactly that, it's that not having to devote a as much bandwidth to dealing with memory management allows me to concentrate more on the logic/algorithm that I'm implementing. Assuming that because someone is more productive in Java than in C/C++ is because they don't understand the later is an invalid assumption, just as assuming that someone that is more productive in C/C++ than in assembler is because they don't understand assembler is an invalid assumption.
Your references to Minecraft mean nothing. I can point out plenty of C/C++ programs that have plenty of problems as well. Bad programmers are a bad programmers regardless of the language they are using. You're references to Java programmers as "mouth breathers" is pure ignorance.
As a long time assembler programmer, I could take take the same stance your are taking and claim C programmers are not real programmers because they let the compiler "hold their hand" managing registers rather than understanding the hardware internals. In fact I recall many years ago my assembler colleagues making that very claim about "C" programmers. They were wrong then just as you are wrong now. The real key is an intimate understanding the language platform you are working with, regardless of whether it's assembler, C or Java. Efficiency is not guaranteed by any language but rather, it is the responsibility of the developer.
References are NOT internally pointers. Just run a java app in a debugger and step through the code. Look at each reference created. The first reference created will have a reference id of something like 16, the second will be 17, and so on. These are simply "references" used to lookup the object, not address locations in memory. In C you can take a pointer and add 1 to it to address the next byte in memory, but you cannot do this with a reference. That's a VERY big difference. If there was a way to increment the reference id (which there is not - and this is not a language construct issue, it is not possible due to the architecture of the JVM), you would be simply referencing a completely different object, or referencing an object that does not exist which the JVM does not allow. In C, a pointer with an address value of 0 is a null pointer, but in Java a variable set to a null reference does not point to an address of zero, but rather references a special object in the JVM called the null object. Again, a big difference.
References ARE absolutely immutable. You can reassign a variable to a different reference (thereby referencing a different object), but you cannot change the reference itself.
I suggest you learn a little about what you are speaking of before making a fool of yourself.
Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers. If you do not understand why then please do not come anywhere near my C code.
1) Objective-C has garbage collection (though admitedly not on iOS at the moment)
Sort of an important distinction don't you think given that it's not available on iOS and this thread is about mobile development?
2) Even without GC, cocoa's reference counting system is about the best there ever has been and makes life *almost* as easy as GC –just gotta watch out for retain cycles.
Not a little biased are we?
3) Java very much has pointers – that's why you can get Null pointer exceptions;)
Now here you go just spreading FUD. Java does NOT have pointers. None. Absolutely none. Despite the inappropriately named NullPointerException, pointers do NOT exist in Java. Java has references. References are != Pointers. Pointers "point" to a memory location. References "reference" an object. These are very different concepts and I don't care to write a tutorial on the subject here on/. Suffice it to say that pointers provide a mechanism for code to corrupt (whether intentionality or not) memory while references (being immutable) preclude this.
Also Java DOES have pointers that's why there is even an exception [oracle.com] for when they are NULL.
Actually, to be precise, Java does NOT have pointers (despite the mis-named NPE). It has references. References are NOT the same thing as pointers. While they serve a somewhat similar purpose, they are very different in implementation. I won't go into a long discussion of this on/., but the fact that you are equating the two is misleading and needs to be flagged.
Also, statements like "What exactly is so hard about pointers?" is just geek bravado. I'm a long time hired gun and I can't count the number of times I've had to come into a C or C++ project because the team of programmers working on it could not resolve the reliability issues which were primarily due to pointer problems or memory leaks. While there are definitely performance considerations in Java (and a wise man knows that nothing in life is free), Java offers productivity gains over C (and even Obj-C IMHO) while still maintaining reasonable performance. This combination is unmatched by other language platforms at the current time (although I'd say C# runs a close second - again IMHO).
Programming languages are many, and the way I look at it, they are all part of a continuum from the bare bones assembly languages all the way through to the highest level languages. Each (well, most) have things I like and things I don't and every developer has their own taste. There is no "best" language, but for a particular application, there is usually a best choice (and it doesn't always have to be based on technical merit).
Take away enough people's right to bear arms, vote or otherwise have a say in society and the remaining population is much easier to control. Pretty soon just disagreeing with the government position will be a felony, thereby removing that position from the debate and allowing our corporatist overlords complete control while being able to claim the US is still a democracy (or republic, or whatever term your prefer).
America better wake up soon or it'll be too late (if it's not already).
IBM OS/360 programs (circa 1964) are still binary compatible with the latest Z-OS. That's compatibility from OS/360 through MVT, MVS, OS/390 and now z-OS.
All true, and the trademark "NetBeans" is owned by Oracle. However in 2000, Sun released the software as open-source. You can still download it from Oracle, but their main website is http://netbeans.org/ (emphasis org).
Slashdot Mirror
I'm still holding out hope for a port of edlin.
But then it couldn't be taught at CMU.
There have been OSs for the last 50 or so years and there have been libraries for a great many years as well. Frameworks are much more recent and generally include certain features such as default behavior, IOC, extensibility, etc. In a typical non-framework application, when your program receives control via main(), the entire remaining logic flow is pretty much up to you. This is not so within a framework. In the first place, most frameworks (at least the ones I've used) don't call main(). Instead the framework invokes a function within your C code, usually via callbacks and expect your code to return certain values (and sometimes within certain time constraints). Generally, your application consists of callback routines which are invoked by the framework. This is very different from a standard C program which begins at main().
You are entitled to your own opinions of course, but not your own facts. While there are certainly many grey areas between what may be considered a library and what may be considered a framework, and there are many libraries that may call themselves frameworks when in fact they are libraries, frameworks are not the same thing as libraries and OSs are certainly not frameworks. QT is a framework, the linux kernel is not.
However, to cut to the chase, even though there is no "universal" definition, IMO the commenter that posted the response that started this, something akin to "you call a library, a framework calls you" basically had it right, although as often happens on /., it got completely picked apart. I wouldn't consider (nor would any knowledgeable C programmer I know) the C standard library a framework, regardless of how many machine instructions are executed prior to beginning execution of your logic. That has nothing to do with it anyway. A framework attempts to enforce a predefined way of doing things. In many cases, applications that are invoked via a framework really become extensions or features of that framework, but the core logic is driven by the framework. A library on the other hand is simply a collection of routines that can be called by your applications. What goes on at the machine level really has very little to do with the distinction.
By your description of what constitutes a framework, every single program, regardless of whether it's C, assembler or brainf&ck, is part of a framework because one or more machine instructions gets executed before your main() entry point. I guess we should alert the standards committee that the name needs to be changed to the "C standard framework".
My point is, no program just pops out of nowhere on your machine and begins running. There is always some set of instructions that get executed to prepare for your program to run. However, main() is, and always has been the entry point for a normal "C" program. How this entry point gets invoked is irrelevant (or at least "should" be for the sake of portability). To argue otherwise is purely pedantic.
Why don't C programmers program in assembler...?
Their reasons for preferring C over C++ are equally applicable to "C-vs-assembly language" so I don't understand why they use C....anybody?
Portability and productivity are the first things that come to my mind.
(Be aware that any answer you give will be instantly reworked to fit "C++ vs. C" so you'll lose by default...)
And quite rightly so. Some problem spaces are best suited for assembler, some better suited for C, others more suited for C++ and still others for Java/C#, etc. It boils down to the best tool for the job (with technical considerations as well as programmer availability, expense, etc. all factors to be considered).
If there was money in it, I'd write COBOL apps to run on mainframes that are beowulf clusters of iPads.
But this is impossible - because Jobs has declared that only Obj-C apps can run on iPads.
In general, this is true. In most cases crt0 (containing the _start entry point) is placed before the main() function and performs the initialization you are referring to. However, while this is the default way, it not a requirement. Most C compilers include the source code to crt0 so that developers can write their own initialization code or none at all if not required. If your C code does not call any library routines, no other initialization may be needed (depending on the OS or embedded environment). In fact, it is usually possible (e.g. the -mno-crt0 switch for gcc) to tell the linker to not link the crt0 code and you can instead set the entry point directly to your C code entry point (doesn't necessarily even have to be main).
I could argue corner cases for just about any technique, including self-modifying code, but I wouldn't want to recommend that as a standard programming practice that all programmers should use.
In general, your right, but this is not true in all cases. In some embedded environments the crt0 object module (the module that contains the _start entry point) is just a stub if the code does not call any library routines because the ROM monitor performs all initialization of the hardware, registers, etc.
In that case the same would hold true for an assembler program. The OS has to interpret the shell command, load the program from disk, start up a process, initialize the registers, etc. before calling the entry point. In fact the only environment I can think of where your entry point would be the first thing executed would be if your code was in ROM and the entry point was set to the processor's reset vector (used to be 0xFFFFFFF0 on x86 - not sure if that still holds true with today's processors).
I suppose in most cases this is true, but what crt0 does is very much platform dependent. I don't think of this as initializing the runtime "library" (although if your code calls stdlib routines it does do that as well) because what it is essentially doing is setting up the stack space, initializing the registers (possibly initializing the hardware); basically doing the housekeeping that an assembler program would have to do anyway on startup. In some embedded environments, crt0 is just a stub that does nothing because the ROM monitor establishes the runtime enviroment (stack pointers, hardware initialization, etc). In these cases (unless your C code does calls any runtime library routines, no runtime library code is included at all in the final executable. Most implementations of crt0 are actually inline code that is simply placed "in front" of the C "main" function so it doesn't really "call" the main function but either falls through to it or executes a jump to it.
Sure, there are problem spaces where the efficiencies of straight "C-style" procedural programming are warranted just like there are problem spaces where C is too inefficient and assembler is warranted, but for the vast majority of problem spaces the ability to abstract away the details is absolutely necessary to achieve a reasonably maintainable application, which, at least as I read it, is how the term "superior" is being applied here.
Companies can spend $$$ on highly trained programmers squeezing every bit of performance out of the existing hardware by optimizing low-level code, or they can spend (usually less) $$$ on increasing the performance of the hardware by another 5 or 10% to compensate for the overhead of supporting a less efficient, but easier to maintain OO implementation. Given the ever increasing hardware performance relative to cost trend, most companies opt for the latter.
What? Where are you getting your information. If you examine the assembly code generated from a C program (/FAs option for VisualStudio, -S option for gcc, etc), you'll see that the entry point to the program is exactly at "main". Any C runtime initialization is performed when/if it's needed. In fact, if your program does not link in any C runtime calls, the executable will contain no "runtime" at all. This is no different than if you had coded the program in assembler and named the your entry procedure "_main" and set the entry point for the linker to "_main".
No matter how good a C/C++ programmer you may be, you are still fallible and the slightest mistake with pointer or memory allocations can lead to a crash of the software. Worse than crashes, which can usually be easily debugged, corrupted memory may go completely undetected. In high transaction volume business software errors can cost real $$$, so data integrity is of utmost importance. In C/C++ you have no way to be 100% sure this will not occur unless the program is trivially small.
Finally, what you are calling memory leaks in Java are not memory leaks at all. A memory leak (as often happens in C/C++ programs) is when a pointer to a block of allocated memory is changed, but the memory is not deallocated, resulting in memory that is no longer addressable. This cannot happen in Java since, once an object is no longer referenced, it is removed by the garbage collector. It is absolutely possible to chew up memory in Java by allocating objects and never allowing them to be garbage collected (because they are still referenced in the code) and obviously you can cause a NPE. The difference between these problems in Java and C/C++ is that these conditions are relatively easy to detect and correct in pure Java. I say "pure" Java because once you venture in JNI or some of the Android APIs all bets are off because the JVM is no longer managing resources.
Just because I can write assembly code that would kick your C-code's ass in terms of performance (and believe me, I can) doesn't mean my customers who are paying me by the hour want me to take the time to write everything in assembler. No, they want me to produce quality code that performs well, is reliable and I can get done quickly and within budget. Unless they specifically want me to write the code in C or C++ (or assembler), I can be much more productive in Java, that's just a fact. It's not because I don't understand C/C++ or pointers or manual memory management, I've logged many years doing exactly that, it's that not having to devote a as much bandwidth to dealing with memory management allows me to concentrate more on the logic/algorithm that I'm implementing. Assuming that because someone is more productive in Java than in C/C++ is because they don't understand the later is an invalid assumption, just as assuming that someone that is more productive in C/C++ than in assembler is because they don't understand assembler is an invalid assumption.
Your references to Minecraft mean nothing. I can point out plenty of C/C++ programs that have plenty of problems as well. Bad programmers are a bad programmers regardless of the language they are using. You're references to Java programmers as "mouth breathers" is pure ignorance.
As a long time assembler programmer, I could take take the same stance your are taking and claim C programmers are not real programmers because they let the compiler "hold their hand" managing registers rather than understanding the hardware internals. In fact I recall many years ago my assembler colleagues making that very claim about "C" programmers. They were wrong then just as you are wrong now. The real key is an intimate understanding the language platform you are working with, regardless of whether it's assembler, C or Java. Efficiency is not guaranteed by any language but rather, it is the responsibility of the developer.
But what if they discover the core is really hollow and all the water in all the oceans drains into the hole? What then?
References are NOT internally pointers. Just run a java app in a debugger and step through the code. Look at each reference created. The first reference created will have a reference id of something like 16, the second will be 17, and so on. These are simply "references" used to lookup the object, not address locations in memory. In C you can take a pointer and add 1 to it to address the next byte in memory, but you cannot do this with a reference. That's a VERY big difference. If there was a way to increment the reference id (which there is not - and this is not a language construct issue, it is not possible due to the architecture of the JVM), you would be simply referencing a completely different object, or referencing an object that does not exist which the JVM does not allow. In C, a pointer with an address value of 0 is a null pointer, but in Java a variable set to a null reference does not point to an address of zero, but rather references a special object in the JVM called the null object. Again, a big difference.
References ARE absolutely immutable. You can reassign a variable to a different reference (thereby referencing a different object), but you cannot change the reference itself.
I suggest you learn a little about what you are speaking of before making a fool of yourself.
Java is immensely easier to develop with than any flavor of C because of garbage collection and lack of pointers. If you do not understand why then please do not come anywhere near my C code.
1) Objective-C has garbage collection (though admitedly not on iOS at the moment)
Sort of an important distinction don't you think given that it's not available on iOS and this thread is about mobile development?
2) Even without GC, cocoa's reference counting system is about the best there ever has been and makes life *almost* as easy as GC –just gotta watch out for retain cycles.
Not a little biased are we?
3) Java very much has pointers – that's why you can get Null pointer exceptions ;)
Now here you go just spreading FUD. Java does NOT have pointers. None. Absolutely none. Despite the inappropriately named NullPointerException, pointers do NOT exist in Java. Java has references. References are != Pointers. Pointers "point" to a memory location. References "reference" an object. These are very different concepts and I don't care to write a tutorial on the subject here on /. Suffice it to say that pointers provide a mechanism for code to corrupt (whether intentionality or not) memory while references (being immutable) preclude this.
The sad thing about java is that it enable a lots of morons to write applications
It's even sadder when you realize the next generation of programmers think Objective-C is the best language around because Apple says so.
Also Java DOES have pointers that's why there is even an exception [oracle.com] for when they are NULL.
Actually, to be precise, Java does NOT have pointers (despite the mis-named NPE). It has references. References are NOT the same thing as pointers. While they serve a somewhat similar purpose, they are very different in implementation. I won't go into a long discussion of this on /., but the fact that you are equating the two is misleading and needs to be flagged.
Also, statements like "What exactly is so hard about pointers?" is just geek bravado. I'm a long time hired gun and I can't count the number of times I've had to come into a C or C++ project because the team of programmers working on it could not resolve the reliability issues which were primarily due to pointer problems or memory leaks. While there are definitely performance considerations in Java (and a wise man knows that nothing in life is free), Java offers productivity gains over C (and even Obj-C IMHO) while still maintaining reasonable performance. This combination is unmatched by other language platforms at the current time (although I'd say C# runs a close second - again IMHO).
Programming languages are many, and the way I look at it, they are all part of a continuum from the bare bones assembly languages all the way through to the highest level languages. Each (well, most) have things I like and things I don't and every developer has their own taste. There is no "best" language, but for a particular application, there is usually a best choice (and it doesn't always have to be based on technical merit).
http://tribes.tribenetwork.com/america/thread/2f215d2a-8c88-437c-82ec-cc78ee7588df
Take away enough people's right to bear arms, vote or otherwise have a say in society and the remaining population is much easier to control. Pretty soon just disagreeing with the government position will be a felony, thereby removing that position from the debate and allowing our corporatist overlords complete control while being able to claim the US is still a democracy (or republic, or whatever term your prefer).
America better wake up soon or it'll be too late (if it's not already).
Or you could just have unprotected sex and accomplish the same thing.
IBM OS/360 programs (circa 1964) are still binary compatible with the latest Z-OS. That's compatibility from OS/360 through MVT, MVS, OS/390 and now z-OS.
We only need it until 12/21/2012!
All true, and the trademark "NetBeans" is owned by Oracle. However in 2000, Sun released the software as open-source. You can still download it from Oracle, but their main website is http://netbeans.org/ (emphasis org).
Any questions related to the license can be found at http://wiki.netbeans.org/NetBeansUserFAQ#License_and_Legal_Questions