What's wrong with Java?

[User 13269747]

Quote:

I am OK with the design decisions made, the issue there was conflicting expectations.

Yes, that is the problem: if you're going to have a type called 'byte' in your language, it's better represent a pattern of bits (no matter the size of the byte itself). As I get older, I get more and more irritated that all languages are not keeping to The Law of least Astonishment; they have rules, then exceptions to those rules, then overloaded meanings for keywords, then overloaded meanings for characters ... I keep meaning to design a language that is easier to read than to write: most modern languages right now make the reading very difficult unless you have unreasonable context memorised. C++ is a great example of producing "easy to write, but impossible to read" compound statements - most lines in C++ require knowing complex rules, some part of the standard and some part of the program. In particular, I'd like to shoot whoever thought that pass-by-reference must only be indicated in the declaration, and "helpfully" filled in by the compiler at the point of call. This means that looking at any function or method call is meaningless even if you just want to ignore it while looking for something else.

[Martin ISDN]

lets have 10 links for starters. also the wikipedia article is ok and some of the answers at quora [Object-Oriented Programming is Bad - YouTube](https://www.youtube.com/watch?v=QM1iUe6IofM) [Object-Oriented Programming is Embarrassing: 4 Short Examples - YouTube](https://www.youtube.com/watch?v=IRTfhkiAqPw) for all those propaganda examples of elegant oop code vs neanderthal procedural code, this is the reverse situation where procedural is lean and oop is bureaucracy [Stop Writing Classes - YouTube](https://www.youtube.com/watch?v=o9pEzgHorH0) [What's Wrong With Object-Oriented Programming?](https://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html) [Object-Oriented Cult](http://www.softpanorama.org/SE/anti\_oo.shtml) [Object-Oriented Programming — The Trillion Dollar Disaster](https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7) [Object Oriented Programming is an expensive disaster which must end](https://medium.com/@jacobfriedman/object-oriented-programming-is-an-expensive-disaster-which-must-end-2cbf3ea4f89d) [Rees Re: OO](http://www.paulgraham.com/reesoo.html) [The Web Will Die When OOP Dies](https://www.youtube.com/watch?v=\_CEBG\_s92P8&t=1044s) [Object Oriented Programming Oversold](http://www.oocities.org/tablizer/index.html) this looks like it is about oop in general, but it is about the java way of oop. not against oop in smalltalk, javascript or clos lisp. i know that there are people who can dispute something from this list and even claim that all of it is disputable, it is not. you are free to believe whatever you like. there must be some reason why kotlin has functions (not just methods), go is procedural and rust is not like Java.

[PIEBALDconsult]

The problem with smartphones is that they suck out the subject's soul. :sigh:

[Dan Neely]

From the C# side, it feels clunky and verbose and despite having added a few modern features like lambdas overall feels like I'm stuck in C# 1.x. :sigh:

Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt

[obermd]

Going to Java after C# is really tedious, especially for multi-threaded applications.

[BryanFazekas]

Following on with raddevus' points are: 4) Support -- ongoing support is difficult as the Java versions keep changing. Applications that run in "version X update Y" may not run on "update Y+1". And if multiple installed applications require different versions? Getting each to use the right installed version is its own version of DLL Hell. 5) Hiring -- finding people with experience in the needed versions of specific libraries can be tough. If not using the latest and greatest, finding people with experience and a willingness to work in an older version can be all but impossible. Besides, knowing one version of a library may not mean anything in a different version. Java the language? It's just another language. It's got its pluses and minuses, same as every other language. IMO, the serious problems are everything except the language itself. C# has its own issues, but post-deployment it's MUCH easier to support.

[davecasdf]

Hmmph! https://www.flickr.com/photos/awrose/103252765/in/pool-camerawiki ain't it pretty? Story - 35 yrs ago - guy had done some beautiful work and was very proud that the grain was so fine. I said so? I get that smooth out of Tri-X all the time. He goes uh - OH! you're the one with THAT camera!

[Mike Hankey]

Beautiful camera! I love looking at old photos taken with those types of cameras.

The less you need, the more you have. JaxCoder.com

[trønderen]

Leo56 wrote:

What's a 'camera'? Isn't that what smartphones are for?

Obligatory Geek and Poke[^]

[trønderen]

I am very much two-faced about grains. On the one hand, those super-smooth tones from old 4*5" films (or even larger), when the emulsion was stuffed with silver, and not a trace of grain, can be a pleasure to study for their tonal qualities alone. Then, in significant parts of modern B&W photography, graininess is used as an artistic expression, not unlike the 'dottiness' of some impressionist painters. In journalism and sports photography, graininess and hard, 'graphics style' contrast has been a style of expression for at least 50 years. Even in some landscape photography, grains can add structure to a surface that would otherwise be boring (e.g. a misty landscape). My photography books fill two meters of shelf space. In them, I can "in no time" find a hundred photos, from internationally recognized photographers, that would have lost some of their qualities if they were absolutely grain-less and with a smooth, 'natural' tone scale. Fair enough for 'scientific style' documentary photos, but if you want your photo to tell a story, you may need something beyond a simple and boring 'This is exactly how it looks'. It may be true, but So what? Who said "A picture shouldn't show something, it should be something"? In the process of making it "be" something, grains can be a great tool.

[Bruce Patin]

I tried writing an accounting program in Java, but gave up, when I got tired of trying to outwit UI classes that didn't do the job, and having to write factory classes to construct other classes to do the simplest things in the most complicated way.

[davecasdf]

Ah yes, one of far too many "need to spend time with thats". ( And the F-1, A-1... the D2s ( which are 5-7s, the Gundlach is a 4-5 ) and the Bronica - which I got paid for using _almost_ what I paid for it. )

[Cp Coder]

Were you using Swing or JavaFX?

Get me coffee and no one gets hurt!

[sasadler]

As an embedded engineer, I've only worked on one project that had enough memory to support java. The only snark I'd have for Java is the lack of unsigned integers! I will say that my favorite editor is java based (jEdit).

[trønderen]

I grew up with Open Systems Interconnection - communication protocols that are very explicitly designed for being completely independent of any given tool used to generate the protocol elements. One very fundamental protocol principle is that the application, and all lower layers, should relate to the protocol specification, and nothing else. As OSI was pushed into the darkness, it felt like a rope being tightened around my neck: the protocols replacing the OSI ones more or less demanded that you use specific libraries, specific OS conventions, specific languages - or else you would have to emulate those specific libraries, OSs and languages. But that is troublesome, because new extensions were added all the time, and keeping up with the updates to the libraries, OSs and languages in your emulation was almost impossible. Sometimes, the binding to specific tools is not immediately apparent. Take the RFC 4506 serialization format (a.k.a SUN XDR): In my archives from the years of the network wars is a "benchmark" of it against OSI BER (Basic Encoding Rules). XDR beats BER by an high factor. What the benchmark documents keep perfectly quiet about is that XDR is more or less a direct streaming of the binary layout of a C struct on a SUN machine; there is hardly any conversion at all. After generating the red tape, you set that byte pointer to the start of the struct and send the following sizeof(struct) bytes out on the line. (Needless to say, this benchmark was run on a SUN.) I never thought BER would be anywhere as fast as XDR (BER has a lot more flexibility, which can't be realized at zero extra cost). But if you set up a similar benchmark on a non-SUN machine, the serialization cost of XDR might easily raise by a magnitude. Say, if the machine had a different float format. Different byte order. Maybe an old machine wouldn't be byte addressable - my first three university years, I was programming non byte addressable machines exclusively; the Univac even used 1-complement integers, and its proprietary 6-bit character set. (The Decsystem series used 7-bit ASCII, packed 5 to a 36-bit word.) Say, if your language has proper string handling, you will have to explicitly add a C-style terminating NUL at the end (a use of NUL which is in direct conflict the the ASCII / ISO 646 standard). The specification of how to encode a structure is given by how a C declaration of it looks. And so on. This is typical: As long as you use the "proper" machine, the "proper" language, the "proper" OS, you find it very eas

[Rick York]

I saw that tendency in MFC and I never bought into that aspect of it. I try my best to avoid all of its collections and OS synchronization object wrappers and I use STL and write my own wrappers. That lets me leave only the UI for MFC and I actually like how it handles most of that. It's pretty much on life support now so soon I am going to leave it and move on.

"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"

[Member 12982558]

Depends on what you what domain you are working in. I wrote a DAB (digital Aufio Broadcasting) decoder in C++ and simplified versions - just as a programming exercise - in Ada and in java. The type of program of such a decoder requires extensive interaction with libraries written in C (to name a few, device handling, fft transforms, and aac decoding). In my personal opinion, binding java structures to C libraries is a crime. btw the Ada binding is simpler since I was using the Gnat compiler system, but even then ... Java is just a language, it is not my choice, but for many applications it seems more or less OK. Personally I do not like the GUI handling, but that is probably a matter of taste. The misery with binding to non-java (read: C) libraries is such that I would not recommend it for applications where one depends on that kind of libraries (I dislike all kinds of so-called integrated environments such as IntelliJ or whatever, right now I am writing some stuff where I (more or less) have to use VS as development environment. It is probably my ignorance, but I absolutely dislike the destruction of the formats I use in my coding, and the error messages are a horror. For me the command line tools such as vim, qmake, mae and the GCC suite - with gdb as debugger under Linux - are the ideal development tools)

[Member_5893260]

What's wrong with Java is that it's 30 years old or something, and its architecture is a prisoner of what was available at the time: it no longer makes any sense now that richer and more capable systems exist. And it doesn't have properties, which is ridiculous.

[trønderen]

NelsonGoncalves wrote:

I fondly remember discovering that the byte type is signed (why, really why ???)

Since my student days (long ago!) I have been fighting this concept that "inside a computer, everything is a number". No, it isn't! Data are bit patterns, that are bit patterns, and not "zeroes and ones". A type defines which bit patterns are used (on a given machine) to represent various values, such as 'x' or 'y'. They are letters, da**it, no sort of 'numbers'. Similarly, colors are colors. Dog breeds are dog breeds. Weekdays are weekdays. Seasons are seasons. One problem is that computer professionals are among the most fierce defenders of this 'number' concept, arguing that 'A' really is 65 (or, most would prefer 0x41, but still a 'number'). They think it perfectly natural to divide 'o' by two does not give 'c' (as you might think from the graphical image), but '7' -and that is a perfectly valid operation because 'o' is really not a letter but the numeric value 111, and '7' is really 55. Even programmers who have worked with objects and abstractions and abstractions of abstractions still are unable to see a bit pattern as directly representing something that is not numerical. They cannot relate to the bit pattern as a representation of abstract information of arbitrary type, but must go via a numeric interpretation. So we get this idea that an uninterpreted octet (the ISO term, partially accepted even outside ISO), a.k.a an 8 bit 'byte', in spite of its uninterpretedness does have a numeric interpretation, by being signed. I shake my head: How much has the IT world progressed the last three to four decades (i.e. since High Level Languages took over) at all in the direction of a 'scientific discipline'? When we can't even manage abstractions at the octet level, but insist on a numeric interpretation when it isn't, then I think we are quite remote from a science on a solid academic foundation. The bad thing is that we are not making very fast progress. 40+ years ago, you could, in Pascal, declare 'type season = (winter, spring, summer, fall)', and they are not numeric: You cannot divide summer by two to get spring (the way you can in C and lots of its derivates). There is no strong movement among software developers for a proper enumeration, discrete value, concept: We have written so much software that depends on spring+2 being fall. It would created havo

[Slow Eddie]

Haters are going to Hate! No matter what. The VB guys have been living with B.S. for years.:mad:

Wear a mask! Wash your hands too. The life you save might be your own.