Java Basics [3] - Primitive Variables

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.

 

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

 

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.

 

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

 

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.

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

 

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.

 

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.

 

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

 

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.

 

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.

 

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.

 

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

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?

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.

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?

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.

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.

 

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.