4 ms·

>It's more like starting paragraphs with ">" here. It's a full word, not a single letter operator. Its uses add up to noise pretty fast. >Java likes putting c

>It's more like starting paragraphs with ">" here. It's a full word, not a single letter operator. Its uses add up to noise pretty fast. >Java likes putting context locally How much 'non-local' would a bunch of declarations become if you factor out a common modifier and hoist it just a few lines above them? is your screen real estate situation really that desperate you can't afford a single new line? >Except it doesn't. I literally just don't look at it if I don't care. I have a feeling we won't reach a productive understanding about this, you don't seem to realize that I'm not talking about conscious control. Your brain have an amazing ability to filter out conversations, you can talk to your friend in the middle of a 10000-person company and still be heard loud and clear. Even with this capability, do you like your conversations to always be in the middle of 10000-person groups or in quiet cafés? >unlike your username being repeated, it's actual information, a different value for each line By this argument why write functions then or generics or really any abstraction at all? Every function invocation or generic instantiation is unique and contains novel information, so why not write the whole thing each time for extra readability? If there is no value in factoring out the repeated boilerplate that doesn't change much why aren't we all itching software ALU-control-signal by ALU-control-signal? >Not quite "currently" as of Primitive Objects I'm indeed aware of that, that's why I said 'currently' meaning the current stable release. This won't break my scheme too because those are full-blown objects that are part of the usual class hierarchy and could be manipulated as such, so they are covered by the generic_for_object version. There is another separate proposal to make the boxing of primitives use primitive objects so as to make it as performant as naked primitives and fix the 25-years-old stupid rookie mistake in the language design. This still wouldn't make HashMap<float, bool> legal, it would just make the boxed version more performant. Basically, you would still be left with a small ugly hole in the language where special-cases are introduced just for fun. Because severing the type system into primitives and classes at the language level was never a good idea. >An existing, pre-generics library has "void setProperties(HashMap map);". You want to pass a "HashMap<String,String>" to it. So you do, and it works The autogen solution isn't contradicting the boxing approach, if you absolutely need to use this function, just declare your HashMap to be of <Integer, Integer> instead of <int, int>. The advantage is that you don't need to most of the time, the generated class would still be there for you when you need the performance and have modern libraries to match. >People can like multiple languages. Especially different languages for doing different things. Sure thing, but Java is out-designed by nearly every serious language made after 2000, and most languages made after 1980. Even its niche is overflowing with superior competitors, so I don't understand why you would like it when everything good minus everything bad in it is offered by languages that fill its exact niche. >nice performance, trivial memory management [...], is portable, That's the praises of the JVM being sung here, not java the language. >simple both in terms of language complexity and usage Java is anything but simple, you're literally commenting on a thread discussing how the designers broke the type system by accident. One designer is on record saying that adding constraints to generics (<T implements some_interface>) made contributing to java compilers require too many PhDs. In terms of usage, Java frameworks are some of the most bloated lovecraftian horrors I have ever seen in my life, countless meaningless configuration here and there with no obvious ryhme or reason why this goes there. That's obviously just a single experience, but I have seen it echoed too many times to not be convinced it captures some underlying truth. >is OOP enough Aped it without understanding from smalltalk (through objective C) and couldn't even do it right. >will have libraries when you need them. Again, a feature of the JVM. A compiled .class knows nothing about Java or any other language it happened to come from.

dzaima 5y ago
> It's a full word, not a single letter operator. Its uses add up to noise pretty fast. But it's still 1) a different color; 2) always in the same place (along with static/final). For me to call something "noise", it must be unpredictable, or otherwise hard to avoid. A thing consistently at the start of each line and in a different color is very easy to avoid. > is your screen real estate situation really that desperate you can't afford a single new line? It's not screen real estate, it's how much effort you have to put in to find something. In Java, to find whether a thing is public, I have to just look left a bit. In C++, I have to scan multiple lines upwards for a 'public:' or 'private:'. (but vertical screen real estate is indeed a ton more expensive than horizontal) > Your brain have an amazing ability to filter out conversations My whole point is that the filtering is extremely trivial. Not as trivial as ignoring whitespace at the starts of lines, sure, but still very much not a problem, at all. > By this argument why write functions then or generics or really any abstraction at all? Every function invocation or generic instantiation is unique and contains novel information, so why not write the whole thing each time for extra readability? That information is both very trivially derived, and not that much more useful than the parts. A single type annotation, however, can save a long time on trying to track down what even you're working with. Arbitrary expressions are much more complex, requiring you to either need to use the IDE to assist in understanding (and I can surely scan plain text much faster than any doing interaction with an IDE), or have read & understood much of the preceding/surrounding code to be able to infer the types of things. > Because severing the type system into primitives and classes at the language level was never a good idea. Actually, I prefer them being separated. But that's the performance-wanting part of me, not the language-design one. If done well (which java of course hasn't), it allows for a bunch of trivially achievable performance improvements, and shouldn't complicate usage. (C# has that with class vs struct, but I don't know enough to comment on how easy they are to use) > That's the praises of the JVM being sung here, not java the language. Not every language can performantly map to the JVM though. And, given that the JVM was made for Java, I think it's very fair to praise java for good things about it. End result is the same. > <T implements some_interface> ok yeah those are rough, with all the different variations that exist. But luckily they're used very infrequently, and are nevertheless not that hard to understand in practice. > Java frameworks are some of the most bloated lovecraftian horrors I have ever seen in my life Even with those around (and oh boy are they), there are plenty of actually good frameworks/libraries too. > Again, a feature of the JVM. A compiled .class knows nothing about Java or any other language it happened to come from. I usually prefer source code as documentation over actual documentation, so the library source being in the same language that I'm writing is very valuable to me.

dzaima 5y ago

> It's a full word, not a single letter operator. Its uses add up to noise pretty fast. But it's still 1) a different color; 2) always in the same place (along with static/final). For me to call something "noise", it must be unpredictable, or otherwise hard to avoid. A thing consistently at the start of each line and in a different color is very easy to avoid. > is your screen real estate situation really that desperate you can't afford a single new line? It's not screen real estate, it's how much effort you have to put in to find something. In Java, to find whether a thing is public, I have to just look left a bit. In C++, I have to scan multiple lines upwards for a 'public:' or 'private:'. (but vertical screen real estate is indeed a ton more expensive than horizontal) > Your brain have an amazing ability to filter out conversations My whole point is that the filtering is extremely trivial. Not as trivial as ignoring whitespace at the starts of lines, sure, but still very much not a problem, at all. > By this argument why write functions then or generics or really any abstraction at all? Every function invocation or generic instantiation is unique and contains novel information, so why not write the whole thing each time for extra readability? That information is both very trivially derived, and not that much more useful than the parts. A single type annotation, however, can save a long time on trying to track down what even you're working with. Arbitrary expressions are much more complex, requiring you to either need to use the IDE to assist in understanding (and I can surely scan plain text much faster than any doing interaction with an IDE), or have read & understood much of the preceding/surrounding code to be able to infer the types of things. > Because severing the type system into primitives and classes at the language level was never a good idea. Actually, I prefer them being separated. But that's the performance-wanting part of me, not the language-design one. If done well (which java of course hasn't), it allows for a bunch of trivially achievable performance improvements, and shouldn't complicate usage. (C# has that with class vs struct, but I don't know enough to comment on how easy they are to use) > That's the praises of the JVM being sung here, not java the language. Not every language can performantly map to the JVM though. And, given that the JVM was made for Java, I think it's very fair to praise java for good things about it. End result is the same. > <T implements some_interface> ok yeah those are rough, with all the different variations that exist. But luckily they're used very infrequently, and are nevertheless not that hard to understand in practice. > Java frameworks are some of the most bloated lovecraftian horrors I have ever seen in my life Even with those around (and oh boy are they), there are plenty of actually good frameworks/libraries too. > Again, a feature of the JVM. A compiled .class knows nothing about Java or any other language it happened to come from. I usually prefer source code as documentation over actual documentation, so the library source being in the same language that I'm writing is very valuable to me.