Rust is more like Esperanto isn’t it? It’s Latin, but regularized and with the rough edges sanded off.
Python is more like Spanish. A billion speakers in the world, and really easy to pick up a few phrases, but a small European minority still think they run it.
If you think Rust has zero rough edges you might have drunk too much kool aid.
Esperanto is just Spanish pretending to be a neutral language.
Honestly a very bad language. Nothing intuitive or easy about it. It's as well thought out as QWERTY.
RustyRooster: C is the root of all modern languages
FORTRAN: Am I a joke to you?
Fortran is Proto-Indo-Germanic or whatever it's called again
Lisp (specifically IPL) is Proto-Indo-European. All languages have unwittingly taken inspiration from it
No grandpa fortran, everybody loves you. Now let's get you back inside with cobol.
LISP is too old to care any more.
PHP is Russian. Used to be huge, caused lots of problems, now slowly dwindling away. Its supporters keep saying how it's still better than the competition.
Well latin isn't the root of all modern languages
Yes, but "Proto Indo-European" doesn't exactly roll off the tongue. /s
Dravidian?
It isn't even the root of the indo-european languages and the Indo-European languages are just one of many language families around the world.
Source I am from Austria. :)
Exactly. Nobody knows how the tongue was involved in h~2~.
Java, verbose? laughs in Pascal
Python being Esperanto? Yeah, no, because Python is actually being used
Hearing about Esperanto the first time. Hate itwhen someone copies my idea and does it in 1887
This is highly inaccurate:
D: Esperanto. Highly derivative of C (Latin), designed by people previously writing compilers. It's not being taken seriously as such.
Russian is nowadays being speaken by right-wing authoritarians instead, and any programmer that is auth-right is either coding in C/C++, or a Javascript/Python dev pretending to be a C/C++ dev to "gatekeep" nulangs (sic).
Heeeey!!
^^^(snifs ^^^armprit)
...
Fuck....
Argh, politics in IT.
soo...is FORTRAN greek? Or phoenecian?
Id argue that Octave is Greek or at least Egyptian.
In Soviet Russia memory manages you!
What about basic and assembly? Even Pascal?
Yeah I've not done any coding in a while.
Can anyone actually tell what exactly complicated in Java? Verbose, maybe it was at some point but I find it very straightforward and easy.
Java itself is kind of blissful in how restricted and straightforward it is.
Java programs, however, tend to be very large and sprawling code-bases built on even bigger mountains of shared libraries. This is a product of the language's simplicity, the design decisions present in the standard library, and how the Java community chooses to solve problems as a group (e.g. "dependency injection"). This presents a big learning challenge to people encountering Java projects on the job: there's a huge amount of stuff to take in. Were Java a spoken language it would be as if everyone talked in a highly formal and elaborate prose all the time.
People tend to conflate these two learning tasks (language vs practice), lumping it all together as "Java is complicated."
$0.02: Java is the only technology stack where I have encountered a logging plugin designed to filter out common libraries in stack traces. The call depth on J2EE architecture is so incredibly deep at times, this is almost essential to make sense of errors in any reasonable amount of time. JavaScript, Python, PHP, Go, Rust, ASP, C++, C#, every other language and framework I have used professionally has had a much shallower call stack by comparison. IMO, this is a direct consequence of the sheer volume of code present in professional Java solutions, and the complexity that Java engineers must learn to handle.
Some articles showing the knock-on effects of this phenomenon:
Its standard library reads like someone's Object Oriented Programming 101 final project, and they probably got a B- for it. Everything works and follows OO principles, but they didn't stop to think about how it's actually going to be used.
Let's try to read a file line-by-line:
BufferedReader reader = new BufferedReader(new FileReader("sample.txt"));
String line = reader.readLine();
We're having to instantiate two objects (FileReader and then BufferedReader) just to get an object that has a readLine() method. Why? Can't BufferedReader take a file name on its own and work it out? Or FileReader just provides readLine() itself?
Not only that, but being parsimonious with what we import would result in:
import java.io.BufferedReader;
import java.io.FileReader;
But we're much more likely to be lazy and import everything with import java.io.*;. Which is sloppy, but I understand.
I can see what they were thinking when separating these concerns, but it resulted in more complexity than necessary.
There's a concept of "Huffman Coding" in language design. The term itself comes from data compression, but it can be generalized to mean that things you do often in a programming language should be short and easy. The above is not good Huffman Coding.
Library built this way because it supposed to be flexible and provide ground for complex usecases. It can only be flexible if your API works with simple abstractions which you can then compose. It’s not driven by “I need this specific utility for this specific scenario”. That would be zoo you have in JS where you have 10 ways to iterate over array and 9 of them wrong for your scenario.
Java’s OO is great because they design library with SRP in mind making sure there is few but good ways to do things.
BufferedReader cannot accept file name because it makes arbitrary reader… well buffered. It’s not BufferedFileReader, even that would accept something like Path or File, not string, because File can be remote file, should Reader now know all possible local and remote protocols and path formats? What else it must do?
Having it designed the way it is, allows Java to have utilities for various scenarios. Your scenario covered by standard lib too. See Files.readAllLines which, surprise-surprise, built on top of BufferedReader.
Library built this way because it supposed to be flexible and provide ground for complex usecases.
It’s definitely that, and not the fact that it was written in the first half of the nineties when everyone and their mother was all in on OOP/OOD to the detriment of usability.
BufferedReader cannot accept file name because it makes arbitrary reader… well buffered. It’s not BufferedFileReader, even that would accept something like Path or File, not string, because File can be remote file, should Reader now know all possible local and remote protocols and path formats? What else it must do?
You're just describing the problem. Yes, I see where they're going with this. It's still a usability nightmare. I can't think of another language that makes you jump through hoops like this on IO, and they get along fine without it.
I agree with you. It's a neat design idea to make things a bit more maintainable perhaps, but it's just annoying to program with.
I think a lot of it is "ceremony", so it's pretty common in java to:
Then add on top that you have the increased code of type annotations PLUS the increased code of having to check if a value is null all the time because all types are nullable.
None of that is hugely complicated compared to sone of the concepts in say Rust, but it does lead to a codebase with a lot more lines of code than you'd see in other similar languages.
Rust is esperanto because its only actually used by a small group of nerds,
python is russian because everything made in it is unreliable.
Haskell is Esperanto. The difference being that Rust is actually catching on.
It fits, English and JavaScript are both three languages in a trench coat.
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.