Hacker News Reader

Comment by throwamon | Hacker News Reader

> vastly superior typing system. (=> less bugs)

I have no horse in this race, but claiming it to be "vastly superior" and implying "less bugs" makes it sound like this is a logical consequence, when you're actually staying on one side of an endless debate that to me doesn't have clear winners. For instance, from the little I've learned about Clojure, they claim the lack of a "vastly superior type system" is a feature, not a bug, and it's a result of a fundamental difference in some beliefs about how to write correct software.

From this I wonder how misrepresentative your other comparisons are as well. But don't get me wrong, OCaml is probably my "favorite language I've never actually used" (I've never "actually used" Clojure in "real projects" either).

View on HN

Take any open source python project on github (or others) look at the list of issues and count the number of 'NoneType' has no attribute ... instances. All these could have been avoided by a decent type system. I rest my case ;)

I don't think I've ever seen anyone seriously argue against the claim that strong typing systems at least prevent many types of bugs. Now people may think that they are more productive in a language with weak types but that's a different consideration.

This was on HN the other day: https://github.com/hwayne/awesome-cold-showers#static-vs-dyn.... I would probably add a caveat to the listed caveats that testing might not be considered? Like if every dynamically typed code base implements an ad-hoc typechecker with a testing framework, it's a distinction without a difference.

I’ve passed wrong type of arguments to Python functions and assumed type of the return value wrong countless of times. That has never happened in Haskell. I don’t know how to reconcile my experience with the statement that there’s no evidence that strong typing reduces bugs.

I program primarily in (untyped) Python (which, I get is technically strongly typed but people don't think in technical terms) these days, and I almost never experience type errors. I guess I could attribute this to a couple things:

- I'm very specific about when I use None

- I'm a big fan of named function arguments

- I like to think my naming of things is pretty good, as are my conventions for parameters

- I try to handle all possible cases (what I mean here is I do and if I don't I made a mistake)

I use tests very sparingly in personal projects, but yet I haven't really felt their absence. If I ever write a piece of particularly hairy code (metaprogramming comes to mind... lord) I'll write a quick script testing some cases and then delete it.

Anyway, all that is to say I think part of dynamic programming is you build an immune system for this stuff.

I’ve similarly developed my own habits. But why spend our effort into developing habits, when we can address the problems across people --- junior and senior --- automatically with a type system.

Oh 100% agree. The problem I've run into is my habits aren't others' habits, so we burn time arguing about how best to $CODE, and I rarely walk away from those satisfied or more educated (I'm sure this feeling is mutual haha). I wonder if "immune system" is to "type system" as "my special formatting" is to "use a formatter" here.

Python is OK for throwaway code, but I've mostly seen it used for big systems that people (for whatever reason) didn't think were important enough to write in a real language. The people with that opinion don't share your degree of rigor.

I usually avoid bugs in python code by rewriting in bash (at 1-10% the size of the original python, since bash's error handling can be set to "always do the right thing" with "set euxo pipefail")

If bash is a bad fit for the rewrite, go usually works. I don't work on linear algebra software much these days. Python seems to be a good option for that.

Yeah I love Python for quick work and prototyping, and it's great for small web services and as a DSL for data analysis. I suppose I could also envision it as a backend language for a fleet of microservices too.

I think Python gets bailed out a lot because those things turn out to be a lot of programming these days. The people who have a beef w/ Python are those who've worked with it on large, old codebases. This is a tough job for any language though like, raise your hand if you've ever worked on a large, old codebase in C++ or Java that you liked.

Usually when people push microservices I'm quick with Conway's law, saying "this is a tech solution to an organizational problem that won't actually make a difference", and I think I'm right about that. But I think I've been ignoring that a really nice thing about microservices for engineers is you can keep using languages like Python on small codebases, and at least mentally and emotionally avoid the feeling of working on a huge monolith. That counts for something.

I think the big win is actually immutable data and pure functions. It just so happens that strong typing tends to come along with these things (e.g. Haskell, OCaml)

Clojure is the big outlier

And Erlang / Elixir. These are also some of the most widely used FP languages in delivering real world software.

Reply on news.ycombinator.com