PlayOnLinux 5 To Switch From Being Written In Python To Using Java

[nikiiv]

I'm not sure what you're confused about. Everything I stated in that list is true. In particular, (and forgive me if I'm misreading your comment), Java does not have pattern matching. Unless you count "switch", I guess...?

Oh, and anything more than (for example) the SKI combinators or raw Turing Machines, is syntactic sugar. The thing is... syntax actually matters if you want to get anything practical done. There's a reason we don't program using the TM model. (Or Brainfuck for that matter. That's also Turing Complete, I believe.)

You mean pattern matching as in Haskell.. Why that is of a an importance for a project like PoL?
Otherwise - really... The language with most syntactic sugar wins? Really?

[caligula]

It doesn't leak at all.. It is always a developer bug. In the history of JDKs there were several cases where a bug in the runtime caused memory leaks, but I can't remember a case like that in the past several years.. When i said prone, I meant that developers usually rely on automatic garbage collections and sometime create strong circular references that cannot be automatically released when the execution goes outside the scope of the declaring method/class. I like the way Sift added they syntactic sugar for weak references

These pretty much cover the quirks

http://www.ibm.com/developerworks/java/library/j-jtp11225/index.html

http://www.ibm.com/developerworks/java/library/j-jtp01246/index.html

I agree with you that it doesn't leak. Of course there could always be a bug out there, but the model doesn't leak per se. OTOH reference counting is more error prone with circ refs etc.

[caligula]

I'm a bit surprised how people argue that Java isn't portable. It runs on Windows XP - 10, OS X (any version), Linux (any version), Solaris, BSD, Android, .. supports architectures such as x86, x86-64, armv6, armv7. Almost every machine expect the cheapest and oldest routers run Java. There are also multiple VMs. If you want AOT, why not use Avian?

[anda_skoa]

Garbage collection or some form of memory management isn't "quick and dirty", it's freeing the programmer from manual error-prone memory drudge work, and is the hallmark of any modern language.

I think the bad reputation of garbage collection comes from early times, especially in Java.
Back then it was not possible to explicitly dispose objects, i.e. at garage collection an objects memory and native handles would be freed, with not way of freeing native handles earlier.

This was of course an implementation mistake and, AFAIK, has since then been fixed by allowing explicitlly calling dispose, giving up all non-memory resources and leaving memory reclamation to the garbage collector.

Without that programs that processed lots of files or handled lots of sockets would easily run out of file handles or socket descriptors respectively..

Which made garbage collection a pain point and this is still tainting the concept as a whole.

Cheers,
_

[caligula]

I think the bad reputation of garbage collection comes from early times, especially in Java.
Back then it was not possible to explicitly dispose objects, i.e. at garage collection an objects memory and native handles would be freed, with not way of freeing native handles earlier.

This was of course an implementation mistake and, AFAIK, has since then been fixed by allowing explicitlly calling dispose, giving up all non-memory resources and leaving memory reclamation to the garbage collector.

Without that programs that processed lots of files or handled lots of sockets would easily run out of file handles or socket descriptors respectively..

Which made garbage collection a pain point and this is still tainting the concept as a whole.

Cheers,
_

The latest Java versions have a revised version of (N)IO. I'd expect them to work properly so that there would be less need for native code and JNI.

[fabdiznec]

You mean pattern matching as in Haskell.. Why that is of a an importance for a project like PoL?

It's not specifically of importance for PoL... it's of importance for any project that deals with data structures. That is, all of them -- including PoL.

You mean pattern matching as in Haskell.. Why that is of a an importance for a project like PoL?
Otherwise - really... The language with most syntactic sugar wins? Really?

Um, no. It's not about "most". It's about "most relevant" and "most useful" and "most trivial-error-reducing", etc. Surely, that can't be controversial?

Just as a trivial example, compare

case class Foo(a: String, b: String)

with

public class Foo {
    private String a;
    private String b;
    public String getA() {
        return a;
   };
   public void setA(String a) {
       this.a = a;
   }
   public String getB() {
       return b;
   }
   public void setB(String b) {
       this.a = b;
   }
   public boolean equals(Object other) {
      ...; // Huge amount of error-prone (see Effective Java) boilerplate removed here
      // NB: This code *must* be kept in sync if you add/remove fields or you might get surprises.
   }
   public int hashCode() {
      ...; // Huge amount of error-prone boilerplate removed here.
      // NB: This code *must* be kept in sync if you add/remove fields or you might get surprises.
   }
}

(case classes are by default immutable in Scala, but let's assume we're doing the idiomatic thing for each language/culture.)

Which of these do you think is more vulnerable to copy/paste errors, transcription errors, errors when maintaining, etc.? Hint: The case class is completely boilerplate-free and there's actualy no way to screw it up because you got the identifiers wrong. Btw, did you notice the C&P error that I deliberately put in the Java example to illlustrate my point about such amounts of boilerplate leading to C&P which can lead to subtle mistakes?

(Just as an aside, I think my earlier comment which got a bit muddled was a roundabout way of saying "syntax is an abstraction".)

[oleid]

Yeah, when it's running, everything is just fine. But I often have to run the python-updater because during system updates, the compiling just crashes with some fishy compiler error in some python-libraries. The same problem I've got with perl.

Dunno, I have no problems like this here... and I recently migrated from python-3.3 to 3.4. But then, I'm running (mostly) stable...

[nikiiv]

It's not specifically of importance for PoL... it's of importance for any project that deals with data structures. That is, all of them -- including PoL.



Um, no. It's not about "most". It's about "most relevant" and "most useful" and "most trivial-error-reducing", etc. Surely, that can't be controversial?

Just as a trivial example, compare

case class Foo(a: String, b: String)

with

public class Foo {
private String a;
private String b;
public String getA() {
return a;
};
public void setA(String a) {
this.a = a;
}
public String getB() {
return b;
}
public void setB(String b) {
this.a = b;
}
public boolean equals(Object other) {
...; // Huge amount of error-prone (see Effective Java) boilerplate removed here
// NB: This code *must* be kept in sync if you add/remove fields or you might get surprises.
}
public int hashCode() {
...; // Huge amount of error-prone boilerplate removed here.
// NB: This code *must* be kept in sync if you add/remove fields or you might get surprises.
}
}

(case classes are by default immutable in Scala, but let's assume we're doing the idiomatic thing for each language/culture.)

Which of these do you think is more vulnerable to copy/paste errors, transcription errors, errors when maintaining, etc.? Hint: The case class is completely boilerplate-free and there's actualy no way to screw it up because you got the identifiers wrong. Btw, did you notice the C&P error that I deliberately put in the Java example to illlustrate my point about such amounts of boilerplate leading to C&P which can lead to subtle mistakes?

(Just as an aside, I think my earlier comment which got a bit muddled was a roundabout way of saying "syntax is an abstraction".)

Doesn't your IDE takes care of all these? Because mine does.. Without having to resort to single copy/paste.. and hides them for me.. Say sometimes I do want to tune my hashCode and equals..

I do some Scala and yes, I find that useful, but that doesn't meant a s**t about saying that Java is a mediocre language..
Mind you Java is 20 yro and it adapts.. But one can't just throw away all the legacy since 2/3 of the enterprise rocks Java in some shape or form..
I like Scala since it is functional by design and there are some problems that shine when done in Scala, but that doesn't mean that Java sucks..
C#, Scala, Swift just to name few stepped on top of Java and did some stuff right, after having Java as an example for 10-15 years..
In the future when Scala matures another language will take the good and fix the bad part of it, but does that mean that Scala sucks now?

Say Scala list comprehension is not that neat as Haskel's, not it can work on infinite by design lists but does it mean that Scala sucks.. Or that should be the reason to pick one or the other for a project that strictly doesn't need that?

I have an evaluation engine that evaluates complex boolean rules against a predefined variables. It has to process thousands of evaluation per seconds. First version was written in Java, then 3 years later I re-wrote it in Scala and then a couple of months ago it was re-written in Haskell.. Each implementation was better, cleaner and neater then the previous one as the problem fitted better then the the technology used in the previous iteration.. But then again, the technology was chosen to reflect the needs.. And that alone can't be a reason to say that a language sucks..

Java by design is an imperative language and I've heard complains and whines why it is not Scala.. because it isn't. if you need functional, if you need immutable, go with Scala, but I don't think PoL needs that.. So how is that a reason to pick the technology or piss on another

[fabdiznec]

Doesn't your IDE takes care of all these? Because mine does.. Without having to resort to single copy/paste.. and hides them for me.. Say sometimes I do want to tune my hashCode and equals..

So, your IDE can spot that I typed "this.a" instead of "this.b" in one of those assignments in a setter. That's impressive! It might be an AI! (Seriously, did you spot it or not? Be honest!)

Or maybe you mean that you could generate the code? Well, yeah... the problem with generating code is that code has to be maintained and reviewed by humans. Generated code does not get maintained automatically; hence my comments about hashCode() and equals(). And, in fact, it is actually impossible to generate working code for equals() unless you assume some sort of intent; it all depends on what you want wrt. subclasses comparing equal to superclasses or not. With case classes the intent is made clear (by language semantics).

Also, does your IDE spot that you just added a field and automagically include that field in hashCode() and equals()? Last time I used Eclipse, it certainly didn't. (Even if it did, it's still a crutch for a problem that shouldn't exist in the first place.)

Actually having generated code intermingled with manually written code is insanely error-prone. I've personally worked on several projects where that meant quite a bit of actual money being lost. (Not directly, but indirectly from these types of problems.)

Better languages can avoid the problem entirely, so why don't we...?

(I include a modernized Java in the "better languages" category, FWIW. FutureJava might actually catch up and be a reasonable language once again.)

I do some Scala and yes, I find that useful, but that doesn't meant a s**t about saying that Java is a mediocre language..
Mind you Java is 20 yro and it adapts.. But one can't just throw away all the legacy since 2/3 of the enterprise rocks Java in some shape or form..
I like Scala since it is functional by design and there are some problems that shine when done in Scala, but that doesn't mean that Java sucks..

First, Scala and Java both run on the JVM, so you actually can choose to use Scala instead of Java without throwing away all the legacy. (This is in fact the only reason I currently use Scala rather than Haskell.)

Second, this is not about Scala. It's about Java not being good. I only brought up Scala as an example, y'know for illustrative purposes.

C#, Scala, Swift just to name few stepped on top of Java and did some stuff right, after having Java as an example for 10-15 years..
In the future when Scala matures another language will take the good and fix the bad part of it, but does that mean that Scala sucks now?

No, not *now* (as in 2015). But it means that it will suck in your imagined future scenario (let's say 2025 for simplicity.) That's what "suck" means: When compared to alternatives, it's worse. And Java currently does and I imagine Scala (as of today) will in 2025.

Our ideas of what's acceptable evolves with the times. Is this a difficult concept to understand?

(Btw, Java was a revelation when it appeared in 1995(?) and has spearheaded and legitimized many things that were controversial at the time, e.g. garbage collection and JIT-compilation.)

Say Scala list comprehension is not that neat as Haskel's, not it can work on infinite by design lists but does it mean that Scala sucks.. Or that should be the reason to pick one or the other for a project that strictly doesn't need that?

Non-sequitor and I don't understand why you even bring this up.

I have an evaluation engine that evaluates complex boolean rules against a predefined variables. It has to process thousands of evaluation per seconds. First version was written in Java, then 3 years later I re-wrote it in Scala and then a couple of months ago it was re-written in Haskell.. Each implementation was better, cleaner and neater then the previous one as the problem fitted better then the the technology used in the previous iteration.. But then again, the technology was chosen to reflect the needs.. And that alone can't be a reason to say that a language sucks..

I feel like I'm repeating myself. The fact that X "worked" or could be implemented in language A does not imply that A is a good language. It just means that it was possible to implement it. Hint: It's possible to implement anything in *any* language as long as it's Turing Complete. (And actually has I/O and such... hence the phrase "Pacman Complete".)

Java by design is an imperative language and I've heard complains and whines why it is not Scala.. because it isn't. if you need functional, if you need immutable, go with Scala, but I don't think PoL needs that.. So how is that a reason to pick the technology or piss on another

This is not a complaint about Java being imperative -- after all, I enjoy Haskell which has been described as the world best imperative language (not by me, obviously, but it's a sentiment I agree with). It's a complaint that Java forces everyone to write (or have their IDE) generate a huge amount of boilerplate for no discernible reason given what we've learned about language design. The major issue with boilerplate is that it places an ever-increasing maintenance burden on everyone who's involved with a project. It's not a trivial issue.

(I'd encourage you to investigate Project Lombok if you want to avoid a lot of the boilerplate. It's not perfect, but it usually gets the job done.)

Anyway, that's me done for the thread. It's probably not productive to go on -- you can have the last word if you want it . I will read and think about any reply you do post.

[pal666]

Garbage collection or some form of memory management isn't "quick and dirty", it's freeing the programmer from manual error-prone memory drudge work, and is the hallmark of any modern language.

bullshit
every big java app leaks memory. it just allows shitty programmers to write programs which suck slightly less. in real word resources are not limited to memory and must be freed at non-arbitrary time. in serious languages resource handling is not harder than in joke languages with garbage collector, but more robust. just don't benchmark against portable assembler