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

141–150 of 173 posts

Re: Lisp and Haskell (2015)

#141

Post by guenthert »

the_only_law wrote: post #93
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)

Can someone describe to me what is good about OCaml? Unfortunately I think I've only eve heard complaints about it, many being mentioned here (multicore support, bad tooling, things like utf support you'd expect to be built in, Windows pains, etc.). I've also read a number of admittedly older peices criticizing it's type system among other things. When or why should someone consider using OCaml versus a lisp, modern…

Safer, more expressive than C, easier, saner than C++?

Re: Lisp and Haskell (2015)

#142

Post by guenthert »

timonoko wrote: post #21
andi999 wrote: post #16

Earlier quoted context omitted.

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.

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" was just a mnemonic introducing a conditional branch, etc. . I didn't perceive my poor grasp on English as a hindrance in learning to program (as thankfully introductory text were available in my native language). Of course, you need a good handle on the language, when communicating with co-workers (and all code is communication), but that came much later.

Re: Lisp and Haskell (2015)

#143

Post by marcosdumay »

ghostwriter wrote: post #114
jshholland wrote: post #99

Earlier quoted context omitted.

There is a substantive difference between "couldn't get any users because of an error" (Nothing) and "succeeded but found no users" (Just []). But, if that really is the reason for Maybe [a] over [a], I'd still prefer Either SomeUsefulErrorType [a].

Right, so we essentially say that the provided example doesn't refute the "it works if it compiles" slogan. It just works according to the provided specification expressed in the types, and it so happened that the specification was not specific enough. My specification doesn't make a distinction between absent users and possible error responses because I assume that errors will be processed elsewhere and the getUsers…

Of course, "if it compiles it works" depends on you designing good types.

Haskell will never stop you from representing every value as String, and just throwing exceptions if the strings do not convert back, for example.

Re: Lisp and Haskell (2015)

#144

Post by marcosdumay »

tsimionescu wrote: post #26
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…

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.

> How many functions have you seen, in Haskell, that take Nonempty a versus taking [a]?

Most take Foldable or Traversable.

When it's relevant your functions can be specialized into Nonempty.

Re: Lisp and Haskell (2015)

#145

Post by rowanG077 »

jimbokun wrote: post #127
sullyj3 wrote: post #12

Earlier quoted context omitted.

Type systems can encode proofs of properties that you want your data to have. For example, suppose you want to write a function that returns the first element of a list. head :: [a] -> a This is the type of a function "head" that takes a list of values of some arbitrary type a, and returns an a. if you feed this function an empty list, what will it do? You can reason from the type signature that the only thing it pos…

Shouldn't head return "Maybe a", since the head of an empty list would be "None"? (Not sure if I got the Haskell terminology correct.)

In a better world it would. Currently it the head of an empty list crashes the program. Many people in the Haskell world are really salty about this but they don't want to break the API for it.

Re: Lisp and Haskell (2015)

#146

Post by dunefox »

sidkshatriya wrote: post #46
dunefox wrote: post #37

Earlier quoted context omitted.

> 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.

> OCAML tooling is horrible This is the old view. In 2020 OCaml tooling, if I may be brave to say so, is excellent. Check out the triumvirate of dune (build), opam (external dependencies) and ocaml-lsp (IDE smarts). P.S. ocaml-lsp uses merlin in the backend (ignore that if you are not familiar with merlin).

I just tried it again, everything (m4, dune, opam, ocaml-lsp) installed just fine; then I created a simple hello world project (Quick start guide: https://dune.readthedocs.io/en/latest/quick-start.html) and I could compile and run it. Oh, how things appear to have changed.

Re: Lisp and Haskell (2015)

#147

Post by shakow »

timonoko wrote: post #124
shakow wrote: post #101

Earlier quoted context omitted.

> but most languages do not have "list comprehension" by post-description. "New York has rats bigger than a dog" comes to mind. « New-York a des rats plus gros que des chiens »

That is an indo-european language. Those languages have no grammar or rules. You just string words together and hope it makes sense.

> You just string words together and hope it makes sense.

I beg your pardon? Messing the word orders in French or German will definitely mess up the sentence.

The German would be something like “Im New York sind Ratten, die größter als Hunden sind”, and moving the words would make the sentence invalid – albeit probably understandable.

Re: Lisp and Haskell (2015)

#148

Post by nicusor »

tsimionescu wrote: post #26
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…

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.

We've been using this approach in Typescript. It's more palatable than Haskell since you can express an array that has at least one element as a variadic tuple `[T, ... T]`. Having the possibility to encode invariants in types is very useful, although it gets harder at times since TS chokes when you push it to its limits. Note that this happens in an old Meteor codebase that was completely JS a year and a half ago.

Re: Lisp and Haskell (2015)

#149

Post by vindarel »

tome wrote: post #64
q3k wrote: post #61

Earlier quoted context omitted.

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…

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))

That's why Lisp has multiple return values, which are different from returning a tuple. It's great for refactoring. (https://lispcookbook.github.io/cl-cookbook/functions.html#mu...)

Re: Lisp and Haskell (2015)

#150

Post by vindarel »

higerordermap wrote: post #113
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…

Not just shape of data, but the values that are allowed by data. I agree that it is an oversold fallacy and types get really clunky when pushed too far. But any worthy type system prevents lot of errors. This is not generally acclaimed by empirical studies claiming only 5% improvement because they are caught at compile time. Other benefits are enough to use a sufficiently good static type system, by the way, even for…

All 4 points why I like Lisp so much more than Python!
Post reply on HN