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

91–100 of 173 posts

Re: Lisp and Haskell (2015)

#91

Post by mst »

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 dropped the newline feature, but hopefully a bit more illustrative of what I'd consider 'normal' lisp.

(comments, criticisms and thrown fruit welcome)

Re: Lisp and Haskell (2015)

#92

Post by veddox »

The state of the Common Lisp library ecosystem is probably the saddest thing about the language.

As the author says, the inbuilt standard library is hopelessly too small for modern requirements - even basics like string manipulation are only cursorily covered. And most of the third-party libraries out there are single-person projects, out of date, undocumented, or all three...

The language itself is still fantastic and, IMO, still superior to most other languages out there. But the lack of decent libraries is a major productivity killer.

Re: Lisp and Haskell (2015)

#93

Post by the_only_law »

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)

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 mainstream languahes or even a purely functional language like Haskell?

Re: Lisp and Haskell (2015)

#94

Post by sullyj3 »

tasuki wrote: post #86
sullyj3 wrote: post #78

Earlier quoted context omitted.

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?

Good point! last time I used elm i didn't know what a nonempty list was.

Re: Lisp and Haskell (2015)

#95

Post by thesz »

phoe-krk wrote: post #44
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…

Note that this is on SBCL 1.5.6 which is a little bit over a year old at this point; the article is from 2015 so we should pick a properly dated version from https://sourceforge.net/projects/sbcl/files/sbcl/ and check there. The Common Lisp implementations and compilers keep on getting better with time and they produce more and more compile-time warnings (especially SBCL).

I once read modification of Greenspun's Tenth Rule which looked like "typical Common Lisp implementation contains slow ad hoc bug ridden implementation of half of Haskell type system".

Which case I clearly see here.

Re: Lisp and Haskell (2015)

#96

Post by StreamBright »

fhsm wrote: post #34
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 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…

Great question. Our entire company has moved to F#/CLR/.NET Core at the beginning of 2020 and we could not be happier. It started in 2019 as a hobby project, I just wanted to create a simple (not in par in terms of features) replacement for Google Analytics to track how users use our website and also create an ETL pipeline for it using AWS Lambda. This is how I got into it more in depth. The more I worked with it I started to like it even more. When the time came to select the stack for our next project we had Rust and F# as the two options and F# won because most devs were already familiar with C# and we did not like few things about Rust (especially the string handling) while we could not find any particular issue with F#. Now, 100.000 lines of code later, it was a pretty good decision.

As far as Clojure goes, I usually use it for the JVM world, if I get a project and there are no other devs. Unfortunately it is almost impossible to convince Java devs to use Clojure and there are some limitations (Java interop for example) that makes it hard to sell. I am not even sure what would I do in your situation.

Re: Lisp and Haskell (2015)

#97

Post by phoe-krk »

thesz wrote: post #95
phoe-krk wrote: post #44

Earlier quoted context omitted.

Note that this is on SBCL 1.5.6 which is a little bit over a year old at this point; the article is from 2015 so we should pick a properly dated version from https://sourceforge.net/projects/sbcl/files/sbcl/ and check there. The Common Lisp implementations and compilers keep on getting better with time and they produce more and more compile-time warnings (especially SBCL).

I once read modification of Greenspun's Tenth Rule which looked like "typical Common Lisp implementation contains slow ad hoc bug ridden implementation of half of Haskell type system". Which case I clearly see here.

That's a common phenomenon. Statically typed programming languages try to implement features of dynamically typed programming languages, whereas dynamically typed programming languages try to implement features of statically typed programming languages. On one side, we have a struggle of languages like C++ attempting to relax their own rigidness to achieve dynamic behavior, and on the other, we have languages like Javascript and Lisp attempting to constraint their own dynamic nature for benefits that come from static typing.

Re: Lisp and Haskell (2015)

#98

Post by StreamBright »

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)

> Is it true that the F# compiler can be super slow especially on larger codebases?

Define slow. I never had an issues with the compilation speed of F#.

> why use F# when you can use OCaml?

Even though both of them are in the same family they could not be further away from each other. OCaml has many standard libraries more you can read here: https://discuss.ocaml.org/t/what-is-the-preferable-solution-...

F# has (almost) everything that is available in the CLR, which means tons of high quality libraries, ready to be used in production.

Another advantage is AWS support. Since C# is a tier one language in the cloud F# is also a tier one language. I am not sure where OCaml falls into in this space.

Other than these I am not sure why, but these are pretty big ones for us. I love OCaml and trying to use it whenever I can, which is not that much unfortunately.

Re: Lisp and Haskell (2015)

#99

Post by jshholland »

ghostwriter wrote: post #74
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…

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

Re: Lisp and Haskell (2015)

#100

Post by StreamBright »

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 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.
Post reply on HN