231–240 of 275 posts
Earlier quoted context omitted.
That's sort of outdated. Python now has type hints, protocol oriented programming support, and is quite fast (for what it is). This wasn't the case back in the day but it's all there now.
Python might have nice features, but it also has terrible features. Like using dicts for everything. It's not enough to allow good practices, you have to prevent (or at least reduce) bad practices.
It was right then, but it's kind of dated and misses an evolutionary lesson: beautiful code isn't enough, it has to be safe, beautiful, maintainable, productive, understandable, and resource efficient. Ruby is still great for throwing something together fast and maintaining it until it runs into scale problems. It added gradual typing with sorbet and RBS. Crystal is a neat typed, compiled Ruby-alike but it's buggy. R…
> Ruby is still great for throwing something together fast and maintaining it until it runs into scale problems. It added gradual typing with sorbet and RBS. I think Ruby is much better than Python for building large applications. Ruby is essentially Smalltalk with a neat Algol-like syntax and some Perl-isms. Its OO system is a joy to work with. Python got so popular in data-oriented applications because it's a reall…
Also I remember the dependency management system was a pain in the ass to deal with, especially with modules with native libraries.
Python had some issues with 2, but when 3 came around and fixed all that, it became the language of choice specifically because of its consistency.
Earlier quoted context omitted.
That's sort of outdated. Python now has type hints, protocol oriented programming support, and is quite fast (for what it is). This wasn't the case back in the day but it's all there now.
Python might have nice features, but it also has terrible features. Like using dicts for everything. It's not enough to allow good practices, you have to prevent (or at least reduce) bad practices.
Sorry what? This is absolutely not true.
Typed python is extremely ugly and frustrating. Does anyone have any good advice on doing it well? It seems like every library has their own system and doing any kind of casting just to make the linter be quiet is such a chore.
Yes, don't try to shove all your code into OOP, and you will be fine.
Python is a glue language. If you want to be hardcore you write something in rust (or whatever) with python bindings...
Python is great for small scripts or explorations. You can't use it for anything serious that needs to scale due to the lack of concurrency and significant memory overhead. If you need something to scale you use something like C++, Java, Go, Rust, etc.
Please actually think about what you are saying instead of just parroting off stuff you read on blogs.
Python has concurrency. Its called multiprocessing. Of course, there is startup overhead, but it achieves the same functionality. Furthermore, processes that are most commonly threaded (like fanning out network requests) are well suited to async, which has less overhead than threads.
Also, memory considerations are relevant only for embedded systems, for which you would never use Python. Memory is dirt cheap these days.
Earlier quoted context omitted.
Rust is "not as used" but it has a following who hype it to the point that I've avoided taking time to relearn it just due to the strange vibes I get from their community. These people once mentioned, on twitter, that people who hate systemd are like reactionaries (as in, politically far right), as if a choice of init is a correlative of political ideology. When you view others' preferences for fucking software as so…
>These people once mentioned, on twitter, that people who hate systemd are like reactionaries (as in, politically far right), as if a choice of init is a correlative of political ideology. When you view others' preferences for fucking software as so important to your world view that they might as well be nazis[0], you can tell your priorities are not in order. I hate that everything is politically-coded nowadays, but…
One group thinks change is ultimately a good thing and will make changes for the sake of changes.
Another one thinks change is ultimately a bad thing, and will always oppose it.
Too much change is chaos, too little is stagnation. The truth is somewhere in the middle.
Earlier quoted context omitted.
Things don't die very often due to typing issues. The unit tests always pick up typing problems. Testing the code's behavior implies testing the code's typing. And if you are not testing the code's behavior then the code isn't really tested at all.
Does your code check every single variable is not null before using it? That every function argument is of the expected type? That every attribute exists before it is accessed? And do you have unit tests for all of this too? If so - then you're writing a whole lot of manual checking that a strongly typed language would perform for you, at compile time. If not - well then you're doing less testing than a strongly type…
Testing via typing is very weak testing. Almost worthless. Type checking doesn't find many bugs in general.
Strongly typed languages have 2.5 times the number of bugs as dynamically typed languages per software feature.
Why would you intentationally add bugs to your code?
It doesn't make any sense to me.
Thinking using static typing in a scripting language is a good idea is pretty naive. It's like creating a version of Haskell with mutability.
It was right then, but it's kind of dated and misses an evolutionary lesson: beautiful code isn't enough, it has to be safe, beautiful, maintainable, productive, understandable, and resource efficient. Ruby is still great for throwing something together fast and maintaining it until it runs into scale problems. It added gradual typing with sorbet and RBS. Crystal is a neat typed, compiled Ruby-alike but it's buggy. R…
It's quite verbose, as well, or was the last time I looked at it.
I don't demand a Perl level of terseness (that's going too far the other way), but neither is reinventing the verbosity of COBOL a good idea.
Typed python is extremely ugly and frustrating. Does anyone have any good advice on doing it well? It seems like every library has their own system and doing any kind of casting just to make the linter be quiet is such a chore.
Anyone following this approach is an idiot, it's like prescribing a very niche diet to everybody.
If you want it to be useful instead of doing it everywhere, you should limit it as much as possible. Find a few isolated places where you want types and limit analyzer to this area only (btw, it is entirely possible that there are no places like this in your code - that's a good thing). You can always extend the area that's covered by static analyzer, but you can never shrink it (at least I've never seen it happen).
If you don't do this, typing becomes viral and you will soon be doing typing for the sake of typing and fighting your tools instead of extracting value from them.