3 ms·

Hah. I’ve spent several years writing javascript for a living. You can always tell when code was written by someone who’s arrived fresh from Java or C++. Their

Hah. I’ve spent several years writing javascript for a living. You can always tell when code was written by someone who’s arrived fresh from Java or C++. Their code is full of hundreds of lines of useless classes which can often be replaced by a few simple object literals. Unlike class instances, object literals can be easily json stringified and parsed, too! You can torture people who are like this in code review: “This isn’t idiomatic. Please rewrite this code without the class keyword”. I’ve seen people people make a face like I just had their child expelled from kindergarten. I don’t know any good resources unfortunately. I feel like we need a “motherfuckingwebsite” equivalent for this - “just use a motherfucking function”. I want to link it to whoever insisted on adding a useless TextDecoder class in javascript that you have to instantiate, instead of just calling textDecode(…, “utf8”) using a global function like the rest of the standard library. I think part of the problem is that most people who hate enterprise java just learn a different language, set their resume on fire and start over somewhere better. That’s certainly what I did. I’m writing rust at the moment, and thankfully the lack of classes and distance from the JVM seems to keep most of this nonsense out. But having all the doubters leave makes the problem within the java ecosystem worse.

polotics 3y ago
Word! I just left a Java-only shop for pythonic pastures and the culture is so much more pragmatic and to-the-point. Hopefully soon enough ML models can be fed millions of line of code and produce the functionally equivalent thousands...
- klibertp 3y ago
  They're trained on billions of lines of code - most of them are not very good. I'm using Copilot, and the docstring/docs it suggests are so bad it hurts. If left alone, Copilot would happily generate those thousands of lines instead of helping reduce them to hundreds. It's still useful if given enough direction, but you need to be really careful not to overuse it or risk getting mistaken for a junior straight out of a bootcamp during code review :)
  - tracker1 3y ago
    Yeah... I've noticed about half of what it comes up with needs tweaking... I really enjoyed it for SQL schema writing though... especially many-many table creation.
raverbashing 3y ago
> “This isn’t idiomatic. Please rewrite this code without the class keyword”. I’ve seen people people make a face like I just had their child expelled from kindergarten. Lol true Don't forget all the getters and setters merely updating/reading a variable Python says "explicit is better than implicit" but Java goes too far with it, and in the most verbose/inflexible ways possible
- Izkata 3y ago
  > Don't forget all the getters and setters merely updating/reading a variable > and in the most verbose/inflexible ways possible It's actually extra flexibility meant for two things: being able to override the getter/setter in a subclass, and keeping a consistent interface so users don't need to change how it's called if there was a refactor that adds something to the getter/setter (such as transforming the value because a different representation was more useful internally; particularly useful for libraries). Python has @property to maintain that interface if need be, but these Java conventions started when no such thing existed in the language. I haven't done Java in a long time, so I don't know if it has it even now..
  - klibertp 3y ago
    > these Java conventions started when no such thing existed in the language. Is there language support for these in the newer Java versions (I'm not up to date with newer features, since I won't be able to use them on Android anyway)? The reason for these getters/setters is as you said: a workaround for the language deficiencies. It's true for quite a few patterns, and it's not unique to Java; you get similar (in nature) patterns emerging in all languages. Greenspun's tenth rule and all that. What's problematic is porting these workarounds wholesale to languages that don't have the limitations that originally led to their creation. In Kotlin, for example, every property has an implicit getter and setter, by default - you can override either easily with a dedicated syntax. In that case, insisting on writing explicit methods for getters and setters is simply a misuse of the language. Same in Python, as you note, where you can replace direct access to object attribute with a property without changing the user-facing interface of a class. I think JS also developed a feature like this? It's kind of impressive the OO languages managed to get this so wrong for so long, even though Smalltalk got it right in the 70s...
jcranmer 3y ago
> I want to link it to whoever insisted on adding a useless TextDecoder class in javascript that you have to instantiate, instead of just calling textDecode(…, “utf8”) using a global function like the rest of the standard library. I for one would rather punch the person who proposes such a global function as the only mechanism for conversion, because charset conversion is a reasonable thing to do on chunked partial inputs, and maintaining the state for conversion yourself is actually quite painful. Wrapping a stream converter into a one-shot function is much easier than the reverse, wrapping a one-shot function in a stream converter.
- klibertp 3y ago
  You can have the global function and make it work on "chunked partial inputs" while maintaining the state between calls (that state can be hidden in a closure or made explicit as an argument or a receiver - functions in JS can be called on objects even if they were defined outside of them). The very bad example of this is C's `strtok`, but it's pretty typical for JS to encapsulate the state in a closure to get similar functionality. Said another way: the functional, simplified interface doesn't mean you have to get simplified or lacking functionality. Haskell wouldn't exist if that was the case. The simplified interface providing as much functionality as the more complex interface is possible because the expressive power of JS is leagues above Java - porting Java patterns that emerged due to Java's shortcomings (some call them "design decisions", and they're also right) to JavaScript is simply not a good use of JS as a language.
- replygirl 3y ago
  This is what GP is talking about. Chunking can be done cleanly with very few internal functions (and without changing the call signature, if you want), but you're implying it must be a class and already thinking about hypothetical hacks
- tracker1 3y ago
  It wouldn't need to be a global, it could be mounted on String for example... And one doesn't necessarily prevent the other. String.fromUint8Array: (input: Uint8Array, encoding: string): String; Would be a fine, simple addition where it probably should be. Maybe calling the default for UInt8Array "String.fromBinary" instead.
_ea1k 3y ago
> You can always tell when code was written by someone who’s arrived fresh from Java or C++. AS3 and Flex was practically an attempt by these people to take over the language. Thankfully that failed. TS is great by comparison!

polotics 3y ago

Word! I just left a Java-only shop for pythonic pastures and the culture is so much more pragmatic and to-the-point. Hopefully soon enough ML models can be fed millions of line of code and produce the functionally equivalent thousands...

klibertp 3y ago
They're trained on billions of lines of code - most of them are not very good. I'm using Copilot, and the docstring/docs it suggests are so bad it hurts. If left alone, Copilot would happily generate those thousands of lines instead of helping reduce them to hundreds. It's still useful if given enough direction, but you need to be really careful not to overuse it or risk getting mistaken for a junior straight out of a bootcamp during code review :)
- tracker1 3y ago
  Yeah... I've noticed about half of what it comes up with needs tweaking... I really enjoyed it for SQL schema writing though... especially many-many table creation.

raverbashing 3y ago

> “This isn’t idiomatic. Please rewrite this code without the class keyword”. I’ve seen people people make a face like I just had their child expelled from kindergarten. Lol true Don't forget all the getters and setters merely updating/reading a variable Python says "explicit is better than implicit" but Java goes too far with it, and in the most verbose/inflexible ways possible

Izkata 3y ago
> Don't forget all the getters and setters merely updating/reading a variable > and in the most verbose/inflexible ways possible It's actually extra flexibility meant for two things: being able to override the getter/setter in a subclass, and keeping a consistent interface so users don't need to change how it's called if there was a refactor that adds something to the getter/setter (such as transforming the value because a different representation was more useful internally; particularly useful for libraries). Python has @property to maintain that interface if need be, but these Java conventions started when no such thing existed in the language. I haven't done Java in a long time, so I don't know if it has it even now..
- klibertp 3y ago
  > these Java conventions started when no such thing existed in the language. Is there language support for these in the newer Java versions (I'm not up to date with newer features, since I won't be able to use them on Android anyway)? The reason for these getters/setters is as you said: a workaround for the language deficiencies. It's true for quite a few patterns, and it's not unique to Java; you get similar (in nature) patterns emerging in all languages. Greenspun's tenth rule and all that. What's problematic is porting these workarounds wholesale to languages that don't have the limitations that originally led to their creation. In Kotlin, for example, every property has an implicit getter and setter, by default - you can override either easily with a dedicated syntax. In that case, insisting on writing explicit methods for getters and setters is simply a misuse of the language. Same in Python, as you note, where you can replace direct access to object attribute with a property without changing the user-facing interface of a class. I think JS also developed a feature like this? It's kind of impressive the OO languages managed to get this so wrong for so long, even though Smalltalk got it right in the 70s...

jcranmer 3y ago

> I want to link it to whoever insisted on adding a useless TextDecoder class in javascript that you have to instantiate, instead of just calling textDecode(…, “utf8”) using a global function like the rest of the standard library. I for one would rather punch the person who proposes such a global function as the only mechanism for conversion, because charset conversion is a reasonable thing to do on chunked partial inputs, and maintaining the state for conversion yourself is actually quite painful. Wrapping a stream converter into a one-shot function is much easier than the reverse, wrapping a one-shot function in a stream converter.

klibertp 3y ago
You can have the global function and make it work on "chunked partial inputs" while maintaining the state between calls (that state can be hidden in a closure or made explicit as an argument or a receiver - functions in JS can be called on objects even if they were defined outside of them). The very bad example of this is C's `strtok`, but it's pretty typical for JS to encapsulate the state in a closure to get similar functionality. Said another way: the functional, simplified interface doesn't mean you have to get simplified or lacking functionality. Haskell wouldn't exist if that was the case. The simplified interface providing as much functionality as the more complex interface is possible because the expressive power of JS is leagues above Java - porting Java patterns that emerged due to Java's shortcomings (some call them "design decisions", and they're also right) to JavaScript is simply not a good use of JS as a language.
replygirl 3y ago
This is what GP is talking about. Chunking can be done cleanly with very few internal functions (and without changing the call signature, if you want), but you're implying it must be a class and already thinking about hypothetical hacks
tracker1 3y ago
It wouldn't need to be a global, it could be mounted on String for example... And one doesn't necessarily prevent the other. String.fromUint8Array: (input: Uint8Array, encoding: string): String; Would be a fine, simple addition where it probably should be. Maybe calling the default for UInt8Array "String.fromBinary" instead.

_ea1k 3y ago

> You can always tell when code was written by someone who’s arrived fresh from Java or C++. AS3 and Flex was practically an attempt by these people to take over the language. Thankfully that failed. TS is great by comparison!