I think Python is one of the worst things that hap...
# random
p
I think Python is one of the worst things that happened to programming in general.
m
my list of “worst things” is long, but python isn’t on it!
👍 3
l
Do you know PHP still exists?
a
I'd put JavaScript much higher on that list than Python. Python is actually a v productive language to write in and is a really good 1st language to learn both for OOP & an intro to FP
👍🏼 4
1
m
I’d agree with that - and I’d put Java much higher on the list than Javascript!
u
I don’t really get the hatred for dynamic languages, I too prefer statically typed languages but I feel like dynamic typing brings some benefits. For example testing gets easier since duck-typing is usually a lot easier for a beginner to understand than interfaces. I feel like the main problem with programming today is that people simply don’t test their shit. Sure types eliminate some of the potential errors but far far far from all of them.
1
m
It seems like as soon as you get to a certain size, you’re using dynamic languages anyway: either a Spring context, a rest API, a _database_… At some point you’re losing type-safety where the errors hit regardless of language.
l
@540grunkspin The sole fact that my Kotlin code compiles tell me a lot about it. It's not something I have with dynamic typed languages. Working in a team where others use JS and PHP, I almost never encounter unexpected crashes at runtime like they do. That means it's safer for me to go to production, even with not so many tests, because the compiler does many tests for me
u
But all of this is sort of anecdotal isn’t it. If you look at this study sure it shows that static typing reduces bugs to some extent but there are other and more important factors at play https://dev.to/danlebrero/the-broken-promise-of-static-typing
😬 1
And yes there are flaws to this study but I still think that it goes to show that static typing is not the only factor for bugs. There are other great things you get from static typing. Such as IDE tooling and similar
Maybe I should say article instead of study since it isn't really a study but the point still stands
l
It is completely flawed because it does not say if the repos are pure language (an F# repo may have JS bugs from the minor portion of code), and it doesn't talk about Kotlin (neither about Swift), a simple, but strongly typed language. Kotlin is special because it's pragmatic, has coroutines, has type inference, extension functions, a good compiler and good tooling
u
I agree. Kotlin would probably somewhere there at the top. But like i said. The main reason why i think kotlin would be high up is not mainly due to the static types but rather the other things you mentioned. It is more complex than just types vs no types.
l
Well, I think it would not be as good and as safe if Kotlin was what it is, except with weak/dynamic typing
u
Well I agree, since the language it self is heavily developed with types in mind. But look at languages like clojure and other lisps that manages just fine without types. Same for erlang. Immutability and strong pattern matching takes you a long way
t
I don't agree with this statement. Python did set out to create a language that eliminates boilerplate and is accessible to beginners. It was a novel idea. I think it was an important influence that perhaps even affected Kotlin. That being said, I don't think its design decisions were optimal. Indentation, lack of good FP, and weird OOP constructs are regrettable. The fact python codebases must be doubled or tripled in size with checks and tests speaks volumes on how the philosophy fails in production.
👍 3
Uncle Bob's article made me bang my head a little. I argued with a team of 3 a few weeks ago as they advocated writing Python codebases and nonchalantly were okay with tripling the code size with unit tests and type checking. It took me several Kotlin examples to show them how much they got for free with Kotlin and the fact they didn't have to write checks or tests. As somebody who studied supply chain management and not computer science, it stuns me how many programmers don't see a problem with waste and non-value activity. They just use what they know without question.
2
👍 3
u
I don’t really want to misunderstand you but is your claim that tests are a non-value activity?
I can agree that manual type checking might be a non-value activity but tests imo provide documentation, reduction of manual QA, flexibility to change things with confidence, reduction of bugs, and the list goes on
l
I think his claim is that you have a lot more syntax/typing tests on weakly/dynamically typed languages, and they are a non value compared to just using a stronger typing and let the compiler always do these kind of checks right
u
Yep i can mostly agree with that
t
@540grunkspin @louiscad affirmative. There's waste in testing basic things you can get for free. Testing APIs and end products however make sense.
d
They just use what they know without question.
You're lucky I can't make a thread in a thread, but that's a human problem, not just something that's programmer specific.
t
@dalexander True, I have my biases due to my background like everyone else. But I think tolerance for defective tooling is 10x worse with software engineers. Lean manufacturing has done great work in the past 30 years making cars and aircraft reliable, safe, and cost effective. But software development often remains defective, bloated, and expensive. Practices like Agile try to be lean and eliminate waste, but dont address waste in the technology tooling itself. I dunno why so few folks see this outside the Kotlin community.
d
I agree that there's a lot of room for improvement with tooling. But a lot of it comes down to people wanted to re-use what they already know, even when it wouldn't be appropriate. On the topic of typing, I wonder how much weak typing is a backlash against languages like Java (and Kotlin) not having a sufficiently robust type system to express certain useful concepts, like unions or some of the problems that show up when generics are used with inheritance.
👆🏼 1
t
The big issues is fans of the language ignoring it's glaring problems, and acting like it is the right tool for most jobs. And the snowball keeps on rolling, popular keeps getting more popular. And then unfit languages prevail.
t
@dalexander Python was definitely a backlash against Java, and it hit the mainstream when Java/C#/Objective-C were the primary incumbents (Swift and Kotlin were hardly around yet). From my experience, most Python devs especially in the data science space are unfamiliar with Kotlin. They already had a hard time buying into Scala which caused them to be disinterested in the JVM. But you might be onto to something regarding type systems also, although dynamic typing became popular likely for its "conciseness". Dynamic typing is convenient in the data science space until you need to productionize and support it. I think Kotlin has the best of both worlds for now, but static types can still create extra steps for me in working with data.
t
Languages also depend on their tooling/libs/frameworks. And popular languages get more of those. Leaving a popular language for another language that you think is much saner starts to loose its appeal when you start to see there are too few libs/frameworks for what you want to do, and that you have to re-event the wheel in another language.
@thomasnield i guess it also has to do with OOP. All of those for objects into you. Python does not.
d
Python predates Java by a bit, so I'm not sure how the design itself could be a backlash against Java, but I could see it being a response to C++ and everything C++ stands for, which I think would have been one of the major "production" languages at the time (1990), and Java shares many traits with C++, although it cleaned up a bunch of edge cases. Given that static types tend to create friction for the data science use case, I wonder if there's anything in theory that could be done to streamline that process (for any static language). I wonder what kind of extensions could be made that would make iteration easier?
I also agree the libraries are currently a major reason to use a particular language. For example Tensor Flow has pretty mediocre support in Java, compared to using it from Python.