What's wrong with Java?
-
Nikon is unusable. Pentax is the only true path.
-
I worked with a customer who implemented a serious, corporate-wide Manufacturing Control System using Java. I worked with them on systems at four sites - San Jose, CA; Szenzhen, China; Mainz, Germany; and a place in Thailand I have forgotten the name of. The MCS was used with Windows, AIX, Linux, MacOS, and a few others I can't remember. We used sockets as our interface and there were no problems with it all. I don't even know what OS the systems we directly interfaced with ran on because we didn't need to. That was a few employers ago so I have forgotten some details now. The systems were used in the manufacturing of disk drives and dealt with making the disks themselves. Assembly happened at other sites and we did a few of those systems too.
"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?"
-
I don't understand the snarky comments one sees about Java. :confused: I am well versed in programming both in C# (Visual Studio 2019) and JavaFx (IntelliJ IDE). I enjoy both equally. There must be something wrong with me! :sigh: :laugh:
Get me coffee and no one gets hurt!
Nothing really, as long as you remain inside its walled garden. I had a few interactions with Java, all of them ending in pain and tears because at some point I needed step out of the Virtual Machine. I fondly remember discovering that the byte type is signed (why, really why ???) and spending a few days debugging my hardware to figure out in the end that Java was to blame. Or the magical moment when one of the gazilion DLLs needed by an over engineered project had a bug. I simply fixed the bug and recompiled the source and build the DLL again. Something none of the over Java experts were even aware it was possible. And of course, how can I forget when I relied on the Java standard String library only to find out that the target where the program ran had an incomplete (but still announced as 100% compatible) implementation of that library. What can be more fun than writing your own standard library functions ? A bit more serious, there is nothing wrong with Java. It is widely used, and in most cases it is good enough. I was just an unfortunate victim of the attempt to using Java in the embedded world, where it most definitively is not right an appropriate tool.
-
Uuuhhh... I have no lenses younger than about twenty years -- and some closer to seventy. My latest camera purchase is a Kodak Vigilant Six-20 (circa 1940). Lately I've been playing with a 4x5 monorail camera from the '60s. I say again, Nikon is unusable -- except maybe by wrong-handed practitioners (like my brother). Having said that, Nikon does make good point-and-shoot cameras, my wife is on her third.
-
I don't understand the snarky comments one sees about Java. :confused: I am well versed in programming both in C# (Visual Studio 2019) and JavaFx (IntelliJ IDE). I enjoy both equally. There must be something wrong with me! :sigh: :laugh:
Get me coffee and no one gets hurt!
It is your view because you are a programmer, ask Ops. As mentioned above, versioning. Tell me another software with so many different version number referencing the same thing. Versioning 2.0 : Have you found your version number? Then here is another error message for you: class can not be loaded because it is version 52 but your JVM supports only up to version 51. Well, disk space was cheap THEN, so maybe it was not an issue that a 4th digit upgrade installed the full thing in a new directory. Or at least it was not a problem till someone set the JAVA_HOME to one of them, and yum removed the other one... The usual Java software customizable to an amazing degree via command line switches and config files, but very slow to start up, because it has to read all those small XML files. Config 2.0: The main selling point of one commercial Tomcat clone is that you don't have to hunt tens of config files to set up the thing.
-
I don't understand the snarky comments one sees about Java. :confused: I am well versed in programming both in C# (Visual Studio 2019) and JavaFx (IntelliJ IDE). I enjoy both equally. There must be something wrong with me! :sigh: :laugh:
Get me coffee and no one gets hurt!
Quote:
I don't understand the snarky comments one sees about Java. Confused | :confused:
Because language-hating on $OLD_AND_STABLE_LANGUAGE is currently fashionable. FCOL, 3 years ago I was reading commenters on reddit asking "Why would anyone in their right mind start a new project in C when Rust is available?". In that time, however, Rust changed so much that it is slightly incompatible. My observation is that, feature-wise, all languages converge towards Lisp, while syntax-wise, all languages converge towards C++ (which itself is, syntax-wise, already past the madness event-horizon and still accelerating). Java (and C#) when initially released were fairly easy to read for anyone coming from almost any existing language (C, PHP, Perl, etc). Each feature added, added to the syntax instead of replacing existing grammar (so they didn't break existing programs), leading to the situation now where a symbol may mean almost anything. I look forward to a future where source code looks more like BF than like Pascal /s ...
-
I don't understand the snarky comments one sees about Java. :confused: I am well versed in programming both in C# (Visual Studio 2019) and JavaFx (IntelliJ IDE). I enjoy both equally. There must be something wrong with me! :sigh: :laugh:
Get me coffee and no one gets hurt!
i personally dislike javans because they look down on other people. that is something you haven't noticed because you were on "the winning" team, java and oop. haven't you heard jokes about perl, c and javascript in the last 20 years? it's a personal feeling you get that you cannot describe to others. it's subjective. let me try to put a lighte on it by using this totally unrelated article: [Linux Mint users are surprisingly irresponsible regarding updates](https://betanews.com/2021/02/20/linux-mint-irresponsible-users-updates/) who is this guy telling other people how to use their computers? now imagine this fairy tail rewriten to fit java propaganda from 10 years ago (now javans start to taste the truth that perl and javascript were vastly more powerful than java since inception and the only thing java's got is the story of oop) that everyone is irresponsible by using languages like c, tcl, javascript... any other language usage than java is irresponsible. who needs all those obsolete languages and why are they not facing the inevitable, that there should and will be only java and oop. all this without any real reason for javans to look down upon others. java was never a better c++ as it was advertised. it may be better for some people, but not for others. "Java owes much of its initial popularity to the most intense marketing campaign ever mounted for a programming language." - Bjarne Stroustrup and in that campaign advocates of java were visiting corporations telling people bad things about c++ and what not about c or other languages. every now and then an article would pop up, like "why the c language refuses to die?!" and why is it now difficult to understand that some people want revenge? even if we have to change java with something more bizarre like a purely functional dictatorship static typed language that looks down on java and everybody else at the same time. that's so lame. here is an article from java oop programmer [Execution in the Kingdom of Nouns](http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html) here is a lisp programmer [Why Lisp? | Hacker News](https://news.ycombinator.com/item?id=9507085) notice the: "A Lisp programmer who notices a common pattern in their code can write a macro to give themselves a source-level abstraction of that pattern. A Java programmer who notices the same pattern has to convince Sun that this particular abstraction is worth adding to the language" same works for c, "These languages [Java] solve problems
-
Nothing really, as long as you remain inside its walled garden. I had a few interactions with Java, all of them ending in pain and tears because at some point I needed step out of the Virtual Machine. I fondly remember discovering that the byte type is signed (why, really why ???) and spending a few days debugging my hardware to figure out in the end that Java was to blame. Or the magical moment when one of the gazilion DLLs needed by an over engineered project had a bug. I simply fixed the bug and recompiled the source and build the DLL again. Something none of the over Java experts were even aware it was possible. And of course, how can I forget when I relied on the Java standard String library only to find out that the target where the program ran had an incomplete (but still announced as 100% compatible) implementation of that library. What can be more fun than writing your own standard library functions ? A bit more serious, there is nothing wrong with Java. It is widely used, and in most cases it is good enough. I was just an unfortunate victim of the attempt to using Java in the embedded world, where it most definitively is not right an appropriate tool.
Quote:
I fondly remember discovering that the byte type is signed (why, really why ???)
I know the answer to this one: it's because the representation of signed integers is specified (as two's complement), so there is no problem with bit-shifting (or other bit operations) them as there is with bit-shifting signed numbers in C++ (which doesn't specify the integer representation). In C++, for example, you cannot write this (to check if variable 'a' overflowed):
if (a + 1 < a) { ... }
and expect it to work on all conforming compilers because there is no guarantee that the underlying representation uses twos-complement. In Java the representation is guaranteed to be twos complement. In C++, the result of:
a = b >> 3;
Is undefined if 'b' is signed. In java it's defined (right-shift twos-complement). Sure, those are shitty reasons to leave out unsigned types, but they're still reasons. The only place you're likely to run into problems is when trying to add two signed 64-bit numbers that overflow the signed 64-bit type.
-
i personally dislike javans because they look down on other people. that is something you haven't noticed because you were on "the winning" team, java and oop. haven't you heard jokes about perl, c and javascript in the last 20 years? it's a personal feeling you get that you cannot describe to others. it's subjective. let me try to put a lighte on it by using this totally unrelated article: [Linux Mint users are surprisingly irresponsible regarding updates](https://betanews.com/2021/02/20/linux-mint-irresponsible-users-updates/) who is this guy telling other people how to use their computers? now imagine this fairy tail rewriten to fit java propaganda from 10 years ago (now javans start to taste the truth that perl and javascript were vastly more powerful than java since inception and the only thing java's got is the story of oop) that everyone is irresponsible by using languages like c, tcl, javascript... any other language usage than java is irresponsible. who needs all those obsolete languages and why are they not facing the inevitable, that there should and will be only java and oop. all this without any real reason for javans to look down upon others. java was never a better c++ as it was advertised. it may be better for some people, but not for others. "Java owes much of its initial popularity to the most intense marketing campaign ever mounted for a programming language." - Bjarne Stroustrup and in that campaign advocates of java were visiting corporations telling people bad things about c++ and what not about c or other languages. every now and then an article would pop up, like "why the c language refuses to die?!" and why is it now difficult to understand that some people want revenge? even if we have to change java with something more bizarre like a purely functional dictatorship static typed language that looks down on java and everybody else at the same time. that's so lame. here is an article from java oop programmer [Execution in the Kingdom of Nouns](http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html) here is a lisp programmer [Why Lisp? | Hacker News](https://news.ycombinator.com/item?id=9507085) notice the: "A Lisp programmer who notices a common pattern in their code can write a macro to give themselves a source-level abstraction of that pattern. A Java programmer who notices the same pattern has to convince Sun that this particular abstraction is worth adding to the language" same works for c, "These languages [Java] solve problems
Quote:
i have a particular bookmarked folder for every anti-class based-oop post i have stomp upon written by people who by my opinion have competent or expert skills at programming including oop.
Maybe you should share that ;-)
-
Quote:
I fondly remember discovering that the byte type is signed (why, really why ???)
I know the answer to this one: it's because the representation of signed integers is specified (as two's complement), so there is no problem with bit-shifting (or other bit operations) them as there is with bit-shifting signed numbers in C++ (which doesn't specify the integer representation). In C++, for example, you cannot write this (to check if variable 'a' overflowed):
if (a + 1 < a) { ... }
and expect it to work on all conforming compilers because there is no guarantee that the underlying representation uses twos-complement. In Java the representation is guaranteed to be twos complement. In C++, the result of:
a = b >> 3;
Is undefined if 'b' is signed. In java it's defined (right-shift twos-complement). Sure, those are shitty reasons to leave out unsigned types, but they're still reasons. The only place you're likely to run into problems is when trying to add two signed 64-bit numbers that overflow the signed 64-bit type.
Thanks for the explanation.
Member 13301679 wrote:
Sure, those are sh*tty reasons to leave out unsigned types, but they're still reasons. The only place you're likely to run into problems is when trying to add two signed 64-bit numbers that overflow the signed 64-bit type.
I am OK with the design decisions made, the issue there was conflicting expectations. The Java language designers choose to treat bytes as signed integers, while in the embedded world a byte is simply a string of 8 bits and endianess. In my case, the problem wasn't math but reading data from a serial port. I was getting "garbage" until my colleagues told me that in Java bytes are signed.
-
In (very) special cases: Sure. In those cases, you might as well go to assembly language. I learned 30+ years ago that trying to outsmart an optimizing compiler is futile. In my student days, we thought it crazy to write an OS in a "high" level language - but Unix did succeed, and performance was not an issue. So we abandoned assembly. Not entirely; there are cases for assembly because that is the only possible way to get access to certain hardware functions. But going assembly for performance reasons has no place in the third millennium. Today, the same goes for memory. It is almost as difficult to outsmart automatic memory management by "clever" use of malloc/free as to outsmart a compiler - in particular because you have no insight in actual memory fragmentation. The risk of memory leaks is much larger; too many programmers do not master their own memory use as well as they believe (or, they are not enforcing the programming discipline as they should). Again: There are (very) extreme cases where the cost of garbage collection is unacceptable. Usually, memory fragmentation is then unacceptable as well. So you manage your objects e.g. in a static array, dimensioned for a worst case. (I was programming one such C solution - malloc was not accepted by our coding standards. C++ new would have been rejected as well, so the case for C++ was not very strong.) Analogy: When I talk with extreme HiFi buffs, I must admit that 24 bit samples at 96 kHz does have its place, in a professional studio where a sound recording may go through many generations of various processing, mixing etc. for an end result of unknown sample width and frequency. But that is is the studio. It doesn't mean that the music I listen to on my stereo benefits from being in 96/24 format. Similarly: If you write a physical level driver for a 10 Gbps network interface, you probably cannot tolerate GC delays. But for 99.999% of all code written, GC without memory leaks is a lot better than dubious "private" memory management.
Quote:
I learned 30+ years ago that trying to outsmart an optimizing compiler is futile.
Indoctrination. Processors have been built to prove this point for a long time. Cache penalties, pipeline penalties, millions of addressing modes... Just take a true RISC processor and you are rid of most of that. Now a child can be just as good as the compiler, leaving only the thing that compilers are notoriously bad at and that's choosing the algorithm.
trønderen wrote:
But for 99.999% of all code written, GC without memory leaks is a lot better than dubious "private" memory management.
Maybe, but developers who run into such a problem and know nothing about memory management are helpless 100% of the time. Watching 'team leaders', 'architects' and who knows what other titles they had given themselves camp around a server and trying magical chanting and sacrificing virgins to fix a memory overflow is a sad sight. But I was able to motivate them with lots of good natured humor, which they took as biting sarcasm.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
Thanks for the explanation.
Member 13301679 wrote:
Sure, those are sh*tty reasons to leave out unsigned types, but they're still reasons. The only place you're likely to run into problems is when trying to add two signed 64-bit numbers that overflow the signed 64-bit type.
I am OK with the design decisions made, the issue there was conflicting expectations. The Java language designers choose to treat bytes as signed integers, while in the embedded world a byte is simply a string of 8 bits and endianess. In my case, the problem wasn't math but reading data from a serial port. I was getting "garbage" until my colleagues told me that in Java bytes are signed.
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.
-
Quote:
i have a particular bookmarked folder for every anti-class based-oop post i have stomp upon written by people who by my opinion have competent or expert skills at programming including oop.
Maybe you should share that ;-)
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.
-
What's a 'camera'? Isn't that what smartphones are for? How else to instantly upload to that other essential invention ... social media? ;P
The problem with smartphones is that they suck out the subject's soul. :sigh:
-
I don't understand the snarky comments one sees about Java. :confused: I am well versed in programming both in C# (Visual Studio 2019) and JavaFx (IntelliJ IDE). I enjoy both equally. There must be something wrong with me! :sigh: :laugh:
Get me coffee and no one gets hurt!
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
-
I don't understand the snarky comments one sees about Java. :confused: I am well versed in programming both in C# (Visual Studio 2019) and JavaFx (IntelliJ IDE). I enjoy both equally. There must be something wrong with me! :sigh: :laugh:
Get me coffee and no one gets hurt!
-
There are two main issues to me: 1) versioning -- difficult to know which version to run and what functionality I will have -- this is especially after Oracle took over and then it split even more with the OpenJDK and all that nonsense. It's quite difficult. Along with versioning it is difficult to find tools that feel like they are "official". For instance, I am attempting to use JCov (java coverage tool) and it is supposed to be the "official" but very poorly or not documented at all. 2) UI Framework - Oh boy. I remember the original was something like AWT, right? Then JavaFX (but never caught on fully). 3rd party stuff, and controls that are instantly recognizable that they weren't Windows controls. It was all so confusing and there were better options (C#, Visual Studio and MFC, etc). 3) Java Applets they used applets to introduce Java and it was supposed to be gee-whiz. I was like, "a plugin...?? that fails a lot in my browser...?? and needs to be updated constantly...??? which MS doesn't like to support ???" That intro to Java kind of killed it. After that it felt like a slow cumbersome thing with no direct line to components without lots of management. So, over to C#, which was easy. Much of this isn't "fair" to Java, but it is the perception.
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.
-
Nay brother let me lead you to the true path of enlightenment. Nikon shall set you free and with your purchase of a new lens you shall receive the blessing of the shutter gods.
The less you need, the more you have. JaxCoder.com
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!
-
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!
Beautiful camera! I love looking at old photos taken with those types of cameras.
The less you need, the more you have. JaxCoder.com
-
What's a 'camera'? Isn't that what smartphones are for? How else to instantly upload to that other essential invention ... social media? ;P
