Lisp and Haskell (2015) • Hacker News Board

Re: Lisp and Haskell (2015)

#101

Post by shakow » Thu, Oct 08, 2020, 2:21 PM UTC

timonoko wrote: post #41

andi999 wrote: post #33

Earlier quoted context omitted.

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

Difficult to explain cause not an expert, but most languages do not have "list comprehension" by post-description. "New York has rats bigger than a dog" comes to mind. In Finnish you can but the adjective word have same ending or grammatical case as the main word. Without those clues the sentence would be nonsensical.

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

Re: Lisp and Haskell (2015)

#102

Post by Kednicma » Thu, Oct 08, 2020, 2:32 PM UTC

tome wrote: post #73

q3k wrote: post #65

Earlier quoted context omitted.

Sure, but Python and Python developers don’t hype up its type system to be the solution to all your programming woes :).

I'm not sure what "Haskell developers" are saying, but this Haskell developer says "Haskell provides many tools that can be used to solve programming woes. One such tool is its strong and flexible types system (there are several other tools, such as immutability, functional style)."

And Python provides readable syntax. Your example has an easy-to-spot bug, just from reading the code and knowing Python's semantics. Haskell's "programmable semicolon" ends up being a problem here because, thanks to typeclasses, the programmer usually does not know which semicolon they are programming under!

"Python provides many tools that can be used to solve programming woes. One such tool is its strong and readable syntax." Do you see how empty this sort of platitude is?

Re: Lisp and Haskell (2015)

#103

Post by dunefox » Thu, Oct 08, 2020, 2:32 PM UTC

StreamBright wrote: post #100

sidkshatriya wrote: post #46

Earlier quoted context omitted.

> 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 spent 2 hours on this excellent tooling to try to upgrade a package with opam, I finally gave up after read all the Github issues and Stackoverflow, etc.

I spent two evenings (3 years ago, admittedly) to get the tooling setup so that I could install libraries. I got nowhere and gave up. I'm quite interested in the language but everything else seems to be a dumpsterfire.

Re: Lisp and Haskell (2015)

#104

Post by dunefox » Thu, Oct 08, 2020, 2:33 PM UTC

mst wrote: post #91

dunefox wrote: post #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 distributi…

Plus, the whole ... style ... seems bizarre to me. Common Lisp isn't my usual dialect but I'd've expected something more like: (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) ) ) )) ) ) Note: pseudocode typed straight into the comment box, and I dr…

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

Re: Lisp and Haskell (2015)

#105

Post by jstimpfle » Thu, Oct 08, 2020, 2:34 PM UTC

garethrowlands wrote: post #80

jstimpfle wrote: post #67

Earlier quoted context omitted.

> I guess you probably don't write tests or documentation either? Why would any experienced programmer make such a blanket statement? As always, it depends. Sometimes there is value in documentation (or whatever unchecked types in fancy languages), especially for stuff that is read a lot more, by other people, or yourself in the future. For a lot of stuff there is no point in writing documentation. For example, if th…

The fact that code and types don't diverge can make types useful as documentation, albeit limited documentation. Ideally the compiler figures out the types so you don't have to. Haskellers often find this useful when they refactor a month later.

Code and types can very much diverge if the types aren't checked by the compiler, as my parent poster indicated.

Case in point: type aliases instead of (Haskell) newtypes. Type aliases (which are unchecked, unlike newtypes) can lead to exactly the kind of diverging that I alluded to. Look at the mess that is all the typedefs and defines in the Win32 API for example. It's extremely hard not to pass in the wrong typedefs, and there must be extremely few programmers who know which aliases are the same on every platform and which could change.

Aside, newtypes (Or the equivalent in C for example, wrapping a single member in a struct) can be very annoying. I would advicse against this, just like I'd advise against using type aliases.

Re: Lisp and Haskell (2015)

#106

Post by sk2020 » Thu, Oct 08, 2020, 2:35 PM UTC

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)

You use F# because your use case requires .NET. You can’t write AutoDesk plugins in OCAML, or at least I’ve never heard of that happening. Sometimes you don’t actually have meaningful alternative programming languages for certain uses.

Re: Lisp and Haskell (2015)

#107

Post by dunefox » Thu, Oct 08, 2020, 2:36 PM UTC

jshholland wrote: post #99

ghostwriter wrote: post #74

Earlier quoted context omitted.

Why does getUsers return Maybe [a] in the first place? It should be [a]. You can also implement your own version of length that works only with iterables of your choice. The language allows leveraging type constraints to achieve this, the fact that your team didn't use it doesn't indicate an inherent flaw in the type system you've been provided with. And if you want to go an extra mile, use liquid-base instead of bas…

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

`Either` would be much better, no?

Re: Lisp and Haskell (2015)

#108

Post by tome » Thu, Oct 08, 2020, 2:37 PM UTC

Kednicma wrote: post #102

tome wrote: post #73

Earlier quoted context omitted.

I'm not sure what "Haskell developers" are saying, but this Haskell developer says "Haskell provides many tools that can be used to solve programming woes. One such tool is its strong and flexible types system (there are several other tools, such as immutability, functional style)."

And Python provides readable syntax . Your example has an easy-to-spot bug, just from reading the code and knowing Python's semantics. Haskell's "programmable semicolon" ends up being a problem here because, thanks to typeclasses, the programmer usually does not know which semicolon they are programming under! "Python provides many tools that can be used to solve programming woes. One such tool is its strong and read…

I didn't intend to make this into a competition between Haskell and Python.

Re: Lisp and Haskell (2015)

#109

Post by Kednicma » Thu, Oct 08, 2020, 2:41 PM UTC

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…

Are you sure? https://lobste.rs/s/yyhu4w/real_problems_with_functional_lan...

Re: Lisp and Haskell (2015)

#110

Post by mst » Thu, Oct 08, 2020, 2:47 PM UTC

dunefox wrote: post #104

mst wrote: post #91

Earlier quoted context omitted.

Plus, the whole ... style ... seems bizarre to me. Common Lisp isn't my usual dialect but I'd've expected something more like: (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) ) ) )) ) ) Note: pseudocode typed straight into the comment box, and I dr…

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