Why id Java the best language around?

I can't quite explain why it is, but it just is. I dare you to refute this claim.

Did anyone even do a /prog/ rant-kopipe for java yet? I think I've asked this before but kike spammers slid the forum so hard so I have no idea where the thread is.

>>1

No arguments here. I personally love the type safety that Java provides, it catches so many errors I wouldn't have ever anticipated otherwise. That's why Java programs are so robust and reliable.

1. Java has no built in macro system. It is not possible to implement something as simple as an assertion statement that displays the false expression on an error.
2. Exceptions are the normal style in Java, resulting in complex and inefficient code that frequently unwinds and reconstructs the stack.
3. Java does not have first class functions. However, they may be emulated with anonymous classes, at the cost of being more verbose and harder to read. The need to defi
ne an object that implements a method with a particular name makes it more difficult to write a library for higher order functions.
4. It is not possible to define a function within a function. However, it is possible to define a class within a function, and the class may have methods. There is no ad
vantage to disallowing one while allowing the other, save for making it more verbose.
5. The Object interface provided by all objects provides methods for equality and hash code, but does not provide methods for comparison. Alternative interfaces for comp
arable objects are ugly or incompatible, making ordered data structures harder to use.
6. All methods for a class must be defined within the class body, which can produce very large files if the class has many methods.
7. Lexically scoped classes may develop large definitions, producing enormous source files. They are also hard to divorce from their outer class definition, making it difficult to share code between other such child classes. The real solution is to do away with the lexically scoped definition, but programmers will take the immediately easier solution of copying and pasting code, resulting in large bodies of duplicate code in multiple files.
8. The Java runtime is known for being insecure. Java is now owned by patent troll, Oracle, which creates anxiety about any investment whatsoever in the language. It also doesn't help that they don't plan on fixing the security issues.
9. Package names following the pattern of com.example.www are unnecessarily verbose. Name collisions between packages are rare, and can be resolved easily enough via oth
er means.
10. Tail recursion is not supported, and made impossible by the design of the virtual machine. This is particularly annoying, since tail recursion blends so well with the object oriented notion of the call to the super class.
11. The compiler signals too many false positive errors. Floats need to be explicitly casted to int. Errors about unreachable code will prevent you from compiling and testing code that is still a work in progress.
12. Forcing the programmer to type "public static final" may be negative reinforcement to defining global variables, but it does not remove global variables or provide the programmer with another way to solve their problem.
13. In general, Java strives to find the most verbose representation for everything.
14. Java claims to be more memory secure than alternatives like C++, but this is made invalid by its insecure supporting libraries. It also doesn't matter how memory secure your application is if it still dies from a NullPointerException.
15. The object model is weak and inexpressive. The lack of multiple inheritance makes combining functionality from multiple classes more difficult.
16. APIs may require objects to implement an excessive amount of interfaces and method names in interfaces may collide.
17. APIs are encouraged to make excessive use of design patterns that offer little to no benefit, other than making the library more inefficient and harder to learn.
18. Local variables referenced in lexically scoped anonymous classes must be declared final, which means they can't be changed in loops. This would be fine, but there is no tail recursion, so these variables can't be efficiently used for iteration.
19. Parameterized types in generics cannot always be statically verified, and depend on run time checks that may through exceptions and crash your program.
20. All methods are virtual by default, which produces more inefficient code if not optimized. Every method being virtual makes escape analysis almost impossible to perform locally, since every method call could invoke unknown code.
21. Java code tends to be imperative, which can become difficult to follow as the relationships between objects becomes complex. Java's verbose style makes poorly written code more difficult to read.
22. It is not possible to express packed data structures in Java. Objects must use references to link to other objects, resulting in wasted space and cache incoherent memory look ups, and also more work for the garbage collector.
23. Java is essentially child-proofed C++ with garbage collection. It sacrifices performance while not providing more expressive power. It's a version of C++ for lesser skilled programmers.

1. Java has no built in macro system. It is not possible to implement something as simple as an assertion statement that displays the false expression on an error.
2. Exceptions are the normal style in Java, resulting in complex and inefficient code that frequently unwinds and reconstructs the stack.
3. Java does not have first class functions. However, they may be emulated with anonymous classes, at the cost of being more verbose and harder to read. The need to define an object that implements a method with a particular name makes it more difficult to write a library for higher order functions.
4. It is not possible to define a function within a function. However, it is possible to define a class within a function, and the class may have methods. There is no advantage to disallowing one while allowing the other, save for making it more verbose.
5. The Object interface provided by all objects provides methods for equality and hash code, but does not provide methods for comparison. Alternative interfaces for comparable objects are ugly or incompatible, making ordered data structures harder to use.
6. All methods for a class must be defined within the class body, which can produce very large files if the class has many methods.
7. Lexically scoped classes may develop large definitions, producing enormous source files. They are also hard to divorce from their outer class definition, making it difficult to share code between other such child classes. The real solution is to do away with the lexically scoped definition, but programmers will take the immediately easier solution of copying and pasting code, resulting in large bodies of duplicate code in multiple files.
8. The Java runtime is known for being insecure. Java is now owned by patent troll, Oracle, which creates anxiety about any investment whatsoever in the language. It also doesn't help that they don't plan on fixing the security issues.
9. Package names following the pattern of com.example.www are unnecessarily verbose. Name collisions between packages are rare, and can be resolved easily enough via other means.
10. Tail recursion is not supported, and made impossible by the design of the virtual machine. This is particularly annoying, since tail recursion blends so well with the object oriented notion of the call to the super class.
11. The compiler signals too many false positive errors. Floats need to be explicitly casted to int. Errors about unreachable code will prevent you from compiling and testing code that is still a work in progress.
12. Forcing the programmer to type "public static final" may be negative reinforcement to defining global variables, but it does not remove global variables or provide the programmer with another way to solve their problem.
13. In general, Java strives to find the most verbose representation for everything.
14. Java claims to be more memory secure than alternatives like C++, but this is made invalid by its insecure supporting libraries. It also doesn't matter how memory secure your application is if it still dies from a NullPointerException.
15. The object model is weak and inexpressive. The lack of multiple inheritance makes combining functionality from multiple classes more difficult.
16. APIs may require objects to implement an excessive amount of interfaces and method names in interfaces may collide.
17. APIs are encouraged to make excessive use of design patterns that offer little to no benefit, other than making the library more inefficient and harder to learn.
18. Local variables referenced in lexically scoped anonymous classes must be declared final, which means they can't be changed in loops. This would be fine, but there is no tail recursion, so these variables can't be efficiently used for iteration.
19. Parameterized types in generics cannot always be statically verified, and depend on run time checks that may through exceptions and crash your program.
20. All methods are virtual by default, which produces more inefficient code if not optimized. Every method being virtual makes escape analysis almost impossible to perform locally, since every method call could invoke unknown code.
21. Java code tends to be imperative, which can become difficult to follow as the relationships between objects becomes complex. Java's verbose style makes poorly written code more difficult to read.
22. It is not possible to express packed data structures in Java. Objects must use references to link to other objects, resulting in wasted space and cache incoherent memory look ups, and also more work for the garbage collector.
23. Java is essentially child-proofed C++ with garbage collection. It sacrifices performance while not providing more expressive power. It's a version of C++ for lesser skilled programmers.

>>5
Thank you!

Anyone care to post the Lisp, Python and Ruby ones? Is there a sepples kopipe?

>>6
The python and ruby ones can be found here https://dis.4chan.org/read/prog/1341173740 . I don't think there is a seeples one. I just wrote that Java one. Someone else could probably do a better one.

meant to bump

oh lawdy I luv me sum shitpoastin'

>It's a version of C++ for lesser skilled programmers.
nice abstract

>>10
>le e/g/in meme /g/quotes
nice reddit

>>11
nice job saging the top thread
back to reddit

>>4
>1. Not possible...assertion statement...false expression as an error
So? Just say if (!expectedResult) { System.out.println(expectedResult); throw new Exception(); }
>2. complex and inefficient code
That's an interesting way of saying "I never took the time to understand how coding in Java actually works."
>3. The design of Java makes first-class functions completely unnecessary. Once again, you should actually learn how Java code works.
>4. Function within a function
Why the hell would you need that?
>5. ugly or incompatible
In what way?
>6. Must be defined within the class body
So? Where else would you need to define them? If you put them anywhere besides the class body that would just make everything all the more "complex and inefficient."
>7. enormous source files
Really? It's 2013 and file size for source code is an issue?
>8. insecure
I'll give you this one.
>9. unnecessarily verbose
You see, Java has the best IDEs of any language. Just fucking use Eclipse and you'll never have to type an import statement again. People always complain about Java's excessive boilerplate code but the truth is you almost never have to type any of it.
>10. tail recursion is not supported
Alright, you have 2 points now.
>11. need to be explicitly casted
Casting in Java is not nearly as bad as languages like Haskell. Java makes it completely straightforward.
>11. unreachable code bla bla bla
Ever heard of commenting out code?
>12. bla bla bla
Not a very significant issue
>13. most verbose
Best IDEs.
>14. dies from a NullPointerException
Not if you catch and handle the exception like a normal person. Or just say if (myObject!=null) { //do stuff }
>15. combining functionality from multiple classes
You really don't understand Java's design, do you?
>16. method names...may collide
What are you doing where you need two different interfaces with the same method names and parameters?
>17. Java's design patterns make code much more flexible/easier to change. While it requires a lot of setup, it makes it much easier to change one piece of code without consequentially affecting something unrelated.
>18. bla bla bla
Alright, you have 4 points now. It's still a fairly insignificant point, seeing how sparingly anonymous classes are actually used.
>19. blablabla
Seriously, are you really that bad at coding? Maybe if you actually planned your code out before typing it then you wouldn't have so many problems with exceptions.
>20. all methods are virtual
Most of the time methods will need to be virtual in Java anyway. What if you had to declare every method you wanted to override as virtual? And this is coming from the guy who complains about verbosity...
>21. relationships between objects become complex
Seriously, Java has the most straightforward object system. Come back when you actually learn how it works.
>22. wasted space
>2013
>Is worried about running out of memory
>wtf?
>23. a version of C++ for lesser skilled programmers
More like a version of C++ for people that want an infinitude of libraries, including bindings of C++ libraries, and access to the best IDEs around. Not to mention how fucking simple the syntax is. Also, the standards for class naming/field naming are actually ENGLISH. Unlike C++'s hsgFloatvk num3k = 4.00000. Go to church, kike.

Java = Great infrastructure.

But the language is shit. Luckily there's Scala now.

>>13
I agree, 13-sama. Most of the arguments seemed trite, nitpicky or otherwise solved with use of an IDE (though I guess EXPERT programmers have to use vi/cat for everything).

After slogging through so much university-course C, java is just so much less a pain to work with.

It's basically the current pinnacle of programming practice.

>>13
Haha, nice try. XD
Java still is a childproof C++.

The Java Paradox

What's so great about Lisp? And if Lisp is so great, why doesn't everyone use it? These sound like rhetorical questions, but actually they have straightforward answers. Lisp is so great not because of some magic quality visible only to devotees, but because it is simply the most powerful language available. And the reason everyone doesn't use it is that programming languages are not merely technologies, but habits of mind as well, and nothing changes slower. Of course, both these answers need explaining.

I'll begin with a shockingly controversial statement: programming languages vary in power.

Few would dispute, at least, that high level languages are more powerful than machine language. Most programmers today would agree that you do not, ordinarily, want to program in machine language. Instead, you should program in a high-level language, and have a compiler translate it into machine language for you. This idea is even built into the hardware now: since the 1980s, instruction sets have been designed for compilers rather than human programmers.

Everyone knows it's a mistake to write your whole program by hand in machine language. What's less often understood is that there is a more general principle here: that if you have a choice of several languages, it is, all other things being equal, a mistake to program in anything but the most powerful one. [3]

There are many exceptions to this rule. If you're writing a program that has to work very closely with a program written in a certain language, it might be a good idea to write the new program in the same language. If you're writing a program that only has to do something very simple, like number crunching or bit manipulation, you may as well use a less abstract language, especially since it may be slightly faster. And if you're writing a short, throwaway program, you may be better off just using whatever language has the best library functions for the task. But in general, for application software, you want to be using the most powerful (reasonably efficient) language you can get, and using anything else is a mistake, of exactly the same kind, though possibly in a lesser degree, as programming in machine language.

You can see that machine language is very low level. But, at least as a kind of social convention, high-level languages are often all treated as equivalent. They're not. Technically the term "high-level language" doesn't mean anything very definite. There's no dividing line with machine languages on one side and all the high-level languages on the other. Languages fall along a continuum [4] of abstractness, from the most powerful all the way down to machine languages, which themselves vary in power.

Consider Cobol. Cobol is a high-level language, in the sense that it gets compiled into machine language. Would anyone seriously argue that Cobol is equivalent in power to, say, Python? It's probably closer to machine language than Python.

Or how about Perl 4? Between Perl 4 and Perl 5, lexical closures got added to the language. Most Perl hackers would agree that Perl 5 is more powerful than Perl 4. But once you've admitted that, you've admitted that one high level language can be more powerful than another. And it follows inexorably that, except in special cases, you ought to use the most powerful you can get.

This idea is rarely followed to its conclusion, though. After a certain age, programmers rarely switch languages voluntarily. Whatever language people happen to be used to, they tend to consider just good enough.

Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a very common language called Java. Java falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Java programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Java feature of your choice).

As long as our hypothetical Java programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Java are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Java programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Java, but with all this other hairy stuff thrown in as well. Java is good enough for him, because he thinks in Java.

When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Java. How can you get anything done in Java? It doesn't even have y.

By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Java paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.

I know this from my own experience, as a high school kid writing programs in Basic. That language didn't even support recursion. It's hard to imagine writing programs without using recursion, but I didn't miss it at the time. I thought in Basic. And I was a whiz at it. Master of all I surveyed.

The five languages that Eric Raymond recommends to hackers fall at various points on the power continuum. Where they fall relative to one another is a sensitive topic. What I will say is that I think Lisp is at the top. And to support this claim I'll tell you about one of the things I find missing when I look at the other four languages. How can you get anything done in them, I think, without macros? [5]

Many languages have something called a macro. But Lisp macros are unique. And believe it or not, what they do is related to the parentheses. The designers of Lisp didn't put all those parentheses in the language just to be different. To the Java programmer, Lisp code looks weird. But those parentheses are there for a reason. They are the outward evidence of a fundamental difference between Lisp and other languages.

Lisp code is made out of Lisp data objects. And not in the trivial sense that the source files contain characters, and strings are one of the data types supported by the language. Lisp code, after it's read by the parser, is made of data structures that you can traverse.

If you understand how compilers work, what's really going on is not so much that Lisp has a strange syntax as that Lisp has no syntax. You write programs in the parse trees that get generated within the compiler when other languages are parsed. But these parse trees are fully accessible to your programs. You can write programs that manipulate them. In Lisp, these programs are called macros. They are programs that write programs.

Programs that write programs? When would you ever want to do that? Not very often, if you think in Cobol. All the time, if you think in Lisp. It would be convenient here if I could give an example of a powerful macro, and say there! how about that? But if I did, it would just look like gibberish to someone who didn't know Lisp; there isn't room here to explain everything you'd need to know to understand what it meant. In Ansi Common Lisp I tried to move things along as fast as I could, and even so I didn't get to macros until page 160.

But I think I can give a kind of argument that might be convincing. The source code of the Viaweb editor was probably about 20-25% macros. Macros are harder to write than ordinary Lisp functions, and it's considered to be bad style to use them when they're not necessary. So every macro in that code is there because it has to be. What that means is that at least 20-25% of the code in this program is doing things that you can't easily do in any other language. However skeptical the Java programmer might be about my claims for the mysterious powers of Lisp, this ought to make him curious. We weren't writing this code for our own amusement. We were a tiny startup, programming as hard as we could in order to put technical barriers between us and our competitors.

A suspicious person might begin to wonder if there was some correlation here. A big chunk of our code was doing things that are very hard to do in other languages. The resulting software did things our competitors' software couldn't do. Maybe there was some kind of connection. I encourage you to follow that thread. There may be more to that old man hobbling along on his crutches than meets the eye.

>>16
Alright, then I guess we can just say that every language is just childproof assembly language. Everything would run optimally if we wrote it in pure assembly, so does that mean we should switch over to only programming in assembly from now on?

>>17
Thank you for this. Really great post. Did you write this? If so, you are a really good writer and you make a very strong argument.

>>13

Go back to /g/ dumb goy. And read about issue 19. You don't seem to understand it.

>>15

Java is alright. I could write a lot more about the pitfalls in C++. But that doesn't change that fact that I can still make software using either. But just because a language is usable for some applications doesn't mean it's not shit in terms of design.

>>18
No, other languages provide abstractions whose use is then translated to assembly. Java literally is child proofed C++. They took a subset of its features that are less likely to be abused by programmers and then slapped in GC.

>>21
Listen to ゴールドバーグ様 here.

>>17
During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.

>>19
Hahahaha, thank you kind sir!

According to 16 faggot, we should be coding using circuit diagrams.

>>23 so python is actually good? or no?

i couldn't get over things like x = 5.plus(2)

>>25
see >>21.

>>26
No, I don't know why the guy decided to group Perl, which is actually useful for things, with FIOC, which is unusable for absolutely anything outside of masochism.

>>25
Oh yes, that one. I had five and they were excelent.

>>26
That's said by the poor man's Java no-numerical-tower BigDecimal.

>>28
Java is unusable for absolutely anything also. The standard class library was rewritten several times already!
And that's a nice example how Java goy works, you do bottom-up ``abstract generic enterprise factory'' in advance, but when actual shit comes to your todo list you'll need to rewrite everything again because the shit can't into MVC/cache/concurrency and Java ``most straightforward object/generics system'' can't into aspects/contracts/mixins. That's why JCP is full of new features(!) and half import java.*; is deprecated or unadvised.
The only thing that supports Java nowadays is the \Large community and number of libraries, IDEs, books, et cetera, but at the cost of using a overly verbose language with barely the basic features found on competitor's environments and a quite bloated, unreliable, glued quickfix project of a VM.

That said, I don't hate Java, it's simpler to teach than C++ anyway, so you can get lots of cheap Java developers nowadays. So we love it! =3
Also, if you aren't going to make large/complex programs, why would you spend time to learn anything but the basics, ne?

Just to say anything good about JVM: better languages can run in it, the management/monitoring works, it gets close to C in benchmarks game, and I hope it somehow gets better (I don't expect it to happen though).

>>29
Java is unusable for absolutely anything also.
Yeah I really wasn't implying it was usable for anything, besides trolling clueless execs who are just asking for people to bleed them and their company dry.

Most of my friends program in C++ or Java anyway, why should I care? Because the saddest thing is to not be able to share my code with them. ;__;

>>32'
>implying you have friends

>>33                                                                                                                                                                                          `
>implying green text

>>34'
>implying you didnt check my dubs

>>19
See http://www.paulgraham.com/avg.html.

>>5,13
24. In Java, the signed integer overflow is not undefined. This disables a whole class of compile-time optimizations.

Java is shit.

We almost got fired because Java idiocy.
http://developers.slashdot.org/story/11/02/09/025237/java-floating-point-bug-can-lock-up-servers

>>32-35
e/g/in post /g/roskis, truly e/g/in, le lel face ;)