Lisp and Haskell (2015) • Hacker News Board

Re: Lisp and Haskell (2015)

#21

Post by timonoko » Thu, Oct 08, 2020, 7:37 AM UTC

andi999 wrote: post #16

ashtonkem wrote: post #7

Earlier quoted context omitted.

It was originally supposed to, s-expressions (parenthesis) were supposed to be eventually replaced with m-expressions which were influenced by Algol and FORTRAN (the irony), but reviewers of the paper and the initial implementors of lisp preferred s-expressions, which stuck. That being said, having worked professionally in Lisp, the “un-lispy” macros like Loop are some of the worst parts of that language. They comple…

how would an idiomatic loop statement look like?

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.

Re: Lisp and Haskell (2015)

#22

Post by heavenlyblue » Thu, Oct 08, 2020, 7:42 AM UTC

sullyj3 wrote: post #15

neolog wrote: post #14

Earlier quoted context omitted.

Sure, you can encode various properties in some languages, but it's not that common to actually do so.

In Haskell, it's both common and idiomatic. There's always a tradeoff between the usefulness of having static guarantees, and the complexity of the type system features that enable those guarantees. In some cases it's more trouble than it's worth to enforce certain static properties - you have to weigh the costs and benefits on a case by case basis. But it's nice to have the option, and Haskellers make use of it freq…

You don’t need Haskell to do this however.

Re: Lisp and Haskell (2015)

#23

Post by bjoli » Thu, Oct 08, 2020, 7:46 AM UTC

I played around with Hackett (a parenthesised Haskell) quite a lot, and I really enjoyed creating my own syntactic abstractions in a haskell-like language.

I find I would rarely reach for macros in Haskell, but that I sometimes would like to. Lisp macros do overlap with what you can achieve with Haskell things like typeclasses, laziness, monads and template Haskell, but the overlap is far from 100%.

The author of Hackett has a video about it: https://youtu.be/5QQdI3P7MdY

Re: Lisp and Haskell (2015)

#24

Post by sfvisser » Thu, Oct 08, 2020, 7:52 AM UTC

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…

It works two ways though, which I think is important. Yes, type systems check the shape of your data which is nice.

However, when sufficiently experienced, the type system also guides the developer into good program design. Type systems for me are more a design tool than shape checker.

The checker/inferencer helps me learn about assumptions I make about data in specific parts of my code, which allows me to remodel my data types to better fit my intent. This works cyclic until things just seem to ‘fit’.

Personally at least, this allows me to write far more complicated applications than I would ever be able to do without types. And it’s just very hard for me to imagine this wouldn’t be the case for any other developer.

Re: Lisp and Haskell (2015)

#25

Post by thom » Thu, Oct 08, 2020, 7:58 AM UTC

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…

Most tech companies are (quite rightly) in the business of managing imperfections, not achieving perfection.

Re: Lisp and Haskell (2015)

#26

Post by tsimionescu » Thu, Oct 08, 2020, 8:05 AM UTC

sullyj3 wrote: post #15

neolog wrote: post #14

Earlier quoted context omitted.

Sure, you can encode various properties in some languages, but it's not that common to actually do so.

In Haskell, it's both common and idiomatic. There's always a tradeoff between the usefulness of having static guarantees, and the complexity of the type system features that enable those guarantees. In some cases it's more trouble than it's worth to enforce certain static properties - you have to weigh the costs and benefits on a case by case basis. But it's nice to have the option, and Haskellers make use of it freq…

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.

Re: Lisp and Haskell (2015)

#27

Post by lmm » Thu, Oct 08, 2020, 8:08 AM UTC

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…

> 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 it: the compiler will tell you if your LEGOs fit together, but not if you've built a knife instead of a fork.

Disagree. You can and should be using your type system to express your system design. If it's important that your utensil has at least 3 prongs, it should only be constructible by passing at least 3 prongs; that much is trivial to do even in Java, yet alone a language with a decent (i.e. ML-family) typesystem.

Re: Lisp and Haskell (2015)

#28

Post by Rerarom » Thu, Oct 08, 2020, 8:16 AM UTC

ashtonkem wrote: post #7

timonoko wrote: post #3

Common Lisp could evolve into totally parenthesis-free language. By expanding the "powerfull and versatile" Loop-macro into full powerfullness and versatileness. Unfortunately two parenthessis needed, but you can redefine the language having those by default around every file.

It was originally supposed to, s-expressions (parenthesis) were supposed to be eventually replaced with m-expressions which were influenced by Algol and FORTRAN (the irony), but reviewers of the paper and the initial implementors of lisp preferred s-expressions, which stuck. That being said, having worked professionally in Lisp, the “un-lispy” macros like Loop are some of the worst parts of that language. They comple…

"Haskell is Lisp's missing M-Expression implementation."

Re: Lisp and Haskell (2015)

#29

Post by sidkshatriya » Thu, Oct 08, 2020, 8:17 AM UTC

StreamBright wrote: post #4

Clojure and F# are my two favourite languages and I have similar experience. It is much faster to develop F# code because I can rely on the type system to help me handle all the edge cases, pass in the right things and avoid nulls.

I've always been curious about F#. Is it true that the F# compiler can be super slow especially on larger codebases?

I always wonder: why use F# when you can use OCaml? OCaml has pretty decent third party libraries...

(Yes multicore support in F# would be a good reason but apart from that)

Re: Lisp and Haskell (2015)

#30

Post by FullyFunctional » Thu, Oct 08, 2020, 8:19 AM UTC

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…

I frequently have to defend why I hate Python but the foremost reason is that lack of static typing (which also makes reading other peoples codes harder than it need be). Static typing, especially in a rich type system like, e.g. Haskell and Rust, doesn't guarantee you don't have bugs, but it almost guarantees the ones that remain are better bugs, that is, application level bugs. However in my experience, I can usually tell what kind of code will be correct once it passes and which might still have issues.