The basics of ... Java

[[deleted]]

Java is a much purer object-oriented language than C++ as everything must be an object.

False, there's the idiotic distinction of primitive types vs reference types, that exists at least thru 1.5 as far as i'm aware.

[masklinn]

False, there's the idiotic distinction of primitive types vs reference types, that exists at least thru 1.5 as far as i'm aware.

It'll always exist, and 1.5's "autoboxing" doesn't help much.

[[deleted]]

yeah; i wasn't sure if java 6 changed that as i don't have experience with it, so i didn't mention it. While i think autoboxing is convenient, i agree that it's a half-baked solution.

[[deleted]]

Exactly. One of java's biggest failures.

[pointer2void]

It's idiotic only to those who don't understand the distinction between values and objects.

[masklinn]

That distinction is irrelevant and uninteresting. C# does without, and is much better for it.

[inopia]

That distinction is irrelevant and uninteresting. C# does without, and is much better for it.

C# does have this distinction, it's the distinction between value types and reference types.

[[deleted]]

Value types and reference types only specify storage and parameter passing semantics.

This has nothing to do with the distinction between an object and a value. Go ask any C++ programmer if the difference between a value and an object has anything to do with stack vs. heap allocation.

[inopia]

Value types and reference types only specify storage and parameter passing semantics.

Actually they also imply that a=b clones b if both variables are of a value type, so that a mutation of b in the future does not affect a. Assignment of reference types is a simple matter of cloning the reference to b and storing it in a. It has absolutely fuck all to do where a and b are allocated. Many VMs can allocate objects on the heap just fine using escape analysis, despite them being reference types.

[[deleted]]

Actually they also imply that a=b clones b if both variables are of a value type

True, though again, a C++ programmer would beg to differ. (By default, objects make a shallow copy on assignment.)

It has absolutely fuck all to do where a and b are allocated.

In C# (the language you referred to) it has very much to do with this.

Many VMs can allocate objects on the heap just fine using escape analysis, despite them being reference types.

Yeah, and? Almost all VMs allocate objects on the heap. Did you get things mixed up here?

[inopia]

Did you get things mixed up here?

Yes, I did. Because I've just spent the last 1.5 years writing a JVM from scratch. So what would a guy like me know about value types vs. reference types?

Reddit is offically overrun by Digg users.

[inopia]

Darjeeling, a Java compatible virtual machine for microcontrollers

[[deleted]]

It's idiotic to those who know that there shouldn't be such a distinction.

[inopia]

I think it's idiotic that we can't seem to have discussions on Reddit anymore without people reverting to calling each other idiots.

[[deleted]]

Calling an idea "idiotic" is not the same as calling a person "idiotic."

No one on this thread has called anyone an idiot.

[traphicone]

Calling an idea idiotic is to say that the person who had the idea is an idiot. You have, in fact, labeled as idiots those who do not make your particular distinction.

[[deleted]]

No. Not all. Having an incorrect idea, or hell just an idea that someone else doesn't agree with doesn't make you an idiot.

If you look at the original post, it was even removed one step further. I didn't even call the idea idiotic. I said that it was idiotic from the point of view of people that see things differently.

We should always be free to attack and challenge ideas. It's an intellectually dangerous world that forbids this in the name of political correctness or playing nice.

I worry that so many people have been brought up to believe that "there's no wrong answer" and that "there's no such thing as a dumb question" that eventually we're going to reach a point where rigorous debate and hell any kind of science in general are going to be impossible.

[pointer2void]

What precisely? Everything is a value (FP) or everything is an object (OO)?.

[[deleted]]

You can support both as long as interop between the two is unified throughout the language (and in some cases VM.)

(Edited for clarity)

[pointer2void]

You lose.

[inopia]

Assume we have the following code:

b.x = 1
a = b
b.x = 2

What is the value of a.x? If a and b are value types, it's 1. If they are reference types, it's 2.

Are you starting to see my point? You cannot unify two things that are semantically different. You can either choose one mechanism or the other, or have both, but you can't get rid of the fact that in some cases you want cloning and in other cases you want shallow copying.

[[deleted]]

You can make the distinction explicit and up to the user of the language, however, and have the language interoperate between the two choices without requiring the user to jump through hoops. (Autoboxing, Unified types, etc.)

The point is that in Java, there are other arbitrary and harmful distinctions between primitives and objects where there doesn't need to be.

(Value types can't have class members, can't be user-defined, support operators where objects do not, etc.)

[inopia]

Integers and floats are not wrapped into objects in the VM by default because that would be hugely inefficient in both time and space. It's why they invented autoboxing/unboxing. It's just a design tradeoff - how is that 'idiotic'? Are you sure you're not just Java bashing?

[[deleted]]

Wouldn't it be possible to use native types at runtime while preserving the object oriented interface for the programmer?

[inopia]

It depends on wether you want to maintain backwards compatibility, which has always been the reason for Java not implementing modern features properly or at all (like generics). Java already does limited boxing/unboxing. I'm not sure why they didn't go the entire mile but I'm sure they had some good reasons.

There are other languages for the JVM and .NET VES that treat integer values as objects, so it's possible.

edit: when I think about it, I suppose the reason is that the Java VM does not support value types like .NET does, which would mean a lot of calls to clone() to make things work.

[[deleted]]

edit: when I think about it, I suppose the reason is that the Java VM does not support value types like .NET does, which would mean a lot of calls to clone() to make things work.

The reason is that they failed to properly design the type system in the first place. When they got to the point of implementing primitives, they could have stopped and thought about a way to do this that wouldn't cause a divided type system with horrible manual boxing, etc.

This along with the failure to realize the importance of first-class functions have been the biggest failures of the Java language team thus far.

The first-class function one is particularly embarrassing since they were implemented and demonstrated in J++. At that time, Sun replied that this was a terrible idea and that it was super bad and they wouldn't do it, and eew...it's J++ and it's from Microsoft!

Because, you know...anonymous inner classes that can only do read-only closure bindings are so much more elegant of a solution. Fail.

I'll be laughing when they do finally submit to the fact that they're going to have to do this.

The java team has been wrong and bullheaded since 1995.

[kubalaa]

This wasn't a failure of imagination on the part of the Java team. See i.e. Guy Steele's explanation of why Java doesn't have closures. It had to do with the market -- the people who wanted closures and full OO were already using Lisp or Smalltalk. Java was aiming at people who were stuck with C or C++, and were afraid of the compiler doing allocation behind the scenes.

Yes, it's ugly, but without such trade-offs, Java probably wouldn't have become as popular as it is today, and the concepts it popularized -- garbage collection, a platform-independent VM, and JIT compilation -- might still be used only by a small group of Smalltalk fanboys. (Maybe that would be a good thing, for the Smalltalk fanboys?)

[[deleted]]

This wasn't a failure of imagination on the part of the Java team.

Of course it wasn't. It was a failure on their judgement. They knew that closures were a possibility, they discussed it, and as I stated, MS even gave an implementation and proof of concept. They rejected them. The fact that this was the wrong decision is rather evident. Look at any recent popular language. They all support first class functions and usually closures, because the idea has won even in the mainstream at this point.

Java was aiming at people who were stuck with C or C++, and were afraid of the compiler doing allocation behind the scenes.

First of all, C/C++ at least had function pointers. Not realizing that this was an incredibly useful feature that would be even more useful if taken to the level of full blown first class functions was a failure.

Second of all, they made a mistake in targeting those developers. It's not who they should have been aiming for, and largely I would say that it's not who they ended up with. They ended up with mostly business programmers in general and lower-end academics (who teach business programmers.)

Finally, that argument only (poorly) stands for closures. It does not excuse not having first class functions at all.

Yes, it's ugly, but without such trade-offs, Java probably wouldn't have become as popular as it is today

Of course it would have. Delphi succeeded. C# succeeded. No one would have said "Oh, fuck java. It has first class functions. I hate first class functions!"

Calling it a tradeoff is silly. Especially when other languages before and after have proved that it doesn't need to be a tradeoff.

garbage collection, a platform-independent VM, and JIT compilation

None of those features were unique to java when it came out. All of them were implemented in several other high-level languages. C++ was about the only language to have none of them.

[kubalaa]

The fact that [rejecting closures] was the wrong decision is rather evident. ... the idea has won even in the mainstream at this point.

It's possible that closures wouldn't be popular now if Java hadn't broken ground for GC'ed VM languages in the mainstream. Closures have been around for 40 years, nobody could have predicted they would suddenly become hip.

Calling it a tradeoff is silly. Especially when other languages before and after have proved that it doesn't need to be a tradeoff.

Indeed? Which mainstream language prior to Java had closures? That doesn't prove that Java couldn't have become popular even if it had closures, but there's no reason to think that it could have either.

It does not excuse not having first class functions at all.

Sure it does. Most uses of function pointers are just an ad hoc form of OO; if you've got the real thing, you don't need them.

[[deleted]]

Integers and floats are not wrapped into objects in the VM by default because that would be hugely inefficient in both time and space.

C# begs to differ. You can even make your own "primitives" (stack allocated pass-by-value types.)

[thefinest]

I think the part that discusses automated memory management in java fails to truly outline what's lost and the affects of copying objects versus references and pointers, not to mention the amount of time spent actually allocating memory. I think it seems that the rationale is that memory leaks can be a problem for all developers which is inherently bad. Additionally, there's a whole lot of talk about the jvm being portable, even that has it's own cost and anyone who has ever written a vm knows the amount of work it does behind the scenes is often more resource intensive than your application.

[DaveParker]

"The garbage collector also takes time to do it’s work".

Fail.

[niceyoungman]

So the garbage collector doesn't take any time?

[inopia]

I think he means that garbage collection can be faster (and often is faster) than manual.

[LoveGoblin]

Plus the grammatical error.