231–240 of 369 posts
Earlier quoted context omitted.
Can you enumerate the languages that you deem "real" and those you don't? I have a very hard time understanding what meaning you give to that word.
Languages that you would build serious production software in, rather than some script. C, C++ are the main ones.
I stopped writing anything like rust because rust its ecosystem is mostly complete enough , expressive, and rapid to prototype and use. To save my cognitive load I shelved my python, Bourne, JavaScript, etc, and just write rust now. It’s not a decision for everyone and I’m not here to convince anyone of anything. But my life is simpler, my scripts more general and faster, and I don’t particularly ever miss the interp…
I'm not invalidating your experience, it sounds wonderful to find the solace in one language.
I stopped writing anything like rust because rust its ecosystem is mostly complete enough , expressive, and rapid to prototype and use. To save my cognitive load I shelved my python, Bourne, JavaScript, etc, and just write rust now. It’s not a decision for everyone and I’m not here to convince anyone of anything. But my life is simpler, my scripts more general and faster, and I don’t particularly ever miss the interp…
In my profession (sysadmin related) it seems that if you want the glue-code orchestration and SDK availability of Python, but with better performance and types, you use golang. I don't think most vendors are popping out Rust SDKs for the product's APIs. I'm not invalidating your experience, it sounds wonderful to find the solace in one language.
On apis, honestly, I just write my own api integrations. But most of the APIs I use are documented without programmatic specifications, and sdks are usually garbage written by an intern :-)
Earlier quoted context omitted.
This is roughly my experience, too. Static type safety has interesting YAGNI characteristics. For the bits of the code that must work, and where defects and regressions due to type errors may be subtle and difficult to detect, it's indispensable. But it can also be an impediment to iteration. Sometimes the code you're working on is still so experimental that you don't really know what the best structure and flow of d…
> But it can also be an impediment to iteration. Sometimes the code you're working on is still so experimental that you don't really know what the best structure and flow of data will be yet, and it's easier to just bodge it together with maps and heterogeneous lists for the first few iterations so you can let the code tell you how it wants to be structured. Having to start with static types subtly anchors you to you…
But what I've discovered in practice is that, during those early iterations, I don't really need the compiler to help me predict what will break, because it's already in my head. The more common problem is that static typing results in more breaks than there would be in the code that just uses heterogeneous maps and lists, because I've got to set up special types, constructors, etc. for different states of the data such as "an ID has/has not been assigned yet". So it kind of ends up being the best solution to a problem largely of its own making.
I'm also working from the assumption here that one will go through and clean up code before putting it into production. That could be as simple as replacing dicts with dataclasses and adding type hints, but might also mean migrating modules to cython or Rust when it makes sense to do so. So you should still have good static type checking of code by the time it goes into production.
Earlier quoted context omitted.
> Having to start with static types subtly anchors you to your first idea. And the first is typically the worst. Not just that, but dynamic typing conveniently allows you to try multiple ideas in parallel. In static languages, you tend to refactor The One Representation for a thing and try multiple ideas sequentially, which may or may not be better. Of course, none of this is really inherent to the type system -- ple…
That is a very good point. However, the other side of the coin is that in many Python codebases I've seen, people keep using multiple antagonistic ideas/paradigms in the same code, way past the point where it should have become clear that these ideas are actually incompatible and no amount of heroic hackery will solve the issues.
I think, though, that a lot of Python programmers - particularly less-experienced ones - fail to realize that that typically functions as more of an expectation, perhaps even an obligation, than a liberty.
Earlier quoted context omitted.
> Something I really like about Python for this sort of thing is that I have a lot more ability to delay this industrialization stuff to the last responsible moment This is one of my favorite aspects of Python. I can start with every module in prototype form and industrialize each module as its design firms up. I can spend my early development getting an idea fleshed out with minimal overhead.
> 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…
It's easy to make something that works, is well designed, and either doesn't solve a problem someone has or nobody knows about it.
Earlier quoted context omitted.
> But that's missing the point that Python is still not meant to be the best at anything, but good at most things. The most important thing about Python is readability and its part of its syntax and is one of the best languages out there for readability. Zen of python: >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Compl…
That applies to Python 2.7 and the code that Tim Peters writes. It does not apply to current Python and the coding styles that most people employ. Current coding styles are either: - Java-like ravioli, with class hierarchies that no one understands. - Academic functional and iterator spaghetti, written by academics who think Python offers the same guarantees as Haskell. Both styles result in severely broken code base…
Earlier quoted context omitted.
> But that's missing the point that Python is still not meant to be the best at anything, but good at most things. The most important thing about Python is readability and its part of its syntax and is one of the best languages out there for readability. Zen of python: >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Compl…
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.
And speaking of beautiful and elegant, dunders everywhere, really?
For instance: data classes instead of tuples or dicts. Great, love it.
Now add immutability (frozen=true isn't enough so you're probably going to need pyrsistent) and serialization (dataclasses_json works reasonably well for this), and precommit hooks with pyright or mypy... And you've got yourself a reasonable system for leaning on the type checker.
Except you've been at it all day and you still haven't gotten any "work" done, and you've got all of these weird constructions that aren't complex themselves but they'll make a newcomer to your project go "huh?"
Sometimes it's a necessary evil. My users write python, so I need to write python to ensure that their experience is nice and ergonomic. But if I try to write python like it's rust (which I usually do) I end up with quite a pile of things that add toolchain complexity without addressing any business problems.
Don't get me wrong, I still do it, but I've never managed to make it look like a good enough idea to get other people to join me, which is maybe the universe trying to tell me I should stop.
Earlier quoted context omitted.
Not really. First, the JS ecosystem is very web oriented, so if you want to dabble out of there, you often gonna fall short. Secondly, the JS packaging has very poor support for compiled extensions, which mean everything that needs a perf boosts is unlikely to get good quality treatments. Finally, the community makes it a constant moving target. After 20 years of writing both JS and Python, I can still install old dj…
We gradually wanted to move our Java, C# and C++ into a more “generalised purpose” language because it would be easier to maintain and operate a small team with one language in what was becoming a non-tech enterprise. Python was our first go to, because well, it’s just a nice language that’s easy to learn, but we eventually ended up in Typescript and our story was basically the polar opposite to what you mention here…
Everything Java 11+, modern libraries (no Spring, no Hibernate).
The Java ecosystem is so deep that you can avoid the top 2 libraries/frameworks in any major domain and #3-#5 would be highlights in other ecosystems.