Live data from Hacker News

Lisp and Haskell (2015)

markkarpov.com

31–40 of 173 posts

Re: Lisp and Haskell (2015)

#31
post #15
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…

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 complex as adequately handling an empty array in the code.

My personal struggle is that statically typed languages are annoying to prototype (I don't care if it segfaults on my laptop, I want to validate my idea). My struggle is prototyping in something that I can easily transition to a strictly typed version. I'm curious to try prototyping in Javascript and adding types when I move to production.

Re: Lisp and Haskell (2015)

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

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. I agree that having the option to use a partial function is useful, escape hatches are important, but it shouldn't be the go to.

Nonempty was just a simple example. You're right that it's not very commonly used (probably because it's not in Prelude), but the general culture of writing type safe interfaces and pushing guarantees to compile time %100 is a thing. A commonly used, more complicated example might be Servant, which is a web library which statically ensures your implementation meets an API spec.

Re: Lisp and Haskell (2015)

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

Can you elaborate? I have difficulties understanding what you mean. Do you really mean an idiomatic loop should be 'a jumble of random words'?

Re: Lisp and Haskell (2015)

#34

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 really like both of these languages but don’t work in either and find that I struggle to manage these two totally different platforms for hobby work. Both communities have strong tooling norms such that I feel stuck either burning side project time getting up on tools or burning time fighting “the way” assumes by most online materials.

Any tips on how to have just a little bit of Clojure/JVM and f#/CLR in your life when day-to-day is on neither platform?

Re: Lisp and Haskell (2015)

#35
Just tried the code in SBCL and it definitely gives a compiler warning even without executing the function:

    This is SBCL 1.5.6, an implementation of ANSI Common Lisp.
    More information about SBCL is available at .
    
    SBCL is free software, provided as is, with absolutely no warranty.
    It is mostly in the public domain; some portions are provided under
    BSD-style licenses.  See the CREDITS and COPYING files in the
    distribution for more information.
    * (defun add-text-padding (str &key padding newline)
      "Add padding to text STR. Every line except for the first one, will be
    prefixed with PADDING spaces. If NEWLINE is non-NIL, newline character will
    be prepended to the text making it start on the next line with padding
    applied to every single line."
      (let ((str (if newline
                     (concatenate 'string (string #\Newline) str)
                     str)))
        (with-output-to-string (s)
          (map 'string
               (lambda (x)
                 (princ x s)
                 (when (char= x #\Newline)
                   (dotimes (i padding)
                     (princ #\Space s))))
               str))))
    ; in: DEFUN ADD-TEXT-PADDING
    ;     (MAP 'STRING
    ;          (LAMBDA (X)
    ;            (PRINC X S)
    ;            (WHEN (CHAR= X #\Newline) (DOTIMES (I PADDING) (PRINC #\  S))))
    ;          STR)
    ; 
    ; caught WARNING:
    ;   The function (LAMBDA (X) :IN ADD-TEXT-PADDING) called by MAP returns NULL but CHARACTER is expected
    ;   See also:
    ;     The SBCL Manual, Node "Handling of Types"
    ; 
    ; compilation unit finished
    ;   caught 1 WARNING condition
    ADD-TEXT-PADDING

Re: Lisp and Haskell (2015)

#36

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…

Combination of somewhat high barrier to entry (they're unlike most other languages so experience isn't as transferable), and network effects - those in charge of choosing a technology for a project generally make the subjectively prudent decision to use technology that is already in common use, leaving the less common languages in a catch 22.

Re: Lisp and Haskell (2015)

#37

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)

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

Re: Lisp and Haskell (2015)

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

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 documentation either?

Re: Lisp and Haskell (2015)

#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 checking etc

To reiterate, I love static analysis but I also need control over how and when it runs, I like it in CI and during editing

Otherwise it comprises one of the best things about those old languages, (Smalltalk lisp etc) being able to dev your application by injecting code and recompiling while the app is still running

The feedback loop while coding a live image is hard to explain but anything that makes it slower is disastrous for me, I can lose focus so quick

When deving Clojure idiomatically partial recompile happens at a much greater frequency than most languages, compile time is very important

Re: Lisp and Haskell (2015)

#40

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…

> still they are seldom used in serious software

This is mostly because the majority of software developers only know Java and are averse to learning new languages. Also, companies chose Java at one point and are now taking next to no risks by introducing new languages (not even languages on the JVM). They can also just fire and rehire Java developers because there is a large pool of available developers that they can just plug-n-play, so to speak. They're not interested training people.

Post reply on HN