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

131–140 of 173 posts

Re: Lisp and Haskell (2015)

#131

Post by [deleted] »

sullyj3 wrote: post #12
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…

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…

[deleted]

Re: Lisp and Haskell (2015)

#132

Post by guenthert »

mst wrote: post #110
dunefox wrote: post #104

Earlier quoted context omitted.

(defun add-text-padding (str padding) (let ((lines (split-string "\n" str)) ( cond ((nil? lines) "") (#t (join-string "\n" (cons (car lines) (mapcar (lambda (x) (concat-string (repeat-string " " padding) x)) (cdr lines))))))) The closing brackets are supposed to be in one line, that much I know.

Yes, that's a more common way to format the code. I was trying to elucidate a different structure .

But it makes it unnecessarily hard to read and distracts from what you meant to convey.

Re: Lisp and Haskell (2015)

#134

Post by guenthert »

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…

Yes, I'm somewhat puzzled that static typing seems so important to some, while it clearly only prevents one class of errors (and depending on the language, even that only to some extend, e.g. it's still possible to initialize enumeration class instances with invalid values in C++). I'd have expected that Eiffel's pre- and post-condition or design by contract in general, would have gained more traction with those who care about eliminating possible sources of programmer errors.

Re: Lisp and Haskell (2015)

#135

Post by ImprobableTruth »

msla wrote: post #130
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.

Receiving a None or Nothing or a NULL or similar is something a type system can paper over or, more politely, force you to add code to ward off but there's something happening in the actual data, if not the real world, which is causing that non-value to be present and the type system can't fix that.

But is the issue receiving a null or is it how unexpected the null is? Assuming that functions always can return null is way too tedious, so in practice my issue with dynamic languages like Python is that I'm never sure whether a function can actually return null.

Re: Lisp and Haskell (2015)

#136

Post by mr_custard »

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.

> Clojure and F# are my two favourite languages and I have similar experience

Same. I have worked in both F# and Clojure profressionally. I love them both for different reasons.

As a fun thought experiment, I have often tried to force myself to choose between them, even though one doesn't really have to make a choice. Turns out that it's a tough choice to give one up over the other.

I tend to lean slightly towards Clojure at present, but then I'm using it a great deal at work.

However, if you're looking for a modern strongly typed, immutable functional language with type inference, then F# is really excellent.

I haven't used Haskell professionally and have only played with it but my feeling is that I prefer F# to Haskell because it has some "escape hatches" built in, in order to interop with C# and other .NET languages; So no IO Monad is required. It feels like more of a supporting structure and less of a straightjacket to me.

Re: Lisp and Haskell (2015)

#137

Post by dirkt »

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…

> you don't even want to pay the type annotation tax for.

You won't understand those aphorisms as long as think of "type annotation" as something useless, "tax-like". I know where you come from, in languages like Java it is a tax - you repeatedly write long-winded types in different places.

With type inference, that changes. You have a REPL (or IDE integration) that you can just ask for the inferred type as soon as you write a function. Then you look at it, you think about if it expresses what you want the function to do (that already catches some errors), you copy-and-paste it, make it a bit prettier, and bam, type annotation is done. It's even on an extra line, you don't have to attach it to arguments.

Or, you design with types ("test first style", think of the type annotation as a test). You first write down the type, then you write the function, and you see if the type checker agrees. If it doesn't, you probably found a bug. Or your idea of what the function should do was wrong (has also happened to me).

And everyone who uses that system does know that type checks are very dumb checks. They only help against dumb errors. But the majority of bugs are dumb bugs (at least the majority of my bugs) - misspellings, you forget to write out some part, etc. Those get caught. The hard bugs won't - that's what tests are for. (And automated testing is again simpler in the presence of types, see Quickcheck).

> and encourage the pursuit of bad abstractions like 18-arg functions

It never does. 18-arg functions are just unwieldy. If your function grows to that point, refactor (or rather, refactor long before that). And again, the type systems helps with refactoring.

(Yes, I know I won't convince you, this debate has been going on for at least 30 years. OTOH, it doesn't hurt to see the opinion on the other side).

Re: Lisp and Haskell (2015)

#139

Post by lbj »

I agree with the point on CL libraries, which is truly sad after this many years. But Lisps like Clojure address this formidably by integrating deeply with the JVM and actually also Python.

Im not sure his code is idiomatic SBCL but it could be written more succintly and functionally by most LISPers.

To the point on static/dynamic typing, I disagree. But its a discussion thats been going on for so long that Ive concluded its mostly a matter of taste. For Clojurians who like static typing, Spec packs a big punch without removing flexibility.

Still, Haskell is pretty great but Im more efficient in Clojure, Your mileage will vary.

Re: Lisp and Haskell (2015)

#140

Post by guenthert »

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…

That has been discussed to death already. Common Lisp might be a niche, but it appears to be even more of a niche than it actually is when cursory looking at major projects. Common Lisp (and similar languages) are (particularly, not only) well suited for prototypes created by a small group of well interacting developers. If you shoot for very large systems, with a very large staff of various talent and experience (and inevitable communication break-downs), then e.g. Java is the safer bet. For this reason, rewriting a Common Lisp program into Java is not a sign of failure of the language, but a sign of success of the project.
Post reply on HN