The Python Paradox (2004)

Post by hbrn » Fri, Jan 27, 2023, 6:44 PM UTC

whatyesaid wrote: post #8

RomanPushkin wrote: post #6

It's called "anecdotal evidence", the only thing that makes this post credible(-ish) is that PG wrote it.

It's not just PG: https://news.ycombinator.com/item?id=20212869 Although I do think between Python and Java, just pick your poison, they're not night and day. Unless you're writing 1990s Java consisting of factories of factories which is more to do with library style and over-conventionalism (back then when people were writing APIs after reading GOF). Even in 2004 I don't think there's much credibility in knowing bot…

Post by hbrn » Fri, Jan 27, 2023, 7:28 PM UTC

ReflectedImage wrote: post #238

rjh29 wrote: post #226

Earlier quoted context omitted.

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…

I don't actually care about any of that stuff. You are confusing technically wrong with not working. If the code works in production it doesn't matter that the code is technically wrong. 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…

Post by ReflectedImage » Fri, Jan 27, 2023, 8:14 PM UTC

snapcaster wrote: post #245

ReflectedImage wrote: post #211

Earlier quoted context omitted.

Typed Python code on average takes two times the time to develop and contains two times the number of bugs per delivered software feature. It's bad, really really bad. Refactoring can be done just as well via a good IDE and unit testing. Using typechecking creates far more errors then it finds. They are a necessary evil in compiled languages. It's been measured that it creates more errors. That is not open for debate…

What is this based on? I have a lot of trouble believing untyped python code has half the bugs of typed code being someone who has written and read a lot of both

Post by Nullabillity » Fri, Jan 27, 2023, 11:41 PM UTC

cvccvroomvroom wrote: post #24

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…

    #[derive(PartialEq)]
    struct Option {
        value: T | (),
    }
    impl Option {
        fn some(value: T) -> Self {
            Self { value }
        }
        fn none() -> Self {
            Self { value: () }
        }
        fn is_none(&self) -> bool {
            match self.value {
                _: () => true,
                _: T => false,
            }
        }
    }

Post by stubish » Sat, Jan 28, 2023, 12:05 AM UTC

unlikelymordant wrote: post #61

stubish wrote: post #11

Earlier quoted context omitted.

I too tend to agree with the sentiment. What isn't mentioned though is that is quite possible to run out of people to hire. Which mostly happened to us, where we had grown and everyone in the relatively small Python community who could and would work for us was working or had worked. We had to move on to another new language (Go), although that did rub a number of the Pythonistas the wrong way.

Can you hire people who know other languages and train them in python? Why would you need to change languages?