331–340 of 369 posts
The author should really look at Nim.
Earlier quoted context omitted.
What has this to do with my comment?
"Others take 30 minutes" If you knew what you were doing with Python, you wouldn't have this problem. Obvious solutions include unit tests and pickle.
I would need integration tests, for which I first need to understand how the code works together
Earlier quoted context omitted.
"Others take 30 minutes" If you knew what you were doing with Python, you wouldn't have this problem. Obvious solutions include unit tests and pickle.
Unit tests wouldn't help with that, because it doesn't cover the interaction of all the classes when they pass data on to each other; and they would probably take me months; I would need integration tests, for which I first need to understand how the code works together
Write simpler code, let go of the complex Java class hierarchies.
No one can understand them, it's hard to reasonable them and they are mostly a mess.
The point of Python duck typing is you do more by writing less code.
Earlier quoted context omitted.
I’ve been a Python developer for about 15 years and it isn’t good at most things. Performance is bad, package management is bad, typing is bad, async is bad, etc. Mostly it shines these days because of early mindshare in an exploding niche (AI/ML/numeric computing).
Hey now. Async in Python ain't that bad :)
Go doesn’t have problems like this—you could theoretically block the event loop with something sufficiently CPU-intensive, but Go schedules work across all cores (and moreover, Go gets hundreds or thousands of times more work done per core than Python, so it’s far less likely to run into these problems) so this becomes highly unlikely.
Earlier quoted context omitted.
I don’t know how people reconcile “python is beautiful and elegant” with “name your file __init__.py or __main__.py” while keeping a straight face.
Heck, the package manager having to execute random code in every package (setup.py). And speaking of beautiful and elegant, dunders everywhere, really?
Nope! Not since the mid-2010s. It took a long time, but with wheels[1], install-time actions are finally separate from packaging-time actions, and the former do not include any user-defined actions at all.
Just about every sufficiently general system allows for arbitrary code in the latter, be they in debian/rules or PKGBUILD or the buildPhase argument to mkDerivation or—indeed—in setup.py. (Most systems also try to sandbox those sooner or later, although e.g. the Arch Linux maintainers gave up on cutting off Go and Rust builds from the Internet AFAIU.)
Don’t forget to `python setup.py bdist_wheel` your stuff before you upload it!
> And speaking of beautiful and elegant, dunders everywhere, really?
It’s the one reserved namespace in the language, so its usage for __init__.py and __main__.py seems—perhaps not beautiful, but fairly reasonable?
[1] https://packaging.python.org/en/latest/specifications/binary...
Lots of comments here are stating that typing is half baked in Python, and that if you gotta use types, you should use another language. But that's missing the point that Python is still not meant to be the best at anything, but good at most things. And in this case, it's exactly what you get: optional typing, with decent safety if you need it. You can quick script or design seriously, you can explore in a shell or c…
I haven’t yet had the time to look at dataclasses and pattern matching in recent versions, so serious question: do we finally have a standard solution for doing algebraic-datatype-style stuff? I do have a generic visitor implementation lying around somewhere, but that doesn’t change the fact that every time I see any writeup of the type “Let’s do in Python!”, I spend most of my reading time wishing they had used SML or OCaml—and I don’t even know OCaml.
Earlier quoted context omitted.
Heck, the package manager having to execute random code in every package (setup.py). And speaking of beautiful and elegant, dunders everywhere, really?
> Heck, the package manager having to execute random code in every package (setup.py). Nope! Not since the mid-2010s. It took a long time, but with wheels[1], install-time actions are finally separate from packaging-time actions, and the former do not include any user-defined actions at all. Just about every sufficiently general system allows for arbitrary code in the latter, be they in debian/rules or PKGBUILD or th…
Most other programming language package managers don't, see Maven for Java.
But then again, NONE of the scripting languages ever wanted to learn stuff from Java, especially regarding packaging (lack of packaging namespaces is another major blunder re-created by Python and several others, including Javascript).
Earlier quoted context omitted.
> Heck, the package manager having to execute random code in every package (setup.py). Nope! Not since the mid-2010s. It took a long time, but with wheels[1], install-time actions are finally separate from packaging-time actions, and the former do not include any user-defined actions at all. Just about every sufficiently general system allows for arbitrary code in the latter, be they in debian/rules or PKGBUILD or th…
> Just about every sufficiently general system allows for arbitrary code in the latter, be they in debian/rules or PKGBUILD or the buildPhase argument to mkDerivation or—indeed—in setup.py. (Most systems also try to sandbox those sooner or later, although e.g. the Arch Linux maintainers gave up on cutting off Go and Rust builds from the Internet AFAIU.) Most other programming language package managers don't, see Mave…
So it’s not able to express native extensions or even codegen then? I suppose that’s OK for something that’s not the only available solution, but I don’t think I’d love it, either.
> But then again, NONE of the scripting languages ever wanted to learn stuff from Java, especially regarding packaging[.]
Both Java and its docs are just extremely tedious to read, to be honest. I say that with all due respect to its principal designers and acknowledging my ever-hopeless crush on Self where a lot of the tech originated. (And I don’t only mean 2000s Java—it took me literal days to trawl through the Android frame pacing library to find[1] the two lines constituting the actual predictor, commented “TODO: The exponential smoothing factor here is arbitrary”. The code of the Go standard library, nice as that is, gives me a similar feeling with how... vertical it is.)
That’s not an excuse for ignorance, but it’s a centuries-old observation that you need to avoid inflicting undue pain on your readers if you want your ideas to survive. The flip side is that there may be untapped ideas in obscure or unpleasant texts written by smart people.
So if you can point to things one could learn from Java, I’d very much be interested.
(And no, literature searches are not trivial—I’ve occasionally spent months on literature searches, sometimes to realize that the thing I wanted either isn’t in the literature or is in someone’s thesis that’s only been published a year ago.)
[1] https://android.googlesource.com/platform/frameworks/opt/gam...
The author should really look at Nim.
You know: this always tempts me, but I hold back because nim is not memory-safe (or has a clearly delineated memory-safe subset like Rust), and I would rather pick up an actually memory-safe (even if GCed) language even if some perf-cost (like F#, Ocaml, Swift, Vale ..etc).
https://forum.nim-lang.org/t/9280#61243
There also may well be libs (that you feel unable to not rely upon) which use these language constructs, and trust sure is tricky (in any PL ecosystem as well as just in life).
Earlier quoted context omitted.
> I can start with every module in prototype form and industrialize each module as its design firms up. That is definitely the theory. And this flexibility is indeed very precious for some types of work. However... does it actually happen as you describe? I can count on half of the fingers of one hand the number of Python codebases that I've seen that actually feel like they've properly been reworked into something o…
Wandering offtopic, perhaps, but I've noticed that this kind of behavior seems to strongly correlate with Scrum. The work starts getting rushed toward the end of the sprint. Every two weeks, people start furiously cutting corners to meet a completely artificial due date. And then there's basically zero chance that you'll be able to get the PO to agree to cleaning it up in the next sprint, because they can't see the p…
Given dubious project management schemes, do the refactoring and cleanup first. Then the functional change is easier to review as it's against a sane background, and there's minimal planned cleanup after in case that phase gets dropped. Call writing the tests characterisation if that helps.