Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisp and Haskell (2015)

markkarpov.com

Post reply on HN
Print view View original

71–80 of 173 posts

Re: Lisp and Haskell (2015)

#71

Post by arunix »

rjsw wrote: post #57
behnamoh wrote: post #10

Every once in a while, there's a post on front page HN about Haskell and/or Lisp. Sometimes these posts get a lot of traction, but what confuses me is despite the apparent popularity of these languages among developers, still they are seldom used in serious software. I know there are exceptions (esp. with regards to Lisp), but still these languages never come close to other languages such as Java, JS, C, or even Scal…

I'm writing serious software in Lisp. Other developers working in related areas are using Ruby and Python but my software runs a lot faster.

Which Lisp is that?

Re: Lisp and Haskell (2015)

#72

Post by boloust »

rxhernandez wrote: post #66
boloust wrote: post #60

Earlier quoted context omitted.

> Frankly, if you were to ask me what the top 3 sources of my headaches in Python are, number 1, 2, and 3 would be, receiving a None value when I expected something else Curious example, because that's absolutely something a sufficiently advanced and well-thought-out static type system can completely solve. You're right that the type systems of C and Java do not meet this bar, however.

Is null even a type though? If not, then it would seem it's not a static type system that's solving it; it's something else entirely solving it (whether or not that something is contained in that specific type system).

The issue with null, as commonly implemented, is that null is a value that inhabits all types. So in that sense it is a defect of the type system.

Re: Lisp and Haskell (2015)

#73

Post by tome »

q3k wrote: post #65
tome wrote: post #64

Earlier quoted context omitted.

The Foldable instance for Maybe is one of the biggest warts in Haskell. It's not limited to Haskell, by the way. def getUsers(f): return (logged_in_users(f), logged_out_users(f)) def userCount(f): return len(getUsers(f))

Sure, but Python and Python developers don’t hype up its type system to be the solution to all your programming woes :).

I'm not sure what "Haskell developers" are saying, but this Haskell developer says "Haskell provides many tools that can be used to solve programming woes. One such tool is its strong and flexible types system (there are several other tools, such as immutability, functional style)."

Re: Lisp and Haskell (2015)

#74

Post by ghostwriter »

q3k wrote: post #61
lgessler wrote: post #5

> if your code compiles, it probably works I'm always a little frustrated whenever I see this aphorism perpetuated since I think it gives the impression that a static type system is doing more than it is actually doing. In type systems that are used outside of academia, the main thing your static types are doing is checking whether the shapes of your data and functions all line up. With some small exceptions, that's…

Agreed. I have a strong background in 'bad' programming languages like Go, Python, C. Half a year ago I had a short stint at a Haskell shop and was thoroughly disillusioned. That particular 'writing against the compiler' approach lended itself to write-once, over complex type juggling code. Because why make it readable - if it compiles, it works, and if it works, there won't be any need to read it, right? Well, excep…

Why does getUsers return Maybe [a] in the first place? It should be [a]. You can also implement your own version of length that works only with iterables of your choice. The language allows leveraging type constraints to achieve this, the fact that your team didn't use it doesn't indicate an inherent flaw in the type system you've been provided with. And if you want to go an extra mile, use liquid-base instead of base.

Re: Lisp and Haskell (2015)

#75

Post by sullyj3 »

tsimionescu wrote: post #63
sullyj3 wrote: post #32

Earlier quoted context omitted.

The general consensus in the community afaik, is that head :: [a] -> a in Prelude was a mistake, and the default should be to return a Maybe/Optional. Beginners are generally advised to avoid head, and all other partial functions in the Prelude, such as tail and the indexing operator, wherever possible, and rely on pattern matching instead, which is generally sufficient and more idiomatic for the relevant use cases.…

Well, since the Prelude was never changed to at least add an alternative headMaybe, perhaps it was not seen as a deep enough mistake. Yes, I am aware that the Haskell community generally tries to push more guarantees to compile time, and that Haskell's ease of defining and using new types equivalent to existing ones but that signify some property helps a lot in this. Still, there is some limit to this. For example, y…

Definitely don't disagree!

Re: Lisp and Haskell (2015)

#76

Post by [deleted] »

boloust wrote: post #72
rxhernandez wrote: post #66

Earlier quoted context omitted.

Is null even a type though? If not, then it would seem it's not a static type system that's solving it; it's something else entirely solving it (whether or not that something is contained in that specific type system).

The issue with null, as commonly implemented, is that null is a value that inhabits all types. So in that sense it is a defect of the type system.

[deleted]

Re: Lisp and Haskell (2015)

#77

Post by [deleted] »

tasuki wrote: post #62
tsimionescu wrote: post #26

Earlier quoted context omitted.

How many functions have you seen, in Haskell, that take Nonempty a versus taking [a]? There are reasons why this type of pattern doesn't scale well, and the Haskell designers knew it. Similarly, if they had defined head [a] -> Optional a, that would have produced complications of its own.

What complications would it have produced? Eg Elm has `List.head : List a -> Maybe a` and it's just fine I think?

[deleted]

Re: Lisp and Haskell (2015)

#78

Post by sullyj3 »

tasuki wrote: post #62
tsimionescu wrote: post #26

Earlier quoted context omitted.

How many functions have you seen, in Haskell, that take Nonempty a versus taking [a]? There are reasons why this type of pattern doesn't scale well, and the Haskell designers knew it. Similarly, if they had defined head [a] -> Optional a, that would have produced complications of its own.

What complications would it have produced? Eg Elm has `List.head : List a -> Maybe a` and it's just fine I think?

In practice I've found that it leads to writing code that you know is unreachable, but you can't prove it to the compiler.

Re: Lisp and Haskell (2015)

#80

Post by garethrowlands »

jstimpfle wrote: post #67
pyrale wrote: post #38

Earlier quoted context omitted.

> you don't even want to pay the type annotation tax for. 95% of annotations in the average haskell codebase are unneeded for compilation. People still write them, because they are a useful source of information when reading the code. So tell me, if you feel like you don't want to write down that one line of comment which happens to be checked against the compiler, I guess you probably don't write tests or documentat…

> I guess you probably don't write tests or documentation either? Why would any experienced programmer make such a blanket statement? As always, it depends. Sometimes there is value in documentation (or whatever unchecked types in fancy languages), especially for stuff that is read a lot more, by other people, or yourself in the future. For a lot of stuff there is no point in writing documentation. For example, if th…

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.
Post reply on HN