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

41–50 of 173 posts

Re: Lisp and Haskell (2015)

#41

Post by timonoko »

andi999 wrote: post #33
timonoko wrote: post #21

Earlier quoted context omitted.

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'?

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.

Re: Lisp and Haskell (2015)

#42

Post by tines »

FullyFunctional wrote: post #30
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…

I frequently have to defend why I hate Python but the foremost reason is that lack of static typing (which also makes reading other peoples codes harder than it need be). Static typing, especially in a rich type system like, e.g. Haskell and Rust, doesn't guarantee you don't have bugs, but it almost guarantees the ones that remain are better bugs, that is, application level bugs. However in my experience, I can usual…

Absolutely. The more experience I have, the more repugnant dynamically typed languages seem to me (for domains where they fit, i.e. I'm not talking about untyped assembly or whatever).

Re: Lisp and Haskell (2015)

#44

Post by phoe-krk »

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

Re: Lisp and Haskell (2015)

#45

Post by skellystudios »

slifin wrote: post #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 che…

That sounds super cool, and I'd quite like to give it a go.

I'm not sure if what Haskell has is quite the same, abilities but you can hot-reload modules at runtime in GHCi, and FWIW, I've always found the type checker to be pretty zippy.

Re: Lisp and Haskell (2015)

#46

Post by sidkshatriya »

dunefox wrote: post #37
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)

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

Re: Lisp and Haskell (2015)

#47

Post by pyrale »

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…

As a paid user of haskell and Java, here are a few of the things I experienced when discussing about language choices in corporate settings:

* Fail a project in Java, and you have a project failure. Fail a project in Haskell, and you have a Haskell failure.

* Management has a large veto power, and management usually favors technologies they are used to, or used to use themselves.

* Management also favors their ease of work with the tech. In practice, they often hold the belief that it's much easier to find java developers than it is to find haskell developers.

* Haskell suffers from a reputation of being "academic" and "hard to do real things with".

In practice, I've done great commercial projects in Haskell, and the technology was worth using. When done right, recruiting for haskell projects was much faster than recruiting for any mainstream language. On the flipside, it was sometimes hard to get adequate corporate stewardship for the language (for instance, managers/HR insisting they found no one for the job after publishing through the usual channels when you know half a dozen people at the local meetup that would jump ship if offered a position).

Re: Lisp and Haskell (2015)

#48

Post by rxhernandez »

FullyFunctional wrote: post #30
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…

I frequently have to defend why I hate Python but the foremost reason is that lack of static typing (which also makes reading other peoples codes harder than it need be). Static typing, especially in a rich type system like, e.g. Haskell and Rust, doesn't guarantee you don't have bugs, but it almost guarantees the ones that remain are better bugs, that is, application level bugs. However in my experience, I can usual…

Which is absolutely bizarre to me because most of my experience with Python has been with people who are effectively scientists who don't give a rats-ass about good coding practices and yet I rarely had issues with receiving the wrong type.

Don't get me wrong though, I spent the first 10 years of programming with C and Java so I understand the comfort that a statically typed language provides. I just haven't found it to be a big enough issue over the past 7-8 years of programming in Python to really complain about it.

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; but that's an issue with most languages.

Re: Lisp and Haskell (2015)

#49

Post by iambrj »

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…

For the curious, I suggest reading Philp Wadler's "Theorems for free!" which explains how to derive a theorem for a given type. Practically, this helps compilers make certain optimizations based on the theorems it derives from the types.

Re: Lisp and Haskell (2015)

#50

Post by iambrj »

kgwgk wrote: post #13
goto11 wrote: post #9

Earlier quoted context omitted.

Parentheses in Lisp is like significant whitespace in Python: A big stumbling block for people who don't use the language.

But for those who use the language one is a powerful feature and the other a minor annoyance.

One man's hack is another man's elegance
Post reply on HN