Lisp and Haskell (2015) • Hacker News Board

Re: Lisp and Haskell (2015)

#171

Post by andi999 » Sat, Oct 10, 2020, 5:58 AM UTC

guenthert wrote: post #142

timonoko wrote: post #21

Earlier quoted context omitted.

Just a jumble of random words. They are especially difficult to non-english speakers, because they are not grammatically correct sentences, but rely on some unknown word-order logic in indo-european languages. Same aplies to list comprehension sentences in Python too.

Is that truly a stumbling block? I ask because English is not my native language. Around the time I learned English in high school I also became interested in computers, which to me then meant programming in BASIC. It took an embarrassingly long time for me to realize that e.g. GOTO was actually formed from 'go to' -- to me, "GOTO " just meant that program flow would continue at line , nothing more, nothing less. "IF…

The 'go to' thing probably took me 30 years to realize. I was puzzled when I read the 'go to considered harmful'and the 'structured programming with go to' article until I realized.... It is probably the same as in your case, I learned programming before learning English.

Re: Lisp and Haskell (2015)

#172

Post by pyrale » Sat, Oct 10, 2020, 11:52 PM UTC

jstimpfle wrote: post #164

pyrale wrote: post #160

Earlier quoted context omitted.

Curious to know what led you to interpret this: > which happens to be checked against the compiler as: > the types aren't checked by the compiler, as my parent poster indicated. (also type aliases are still checked. The check is less useful, but it's still a check) > Why would any experienced programmer make such a blanket statement? Because type annotations are less work than tests or documentation, don't suffer fro…

maybe I misread. I went with > 95% of annotations in the average haskell codebase are unneeded for compilation Like type aliases. They are not distinct types, so the compiler doesn't (can't) check that you're using the "right" name.

What I mean is that these annotations are going to prevent compilation if you get them wrong, but the compiler's type inference is good enough that you only need to provide types when there is ambiguity.

That means most of the type annotations written exist because developers find them useful for documentation.

Re: Lisp and Haskell (2015)

#173

Post by pyrale » Sun, Oct 11, 2020, 12:09 AM UTC

higerordermap wrote: post #115

garethrowlands wrote: post #80

Earlier quoted context omitted.

The fact that code and types don't diverge can make types useful as documentation, albeit limited documentation. Ideally the compiler figures out the types so you don't have to. Haskellers often find this useful when they refactor a month later.

> Ideally the compiler figures out the types so you don't have to. Doesn't it cause unintended API breaks because type changed from, say, a single type to union type, without changing any annotations?

If that change goes through your whole program without causing any breakage, from Haskell's point of view it's a good change.

If you have an API that exposes data to external systems, that may cause an integration breakage, indeed. That is why Haskell users like to use libs like Servant, which let you specify your API as a type. This way, if you change your system, your API has to change aswell.

Another benefit of Servant is that you can generate swagger and clients for other languages easily, which your users can use in their own build to get type safety too.