4 ms·

Algorithms are a lot easier to understand when they are written in Python. I'm actually right now documenting medium size Java codebase by writing pseudocode, w

by zeroc8 1y ago

Algorithms are a lot easier to understand when they are written in Python. I'm actually right now documenting medium size Java codebase by writing pseudocode, which looks like Python. Just by doing that, I've already discovered multiple bugs, which I didn't catch by looking at the Java code.

bunderbunder 1y ago
That might be the big thing that I think gets glossed over in a lot of these discussions. I agree that I wouldn't want to maintain 100kloc of Python. But, I don't really view that as a realistic hypothetical for a business application. Idiomatic Python tends to require a fraction as much code as idiomatic Java to accomplish the same task. The only time it even gets close is when you have code written by people who go out of their way to make things look like old-school enterprisey Java. So it ends up accumulating a bunch of stuff like class IWantToBeABean: def init(self, arg1: int, arg2: str, arg4: str) -> None: self._field1: int = arg1 self._field2: str = arg2 self._field3: str = arg3 def get_field1(self) -> int: return self._field1 def set_field1(self, value: int) -> None: self._field1 = value def get_field2(self) -> str: return self._field2 def set_field2(self, value: str) -> None: self._field2 = value def get_field3(self) -> str: return self._field3 def set_field3(self, value: str) -> None: self._field3 = value when it could have just been: @dataclass class IDontWantToBeABean: field1: int field2: str field3: str The worse case for Python is when you get people doing the oldschool Python thing of acting like dynamic and duck typing means it's OK to be a type anarchist. Scikit-learn's a good one to put on blast here, with the way that the type and structure of various functions' return values, or even the type and structure of data they can handle, can vary quite a bit depending on the function's arguments. And often in ways that are not clearly documented. Sometimes the rules even change without fanfare on minor version upgrades. The reason why large Python codebases are particularly scary isn't necessarily the size itself. It's that for a codebase to even get that large in the first place it's very likely to have been around so long that the probability of it having had at least one major contributor who likes to do cute tricks like this is close to 1. And I'd take overly verbose like the Java example above over that kind of thing any day.
- deepsun 1y ago
  Hey, you forgot useless comments for each method: get_field1(self) -> int: """ Gets Field1. @rtype: int @return: the field1 """ self._field1 And use double underscores for private fields, because, you know, encapsulation. Seriously though, in Java you don't need get*() either. Typically you either: 1. use `record` types (since Java14, 2020), or 2. use Lombok that auto-generates them [1], or 3. use Kotlin `data class`, or 4. just raw field access. I don't buy the encapsulation thing if my code is not a library for wide internet to use. [1] https://projectlombok.org/features/GetterSetter https://projectlombok.org/features/GetterSetter
deepsun 1y ago
Try Kotlin then. I wouldn't call it a new language, for me it's just a syntactic sugar over Java, but for any problem you would google "how to do X in Java", not "how to do X in Kotlin". But there you can do way simpler syntax, like: 0..100 meters with -45..45 deg within 3 seconds Because "0..100 meters ..." is equivalent to "(0..100).meters(...)" (0..100) is a built-in IntRange type, that you can extend: data class MyDistanceRange(val meters: ClosedRange<Double>) val IntRange.meters: MyDistanceRange get() = MyDistanceRange(first.toDouble()..last.toDouble()) and
- bunderbunder 1y ago
  IMO Kotlin has some features that take it way beyond just being syntactic sugar over Java. Like, I know you could probably use some eye-watering gang-of-four pattern to achieve the same effect as extension methods. But it's going to be such a PITA to maintain that calling the Kotlin feature syntactic sugar for the same thing is about as useful as saying that function definitions are just syntactic sugar over assembly language calling conventions.
- zeroc8 1y ago
  I've played with it for a bit but it doesn't excite me enough to spend time learning it properly. I also don't care about Python beyond using it for learning algorithms and maybe some smaller Pyside UIs. However, together with Mojo it might become more interesting again.

by zeroc8 1y ago

bunderbunder 1y ago

That might be the big thing that I think gets glossed over in a lot of these discussions. I agree that I wouldn't want to maintain 100kloc of Python. But, I don't really view that as a realistic hypothetical for a business application. Idiomatic Python tends to require a fraction as much code as idiomatic Java to accomplish the same task. The only time it even gets close is when you have code written by people who go out of their way to make things look like old-school enterprisey Java. So it ends up accumulating a bunch of stuff like class IWantToBeABean: def init(self, arg1: int, arg2: str, arg4: str) -> None: self._field1: int = arg1 self._field2: str = arg2 self._field3: str = arg3 def get_field1(self) -> int: return self._field1 def set_field1(self, value: int) -> None: self._field1 = value def get_field2(self) -> str: return self._field2 def set_field2(self, value: str) -> None: self._field2 = value def get_field3(self) -> str: return self._field3 def set_field3(self, value: str) -> None: self._field3 = value when it could have just been: @dataclass class IDontWantToBeABean: field1: int field2: str field3: str The worse case for Python is when you get people doing the oldschool Python thing of acting like dynamic and duck typing means it's OK to be a type anarchist. Scikit-learn's a good one to put on blast here, with the way that the type and structure of various functions' return values, or even the type and structure of data they can handle, can vary quite a bit depending on the function's arguments. And often in ways that are not clearly documented. Sometimes the rules even change without fanfare on minor version upgrades. The reason why large Python codebases are particularly scary isn't necessarily the size itself. It's that for a codebase to even get that large in the first place it's very likely to have been around so long that the probability of it having had at least one major contributor who likes to do cute tricks like this is close to 1. And I'd take overly verbose like the Java example above over that kind of thing any day.

deepsun 1y ago
Hey, you forgot useless comments for each method: get_field1(self) -> int: """ Gets Field1. @rtype: int @return: the field1 """ self._field1 And use double underscores for private fields, because, you know, encapsulation. Seriously though, in Java you don't need get*() either. Typically you either: 1. use `record` types (since Java14, 2020), or 2. use Lombok that auto-generates them [1], or 3. use Kotlin `data class`, or 4. just raw field access. I don't buy the encapsulation thing if my code is not a library for wide internet to use. [1] https://projectlombok.org/features/GetterSetter https://projectlombok.org/features/GetterSetter

deepsun 1y ago

Try Kotlin then. I wouldn't call it a new language, for me it's just a syntactic sugar over Java, but for any problem you would google "how to do X in Java", not "how to do X in Kotlin". But there you can do way simpler syntax, like: 0..100 meters with -45..45 deg within 3 seconds Because "0..100 meters ..." is equivalent to "(0..100).meters(...)" (0..100) is a built-in IntRange type, that you can extend: data class MyDistanceRange(val meters: ClosedRange<Double>) val IntRange.meters: MyDistanceRange get() = MyDistanceRange(first.toDouble()..last.toDouble()) and

bunderbunder 1y ago
IMO Kotlin has some features that take it way beyond just being syntactic sugar over Java. Like, I know you could probably use some eye-watering gang-of-four pattern to achieve the same effect as extension methods. But it's going to be such a PITA to maintain that calling the Kotlin feature syntactic sugar for the same thing is about as useful as saying that function definitions are just syntactic sugar over assembly language calling conventions.
zeroc8 1y ago
I've played with it for a bit but it doesn't excite me enough to spend time learning it properly. I also don't care about Python beyond using it for learning algorithms and maybe some smaller Pyside UIs. However, together with Mojo it might become more interesting again.