Java Basics [3] - Primitive Variables

[Emperor Nero]

I hear cavemen are primitive. Eh, eh, you get it?

So I don't get infracted, why does this have to be a one sided dick swinging competition? It's a guide of basics.

 

[SuF]

I understand, however your post could be misinterpreted to reinforce the misconception that String is among the primitive types.
I just hoped to clear that up

For any beginners, all you really need to know about Strings is this:

- Strings are objects. 
- Strings are immutable which means they cannot change.
- A String to put it simply, is just an array of chars(The primitive type) wrapped in an object.
- The == operator should not be used to compare Strings.
- To compare strings use the built in .equals() method.

To give a better understanding of why, a String(internally) works a bit like this:

char[] chris = {'c', 'h', 'r', 'i', 's'};

Now, this is wrapped in an class called String.
*Note that '' denotes a char(primitive) and "" denotes a String(Object).

public class String {
      char[] chris = {'c', 'h', 'r', 'i', 's'};
}

When you do "chris" == "chris", what java does is it compares the value of both OBJECTS.
Since a string is an Object, it checks if "chris" is the same object as "chris".
For example:

Object obj = new Object();
if(obj == obj) {
  System.out.println("This is the same as 'chris' == 'chris'");
}

if(object == new Object()) {
  System.out.println("This is not, and will return false");
}

In this case "chris" == "chris" will return true because Java under normal circumstances creates strings and caches them in the String pool.
So the first time you do "chris", Java creates a new String object and adds it to the String pool.
The second time it grabs the Object "chris" from the string pool.

Thus they are the SAME object and that statement will return true.

"chris" == "bob" WILL return false because they are two DIFFERENT Objects.
Even though this does work, it's not garunteed to work because it does not compare their values.

The .equals() method should be used instead because it compares each character in the strings and checks if they match.
(It does: 'c' == 'c' and 'h' == 'h' and 'r' == 'r', and so on to check if the strings match)

I'm not the best teacher, so I hope this was easily understood

None of this will make any sense to a beginner.

 

[CompileTime]

None of this will make any sense to a beginner.

Maybe not all of it, but the main point was that they should be comparing strings via the .equals() method rather than the == operator.
I just felt it was necessarily to explain why.

As with everything I tried to make it as easily understandable and coherent as possible

 

[SuF]

Maybe not all of it, but the main point was that they should be comparing strings via the .equals() method rather than the == operator.
I just felt it was necessarily to explain why.

As with everything I tried to make it as easily understandable and coherent as possible

This guide hasn't even gotten to boolean operations. All you are doing is confusing people more.

 

[slimeychicken]

This guide hasn't even gotten to boolean operations. All you are doing is confusing people more.

Do you really think your students aren't going to attempt to compare values themselves? What else are they gonna do with their variables, initialize em? What fun.. All you did was make it more confusing by throwing Strings in with primitives.

 

[SuF]

Do you really think your students aren't going to attempt to compare values themselves? What else are they gonna do with their variables, initialize em? What fun.. All you did was make it more confusing by throwing Strings in with primitives.

Well had I finished they would do that in a later guide.

 

I love how butt hurt everyone is getting over such a crummy language. For what its worth, since arrays in java are objects I think your first guide should include both object types and primitive types, precisely because it is confusing to beginners and they need to know about both right from the outset.

 

[slimeychicken]

I think your first guide should include both object types and primitive types

If you ask me, his troubles in explaining the topic made his guide longer than it should be. He should've covered it as "Types and Variables", rather than whatever route he was planning on taking.

I love how butt hurt everyone is getting over such a crummy language.

How is Java crummy? What language(s) do you prefer?

 

How is Java crummy?

I don't even know where to begin.

I guess firstly you have to lug around the JVM ball and chain wherever you want to run your code. You have the illusion of platform independence but it is not an interpreted language so you still have to compile it, and then to do anything useful on the target platform you usually have to use JNI to access platform specific hardware at some point anyway.

The whole language itself is badly designed. Apart from being unnecessarily verbose, you have to manage pointers (including managing casting either directly or via generics) but yet you have no direct access to memory or pointer arithmetic, and then you have to put up with java's heap management and garbage collection (you don't even have the option to manage your own memory). The gc will run unexpectedly and chew up system resources unless you force it to run at the least inconvenient time. As I assume you are aware: Good programming practice is to clean up after you finish with memory so that you never need a garbage collector. In otherwords Java forces bad programming practice.

The security model is again rubbish. JVM runs in a process with usually liberal permissions and is expected to keep its own house security internally with respect to code running on it. Except it doesn't. There must have been a dozen exploits for the Java security model by now -- to the point that it is standing policy in many organizations not to install Java on end user/worker PCs.

But more to the point, the downsides of Java were supposed to be made-up-for by its platform independence. This was well and good in the 90s when there wasn't much else in the way of cross platform solutions. But now we have high quality (and free) cross compilers for practically every platform, hardware accelerated virtualization and a raft of other solutions to this problem.

I've taught C and Java at a university level for many years as a head tutor. Usually the students do Java before they move on to the C course. Java does give rise to numerous extremely bad programming habits and in my opinion 'breaks' new programmers before they even learn how to cut code. I would always start a new programmer off in C so they can get a good understanding of what is actually happening on the machine. IMHO it is very difficult to be a good programmer with no appreciation for the iron your code is running on..

 

[SuF]

I love how butt hurt everyone is getting over such a crummy language. For what its worth, since arrays in java are objects I think your first guide should include both object types and primitive types, precisely because it is confusing to beginners and they need to know about both right from the outset.

I really don't want to try to explain references but I would like them to be able to do basic string shit early on.

 

[SuF]

I don't even know where to begin.

I guess firstly you have to lug around the JVM ball and chain wherever you want to run your code. You have the illusion of platform independence but it is not an interpreted language so you still have to compile it, and then to do anything useful on the target platform you usually have to use JNI to access platform specific hardware at some point anyway.

The whole language itself is badly designed. Apart from being unnecessarily verbose, you have to manage pointers (including managing casting either directly or via generics) but yet you have no direct access to memory or pointer arithmetic, and then you have to put up with java's heap management and garbage collection (you don't even have the option to manage your own memory). The gc will run unexpectedly and chew up system resources unless you force it to run at the least inconvenient time. As I assume you are aware: Good programming practice is to clean up after you finish with memory so that you never need a garbage collector. In otherwords Java forces bad programming practice.

The security model is again rubbish. JVM runs in a process with usually liberal permissions and is expected to keep its own house security internally with respect to code running on it. Except it doesn't. There must have been a dozen exploits for the Java security model by now -- to the point that it is standing policy in many organizations not to install Java on end user/worker PCs.

But more to the point, the downsides of Java were supposed to be made-up-for by its platform independence. This was well and good in the 90s when there wasn't much else in the way of cross platform solutions. But now we have high quality (and free) cross compilers for practically every platform, hardware accelerated virtualization and a raft of other solutions to this problem.

I've taught C and Java at a university level for many years as a head tutor. Usually the students do Java before they move on to the C course. Java does give rise to numerous extremely bad programming habits and in my opinion 'breaks' new programmers before they even learn how to cut code. I would always start a new programmer off in C so they can get a good understanding of what is actually happening on the machine. IMHO it is very difficult to be a good programmer with no appreciation for the iron your code is running on..

Great explanation and points. However I liked one of my professors' take on the matter which is to teach Javascript as the first language. He basically wanted everyone to be able to do something cool and relevant in the first hour of starting to learn to code, aka the first class. I think as a college class that is a great way to get more people into the field.

 

[slimeychicken]

I don't even know where to begin.

I guess firstly you have to lug around the JVM ball and chain wherever you want to run your code. You have the illusion of platform independence but it is not an interpreted language so you still have to compile it, and then to do anything useful on the target platform you usually have to use JNI to access platform specific hardware at some point anyway.

The whole language itself is badly designed. Apart from being unnecessarily verbose, you have to manage pointers (including managing casting either directly or via generics) but yet you have no direct access to memory or pointer arithmetic, and then you have to put up with java's heap management and garbage collection (you don't even have the option to manage your own memory). The gc will run unexpectedly and chew up system resources unless you force it to run at the least inconvenient time. As I assume you are aware: Good programming practice is to clean up after you finish with memory so that you never need a garbage collector. In otherwords Java forces bad programming practice.

The security model is again rubbish. JVM runs in a process with usually liberal permissions and is expected to keep its own house security internally with respect to code running on it. Except it doesn't. There must have been a dozen exploits for the Java security model by now -- to the point that it is standing policy in many organizations not to install Java on end user/worker PCs.

But more to the point, the downsides of Java were supposed to be made-up-for by its platform independence. This was well and good in the 90s when there wasn't much else in the way of cross platform solutions. But now we have high quality (and free) cross compilers for practically every platform, hardware accelerated virtualization and a raft of other solutions to this problem.

I've taught C and Java at a university level for many years as a head tutor. Usually the students do Java before they move on to the C course. Java does give rise to numerous extremely bad programming habits and in my opinion 'breaks' new programmers before they even learn how to cut code. I would always start a new programmer off in C so they can get a good understanding of what is actually happening on the machine. IMHO it is very difficult to be a good programmer with no appreciation for the iron your code is running on..

The idea of GC and heap is to not require the programmer to focus on the underlying information, such as managing memory, and more on the actual application itself. Removes a cross-cutting concern thats irrelevant to how a client would use your application.

The idea has yet to be perfected, I agree that how the GC is implemented on most JVMs could be improved, and I understand your notion of not using any kind of GC to clean up resources, and people should manage it themselves. But as computers increase in power, the need to free up resources right away becomes less of a problem, and not needing to worry about pointers (null is the only pointer problem to worry about now) or when to free up memory can really speed up production. I'm not gonna argue with the fact that C is a more robust language, but it requires you to manage a cross-cutting concern (memory) that takes focus away from the actual application, which is what we are trying to advance from.

I do admit that it'll be nice to have the option to allocate and free up memory at will if you know what you're doing, but the requirement would have an impact on the audience of programmers we have. The idea of freeing up memory as soon as possible has always been best, but not needing to worry about it is an even stronger advantage.

As for the illusion of being platform independent, that's pretty damn true. There are a lot of kinks, but it's a big step towards removing concerns that don't relate to how the client will be using your application. It's similar to making dinner: Before, we had to find the chicken and wait for it to lay an egg before we can eat them. Now, it's nice to know where your egg came from, but it doesn't have anything to do with ensuring you eat an egg, so it's nice that the concern is no longer there.

I don't believe it's teaching bad practice; although it is best to free up memory as soon as possible, the idea of not needing to worry about it is powerful. It's a different view on how people should program: focus more on YOUR application, rather than how the computer handles it

 

The idea of GC and heap is to not require the programmer to focus on the underlying information, such as managing memory, and more on the actual application itself. Removes a cross-cutting concern thats irrelevant to how a client would use your application.

The concept is a contradiction in terms. The entire point of software is to enable users to make generic hardware do useful specific tasks. A programmer who is not focused on building that bridge between the desires and actions of the user and the response of the hardware is not really doing programming, but something else entirely (art maybe?)

At the end of the day when all is said and done, there is just native code running on the chip which is accepting inputs and providing outputs. You should be focused on taking those inputs in the best and most responsive possible way can and making the outputs as attractive and useful as you can.

Java and related languages are lazy, superficial and in my sincere opinion add little if any value to the discipline. Just my 2c however.

 

[slimeychicken]

The concept is a contradiction in terms. The entire point of software is to enable users to make generic hardware do useful specific tasks. A programmer who is not focused on building that bridge between the desires and actions of the user and the response of the hardware is not really doing programming, but something else entirely (art maybe?)

At the end of the day when all is said and done, there is just native code running on the chip which is accepting inputs and providing outputs. You should be focused on taking those inputs in the best and most responsive possible way can and making the outputs as attractive and useful as you can.

Java and related languages are lazy, superficial and in my sincere opinion add little if any value to the discipline. Just my 2c however.

You could call it lazy, but you would also be referring to using third party APIs, or even any API that doesn't refer to native code, as lazy. Even if it might be lazy, some people can't be bothered to do things someone or something else can do for them. Maybe they have deadlines, and can't spend as much time focusing on things like the underlying information.

It might not be as flexable as C, but it's definitely user friendly. Unless you use C++ or some kind of hack, you can't use object orientation. I'm not hating on it for that, I'm just saying theres upsides and downsides to everything.

Yeah it sucks you gotta carry around the JVM, but other languages were written for it allowing for new coding styles that speed up development, like Scala. Mixing the two languages give you a strong advantage (quick hidden implementation creation with Scala, safe API release with Java).

I totally understand where you're coming from with the downfalls compared to C, but the comparison isn't fair. You're trying to work as close to the hardware as possible, because in the end the hardware is what makes things happen. But the function of Java isn't to get the best performance. Yeah, people are working on making it faster, but thats more of a "getting out of the ditches" than trying to compete with C. It's to make develment of an application easier by not forcing the developer to focus on things unrelated to the purpose of their application.

You're saying it's a contradiction, but that depends on your view. We're past the view of "getting hardware to do specific tasks", and we're onto the view of "making things people find useful". For those interested in maximizing what they get out of their hardware (which people are; still making better CPUs) and see no higher priority, then yes, it's a contradiction. But if your focus is getting stuff done within deadlines testing quickly, then these "lazy" ways are extremely helpful.

 

[CompileTime]

I don't even know where to begin.

I guess firstly you have to lug around the JVM ball and chain wherever you want to run your code. You have the illusion of platform independence but it is not an interpreted language so you still have to compile it, and then to do anything useful on the target platform you usually have to use JNI to access platform specific hardware at some point anyway.

The whole language itself is badly designed. Apart from being unnecessarily verbose, you have to manage pointers (including managing casting either directly or via generics) but yet you have no direct access to memory or pointer arithmetic, and then you have to put up with java's heap management and garbage collection (you don't even have the option to manage your own memory). The gc will run unexpectedly and chew up system resources unless you force it to run at the least inconvenient time. As I assume you are aware: Good programming practice is to clean up after you finish with memory so that you never need a garbage collector. In otherwords Java forces bad programming practice.

The security model is again rubbish. JVM runs in a process with usually liberal permissions and is expected to keep its own house security internally with respect to code running on it. Except it doesn't. There must have been a dozen exploits for the Java security model by now -- to the point that it is standing policy in many organizations not to install Java on end user/worker PCs.

But more to the point, the downsides of Java were supposed to be made-up-for by its platform independence. This was well and good in the 90s when there wasn't much else in the way of cross platform solutions. But now we have high quality (and free) cross compilers for practically every platform, hardware accelerated virtualization and a raft of other solutions to this problem.

I've taught C and Java at a university level for many years as a head tutor. Usually the students do Java before they move on to the C course. Java does give rise to numerous extremely bad programming habits and in my opinion 'breaks' new programmers before they even learn how to cut code. I would always start a new programmer off in C so they can get a good understanding of what is actually happening on the machine. IMHO it is very difficult to be a good programmer with no appreciation for the iron your code is running on..

The whole "Write once, run anywhere" thing is a bit of a gimmick.

Java does not allow you to take full control of and manage memory. However, with most client-side applications nowadays, you don't really need to worry about that. Consumer hardware is always becoming cheaper and more efficient, micro-managing memory and reinventing the wheel is not really needed with Java. What Java offers is speed in development, separation from most platform specific logic, and it helps developers do what they really want to do. Now of course to do anything, the JVM has to make native system calls and there is a bit more overhead in Java applications. However, you act like the JVM weighs down Java programs considerably and that Java is a bulky, slow language. That is just not true, and the trade-off for most developers is worth it.

Now I agree with the your point that developers should learn about how the code they write actually works. This is something I strive to do myself, but saying that Java is a poor language to learn if you're just starting out, I would have to say that's rubbish. Java is a solid language to start with, it will help you understand object-oriented programming and it is very user friendly. Also there are some up sides to running on a VM... Like hot swapping


TLDR;

There are some times where you would benefit from using platform-specific languages like C, or C++. However, for a lot of applications, nowadays, it won't make much of a difference. I would agree with the fact that Java code can be a bit verbose, and sometimes excessive. However, saying that Java enforces "bad programming practices" is just not true. There are plenty of things beginners can learn from Java, such as, Design Patterns, Code scalability, API Design, I could go on.

Java is just one of those things people love to hate on.
But if you're someone who's just starting out, don't let them deter you. Java is a solid first choice.

 

You could call it lazy, but you would also be referring to using third party APIs, or even any API that doesn't refer to native code, as lazy. Even if it might be lazy, some people can't be bothered to do things someone or something else can do for them. Maybe they have deadlines, and can't spend as much time focusing on things like the underlying information.

All code compiled for a target platform, running on the target platform is native code including third party APIs. The only code that is not native is code which is emulated or interpreted, but even this is emulated or interpreted by native code.

It might not be as flexable as C, but it's definitely user friendly. Unless you use C++ or some kind of hack, you can't use object orientation. I'm not hating on it for that, I'm just saying theres upsides and downsides to everything.

Right and so you would use C++ if you needed objects... In most cases you don't even need to change compilers. But I wasn't so much selling people on C or another language as I was un-selling them on Java.

Yeah it sucks you gotta carry around the JVM, but other languages were written for it allowing for new coding styles that speed up development, like Scala. Mixing the two languages give you a strong advantage (quick hidden implementation creation with Scala, safe API release with Java).

I totally understand where you're coming from with the downfalls compared to C, but the comparison isn't fair. You're trying to work as close to the hardware as possible, because in the end the hardware is what makes things happen. But the function of Java isn't to get the best performance. Yeah, people are working on making it faster, but thats more of a "getting out of the ditches" than trying to compete with C. It's to make develment of an application easier by not forcing the developer to focus on things unrelated to the purpose of their application.

When you write code you are writing code for something. I cannot emphasize enough that programming is literally the programming of machines. This idea that you can go off and live in a fuzzy abstract world where you don't need to know anything about the machine you are programming for is pure nonsense.

High level languages have a very specific and important roles to play in software engineering. Usually this involves building a specific type of a generic underlying program. An example would be a regex or an SQL statement -- these are both used for searching or modifying potentially large datasets -- a task that is mostly boilerplate and does not need to be written out verbosely each time it is done.

You're saying it's a contradiction, but that depends on your view. We're past the view of "getting hardware to do specific tasks", and we're onto the view of "making things people find useful". For those interested in maximizing what they get out of their hardware (which people are; still making better CPUs) and see no higher priority, then yes, it's a contradiction. But if your focus is getting stuff done within deadlines testing quickly, then these "lazy" ways are extremely helpful.

You're still programming a machine, you're still making hardware do a specific task, you're just opting to do it badly.

The whole "Write once, run anywhere" thing is a bit of a gimmick.

Java does not allow you to take full control of and manage memory. However, with most client-side applications nowadays, you don't really need to worry about that. Consumer hardware is always becoming cheaper and more efficient, micro-managing memory and reinventing the wheel is not really needed with Java. What Java offers is speed in development, separation from most platform specific logic, and it helps developers do what they really want to do. Now of course to do anything, the JVM has to make native system calls and there is a bit more overhead in Java applications. However, you act like the JVM weighs down Java programs considerably and that Java is a bulky, slow language. That is just not true, and the trade-off for most developers is worth it.

Memory is a finite resource on any system. I'm not talking about micromanaging memory (as you might do writing machine code), I am talking about managing your heap. It is one of the most important tasks in programming and neither of you apparently understand its importance (again demonstrating that Java teaches bad programming habits.)

Now I agree with the your point that developers should learn about how the code they write actually works. This is something I strive to do myself, but saying that Java is a poor language to learn if you're just starting out, I would have to say that's rubbish. Java is a solid language to start with, it will help you understand object-oriented programming and it is very user friendly. Also there are some up sides to running on a VM... Like hot swapping


TLDR;

There are some times where you would benefit from using platform-specific languages like C, or C++. However, for a lot of applications, nowadays, it won't make much of a difference. I would agree with the fact that Java code can be a bit verbose, and sometimes excessive. However, saying that Java enforces "bad programming practices" is just not true. There are plenty of things beginners can learn from Java, such as, Design Patterns, Code scalability, API Design, I could go on.

Java is just one of those things people love to hate on.
But if you're someone who's just starting out, don't let them deter you. Java is a solid first choice.

As I said before, having taught it I strongly disagree. Learning Java as a first programming language is quite akin to learning to fly a plane on autopilot and then instead of learning to land the plane when you're at your destination, you just crash it into the sea and get a new one every time. Then you walk around and call yourself a pilot.

The programming of machines is a science, not an art. It calls for discipline, understanding and study. When you work with machines you must appreciate that the machine has finite resources, and as the programmer of that machine it is up to you to treat and use these resources in the best possible way to maximize the utility of the machine. This is exactly as true today as it was in 1970.

As a programmer of a machine your job has four pieces: 1. accept inputs, 2. provide outputs, 3. manipulate, store and otherwise treat data, 4. manage and treat the finite resource of the machine properly.

If your language of choice does not allow or actively prevents you doing any of your primary tasks as a programmer then it is not a good choice of programming language.

 

[SuF]

When you write code you are writing code for something. I cannot emphasize enough that programming is literally the programming of machines. This idea that you can go off and live in a fuzzy abstract world where you don't need to know anything about the machine you are programming for is pure nonsense.

High level languages have a very specific and important roles to play in software engineering. Usually this involves building a specific type of a generic underlying program. An example would be a regex or an SQL statement -- these are both used for searching or modifying potentially large datasets -- a task that is mostly boilerplate and does not need to be written out verbosely each time it is done.

I feel that way when I am writing Haskell. Look at these couple parts of IRC message parsing. Easy to read and easy to write. Don't need to play with Strings and realize mid way through that you are doing way too much memory copying with String operations or anything.

parseUserhost :: Parser (Maybe Userhost)
parseUserhost = option Nothing $
parseUsername >>= \username ->
parseHostname >>= \hostname ->
return (Just (Userhost username hostname))

parseUsername :: Parser (Maybe String)
parseUsername = option Nothing $
char '!' >>
takeTill (== '@') >>= \p1 ->
return (Just (unpack p1))

parseHostname :: Parser String
parseHostname =
char '@' >>
takeTill (== ' ') >>= \p1 ->
return (unpack p1)

 

[slimeychicken]

All code compiled for a target platform, running on the target platform is native code including third party APIs. The only code that is not native is code which is emulated or interpreted, but even this is emulated or interpreted by native code.

My point was using libraries is the act of having someone else do something for you. Saying Java is bad for allowing other people manage memory for you is like saying using an API that you didn't write the implementation to is also bad.. It helps save time

But I wasn't so much selling people on C or another language as I was un-selling them on Java.

The way I see it, languages are nothing more than tools, and some shine more than others in some areas. Using Java for a game client like RuneScape isn't the best use of java, that's for sure. But people everywhere use JSP for dynamic webpages and Java for their servers. Some people even mix C and Java (like Google), so it serves SOME purpose. The purpose just isn't targeted towards ensuring nothing is looming around in heap when it isn't being used, unless maybe it's a password which there are ways around it. Memory really isn't as scarce as you're thinking. Out of curiosity, what language would you sell people onto?

When you write code you are writing code for something.

A lot of the time, it's software for clients who aren't patient and don't care if the computer is handling it as perfectly as possible. As long as there's resources when needed, you're fine. If resources are needed, things will be de-allocated. Yeah, it's not the perfect way to do it, but the upsides are worth it.

Memory is a finite resource on any system. Managing your heap is one of the most important tasks in programming and neither of you apparently understand its importance

It's finite, but it's definitely not scarce. Of course memory management is important, but you're acting like a bunch of 5 year olds wrote the systems managing memory for java developers. Resource gets freed up when it's needed. It's not like everyone is using up all their memory on tedious things, and GC happens on a separate thread, so it's not having a huge affect on processing time. If you really don't feel I understand the importance of it, why don't you give me a lesson?

Learning Java as a first programming language is quite akin to learning to fly a plane on autopilot and then instead of learning to land the plane when you're at your destination, you just crash it into the sea and get a new one every time. Then you walk around and call yourself a pilot.

I think a better analogy would be that our planes are now learning how to land themselves. Programming is evolving, and if you don't wanna call them programmers, then fine. But high-level programming languages lower the fences and allow for innovators who aren't interested in the true aspect of computers to show their stuff.

The programming of machines is a science, not an art.

There's no point in trying to convince you of their use. Programming an application with the idea of a client using it for functionality (like Skype, and whatever else will come in the future), and programming an application/machine with the idea of a client using it for speed and performance (like an OS) are two totally different things.

As a programmer of a machine your job has four pieces: 1. accept inputs, 2. provide outputs, 3. manipulate, store and otherwise treat data, 4. manage and treat the finite resource of the machine properly.

But you never mentioned programming with functionality, scalability and time constraints in mind.

Yeah it sucks that programmers now-a-days aren't required to learn about managing memory, but the people who have true interest look into that stuff, so it's not like we have to worry about it being neglected. We are sucking in people that would probably quit within a week (since they don't feel as if they're making progress on their application), and allowing more room for innovation. I'm not saying it's the best language to start off with, that's not my opinion. I'm saying it serves a purpose. The people who choose it as a starting language most likely don't have as much interest in learning about the underlying details, and wanna get their ideas out.

 

Just for anyone following this debate. Garbage collection and reference counting can be used in many languages. If having a GC is your main reason for using Java then you should definitely branch out.

 

[slimeychicken]

If having a GC is your main reason for NOT using Java, keep in mind that .NET also implemented a garbage collector in the CLR, so if you're gonna hate on Java, you also gotta hate on C#. Memory is not a scarce resource anymore; I'm not saying using a GC will allow your program to perform better. If anything, it's quite the opposite (although, the results are seriously invisible to us, and VM could optimize enough to make a badly written program writting in Java run faster than a badly written program written in C++). But the pros outweight the cons.

If you're following this debate, just do your own research.