Hacker News new | past | comments | ask | show | jobs | submit login

> To what degree do you use Lisp as an FP language? As a pure FP language?

It depends on what I'm doing, but I generally write in an OO style more than a functional style. Real problems have state.

> If you dislike new languages

I want to be clear that this is just a general observation. I don't dislike new things because they are new, I tend to dislike them because they are generally bad. But they are not all bad. Clojure is cool. WebASM is very cool. The work that has been done on Javascript compilers is nothing short of miraculous (even though the language itself still sucks).

> I bet XML drives you straight up the wall

Kind of, but not really. Yes, I dislike XML because it is nothing but S-expressions with a more complicated syntax. But it doesn't drive me up a wall because when I need to deal with XML I just parse it into S-exprs, do what I need to do, and render the results back into XML.




I dislike XML because it's a nested tree of internal nodes and typeless character string leaves.

In XML I have no way to place "255" and "FF" in such a way that XML understands them to be the same object, of integer type.


Sure you do. <base10>255</base10> <base16>FF</base16>


Pure FP deals with state!


Sure, everything non-trivial is Turing-complete. But FP begins as a stateless paradigm and then tacks on state as a sort of a kludge while all the while seeming to be a little embarrassed about it, while OO embraces state from the beginning as part and parcel of the mental model that it endorses. I find the OO model has a better impedance match to my brain and the real world. Reasonable people can (and do!) disagree.


State is something that is best just embraced rather than "dealt with".


An analogy to that is that OO doesn't embrace IO. Yet weirdly enough that makes OO-IO better than older languages that have built in commands to write to disk.

Haskell doesn't have state but you have multiple models to choose from, from simple folds to STM or State or Reader or Writer Monads all of which serve different purposes and do different jobs well.


OOP absolutely embraces I/O. I/O begs to be OOP and makes, hands down, the best use case for illustrating OOP.


What I am getting at is that OOP languages like C++ have no IO commands built in it is all delegated to libraries.

Haskell has no state support built in, it is all delegated to libraries.

So:

C++ has excellent IO support, but the language doesn't embrace IO at all.

Haskell has excellent State support, but the language doesn't embrace State at all.


C++ I/O libraries in fact depend on the sequencing semantics built into the language. If we make two calls to the library, they happen in that order; consequently, the I/O happens in that order. We can do wrong things like:

    f(cout << x, cout << y)
where we don't know whether x is sent to cout first or y.

C++ statements could be added to C++ (e.g. as a compiler extension). They would be straightforward to use; C++ doesn't inherently reject that the way Haskell and its ilk reject sequencing and state.


Haskell doesn't reject sequencing. f = g . h will require h is evaluated first.


h might not be evaluated at all! Consider

    h x = factorial x
    g x = 0
(but I agree that Haskell doesn't reject sequencing).


Yeah the IO monad will, but it isn't generally true of monads. Infant the maybe monad Will cease early on Nothing by design. So it is a brain shift.


> Haskell has excellent State support

Someone who understands where that support is and how to use it should rewrite atrocities like:

https://rosettacode.org/wiki/Assigning_Values_to_an_Array#Ha...


I don't think that's so bad, it's just you are using a function instead of the usual built in indexing operator [0]. Here's something a bit more convenient using Data.Array.Lens[1].

    arr ^. ix 2
vs the original:

    readArray arr 2




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: