7 ms·

My opinion is that python shouldn't be used for mission- critical systems anyway.

by astrea 7y ago

traverseda 7y ago
Aside from static types, why?
- jraph 7y ago
  One thing I dislike in Java is the string comparison. If you write str1 == str2, it compiles but probably does not do what you want (object identity vs string comparison). (edit: to clarify, this does not mean Java is not a good language overall, every language has its own set of shortcomings and as someone points out in the replies, this behavior is consistent with everything else in the language)
  - weberc2 7y ago
    It’s been a while since I used Java, but what on earth does that string comparison do if not comparing the strings? Is it an address-only comparison?
    - dpratt 7y ago
      Yes, and this is entirely consistent with the overall design of the language. The ‘==‘ does not have a special overload for String instances, which are reference types just like any other in the JVM. The equals operator does a reference comparison, just as it should. If you want to do a logical comparison of instances, you use the equals() method just as you would for anything else. Frankly, if this is the most meaningful complaint you can come up with, it might be indicative that you haven’t learned enough about it to have an informed opinion.
      - CamouflagedKiwi 7y ago
        It isn't at all consistent, because integer types compare correctly with == and do not have a .equals() method. And regardless of consistency, if it's a mistake people make frequently with the language and need to learn not to do the obvious thing, it's probably not an ideal bit of design.
        dpratt 7y ago
        In java (and every other C derived language that I know of) there’s a hard and explicit distinction between reference and primitive types. In fact, from a certain perspective the two flavors get treated identically. Comparing two integers with ‘==‘ will be true if the contents of the variables are the same, and comparing two references will be true if the pointers they contain are the same value. It just so happens that for primitives identity and logical equality are the same thing.
        weberc2 7y ago
        C, C++, Rust, Go, etc have no special distinction between reference types and primitive types but rather everything is a value and some values are pointers/references. In a language with operator overloading, I don’t see why you’d ever want to check string identity by default. Interestingly, Go doesn’t have operator overloading but it treats strings as a special case including doing a string comparison for ==. Not saying this is better or worse, although no one makes mistakes with string comparison as far as I’m aware, for whatever that is worth.
        CamouflagedKiwi 7y ago
        That special case isn't specifically for strings - you can also compare arrays, channels and structs that way (as long as the array/struct doesn't contain anything non-comparable). Unfortunately it's a rarer footgun though since it can panic when comparing interfaces :(
        int_19h 7y ago
        The flaw in Java design is that String is a reference type. Logically, it's a value, and should be treated as such (and not copying the underlying data should be an implementation detail). The problem is that in Java, there are no user-defined value types, only primitives; and primitives can't have methods. So if it were a primitive, you'd have to write "String.length(s)" etc. Also, all other Java primitives are basically bit sequences that are interpreted in one way or another, but that wouldn't be the case for strings. .NET/C#, though, doesn't get that excuse. It totally could have defined String as a struct with an internal char[] field, and then there would be no question of value/reference equality for its ==. But that would also mean that you couldn't use null for strings - and they didn't have nullable value types back then. I suspect that, plus the overall mindset carried over from Java, is what won the day. Side note: there's no hard and explicit distinction between reference and primitive types in C itself, nor in C++. If Python is "everything is an object reference", and Java is "everything is an object reference except for primitives that are values", then C++ is "everything is a value, including object references". Thus, there's no ambiguity with == in C++ - it always compares values, it's just that sometimes those values are pointers. I think sometimes that perhaps the implicitness of object references that is so common to OO languages, that I think was introduced by Smalltalk, is a mistake. It's interesting that Simula-67 didn't have it - although it was very Java-like otherwise, having only primitive values and references to objects (i.e. no objects as values, like C++), it distinguished the two consistently by using distinct equality operators (= vs ==), and even distinct assignments (:= vs :-). Or, alternatively, treat everything as an object reference, but make == do implicit dereferencing as well, as Python and VB do; and provide a completely distinct operator for reference equality, such as "is". Python has a problem in that regard in that it has a default implementation of == for all classes that compares references, and so it ends up used as reference equality in practice sometimes. It would be better to have no default for == at all, just as there's no default for other comparison operators; this is what VB does. It might also be best to stop talking about value and reference types altogether - what's actually important is the presence or absence of identity. Then everything can be an object reference, but not all object references can be compared for equality (and in practice, under the hood, the implementation can just skip the references and copy the data itself - or not, depending on mutability and size).
      - kevin_thibedeau 7y ago
        They have a magic overload for '+'. Consistency wasn't much of a priority.
      - andybak 7y ago
        > The ‘==‘ does not have a special overload for String instances As a non-Java developer I have to ask why you think this is a reasonable design choice. It's a massive footgun for the a casual polyglot Java developer. I can imagine just forgetting I can't do == if I've just switched from being immersed in another language.
        dpratt 7y ago
        It’s precisely the same behavior you would get with C, C++, C# for references, with C# defaulting the ‘==‘ operator to short-circuit to ReferenceEquals() unless otherwise re-defined.
        andybak 7y ago
        > with C# defaulting the ‘==‘ operator Which is surely the important bit. I can just use "==" in C#.
    - deleted 7y ago
      [deleted]
    - recursivecaveat 7y ago
      Yes, it's an object-identity comparison, not a logical one. Worse, you can sometimes get spurious true results due to optimization.
dfee 7y ago
I’m on the other side; having gotten deeper into languages like c# and java; I think those technologies are vastly over used, and great languages like Python and Typescript are under used.
- weberc2 7y ago
  How do you figure? If it’s mission critical, it means failure is unacceptable. Python and other dynamic languages (TS is a middle ground here) excel when failure isn’t so bad and making and deploying changes is fast/easy/cheap. This is exactly the wrong tradeoff for mission critical systems.
  - igor47 7y ago
    Why do dynamic languages excel when failure is not so bad? What makes non-dynamic (compiled?) languages better when failure is bad? I'm parsing your comment to mean, "it's easier to write correct code in compiled languages", but this is not obvious to me, or anyone who's, for instance, written any C at all.
    - Reelin 7y ago
      C is the wrong comparison to make here - it's extremely low level. Java or perhaps C++ would be much closer. * Ahead of time compiled languages reduce flexibility but allow the compiler to do more reasoning about the system. * Statically typed languages allow the compiler to reason about the assignments you make and methods you call. If the language is also AOT compiled, you avoid crashing at runtime. * Dynamically typed languages significantly reduce boilerplate and avoid the mental effort of expressing an idea in a rigorously typed manner. It's the "hold my beer" approach.
      - pytester 7y ago
        C is a good example precisely because it highlights the fact that explicit typecasts and memory safety are a LOT better at preventing bugs than static types.
    - 7y ago
1e10 7y ago
Why? Seems that it is a well proven language. Just like php, asp.net, and other languages people like to hate on. Or rather, how would you define mission critical?
jtdev 7y ago
Care to elaborate? Which languages would you use for mission-critical systems? What specifically about Python is not conducive to such systems? You realize that many mission-critical workloads run on Python with great success, right?
- deleted 7y ago
  [deleted]
senko 7y ago
That depends on the mission, wouldn't you say?
staticassertion 7y ago
People are gonna dogpile you, but if you'd said this about JS they wouldn't have blinked.
- pytester 7y ago
  Coz there's a difference between "dynamic type system" and "type system that's thrown together with bits of string and rubber bands": https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
  - staticassertion 7y ago
    Python has is own 'wat' stuff, especially Python 2. https://stackoverflow.com/questions/3270680/how-does-python-2-compare-string-and-int-why-do-lists-compare-as-greater-than-n https://stackoverflow.com/questions/3270680/how-does-python-... "CPython implementation detail: Objects of different types except numbers are ordered by their type names; objects of the same types that don’t support proper comparison are ordered by their address."
    - pytester 7y ago
      None of those surprising behaviors exist in python 3. I wouldn't say "100" < "2" really counts, since, alphabetically it makes sense (an equivalent would be "baa" < "c").
      - staticassertion 7y ago
        Yes, Python2 was called out explicitly. Reference equality is definitely 'wat' shit IMO, though it's really mainstream too.
    - detaro 7y ago
      > objects of different types always compare unequal, and are ordered consistently but arbitrarily Seems like a completely reasonable thing to do?
HALtheWise 7y ago
Would you rather build safety-critical systems in Python (type-unsafe but memory-safe) or C++(type-safe but memory-unsafe)? While static typing does catch code errors, in my experience they are mostly errors that would be caught somewhere else in the testing process. Memory safety issues are rarer, but also have a penchant for showing up unexpectedly and for crashing the entire system in unrecoverable ways. Obviously, the best would be to have both kinds of safety, but people program safety critical systems in C++ all the time, and deal with the consequences. At least you can catch a TypeError in Python and handle it.
- ailideex 7y ago
  I would rather build it in a type-safe and memory-safe language - but if that is not allowed I would go for C++ even though I have my issues with it. Catching TypeError in python and handling it is not a substitute for static typing.

My opinion is that python shouldn't be used for mission- critical systems anyway.

by astrea 7y ago

My opinion is that python shouldn't be used for mission- critical systems anyway.

traverseda 7y ago

Aside from static types, why?

jraph 7y ago
One thing I dislike in Java is the string comparison. If you write str1 == str2, it compiles but probably does not do what you want (object identity vs string comparison). (edit: to clarify, this does not mean Java is not a good language overall, every language has its own set of shortcomings and as someone points out in the replies, this behavior is consistent with everything else in the language)
- weberc2 7y ago
  It’s been a while since I used Java, but what on earth does that string comparison do if not comparing the strings? Is it an address-only comparison?
  - dpratt 7y ago
    Yes, and this is entirely consistent with the overall design of the language. The ‘==‘ does not have a special overload for String instances, which are reference types just like any other in the JVM. The equals operator does a reference comparison, just as it should. If you want to do a logical comparison of instances, you use the equals() method just as you would for anything else. Frankly, if this is the most meaningful complaint you can come up with, it might be indicative that you haven’t learned enough about it to have an informed opinion.
    - CamouflagedKiwi 7y ago
      It isn't at all consistent, because integer types compare correctly with == and do not have a .equals() method. And regardless of consistency, if it's a mistake people make frequently with the language and need to learn not to do the obvious thing, it's probably not an ideal bit of design.
      - dpratt 7y ago
        In java (and every other C derived language that I know of) there’s a hard and explicit distinction between reference and primitive types. In fact, from a certain perspective the two flavors get treated identically. Comparing two integers with ‘==‘ will be true if the contents of the variables are the same, and comparing two references will be true if the pointers they contain are the same value. It just so happens that for primitives identity and logical equality are the same thing.
        weberc2 7y ago
        C, C++, Rust, Go, etc have no special distinction between reference types and primitive types but rather everything is a value and some values are pointers/references. In a language with operator overloading, I don’t see why you’d ever want to check string identity by default. Interestingly, Go doesn’t have operator overloading but it treats strings as a special case including doing a string comparison for ==. Not saying this is better or worse, although no one makes mistakes with string comparison as far as I’m aware, for whatever that is worth.
        CamouflagedKiwi 7y ago
        That special case isn't specifically for strings - you can also compare arrays, channels and structs that way (as long as the array/struct doesn't contain anything non-comparable). Unfortunately it's a rarer footgun though since it can panic when comparing interfaces :(
        int_19h 7y ago
        The flaw in Java design is that String is a reference type. Logically, it's a value, and should be treated as such (and not copying the underlying data should be an implementation detail). The problem is that in Java, there are no user-defined value types, only primitives; and primitives can't have methods. So if it were a primitive, you'd have to write "String.length(s)" etc. Also, all other Java primitives are basically bit sequences that are interpreted in one way or another, but that wouldn't be the case for strings. .NET/C#, though, doesn't get that excuse. It totally could have defined String as a struct with an internal char[] field, and then there would be no question of value/reference equality for its ==. But that would also mean that you couldn't use null for strings - and they didn't have nullable value types back then. I suspect that, plus the overall mindset carried over from Java, is what won the day. Side note: there's no hard and explicit distinction between reference and primitive types in C itself, nor in C++. If Python is "everything is an object reference", and Java is "everything is an object reference except for primitives that are values", then C++ is "everything is a value, including object references". Thus, there's no ambiguity with == in C++ - it always compares values, it's just that sometimes those values are pointers. I think sometimes that perhaps the implicitness of object references that is so common to OO languages, that I think was introduced by Smalltalk, is a mistake. It's interesting that Simula-67 didn't have it - although it was very Java-like otherwise, having only primitive values and references to objects (i.e. no objects as values, like C++), it distinguished the two consistently by using distinct equality operators (= vs ==), and even distinct assignments (:= vs :-). Or, alternatively, treat everything as an object reference, but make == do implicit dereferencing as well, as Python and VB do; and provide a completely distinct operator for reference equality, such as "is". Python has a problem in that regard in that it has a default implementation of == for all classes that compares references, and so it ends up used as reference equality in practice sometimes. It would be better to have no default for == at all, just as there's no default for other comparison operators; this is what VB does. It might also be best to stop talking about value and reference types altogether - what's actually important is the presence or absence of identity. Then everything can be an object reference, but not all object references can be compared for equality (and in practice, under the hood, the implementation can just skip the references and copy the data itself - or not, depending on mutability and size).
    - kevin_thibedeau 7y ago
      They have a magic overload for '+'. Consistency wasn't much of a priority.
    - andybak 7y ago
      > The ‘==‘ does not have a special overload for String instances As a non-Java developer I have to ask why you think this is a reasonable design choice. It's a massive footgun for the a casual polyglot Java developer. I can imagine just forgetting I can't do == if I've just switched from being immersed in another language.
      - dpratt 7y ago
        It’s precisely the same behavior you would get with C, C++, C# for references, with C# defaulting the ‘==‘ operator to short-circuit to ReferenceEquals() unless otherwise re-defined.
        andybak 7y ago
        > with C# defaulting the ‘==‘ operator Which is surely the important bit. I can just use "==" in C#.
  - deleted 7y ago
    [deleted]
  - recursivecaveat 7y ago
    Yes, it's an object-identity comparison, not a logical one. Worse, you can sometimes get spurious true results due to optimization.

dfee 7y ago

I’m on the other side; having gotten deeper into languages like c# and java; I think those technologies are vastly over used, and great languages like Python and Typescript are under used.

weberc2 7y ago
How do you figure? If it’s mission critical, it means failure is unacceptable. Python and other dynamic languages (TS is a middle ground here) excel when failure isn’t so bad and making and deploying changes is fast/easy/cheap. This is exactly the wrong tradeoff for mission critical systems.
- igor47 7y ago
  Why do dynamic languages excel when failure is not so bad? What makes non-dynamic (compiled?) languages better when failure is bad? I'm parsing your comment to mean, "it's easier to write correct code in compiled languages", but this is not obvious to me, or anyone who's, for instance, written any C at all.
  - Reelin 7y ago
    C is the wrong comparison to make here - it's extremely low level. Java or perhaps C++ would be much closer. * Ahead of time compiled languages reduce flexibility but allow the compiler to do more reasoning about the system. * Statically typed languages allow the compiler to reason about the assignments you make and methods you call. If the language is also AOT compiled, you avoid crashing at runtime. * Dynamically typed languages significantly reduce boilerplate and avoid the mental effort of expressing an idea in a rigorously typed manner. It's the "hold my beer" approach.
    - pytester 7y ago
      C is a good example precisely because it highlights the fact that explicit typecasts and memory safety are a LOT better at preventing bugs than static types.
  - 7y ago

1e10 7y ago

Why? Seems that it is a well proven language. Just like php, asp.net, and other languages people like to hate on. Or rather, how would you define mission critical?

jtdev 7y ago

Care to elaborate? Which languages would you use for mission-critical systems? What specifically about Python is not conducive to such systems? You realize that many mission-critical workloads run on Python with great success, right?

deleted 7y ago
[deleted]

senko 7y ago

That depends on the mission, wouldn't you say?

staticassertion 7y ago

People are gonna dogpile you, but if you'd said this about JS they wouldn't have blinked.

pytester 7y ago
Coz there's a difference between "dynamic type system" and "type system that's thrown together with bits of string and rubber bands": https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
- staticassertion 7y ago
  Python has is own 'wat' stuff, especially Python 2. https://stackoverflow.com/questions/3270680/how-does-python-2-compare-string-and-int-why-do-lists-compare-as-greater-than-n https://stackoverflow.com/questions/3270680/how-does-python-... "CPython implementation detail: Objects of different types except numbers are ordered by their type names; objects of the same types that don’t support proper comparison are ordered by their address."
  - pytester 7y ago
    None of those surprising behaviors exist in python 3. I wouldn't say "100" < "2" really counts, since, alphabetically it makes sense (an equivalent would be "baa" < "c").
    - staticassertion 7y ago
      Yes, Python2 was called out explicitly. Reference equality is definitely 'wat' shit IMO, though it's really mainstream too.
  - detaro 7y ago
    > objects of different types always compare unequal, and are ordered consistently but arbitrarily Seems like a completely reasonable thing to do?

HALtheWise 7y ago

Would you rather build safety-critical systems in Python (type-unsafe but memory-safe) or C++(type-safe but memory-unsafe)? While static typing does catch code errors, in my experience they are mostly errors that would be caught somewhere else in the testing process. Memory safety issues are rarer, but also have a penchant for showing up unexpectedly and for crashing the entire system in unrecoverable ways. Obviously, the best would be to have both kinds of safety, but people program safety critical systems in C++ all the time, and deal with the consequences. At least you can catch a TypeError in Python and handle it.

ailideex 7y ago
I would rather build it in a type-safe and memory-safe language - but if that is not allowed I would go for C++ even though I have my issues with it. Catching TypeError in python and handling it is not a substitute for static typing.