- vzq ( @vzq@lemmy.blahaj.zone ) 2•3 hours ago
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.
- geneva_convenience ( @geneva_convenience@lemmy.ml ) 1•3 hours ago
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.
- NotAnOnionAtAll ( @NotAnonymousAtAll@feddit.org ) 4•6 hours ago
RustyRooster: C is the root of all modern languages
FORTRAN: Am I a joke to you?
- Gsus4 ( @Gsus4@mander.xyz ) 1•5 hours ago
soo…is FORTRAN greek? Or phoenecian?
- vga ( @vga@sopuli.xyz ) 23•12 hours ago
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.
- S_H_K ( @S_H_K@lemmy.dbzer0.com ) 13•12 hours ago
Heeeey!!
^^^(snifs ^^^armprit)
…
Fuck… - I Cast Fist ( @ICastFist@programming.dev ) 13•12 hours ago
Java, verbose? laughs in Pascal
Python being Esperanto? Yeah, no, because Python is actually being used
- mexicancartel ( @mexicancartel@lemmy.dbzer0.com ) English12•12 hours ago
Well latin isn’t the root of all modern languages
- mexicancartel ( @mexicancartel@lemmy.dbzer0.com ) English9•12 hours ago
Hearing about Esperanto the first time. Hate itwhen someone copies my idea and does it in 1887
- MonkderVierte ( @MonkderVierte@lemmy.ml ) 13•14 hours ago
Argh, politics in IT.
- panzo ( @panzo@lemy.lol ) 11•16 hours ago
Assembly is Turk, started everything.
- sexual_tomato ( @sexual_tomato@lemmy.dbzer0.com ) 3•11 hours ago
Assembly is proto-indo-european
- _brian ( @_brian@programming.dev ) 2•12 hours ago
i’m in this photo and i don’t like it
- Lysergid ( @Lysergid@lemmy.ml ) 12•17 hours ago
Can anyone actually tell what exactly complicated in Java? Verbose, maybe it was at some point but I find it very straightforward and easy.
- frezik ( @frezik@midwest.social ) 8•12 hours ago
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 thenBufferedReader
) just to get an object that has areadLine()
method. Why? Can’tBufferedReader
take a file name on its own and work it out? OrFileReader
just providesreadLine()
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.
- Lysergid ( @Lysergid@lemmy.ml ) 3•10 hours ago
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.
- vzq ( @vzq@lemmy.blahaj.zone ) 1•3 hours ago
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.
- frezik ( @frezik@midwest.social ) 2•10 hours ago
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.
- PlexSheep ( @PlexSheep@infosec.pub ) 1•6 hours ago
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.
- houseofleft ( @houseofleft@slrpnk.net ) English7•14 hours ago
I think a lot of it is “ceremony”, so it’s pretty common in java to:
- create a get method for every object variable
- create a set method for every object variable
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.
- houseofleft ( @houseofleft@slrpnk.net ) English4•14 hours ago
Before someone says it, I know a lot of this stuff doesn’t need to be done. I’m just giving it as examples for why Java has the rep it does.
- beveradb ( @beveradb@lemm.ee ) 4•17 hours ago
Char count for same functionality is still at least double in java vs python. It just feels like a chore to me. jetbrains helped, but still python is just so light
- Lysergid ( @Lysergid@lemmy.ml ) 6•17 hours ago
Char count is poor complexity metric. Perl is better than Python with your logic as it is more condensed.
- bricklove ( @bricklove@midwest.social ) English29•21 hours ago
In Soviet Russia memory manages you!
- Birbatron ( @Birbatron@slrpnk.net ) 39•1 day ago
the root of all modern languages
the whole universe used to speak it
uhhhhhhhhhhhhhhhhhhhh
P.S: the closest thing to that is Egyptian, but not the language, the Alphabet (the Symbols, not a literal alphabet). Tons of alphabets are descended from Egyptian, including, but not limited to: Greek (and by Proxy Latin, Cyrillic, Georgian, Armenian, Armenian and Armenian (I just noticed this, I’m leaving it in because it’s funny)), Arabic (and by proxy- I won’t list all that), Hebrew, and Aramaic (and by proxy all Indian languages but one, as well as Tibetan, Phags-pa mongol (and by proxy exactly 5 letters of Hangul), Thai, Lao, Sundanese, and Javanese). There’s a lot of dead languages that used scripts derived from Egyptian too but I didn’t mention them because I’d be here all day listing stuff like Sogdian or Norse Runes.
- CanadaPlus ( @CanadaPlus@lemmy.sdf.org ) 1•6 hours ago
The whole (Mediterranean) universe.
- Wiz ( @Wiz@midwest.social ) English16•23 hours ago
Ackshully, Clojure is Esperanto, and I will not be taking questions at this time.