97
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 13 Nov 2023
97 points (92.2% liked)
Programming
16207 readers
359 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
Python. Not even a competition. My love of programming quadrupled the day I switched to python and it's getting stronger and stronger. I have now 10 years of professional python experience and around the same of C++ with occasional C#. A few projects in Go and Java. They all have ups and downs, but... Not even comparable how much everything is more elegant and simple in python
I don't get it. I love python for small quick projects. But anytime things get more complicated, I find myself constantly tripping over myself without the strong typing and errors letting me know I when I've changed a property in a class that in falling elsewhere.
Python was always strongly typed. For years there has been optional static typing and - you know - unit tests.
If you're having significant issues due to not knowing what types you're using, the type system may not be your greatest problem...
Sorry, I meant static typing, not strongly typing. I often cross the two. But this is exactly what I mean, if you want something to be statically typed you have to put in the extra effort, if not you've got dynamically typing, which is fine when things are small but I find causes stumbling blocks when things get larger.
And depending on the scale of the project I'm working on, my unit tests usually take minutes to run, if not hours. If I'm debugging and I change a property, when I compile it instantly catches that I forgot to change it elsewhere. Hell, even when I save it I'll get a little error warning. Maybe running unit tests all the time is fine if the project is small, but not if it's large. I'm not going to run unit tests every time I'm starting a new debugging session. Linters kind of make up for this. But then we are back to making sure there are type hints, which, as I've been told, is not "pythonic."
If people like it, more power to them, I'm not shitting on the language as even I like it. I just can't use it for larger stuff, and I've never worked anywhere that uses it for larger stuff, and I think for good reason.
These exist in theory, but as a whole, I've never seen them working at even the base level of what you get in other languages.
Adding type hints to your code is fucking exhausting, because there is no type inference.
MyPy regularly calls it quits, when any library doesn't have type hints. PyCharm regularly doesn't properly auto-complete, because it doesn't have type information (if it can load your project correctly to begin with).
Unit tests exist, yes, but you need 100% test coverage to make the language properly check all code paths. Without it, even just calling a library isn't guaranteed to work. In no fully statically typed language, would I recommend 100% test coverage, unless you have special correctness requirements.
If you pick Python, do you still get libraries written in C or Rust?
Yeah, C libraries can be used in basically any mature language. It's just too useful to not have.
And Rust, since it doesn't need a runtime, can emulate the format of C libraries.
Rust libraries can also specifically target Python via https://pyo3.rs, but as I understand, this just does the C library format, plus a basic Python wrapper to make it nicer to use.
Sorry, I meant in the context of OPs question (so i guess up to them to set the rules). As in, you pick Python for the rest of your life, does that lock you out of C libraries? Its a bit of a rabbithole though, as many language runtimes would get excluded as well. There arent many languages that actually stand alone.
Ah, right, my interpretation is that as long as you don't need to touch the source code, you're good.
But yeah, it's certainly not as clear cut. My pick would actually be Rust, because you can use it for pretty much everything, including web frontends via WebAssembly.
However, in that case, you still write HTML+CSS, which technically may or may not be programming languages, and the DOM API is actually only documented in JavaScript. So, I wouldn't need to write JS, but would still want to read it...
Thats probably the best way to look at it, otherwise it gets very difficult very fast.
If markup languages are locked out, then rust has other problems, because you then can't change your cargo.toml file anymore.
And then there is the build script problem :/
As a thought excercise this has been interesting, there certainly are a lot of inter-dependencies between languages the deeper you look.
Yeah, I found it quite interesting, too. To some degree, I've been wondering why it's so natural for programmers to be programming language polyglots, even if they're not actively nerds/excited about them.
And yeah, this discussion made me realize that you basically can't take a single step in programming without being confronted with multiple languages/syntaxes at once.