Hacker News Reader

Comment by nijave | Hacker News Reader

It seems like a lot of criticism of Python is directed at the data science community but I'm curious what the alternative is here?

Is it surprising people trained in math are writing hard to maintain programs? Is biology+Perl any better (I'd argue worse).

What languages exist that are hard to write bad code in? I've worked at places that rewrite abominations of Java every 5 years because they are such coupled, unmaintainable messes.

JPMC has Athena and Pinterest seem firmly committed to Python. I know some people that worked at Braintree (now part of PayPal) that heavily used Python

Home Assistant and Ansible are two massive OSS projects

View on HN

Julia or Swift

I'm hoping the default choice becomes Julia. For one, it's Lisp. Imagine tensorflow or whatever being distributed as one Julia codebase, no separate C++ to compile, no need because Julia can do it all. I hope it replaces R, Mathematica, Matlab, Excel VBA.

I would like to see Kotlin get more love, but that's just a personal wish

Julia is apparently gaining steam in scientific computing.

> What languages exist that are hard to write bad code in?

A language with a good type system (ex. Haskell, OCaml, Rust etc.) makes it hard to write bad code, because it eliminates a large class of potentially "bad" programs, and thus provides guarantees about the code that does type check.

If I have an arbitrary Haskell program, it might still be messy and hard to read, but I know I'll have certain guarantees about the code. For example, if a function isn't in IO, it won't have any effects, and a replacing it with a function that returns the same values for the same arguments will be safe.

Additionally, the language makes it easy for libraries to have well designed APIs, that ensure that the user doesn't forget to make the required checks. For example, removing null, and forcing Option/Maybe for functions that might fail forces the the caller to handle the failure case, instead of just forgetting to check for null, which is common.

If they don’t have bad code it’s because it’s a bunch of enthusiasts that are good at coding. Realistically I’m sure there’s even now examples of code that would be considered “bad” in any of those languages.

It's more the fact that these languages force certain best practices using their compiler. While python can be great when used in best practice, its level of freedom make it easy for the user to get away with obvious mistakes. It's great to have freedom like that when you're writing small projects, but a large project could lead to unintended effects that cause more damaging issues than the time lost using a stricter language.

That’s all great in principle, but is there any evidence to support this claim?

Certain properties are of course enforced so it’s impossible for a project to do certain things that make the code harder to read. On the other hand, humans are so creative that I have a hard time imagining that, given time and a wider mix of talent, you’ll still have code hygiene issues. Maybe not the exact problems that another language might have, but certainly your own flavor will be developed as developers have less contact with the core language enthusiasts that establish said best-practices..

Again, happy to be proven wrong but I’d like at least anecdotes or some kind of evidence rather than a theoretical argument from first principles that completely ignores the human element.

> and a replacing it with a function that returns the same values for the same arguments will be safe

No. That is only safe at compile time but not at runtime. Because the type alone often does not guarantee the meaning and semantics of the values in the specific context and program are the same.

I'm not sure I get the argument here. So long as the input-output mapping for the function is identical, it cannot change the benavior of the program. This is what I would consider safe.

The semantics of values are irrelevant because the function will behave identically regardless of those semantics.

This only true if the type describes the whole meaning of the values. If the exit code of a unix program changes from 0 to 1 it still returns an int, but the meaning of that value is completely different one.

But the exit code can't change from 0 to 1. For any given input to the Unix program, if the output was 0 with one implementation, then it would always remain 0 with any other _equivalent_ implementation.

This is literally what is meant by "returns the same values for the same arguments". Any function that fits this description, by definition, cannot suffer from the problem you are describing.

>A language with a good type system (ex. Haskell, OCaml, Rust etc.) makes it hard to write bad code,

Maybe they wouldn't be writing any code if they had to write it in a languages like that.

In a world where unsafePerformIO, error, etc don't exist, sure.

The reason most Haskell codebases are cleaner is because the culture manages to uniquely emphasize good practices such that people don't try to break abstraction barriers.

I'm sure it's possible to write Haskell code that "misbehaves" as much as python code does. Once smart people with no training are let loose on something, that'll definitely happen.

We're lucky that Haskell hasn't been attacked yet :)

Words like "any effects" and "safe" have broader meanings than the way they are used in type systems. I ask that you be a bit more precise in your advocacy.

I can replace a sorting method having O(N log N) time with one having O(N^2) time, without changing the type. But it will certainly have an effect on my system, and if the run-time is too long, may result in an unsafe system (eg, in a real-time control system which requires a maximum response time).

While I know what you mean, "bad code" includes things like unacceptable performance.

I also find it hard to understand how to apply type systems to algorithms. What is the type of an algorithm which returns a graph diameter, and how does it differ from one returning the graph eccentricity or other graph property?

(That's where "same values for the same arguments" comes in, but that's that hard part of the problem, yes?)

> What languages exist that are hard to write bad code in?

Plenty of languages exist that are hard to write any code in, good or bad.

I often think that stopping people from writing code might be the best way to avoid bad code.

Stricter languages like Rust, ADA, or even F# (quite strongly typed), will not let you compile until you reach a certain level of explicitness/correctness. Thereby teaching you some basic things until you can compile.

Languages like Perl and Python allow you to do a lot of things, which ends up unmaintainable because it's too easy. The easy version just breaks during runtime then.

Reply on news.ycombinator.com