[rozgo]

This is absolutely the case for programming languages. From Haskell to Rust. Programming languages shape the way we think and reason about the problem. Sometimes it does this so well, it leaves us starring into the abyss. Facing dead on the problem domain—after all sides quests have been removed. Once you can delegate away all the busy work, you can focus on bigger and better abstractions.

[blub]

Both Haskell and Rust are poor examples because one has to focus more on the notation (i.e. types, declarations, etc).

Python is better.

[d2v]

Types in Haskell are generally used to describe the structure of the data. Defining a type in Haskell is like writing documentation and a test all in one. I can mentally offload certain concerns to the compiler, which will tell me whether or not the shape of the data in my head matches the code I'm writing. I pretty frequently use the compiler to guide my development, especially with a tool ghcid, which gives instantaneous feedback as I'm programming. It's also like a million times easier to refactor, I tweak a type signature and the compiler will basically give me a list of things I need to update. No need to hunt for and test every instance of that kind of input, the compiler just tells me where it is, and what is wrong.

You also don't have to write out type signatures 99.9% of the time after declaring a type, the compiler can infer them. People in the Haskell community tend to write out signatures for functions because it makes it easier to understand, but it's pretty rare to see a type signature in the body of a function.

That's not to say thinking in Haskell is always as natural or more natural than Python, but I'd argue that immutability and laziness more than types can require a lot more mental effort that can feel like fitting square pegs into round holes for certain problems. When it comes to types (at least Haskell vs. Python), I'd say it's much more a matter of personal taste.

[blub]

That's not relevant unless you can do all of the above instinctively and without involving the higher faculties of the brain.

[avindroth]

You had to learn 0,1,2,3, etc. at some point. The thing with notation is that it takes time to learn, but it proves profoundly useful over time. The benefit of notation integrated over your career outweighs the adoption costs.

Arabic numbers are like this (no child immediately ‘groks’ Arabic numbers), and Haskell notation is making the same case. Haskell abbreviates abstract structures so that they become fluid.

If focusing on notation is a problem, then we should all have grown up to use our fingers for counting, not Arabic numerals.

[blub]

You have to remember the context in order to understand my reply. Here it is once again "It is a profoundly erroneous truism, repeated by all copy-books and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilisation advances by extending the number of important operations which we can perform without thinking about them."

First of all programming without thinking about it (i.e. instinctively) is arguably not even possible. But let's be generous and assume that it is somehow.

Are you seriously trying to argue that it's possible to program in a complex programming language which not only requires types, but almost requires encoding complex relationships in them without involving the "higher faculties of the brain"? This is such an extraordinary claim that it requires evidence to even consider it.

[tkzed49]

Imagine I'm consuming code written by someone else, without looking deeply into its implementation. Would I now be disadvantaged by careful and explicit typing? How much time is spent consuming code versus writing it, of course, is a bit situational.

[dependenttypes]

In python you have to focus more on the debugging where this run-time type-error came from. Also, Haskell has type inference unlike the other two.

[blub]

Python merely allows you to program quite close to a state where you focus on the problem and less on the infrastructure and syntax required to solve the problem. At least in exploratory phases and when working with smaller pieces of code.

Other languages almost always require more thinking and design upfront, even when doing exploratory programming.

[dependenttypes]

> and less on the infrastructure and syntax required to solve the problem

I do not think that this is true for python any more than it is true for haskell for example.

[johnsonjo]

I’m not sure. I find this in people that say JavaScript is better than TypeScript. Most people that learn TypeScript or Flow learn to love it even more than JavaScript once they get over the initial hurdles. Why? It’s more self documenting. It actually provides better auto completion. It scales much better for larger Frontend projects. Going without it is almost painful to me now. I now know a bit better a few of the big reasons why a lot of devs hate JavaScript. Because they are used to the great properties, tools, and features that come from having a well typed language. Languages seem to have big hurdles for no reason when it comes to their type systems, but those hurdles pay off.

[tome]

Which one requires more focus on the notation?

    def square(x):
        return x * x

    square x = x * x