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

81–90 of 173 posts

Re: Lisp and Haskell (2015)

#81

Post by jbotz »

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…

> the compiler will tell you if your LEGOs fit together, but not if you've built a knife instead of a fork.

OK, let's stretch that metaphor a bit. A powerful type system like Haskell's is really a way of both restricting which LEGO(tm) pieces you can use and designing custom new ones. So when you design and write software in truly idiomatic Haskell, after getting all your types lined up there is no way to make anything other than a fork.

Re: Lisp and Haskell (2015)

#82

Post by dtbx »

dunefox wrote: post #37
sidkshatriya wrote: post #29

Earlier quoted context omitted.

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)

> why use F# when you can use OCaml? I have looked at both without any prior experience in them and OCAML tooling is horrible. Also, with no support for unicode in Ocaml, F# is just much better in this regard - even if it lacks modules, functors, etc.

You can use camomile library to handle unicode strings, count code points, perform locale aware lowercase / uppercase, etc

For utf8 regexes, you can use Pcre in ocaml, which is faster than camomile regexes.

Re: Lisp and Haskell (2015)

#83

Post by bonthron »

sidkshatriya wrote: post #29
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)

If you're already doing C#, then it's easy to start using F#. You probably are using VS Studio/Code, you already know the standard .NET libraries. etc.. F# is a little weird because there are accommodations to ensure it will interop with C#. But it is fun.

Re: Lisp and Haskell (2015)

#85

Post by bachmeier »

This is not the most impressive piece. Two of the main complaints about "Lisp" are that it's not really a functional language and that there aren't enough libraries/the standard library isn't what it should be. These are specific to Common Lisp. Clojure gives you a functional-first Lisp, access to all Java libraries, and a decent standard library. The Common Lisp standard is very old, even if you look at the date it was finalized (1994), but most components are from a much earlier period than 1994.

Re: Lisp and Haskell (2015)

#86

Post by tasuki »

sullyj3 wrote: post #78
tasuki wrote: post #62

Earlier quoted context omitted.

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.

If you know the list can't be empty, can't you prove that to the compiler by using a non-empty list type?

Re: Lisp and Haskell (2015)

#87

Post by adamkl »

skellystudios wrote: post #45
slifin wrote: post #39

In Clojure it's common to develop your application by building it inside a running system Every REPL form sent recompiles the running program, I don't want that fast loop to be force lagged by the program checking types I'm more than happy for that to happen at edit time, independent of compile time outside of my application process So I heavily encourage using clj-kondo to check for mistakes doing primitive type che…

That sounds super cool, and I'd quite like to give it a go. I'm not sure if what Haskell has is quite the same, abilities but you can hot-reload modules at runtime in GHCi, and FWIW, I've always found the type checker to be pretty zippy.

This is what REPL-based development looks like in practice:

https://vimeo.com/230220635

I agree, its pretty cool, and actually pretty fun.

Re: Lisp and Haskell (2015)

#88

Post by agentultra »

curryst wrote: post #31
sullyj3 wrote: post #15

Earlier quoted context omitted.

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…

I find these generally worth it because you can surface those aspects up to the function signature. It would be a lot nicer to have a function signature that shows the limits than it is to have a failure and have to open the docs for the library to see what the limits are. If the code is sound, it should have the same complexity anyways. I.e. putting a non-empty requirement in the function signature is just as comple…

I used to think Javascript was a great prototyping language. In fact I specifically practiced prototyping with it -- my github is littered with repo's for each of my prototypes -- I call them the Laundromat Demos. I would use the 70-80 minutes I had at the laundromat to write a prototype for a game in JS.

However I've tried something similar with Haskell. I think I prefer Haskell for prototyping these days. It turns out you can get a long way playing with the types. Often I spend more time prototyping the types and they guide me to the implementation which is often quite small.

It takes some training and work to get there but I think Haskell, for me, is a better prototyping language -- I don't have to deal with undefined, accidental prototype overloading, etc.

Re: Lisp and Haskell (2015)

#89

Post by adamkl »

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.

Heck, why not just go one (several?) steps further and just use macros to create a DSL for ?

https://aphyr.com/posts/353-rewriting-the-technical-intervie...

Re: Lisp and Haskell (2015)

#90

Post by z3phyr »

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…

Just wait for symbolic computers to be rediscovered and the industry will probably adopt lisp and prolog's successors.
Post reply on HN