12 ms·

Slightly related question: why do people love Python so much? Or, any dynamically typed language? There's almost nothing that has frustrated me more in a profes

Slightly related question: why do people love Python so much? Or, any dynamically typed language? There's almost nothing that has frustrated me more in a professional setting than trying to figure out what some dynamically typed code is doing and ensuring I don't break anything by making changes.

codedokode 4y ago
Because you can do a lot with little typing and there are lots of great libraries. Python is probably the best choice when you need to get something done quick or calculate something when performance is not important. It is also not an exotic functional language without loops and filled with linked lists. Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages. If you name a language, with high probability Python will be better in something unless it is about performance. What I don't like: no type hints in many libraries, some libraries are not type-hint friendly, lot of unnecessary dynmamic features (like being able to patch modules in runtime) and absolutely no caring about performance and being able to compile into machine code. > trying to figure out what some dynamically typed code is doing There should be type hints.
- toomanydoubts 4y ago
  >There should be type hints. "Hey, this variable is probably of this type. Now go on, run the code and launch a debugger the same way you would if there was no hint just to make sure it's correct. Oh, and don't forget to check all the possible code paths that lead to this to make sure you've exhausted all possibilities." Don't get me wrong, type hints are cool but they're just a toy compared to proper static typing.
  - joshuamorton 4y ago
    > Oh, and don't forget to check all the possible code paths that lead to this to make sure you've exhausted all possibilities." This is literally what mypy does. There's no difference between a mypy-enabled codebase and a java codebase in terms of static typing (other than that mypy actually supports a generally richer type system). Like yes if you aren't validating the type hints you aren't getting the value, but if you are, you don't need to run the code! I get most of my python errors at compile time, and you can too. I promise.
    - FridgeSeal 4y ago
      Sorry, but MyPy and friends can barely hold a candle to what actual static-typing systems do - Rust, Haskell, OCaml, Typescript, even .Net (C#/F#) offer more safety and guarantees. Type hints in python are _just that_, they're hints. The whole "typed" python ecosystem relies on packages and the language using them, using them correctly, and using them consistently. In my experience so far, I've seen little widespread use, and nothing from core python, which is a huge hole IMO.
      - joshuamorton 4y ago
        > Sorry, but MyPy and friends can barely hold a candle to what actual static-typing systems do - Rust, Haskell, OCaml, Typescript, even .Net (C#/F#) offer more safety and guarantees. Note that you don't include the most common static languages there (cpp, java, golang), you include languages known *specifically " for their extremely powerful type systems, one of which , just like mypy, uses gradual typing! This supports my argument!
        FridgeSeal 4y ago
        I mean sure, we can include C++, go and java in there if you want? I don’t really know what the point you’re making here is? > one of which , just like mypy, uses gradual typing! This is like arguing that because your scooter also has a petrol engine, it’s as fast and efficient as an F1 car. My argument was that MyPy doesn’t compete with the capabilities of modern statically typed languages. TS might also technically be gradually typed, but most devs I know just go straight to fully typed TS, because working in a mix/gradual environment is painful and the community uptake of strict types is far higher.
        joshuamorton 4y ago
        What features that Javas type system provides does pythons lack? I can name dozens that python has that Java doesn't. My point is that if you include cpp or java or golang the statement becomes false. Python's type system is actually generally speaking more robust than those (cpp is comparable, but I don't think python's is worse). So I'm asking, be specific what capabilities does mypy lack that cpp or java or golang provide? Keep in mind, mypy supports literal types, limited dependent types, dynamic-duck typing (protocols), limited contract types, and more. Java doesn't, go doesn't. Cpp supports some of those but it requires arcane incantations.
- toomanydoubts 4y ago
  >no type hints in many libraries, some libraries are not type-hint friendly. >There should be type hints. So, is it one or the other?
- peaky_blinder 4y ago
  > Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages. There is no such thing as a buggy language. Software can be buggy (or language implementation), but not the language. And the reason you do not have integer overflow is because integers are implemented as integer objects of arbitrary size, which is great if you're doing something quick and dirty, but could be disastrous for a serious work.
  - still_grokking 4y ago
    > There is no such thing as a buggy language. How can you know if you don't have a verified formal description of your language's semantics? It's very much possible (and imho even quite likely) that a lot of language definitions are self contradicting. Of course one could argue that such self contradictions aren't "bugs" at all. But such an argumentation would seem very odd, imho, no matter one can actually "define" whatever one likes.
    - hnfong 4y ago
      http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-... > Signed integer overflow: If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN. Probably not what the GP meant, but I think this qualifies as a "buggy language (spec)"
      - still_grokking 4y ago
        I don't think defining something as undefined is buggy per se. That's not what I've meant. But defining some things in a contradicting manner would make up a buggy spec, I guess. Regarding the int example, funny enough I made a comment about that just before here: https://news.ycombinator.com/item?id=32457056 https://news.ycombinator.com/item?id=32457056
  - dannymi 4y ago
    >could be disastrous for a serious work. How so?
- elcritch 4y ago
  Wow, I thought Rust's integers would let you handle integer overflows.. Apparently thats not the case and overflows are only checked in debug builds and then they just panic. Huh. After programming in Nim (and Python back in the day), I've become used to being able to detect integer overflows as a normal exception. At least for signed ints, since not all CPU support efficient overflow detection on unsigned ints. Its handy to to let uints wrap as sometimes thats what you want. I figured all new languages would do similar things.
  - bobbylarrybobby 4y ago
    Rust has a variety of checked methods -- `checked_add` etc -- that allow for fallible int operations. And there are corresponding `wrapping_` versions that indicate wrapping is the correct behavior (and shouldn't panic in debug builds).
- chaxor 4y ago
  What i don't like about python: The goddamn versioning and packaging problems. About 5 years ago python was incredible. You could pop out a project quickly because there were very few packages that made breaking changes over their development, so you could often use your standard workflow with the set of packages you we're comfortable with, even if there were new versions available that day. Now, Nvidia and Google ruined everything. Python is the ML language, so every package likely depends somehow on tensorflow or some GPU acceleration. This is a problem because every damn version of ' insert tf/pytorch/Jax/cuda/etc ml package here' only works with that exact version configuration ONLY ( and honestly, it probably doesn't actually work anyway). So, if you have an idea of using two packages together that aren't already in a package - be prepared to spend the next month trying in despair to get that to work (and probably ultimately give up). It's insane to me that the workflow of today necessitates (in python anyway) setting up multiple docker containers to talk to each other, simply because python packages seem to have no problem making breaking changes every freaking week.
  - echelon 4y ago
    I feel this comment in my bones. I went from loving Python to hating it with a seething rage. Python package managers are all so bad that the only reasonable solution is Docker containers or vendoring everything (not easy). And even so, I've had untouched Docker builds still die because dependencies mysteriously get yanked or changed. God, I hate Python so much now.
    - still_grokking 4y ago
      If you like the look & feel of Python, but not the ecosystem: https://docs.scala-lang.org/scala3/book/scala-for-python-devs.html https://docs.scala-lang.org/scala3/book/scala-for-python-dev... Sorry for that quite random comment, but SCNR.
      - theblazehen 4y ago
        Thanks for that! I've heard about scala before, never investigated it. I'm really looking the like of it now
- kevin_thibedeau 4y ago
  Overflowing integers is not a bug. It's literally how an adder circuit operates on fixed precision. Ignoring them by default is worth criticizing but there are plenty of times where silent overflow is correct and desirable behavior.
  - tomp 4y ago
    It's technically not a "bug" in Rust or C++, it's undefined behaviour, which is much worse than a bug! (and it's never correct behaviour)
    - still_grokking 4y ago
      Little nitpick: In C/C++ it's "only" UB for signed ints. For unsigned ints it's arithmetic modulo 2^n (where n is the number of bits in the value representation of that particular size of integer). Such divergent definitions make the whole mess of course even bigger, that's not the point.
      - pratk 4y ago
        Also, the UB can be mitigated with -fwrapv (if desired) to handle overflowing integers with 2's complement
        still_grokking 4y ago
        Stupid question, but how can a compiler flag "mitigate" some UB that is (to my knowledge) defined by the standard as UB? This would be possible only if the standard would define the behavior in question as implementation defined. But that's not the case afaik. Signed overflow is undefined behavior as it's afaik defined to be that. But maybe I'm just wrong here? But at least SO is confining my knowledge: https://stackoverflow.com/questions/16188263/is-signed-integer-overflow-still-undefined-behavior-in-c https://stackoverflow.com/questions/16188263/is-signed-integ...
        4y ago
- HdS84 4y ago
  For runtime patching: I needed that twice: First there was a bug in the stdlib event log logging for windows which crashed when the user was not an admin (2.7 days). We could monkey patch that problem on the fly which was much better than any alternative. Second I needed to redirect scikitlearn logging to a file. Which did not work because scikit does not use logging but something homegrown. We just overwrite the internal log function and all was good. Yes it's seldom needed and it's a very sharp sword but it's much better that it's there when you need it. I encountered bugs in .net stdlib which where there was no alternative than to wait for the next release. Very ugly when you need to ship.
- dexterlemmer 4y ago
  Type hints and static typing are completely orthogonal. It is merely more common for the designers of dynamically typed languages to make the mistake of not allowing type hints pretty much every where and requiring them in a library's API (or at least linting for them being missing in the API) than making the same mistake is for the designers of staically typed languages.
sdeframond 4y ago
I believe dynamically typed languages are easier to use than old-style statically typed langages (Java, C, etc). More modern statically typed languages can be quite easy to use (I am thinking of Scala) but none provides an ecosystem as rich as python's. Plus, recent static languages (Scala, Rust, Haskell or even Elm) are more oriented toward "Software Engineers" or CS academics. Python appeals to a lot of "programmers" who's main job is actually data science, mechanical engineering, biologist...
- epgui 4y ago
  I think the latter point hits the nail right on the head: the preference for python is probably more of a social issue than a technical one at this particular point in History. I think when FP languages and paradigms become the norm (you can quote me on this, I predict that it's only a matter of time), preferences will change. People tend to prefer what they know, and it will take some time for culture to change.
- gilch 4y ago
  I found Scala horribly overwrought compared to either Java or Haskell. It's like it tried to mush together two different type systems and got the worst of both worlds. Languages do not need to be that complex. My next JVM language was Clojure, and I've never looked back. I'd try Kotlin before I'd go back to Scala.
analog31 4y ago
I have a hunch that a lot of Python users didn't carefully evaluate the language on its merits, but rather, just started using it. In my own case, I was using Visual Basic 6 before Python, and mostly Turbo Pascal before that. A huge attraction of Python was the libraries -- scipy, matplotlib, etc. In fact when a lot of people say they're using "Python," they're actually referring to Python plus a large collection of libraries that came from somewhere. It's the community. Network effect looms large. While typing is dynamic, I rarely see this being used, perhaps with the exception of identifying empty variables with None. Most identifiers are born and die the same type. It would be interesting to see how much effect dynamic typing has on the rate of programming errors. Also, for me, Jupyter is huge.
- cpeterso 4y ago
  I suspect the same. People adopt Python because its clean syntax and REPL make the language approachable and easy to get started and then the huge library ecosystem helps you glue together (in a good way) powerful systems. But how many Python users and libraries actually use the language’s extremely dynamic runtime behavior? Something they’re paying for with a big performance penalty and surprising bugs.
  - gilch 4y ago
    Numpy uses magic methods (Python's version of operator overloading). Django uses metaclasses. Pytest dynamically rewrites assert statements using AST. I'd say it's pretty common, at least in libraries. I certainly depend on Python's dynamism when fully leveraging the REPL.
    - analog31 4y ago
      Indeed, these capabilities of the language are some of its strengths, even if we don't all trust ourselves to use them. The casual programmer doesn't know how or why numpy works, and we don't play with magic methods except out of curiosity. The people who do maintain numpy are using more formal methods to ensure its quality. In the case of Python, the things that professional caliber programmers can use to extend its functionality, and the things that the rest of us can use to be productive, are the same language and are not hidden from one another. This is not the case in some languages of the past, e.g., you could use objects in Visual Basic but not build them without another language or eventually a special version.
VectorLock 4y ago
>ensuring I don't break anything by making changes I think this is a problem in both static and dynamic languages and is pretty much solved in the same way: you test your code.
- toomanydoubts 4y ago
  But is it the same problem, really? Static typing eliminates a whole class of issues that dynamic typed languages don't. Of course you can still have logical bugs, but it's definitely not the same thing. I don't know how to put it better, but you should try writing haskell sometime and you'll see what I mean.
  - gilch 4y ago
    And static languages introduce a whole class of issues that dynamic languages don't have to deal with. You have to learn a separate metalanguage just for the types that isn't expressive enough to do things that are easy in a dynamic language, and even if it were, you'd still have to write everything twice: once in the real language, and once again in the type language. And then you still have to test, don't pretend you don't. If tests are both necessary and sufficient, then why bother with the type language? The static typing is not worth the cost.
    - hsbauauvhabzb 4y ago
      So why not static with the ability to ignore hinting or similar? C# does this. I think function definitions should be statically defined, but the actual body of a function could easily stay largely dynamic.
      - gilch 4y ago
        I do think that's helpful compared to the strict alternative, but much of the up-front cost is still there. You still write most things twice, and the static type checker still slows you down when prototyping. You'd still be tempted to write bad code to work around the insufficiently-expressive type language, rather than write it in the most natural way, and only give up when it's too hard. You can also approach this from the other direction: why not start with a dynamic language for the rapid prototyping and gradually introduce typing as the code stabilizes? Python and Typescript do this.
qsort 4y ago
- Huge ecosystem. - Common stuff (opening files, dealing with databases, string processing, math, regexps) is very easy. Sane defaults. - Works well with the existing C ecosystem. It's not a "rewrite everything in X" language. - It's everywhere, most machines run Python just fine. - It doesn't treat Windows like a second-class citizen. - It doesn't force upon you a programming model that you might or might not care about. It's not a puzzle language where everything is a monad, or everything is a class, or everything is some weird widget. Write the damn code. - I'm personally not a fan of the language itself, but it's mostly a bog-standard algol if you don't poke it too much. It's relatively standard, people just get it even if Python isn't their main language. - Very personal point, but it's the only language I can edit with a plain text editor. Think nano, vi, Windows Notepad, that kind of thing. I don't know what to tell you, maybe it's my tiny monkey brain, but I can't do the same in Java or C++. Not that it's my preferred way to edit software, but I like having that option in a pinch. At least for what I do (developer, but with a data engineering/data science flavor) the overall architecture is usually the important thing, so admittedly some downsides might hit me less. I'd still rather write medium-to-large pieces of software (say 10,000+ LOC) in something else (Java, C#, C++, something boring like that), but it's pretty much unbeatable for small programs as far as I'm concerned.
- fezfight 4y ago
  To be fair, Microsofts citizen status is self inflicted. There was a time when they were actively hostile to programming languages not built in house. See, for example, Java. https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...
  - pjmlp 4y ago
    Nah, it is only for UNIX folks that see UNIX everywhere, and start complaing when an OS isn't POSIX compatible. Even on those days there were always Java alternatives to chose from, J++ wasn't required.
    - fezfight 4y ago
gilch 4y ago
Python is statically typed though. [1][2][3][4] These aren't just some third-party tools bolted on. The type annotation syntax is built into the language[5] and standard library[6][7]. I personally find static typing to be more trouble than it's worth most of the time. Industry typing metalanguages are not expressive enough to deal with even fairly basic real-world programs and force you to write bad code to work around the type checker's stupidity. And, of course, you still have to write tests. Maybe someday they'll catch up to Idris. Python's static typing is no better, but at least it allows you to turn it off when it's not worth it. [1]: https://github.com/microsoft/pyright https://github.com/microsoft/pyright [2]: https://github.com/python/mypy https://github.com/python/mypy [3]: https://github.com/google/pytype https://github.com/google/pytype [4]: https://github.com/facebook/pyre-check https://github.com/facebook/pyre-check [5]: https://peps.python.org/pep-3107/ https://peps.python.org/pep-3107/ [6]: https://peps.python.org/pep-0484/ https://peps.python.org/pep-0484/ [7]: https://docs.python.org/3/library/typing.html#module-typing https://docs.python.org/3/library/typing.html#module-typing
- still_grokking 4y ago
  > Industry typing metalanguages are not expressive enough to deal with even fairly basic real-world programs and force you to write bad code to work around the type checker's stupidity. I honestly don't see that. Could you provide some examples?
agumonkey 4y ago
casual and fast prototyping now you can have succint code and fast repl (ala sml) but you don't get the libs
gilch 4y ago
Anecdote, but I like the Python community's emphasis on "readability counts". I did not get that from e.g. Ruby. Python's internals are also relatively accessible and easy to work with, so it's smooth sailing once you have that need. The language starts out easy, and grows with you. Of the languages I've tried (and there are many), only Smalltalk and the Lisp family were comparable in expressiveness. The language mostly gets out of my way and lets me do what I want. I don't feel like I have to fight the compiler (at least until I tried Mypy) or write a lot of tediously verbose boilerplate just to get out a "Hello, World!" like I did in Java. Unlike, say, JavaScript, Python is pretty strongly typed and fails fast. The stack traces almost always point you to the exact location of the problem (unlike the JS tendency to propagate `undefined` everywhere). There aren't a lot of surprises or gotchas. I can pretty much run it in my head just by reading the code and be right most of the time. I cannot say the same for C++ or JavaScript, which naturally tend to become inscrutable without discipline.
- smt88 4y ago
  Python is among the least-readable languages for me. The lack of whitespace and brackets around code blocks just make it look like the "wall of text" that everyone hates in emails. And then there's the fact that Python has significant characters that are literally unreadable because they're invisible (semantic whitespace).
  - maleldil 4y ago
    I never got the point against meaningful whitespace. It's indentation. You already indent blocks anyway; the only difference is that you don't need braces or begin/end. I also did not understand your point about "lack of whitespace" around blocks. The only difference between blocks in Python and other languages is that the block start uses a colon instead of an opening brace and you don't have a line for the closing brace. Is that closing line such a big deal for you?
    - alpaca128 4y ago
      As someone who recently switched to opening curly brackets on new lines and did some Python coding last week I kind of agree - you either put in empty lines everywhere or you have a continuous block of code through all scopes. It's a matter of preference and you can still work with it of course, but I've learned to appreciate reducing code density. And regarding the syntax, using curly brackets like in C-like languages only takes one more symbol per scope and the difference in readability (where a scope ends etc.) is bigger for me. Also while indentation in Python kind of works as syntax it's not ideal as it can lead to literally invisible syntax errors, and imho the syntax isn't strict enough as Python allows you to have a different indentation width in every single scope. That said it's still a great language for little experiments. Similar to Bash, despite Bash being not the best designed language to put it mildly.
smitty1e 4y ago
I think in python very easily.
dbrueck 4y ago
Many reasons, many are of course pretty subjective, but it's been called 'executable pseudocode' for good reason. Out of all the languages I've used, it gets in the way the least, and often by a pretty wide margin. I agree that working with Python code from an undisciplined/sloppy/inexperienced developer can be a pain (although in those situations I've found code from those same developers in others languages to be a problem too, but maybe worse in Python? I dunno), but in the hands of a solid dev, Python code is so readable and easy to follow, that to me code in other languages often feels much noisier. YMMV of course.
the__alchemist 4y ago
- 1 Numpy and Scipy are nice for both scripting, and as a super-calculator with ipython. (albeit poorly documented) - Django is a robust, batteries-included web framework that doesn't have an analog in, for example, Rust.
GlennS 4y ago
Honestly I guess it's just a difference in taste/demenour. My background was originally in C# then Java (plus JavaScript on the side, since most of us have to do that), and when I first came to Python I found it to be a lovely language and a breath of fresh air. I guess I would say to me it feels neat and tidy, thoughful about interface design, and gives me a sense of quality. I get a similar feeling from Clojure (perhaps even more so). I don't find static typing as valuable as you do, and additionally I find the cost in verbosity and in time wasted solving type-checking puzzles quite painful. Perhaps if I'd spent more time with one of the more sophisticated type systems I'd feel differently (Java and C# are quite limited here), but not convinced enough to try.
jillesvangurp 4y ago
Amateur coders always have flocked to the simple and unfashionable stuff. Basic used to be big for this reason. Javascript took off for this reason as well. Web designers could just copy paste javascript fragments in their web pages and get some simple things working. And python seems to appeal to a lot of amateur coders with non computer science backgrounds. At least I know a lot of people with physics, chemistry, bio medical, etc. backgrounds that seem to mainly know python. Objectively, none of these languages are particularly good at what they do and there are other languages that tend to be preferred by people who code for a living. But these are harder to learn and have higher barrier for entry. You typically need some theoretical background and experience. I've used all of the above BTW. I learned programming using the manual that came with my Commodore 64 in the eighties (Basic, obviously). I kind of like Python for some things. Javascript is fine for simple things. None of these are my first choice of language but I can work with these languages. They are very approachable languages. Just open an editor and start adapting code. There's a lot of language snobbery out there where objectively, the advantages aren't that huge or dramatic as people like to believe.

codedokode 4y ago

Because you can do a lot with little typing and there are lots of great libraries. Python is probably the best choice when you need to get something done quick or calculate something when performance is not important. It is also not an exotic functional language without loops and filled with linked lists. Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages. If you name a language, with high probability Python will be better in something unless it is about performance. What I don't like: no type hints in many libraries, some libraries are not type-hint friendly, lot of unnecessary dynmamic features (like being able to patch modules in runtime) and absolutely no caring about performance and being able to compile into machine code. > trying to figure out what some dynamically typed code is doing There should be type hints.

toomanydoubts 4y ago
>There should be type hints. "Hey, this variable is probably of this type. Now go on, run the code and launch a debugger the same way you would if there was no hint just to make sure it's correct. Oh, and don't forget to check all the possible code paths that lead to this to make sure you've exhausted all possibilities." Don't get me wrong, type hints are cool but they're just a toy compared to proper static typing.
- joshuamorton 4y ago
  > Oh, and don't forget to check all the possible code paths that lead to this to make sure you've exhausted all possibilities." This is literally what mypy does. There's no difference between a mypy-enabled codebase and a java codebase in terms of static typing (other than that mypy actually supports a generally richer type system). Like yes if you aren't validating the type hints you aren't getting the value, but if you are, you don't need to run the code! I get most of my python errors at compile time, and you can too. I promise.
  - FridgeSeal 4y ago
    Sorry, but MyPy and friends can barely hold a candle to what actual static-typing systems do - Rust, Haskell, OCaml, Typescript, even .Net (C#/F#) offer more safety and guarantees. Type hints in python are _just that_, they're hints. The whole "typed" python ecosystem relies on packages and the language using them, using them correctly, and using them consistently. In my experience so far, I've seen little widespread use, and nothing from core python, which is a huge hole IMO.
    - joshuamorton 4y ago
      > Sorry, but MyPy and friends can barely hold a candle to what actual static-typing systems do - Rust, Haskell, OCaml, Typescript, even .Net (C#/F#) offer more safety and guarantees. Note that you don't include the most common static languages there (cpp, java, golang), you include languages known *specifically " for their extremely powerful type systems, one of which , just like mypy, uses gradual typing! This supports my argument!
      - FridgeSeal 4y ago
        I mean sure, we can include C++, go and java in there if you want? I don’t really know what the point you’re making here is? > one of which , just like mypy, uses gradual typing! This is like arguing that because your scooter also has a petrol engine, it’s as fast and efficient as an F1 car. My argument was that MyPy doesn’t compete with the capabilities of modern statically typed languages. TS might also technically be gradually typed, but most devs I know just go straight to fully typed TS, because working in a mix/gradual environment is painful and the community uptake of strict types is far higher.
        joshuamorton 4y ago
        What features that Javas type system provides does pythons lack? I can name dozens that python has that Java doesn't. My point is that if you include cpp or java or golang the statement becomes false. Python's type system is actually generally speaking more robust than those (cpp is comparable, but I don't think python's is worse). So I'm asking, be specific what capabilities does mypy lack that cpp or java or golang provide? Keep in mind, mypy supports literal types, limited dependent types, dynamic-duck typing (protocols), limited contract types, and more. Java doesn't, go doesn't. Cpp supports some of those but it requires arcane incantations.
toomanydoubts 4y ago
>no type hints in many libraries, some libraries are not type-hint friendly. >There should be type hints. So, is it one or the other?
peaky_blinder 4y ago
> Also, in Python integers do not overflow, unlike in Rust, C and other buggy languages. There is no such thing as a buggy language. Software can be buggy (or language implementation), but not the language. And the reason you do not have integer overflow is because integers are implemented as integer objects of arbitrary size, which is great if you're doing something quick and dirty, but could be disastrous for a serious work.
- still_grokking 4y ago
  > There is no such thing as a buggy language. How can you know if you don't have a verified formal description of your language's semantics? It's very much possible (and imho even quite likely) that a lot of language definitions are self contradicting. Of course one could argue that such self contradictions aren't "bugs" at all. But such an argumentation would seem very odd, imho, no matter one can actually "define" whatever one likes.
  - hnfong 4y ago
    http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-... > Signed integer overflow: If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN. Probably not what the GP meant, but I think this qualifies as a "buggy language (spec)"
    - still_grokking 4y ago
      I don't think defining something as undefined is buggy per se. That's not what I've meant. But defining some things in a contradicting manner would make up a buggy spec, I guess. Regarding the int example, funny enough I made a comment about that just before here: https://news.ycombinator.com/item?id=32457056 https://news.ycombinator.com/item?id=32457056
- dannymi 4y ago
  >could be disastrous for a serious work. How so?
elcritch 4y ago
Wow, I thought Rust's integers would let you handle integer overflows.. Apparently thats not the case and overflows are only checked in debug builds and then they just panic. Huh. After programming in Nim (and Python back in the day), I've become used to being able to detect integer overflows as a normal exception. At least for signed ints, since not all CPU support efficient overflow detection on unsigned ints. Its handy to to let uints wrap as sometimes thats what you want. I figured all new languages would do similar things.
- bobbylarrybobby 4y ago
  Rust has a variety of checked methods -- `checked_add` etc -- that allow for fallible int operations. And there are corresponding `wrapping_` versions that indicate wrapping is the correct behavior (and shouldn't panic in debug builds).
chaxor 4y ago
What i don't like about python: The goddamn versioning and packaging problems. About 5 years ago python was incredible. You could pop out a project quickly because there were very few packages that made breaking changes over their development, so you could often use your standard workflow with the set of packages you we're comfortable with, even if there were new versions available that day. Now, Nvidia and Google ruined everything. Python is the ML language, so every package likely depends somehow on tensorflow or some GPU acceleration. This is a problem because every damn version of ' insert tf/pytorch/Jax/cuda/etc ml package here' only works with that exact version configuration ONLY ( and honestly, it probably doesn't actually work anyway). So, if you have an idea of using two packages together that aren't already in a package - be prepared to spend the next month trying in despair to get that to work (and probably ultimately give up). It's insane to me that the workflow of today necessitates (in python anyway) setting up multiple docker containers to talk to each other, simply because python packages seem to have no problem making breaking changes every freaking week.
- echelon 4y ago
  I feel this comment in my bones. I went from loving Python to hating it with a seething rage. Python package managers are all so bad that the only reasonable solution is Docker containers or vendoring everything (not easy). And even so, I've had untouched Docker builds still die because dependencies mysteriously get yanked or changed. God, I hate Python so much now.
  - still_grokking 4y ago
    If you like the look & feel of Python, but not the ecosystem: https://docs.scala-lang.org/scala3/book/scala-for-python-devs.html https://docs.scala-lang.org/scala3/book/scala-for-python-dev... Sorry for that quite random comment, but SCNR.
    - theblazehen 4y ago
      Thanks for that! I've heard about scala before, never investigated it. I'm really looking the like of it now
kevin_thibedeau 4y ago
Overflowing integers is not a bug. It's literally how an adder circuit operates on fixed precision. Ignoring them by default is worth criticizing but there are plenty of times where silent overflow is correct and desirable behavior.
- tomp 4y ago
  It's technically not a "bug" in Rust or C++, it's undefined behaviour, which is much worse than a bug! (and it's never correct behaviour)
  - still_grokking 4y ago
    Little nitpick: In C/C++ it's "only" UB for signed ints. For unsigned ints it's arithmetic modulo 2^n (where n is the number of bits in the value representation of that particular size of integer). Such divergent definitions make the whole mess of course even bigger, that's not the point.
    - pratk 4y ago
      Also, the UB can be mitigated with -fwrapv (if desired) to handle overflowing integers with 2's complement
      - still_grokking 4y ago
        Stupid question, but how can a compiler flag "mitigate" some UB that is (to my knowledge) defined by the standard as UB? This would be possible only if the standard would define the behavior in question as implementation defined. But that's not the case afaik. Signed overflow is undefined behavior as it's afaik defined to be that. But maybe I'm just wrong here? But at least SO is confining my knowledge: https://stackoverflow.com/questions/16188263/is-signed-integer-overflow-still-undefined-behavior-in-c https://stackoverflow.com/questions/16188263/is-signed-integ...
        4y ago
HdS84 4y ago
For runtime patching: I needed that twice: First there was a bug in the stdlib event log logging for windows which crashed when the user was not an admin (2.7 days). We could monkey patch that problem on the fly which was much better than any alternative. Second I needed to redirect scikitlearn logging to a file. Which did not work because scikit does not use logging but something homegrown. We just overwrite the internal log function and all was good. Yes it's seldom needed and it's a very sharp sword but it's much better that it's there when you need it. I encountered bugs in .net stdlib which where there was no alternative than to wait for the next release. Very ugly when you need to ship.
dexterlemmer 4y ago
Type hints and static typing are completely orthogonal. It is merely more common for the designers of dynamically typed languages to make the mistake of not allowing type hints pretty much every where and requiring them in a library's API (or at least linting for them being missing in the API) than making the same mistake is for the designers of staically typed languages.

sdeframond 4y ago

I believe dynamically typed languages are easier to use than old-style statically typed langages (Java, C, etc). More modern statically typed languages can be quite easy to use (I am thinking of Scala) but none provides an ecosystem as rich as python's. Plus, recent static languages (Scala, Rust, Haskell or even Elm) are more oriented toward "Software Engineers" or CS academics. Python appeals to a lot of "programmers" who's main job is actually data science, mechanical engineering, biologist...

epgui 4y ago
I think the latter point hits the nail right on the head: the preference for python is probably more of a social issue than a technical one at this particular point in History. I think when FP languages and paradigms become the norm (you can quote me on this, I predict that it's only a matter of time), preferences will change. People tend to prefer what they know, and it will take some time for culture to change.
gilch 4y ago
I found Scala horribly overwrought compared to either Java or Haskell. It's like it tried to mush together two different type systems and got the worst of both worlds. Languages do not need to be that complex. My next JVM language was Clojure, and I've never looked back. I'd try Kotlin before I'd go back to Scala.

analog31 4y ago

I have a hunch that a lot of Python users didn't carefully evaluate the language on its merits, but rather, just started using it. In my own case, I was using Visual Basic 6 before Python, and mostly Turbo Pascal before that. A huge attraction of Python was the libraries -- scipy, matplotlib, etc. In fact when a lot of people say they're using "Python," they're actually referring to Python plus a large collection of libraries that came from somewhere. It's the community. Network effect looms large. While typing is dynamic, I rarely see this being used, perhaps with the exception of identifying empty variables with None. Most identifiers are born and die the same type. It would be interesting to see how much effect dynamic typing has on the rate of programming errors. Also, for me, Jupyter is huge.

cpeterso 4y ago
I suspect the same. People adopt Python because its clean syntax and REPL make the language approachable and easy to get started and then the huge library ecosystem helps you glue together (in a good way) powerful systems. But how many Python users and libraries actually use the language’s extremely dynamic runtime behavior? Something they’re paying for with a big performance penalty and surprising bugs.
- gilch 4y ago
  Numpy uses magic methods (Python's version of operator overloading). Django uses metaclasses. Pytest dynamically rewrites assert statements using AST. I'd say it's pretty common, at least in libraries. I certainly depend on Python's dynamism when fully leveraging the REPL.
  - analog31 4y ago
    Indeed, these capabilities of the language are some of its strengths, even if we don't all trust ourselves to use them. The casual programmer doesn't know how or why numpy works, and we don't play with magic methods except out of curiosity. The people who do maintain numpy are using more formal methods to ensure its quality. In the case of Python, the things that professional caliber programmers can use to extend its functionality, and the things that the rest of us can use to be productive, are the same language and are not hidden from one another. This is not the case in some languages of the past, e.g., you could use objects in Visual Basic but not build them without another language or eventually a special version.

VectorLock 4y ago

>ensuring I don't break anything by making changes I think this is a problem in both static and dynamic languages and is pretty much solved in the same way: you test your code.

toomanydoubts 4y ago
But is it the same problem, really? Static typing eliminates a whole class of issues that dynamic typed languages don't. Of course you can still have logical bugs, but it's definitely not the same thing. I don't know how to put it better, but you should try writing haskell sometime and you'll see what I mean.
- gilch 4y ago
  And static languages introduce a whole class of issues that dynamic languages don't have to deal with. You have to learn a separate metalanguage just for the types that isn't expressive enough to do things that are easy in a dynamic language, and even if it were, you'd still have to write everything twice: once in the real language, and once again in the type language. And then you still have to test, don't pretend you don't. If tests are both necessary and sufficient, then why bother with the type language? The static typing is not worth the cost.
  - hsbauauvhabzb 4y ago
    So why not static with the ability to ignore hinting or similar? C# does this. I think function definitions should be statically defined, but the actual body of a function could easily stay largely dynamic.
    - gilch 4y ago
      I do think that's helpful compared to the strict alternative, but much of the up-front cost is still there. You still write most things twice, and the static type checker still slows you down when prototyping. You'd still be tempted to write bad code to work around the insufficiently-expressive type language, rather than write it in the most natural way, and only give up when it's too hard. You can also approach this from the other direction: why not start with a dynamic language for the rapid prototyping and gradually introduce typing as the code stabilizes? Python and Typescript do this.

qsort 4y ago

- Huge ecosystem. - Common stuff (opening files, dealing with databases, string processing, math, regexps) is very easy. Sane defaults. - Works well with the existing C ecosystem. It's not a "rewrite everything in X" language. - It's everywhere, most machines run Python just fine. - It doesn't treat Windows like a second-class citizen. - It doesn't force upon you a programming model that you might or might not care about. It's not a puzzle language where everything is a monad, or everything is a class, or everything is some weird widget. Write the damn code. - I'm personally not a fan of the language itself, but it's mostly a bog-standard algol if you don't poke it too much. It's relatively standard, people just get it even if Python isn't their main language. - Very personal point, but it's the only language I can edit with a plain text editor. Think nano, vi, Windows Notepad, that kind of thing. I don't know what to tell you, maybe it's my tiny monkey brain, but I can't do the same in Java or C++. Not that it's my preferred way to edit software, but I like having that option in a pinch. At least for what I do (developer, but with a data engineering/data science flavor) the overall architecture is usually the important thing, so admittedly some downsides might hit me less. I'd still rather write medium-to-large pieces of software (say 10,000+ LOC) in something else (Java, C#, C++, something boring like that), but it's pretty much unbeatable for small programs as far as I'm concerned.

fezfight 4y ago
To be fair, Microsofts citizen status is self inflicted. There was a time when they were actively hostile to programming languages not built in house. See, for example, Java. https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...
- pjmlp 4y ago
  Nah, it is only for UNIX folks that see UNIX everywhere, and start complaing when an OS isn't POSIX compatible. Even on those days there were always Java alternatives to chose from, J++ wasn't required.
  - fezfight 4y ago

gilch 4y ago

Python is statically typed though. [1][2][3][4] These aren't just some third-party tools bolted on. The type annotation syntax is built into the language[5] and standard library[6][7]. I personally find static typing to be more trouble than it's worth most of the time. Industry typing metalanguages are not expressive enough to deal with even fairly basic real-world programs and force you to write bad code to work around the type checker's stupidity. And, of course, you still have to write tests. Maybe someday they'll catch up to Idris. Python's static typing is no better, but at least it allows you to turn it off when it's not worth it. [1]: https://github.com/microsoft/pyright https://github.com/microsoft/pyright [2]: https://github.com/python/mypy https://github.com/python/mypy [3]: https://github.com/google/pytype https://github.com/google/pytype [4]: https://github.com/facebook/pyre-check https://github.com/facebook/pyre-check [5]: https://peps.python.org/pep-3107/ https://peps.python.org/pep-3107/ [6]: https://peps.python.org/pep-0484/ https://peps.python.org/pep-0484/ [7]: https://docs.python.org/3/library/typing.html#module-typing https://docs.python.org/3/library/typing.html#module-typing

still_grokking 4y ago
> Industry typing metalanguages are not expressive enough to deal with even fairly basic real-world programs and force you to write bad code to work around the type checker's stupidity. I honestly don't see that. Could you provide some examples?

agumonkey 4y ago

casual and fast prototyping now you can have succint code and fast repl (ala sml) but you don't get the libs

gilch 4y ago

Anecdote, but I like the Python community's emphasis on "readability counts". I did not get that from e.g. Ruby. Python's internals are also relatively accessible and easy to work with, so it's smooth sailing once you have that need. The language starts out easy, and grows with you. Of the languages I've tried (and there are many), only Smalltalk and the Lisp family were comparable in expressiveness. The language mostly gets out of my way and lets me do what I want. I don't feel like I have to fight the compiler (at least until I tried Mypy) or write a lot of tediously verbose boilerplate just to get out a "Hello, World!" like I did in Java. Unlike, say, JavaScript, Python is pretty strongly typed and fails fast. The stack traces almost always point you to the exact location of the problem (unlike the JS tendency to propagate `undefined` everywhere). There aren't a lot of surprises or gotchas. I can pretty much run it in my head just by reading the code and be right most of the time. I cannot say the same for C++ or JavaScript, which naturally tend to become inscrutable without discipline.

smt88 4y ago
Python is among the least-readable languages for me. The lack of whitespace and brackets around code blocks just make it look like the "wall of text" that everyone hates in emails. And then there's the fact that Python has significant characters that are literally unreadable because they're invisible (semantic whitespace).
- maleldil 4y ago
  I never got the point against meaningful whitespace. It's indentation. You already indent blocks anyway; the only difference is that you don't need braces or begin/end. I also did not understand your point about "lack of whitespace" around blocks. The only difference between blocks in Python and other languages is that the block start uses a colon instead of an opening brace and you don't have a line for the closing brace. Is that closing line such a big deal for you?
  - alpaca128 4y ago
    As someone who recently switched to opening curly brackets on new lines and did some Python coding last week I kind of agree - you either put in empty lines everywhere or you have a continuous block of code through all scopes. It's a matter of preference and you can still work with it of course, but I've learned to appreciate reducing code density. And regarding the syntax, using curly brackets like in C-like languages only takes one more symbol per scope and the difference in readability (where a scope ends etc.) is bigger for me. Also while indentation in Python kind of works as syntax it's not ideal as it can lead to literally invisible syntax errors, and imho the syntax isn't strict enough as Python allows you to have a different indentation width in every single scope. That said it's still a great language for little experiments. Similar to Bash, despite Bash being not the best designed language to put it mildly.

smitty1e 4y ago

I think in python very easily.

dbrueck 4y ago

Many reasons, many are of course pretty subjective, but it's been called 'executable pseudocode' for good reason. Out of all the languages I've used, it gets in the way the least, and often by a pretty wide margin. I agree that working with Python code from an undisciplined/sloppy/inexperienced developer can be a pain (although in those situations I've found code from those same developers in others languages to be a problem too, but maybe worse in Python? I dunno), but in the hands of a solid dev, Python code is so readable and easy to follow, that to me code in other languages often feels much noisier. YMMV of course.

the__alchemist 4y ago

- 1 Numpy and Scipy are nice for both scripting, and as a super-calculator with ipython. (albeit poorly documented) - Django is a robust, batteries-included web framework that doesn't have an analog in, for example, Rust.

GlennS 4y ago

Honestly I guess it's just a difference in taste/demenour. My background was originally in C# then Java (plus JavaScript on the side, since most of us have to do that), and when I first came to Python I found it to be a lovely language and a breath of fresh air. I guess I would say to me it feels neat and tidy, thoughful about interface design, and gives me a sense of quality. I get a similar feeling from Clojure (perhaps even more so). I don't find static typing as valuable as you do, and additionally I find the cost in verbosity and in time wasted solving type-checking puzzles quite painful. Perhaps if I'd spent more time with one of the more sophisticated type systems I'd feel differently (Java and C# are quite limited here), but not convinced enough to try.

jillesvangurp 4y ago

Amateur coders always have flocked to the simple and unfashionable stuff. Basic used to be big for this reason. Javascript took off for this reason as well. Web designers could just copy paste javascript fragments in their web pages and get some simple things working. And python seems to appeal to a lot of amateur coders with non computer science backgrounds. At least I know a lot of people with physics, chemistry, bio medical, etc. backgrounds that seem to mainly know python. Objectively, none of these languages are particularly good at what they do and there are other languages that tend to be preferred by people who code for a living. But these are harder to learn and have higher barrier for entry. You typically need some theoretical background and experience. I've used all of the above BTW. I learned programming using the manual that came with my Commodore 64 in the eighties (Basic, obviously). I kind of like Python for some things. Javascript is fine for simple things. None of these are my first choice of language but I can work with these languages. They are very approachable languages. Just open an editor and start adapting code. There's a lot of language snobbery out there where objectively, the advantages aren't that huge or dramatic as people like to believe.