
Make the Leap from JavaScript to PureScript - lelf
https://javascript.works-hub.com/learn/make-the-leap-from-javascript-to-purescript-c7ac7
======
tmountain
PureScript really hits the sweet spot for me, and it's become my favorite
functional language over the last six months. It really feels like a purpose
built stripped down Haskell without some modern refinements (string handling,
records, compiles to readable JavaScript). You can easily manage dependences
to incorporate the absolutely minimum set of packages necessary to run your
project, and I think its safety is unparalleled.

That said, the community is pretty small (but also really awesome), and it
fits into what is starting to feel like a crowded space (ReasonML, Elm,
ClojureScript [kind of], TypeScript, etc), but I'm still hopeful that
PureScript gets some traction over the next few years and becomes more widely
used in the industry, as it is a fantastic language and deserves to be more
widely recognized.

Also, if anyone is looking to try PureScript with minimal effort, I threw
together this guide a while back:

[https://github.com/tmountain/purescript-
reproducible](https://github.com/tmountain/purescript-reproducible)

~~~
the_duke
> without some modern refinements

Did you mean "with some modern refinements" ?

Otherwise, I agree. String handling, vectors, and record namespacing/access
are quite annoying legacy burdens of Haskell, improved upon in Purescript.

The type system lacks some of the power, but is sufficient for most designs
IMO.

~~~
tmountain
Sorry, yes, that was a typo.

------
kepano
We use PureScript for almost all frontend happening at my company, Lumi (YC
W15). We're definitely biased towards functional programming since we use
Haskell on the backend, and the creator of PureScript, Phil Freeman, works
here as Director of Engineering.

We're starting to publish more about the benefits of this approach and sharing
open source libraries here: [https://www.lumi.dev/](https://www.lumi.dev/)

Our React bindings are interesting to look at if you are curious:
[https://github.com/lumihq/purescript-react-
basic](https://github.com/lumihq/purescript-react-basic)

------
kadblas
A resource that covers more of these questions is covered here:
[https://github.com/JordanMartinez/purescript-jordans-
referen...](https://github.com/JordanMartinez/purescript-jordans-
reference/blob/latestRelease/00-Getting-Started/01-Why-Learn-PureScript.md)
Not all of it is up-to-date or presents the best arguments one could muster.
Rather, it's goal is to be "good enough."

Also related (but unfortunately not yet finished):
[https://github.com/chexxor/purescript-documentation-
discussi...](https://github.com/chexxor/purescript-documentation-
discussion/blob/50351c1aae8346c0f24125157316476ebb310db8/02-Context-or-
Narrative/State-of-PureScript-Documentation-2019.md)

See these repos for an example of the language in action: \-
[https://github.com/jordanmartinez/purescript-jordans-
referen...](https://github.com/jordanmartinez/purescript-jordans-reference) \-
[https://github.com/jordanmartinez/learn-
halogen](https://github.com/jordanmartinez/learn-halogen) \-
[https://github.com/thomashoneyman/purescript-halogen-
realwor...](https://github.com/thomashoneyman/purescript-halogen-realworld/)

------
Leace
I've been thinking about using PureScript years ago as I've enjoyed the
PureScript by Example book [0] and the language that seems like a cleaned-up
version of Haskell.

I didn't like that the compiler is not written in PureScript (although there
was a proof of concept [1]. Additionally, even though it compiles to
JavaScript, the code that is generated is sub-optimal performance-wise [2].

Ultimately I used TypeScript and have been happy with that but still long for
better FP language that generates lean code and can be used in a browser.

[0]:
[https://leanpub.com/purescript/read](https://leanpub.com/purescript/read)

[1]: [https://github.com/purescript/purescript-in-
purescript](https://github.com/purescript/purescript-in-purescript)

[2]:
[https://github.com/purescript/purescript/issues/2577](https://github.com/purescript/purescript/issues/2577)

~~~
huy-nguyen
I'm also concerned about PureScript's JS output so I looked into ReasonML and
has been quite impressed. The type system is a bit less powerful (no type
classes yet) but the JS output is very readable and maps almost line-to-line
to ReasonML code.

------
cryptica
I don't buy this idea that the programming language you use determines the
quality of your work. There is no evidence to support this. These extreme
programming fads were invented to sell books.

If novelists followed the same approach as programmers and they kept trying to
find the perfect language to write their books in, they wouldn't manage to
publish a single interesting novel.

A language cannot prevent someone from making stupid mistakes. At best, it
solves one set of familiar problems and replaces them with a new set of
unfamiliar (but equally bad) problems; then you have to learn to cope with
those new problems until the next hyped-up language fad comes along claiming
to solve those new problems and then you repeat the cycle.

~~~
com2kid
> A language cannot prevent someone from making stupid mistakes.

This can be refuted in one.

    
    
        if(a = b)
    

Languages that uses := for assignment, or some other operator, don't have the
mental overload of equals being used both for assignment and for equality
checks. Typos like the above become not possible.

Other languages just don't allow assignment in 'if' statements.

In regards to floating point support, a language could default overload
equality checks so that they are configurably fuzzy when comparing floats.

And of course, languages already prevent stupid mistakes. Even the humble C
compiler properly arranges the stack for us when exiting a function, putting
all return values in the appropriate place based on the platform's ABI and
restoring registers that are supposed to be preserved.

~~~
cryptica
>> Typos like the above become not possible.

In my 15 years of programming experience of programming every single day, I
have made this kind of typo maybe 2 or 3 times in total and it took me less
than a minute to identify and fix the problem each time.

On the other hand, the amount of time that it would have taken me to type out
that extra ':' a few million times would have been much more costly.

~~~
T-R
This is a _really_ arrogant statement. In C, `if(a = b)` could cause
incredibly subtle bugs. It was prominent enough that it got addressed in all
the best practices books, like "Writing Solid Code", with a style that got
later termed "yoda conditions" \- a style that was prominent in spite of being
acknowledged as less readable, because it forced a compiler error more often.
It's hard to even think of many other types of bug with that kind of
significance, and you just dismissed it out of hand with "I don't make those
kinds of mistakes".

~~~
Udik
If the problem is so bad, why not simply use a linter? Actually, almost all
instances of this typo can be caught by a simple regular expression.

~~~
T-R
Well, that's pretty much equivalent to the the language preventing bugs, for
the purpose of the conversation. You can imagine similar cases that would be
harder for a linter to pick up. Things like type errors, or accessing the
wrong side of a union - in C++ people used Hungarian Notation for a good while
to try to make these kind of errors more detectable; now some languages have
tagged unions/sum types to make them nearly impossible. The point where a
linter _is_ distinct from the language in catching syntactically evident
errors is that, even if I use a linter for my own code, that isn't the same as
having buy-in from the whole team to block any code that doesn't pass the
linter from shipping to production; language syntax, on the other hand, is
implicitly agreed upon.

Addressing this specific example, historically, running a linter all the time
wasn't always practical, and `if(a = b)` was used intentionally a lot, e.g. to
inline a check for a null pointer with an assignment.

------
Klathmon
Does anyone have any experience with both PureScript and ReasonML that can
compare the 2?

~~~
nobleach
During the 2016-2017 New Year I did an intense look into Purescript. I bought
the LeanPub book and did all kinds of stuff with it. More recently I did a
look into ReasonML. I bought the Pragprog book and worked through that. For
me, it came down to Haskell vs OCaml. I'll admit, I have a serious love for
OCaml/F#, so I immediately was excited about ReasonML. Many concepts just
transferred very easily. Purescript felt very academic once I got into trying
to build real things. Watching Phil Freeman's talks/Google Hangouts on
building cool new projects really was eye-opening. That guy thinks on an
entirely new level... who knows, maybe most Haskellers do? I have a sincere
appreciation for Haskell, but I have yet to bend my mind around it, so
Purescript left me in the same place - I felt like I wasn't really grokking
it. I should stress that this is ME, so you may have an entirely different
experience. I'm not saying that Purescript was bad at all.... it just wasn't
clicking very well.

------
automathematics
This just reminds me of "Make the Leap from Javascript to Coffeescript"

Remember where that got us?

This stuff is all really cool and fun to work on, but instead maybe we should
focus on changing the JS standard for the better since we always end up
working in it anyways!

[https://js.foundation/](https://js.foundation/)

~~~
ARandomerDude
Why not both?

CoffeeScript was awesome at the time, and ahead of its time. JavaScript owes
many of its new niceties _to_ CoffeeScript.

Yes, please, let's advance the state of JS. And let's push the boundaries with
other languages that don't have the backwards-compatibility constraints and
corporate sluggishness that JavaScript does. Then take the best features and
merge them into JS.

~~~
automathematics
Yeah it was awesome! But then years later most projects are wasting
engineering time to convert their whole code base which is a bummer! That's
all I'm saying.

------
jaequery
Question is why? What’s better about PureScript that would make other FP
programmers (eg; Elm) choose over it?

~~~
ff_
One of the biggest reasons for me is that you can run it on the backend too
(on NodeJS, or Erlang, or some other VM - yes, there are several backends
available)

~~~
_bxg1
Anything that targets JS, including Elm, can in theory be run on Node.

~~~
tutfbhuf
Can I run PureScript on node practically? If so, examples please.

~~~
ff_
Here's a wrapper for express: [https://github.com/nkly/purescript-
express](https://github.com/nkly/purescript-express)

Examples: [https://github.com/nkly/purescript-
express/tree/master/examp...](https://github.com/nkly/purescript-
express/tree/master/examples)

------
gridlockd
I'm put off (not because of the formatting):

[http://try.purescript.org/?session=60f1839b-bd82-d9af-75ef-d...](http://try.purescript.org/?session=60f1839b-bd82-d9af-75ef-
dcd936c4a0a2)

It adds weird syntax where it doesn't matter, like "<>" for string
concatenation, but it doesn't cut down on noise where it _does_ matter, i.e.
the "list of records" in the example.

I'm also wary of a language that puts "pure" right in the name. Purity is nice
and often beneficial, but there's a point where it just becomes a crutch. That
point which is where the FP adherents and the mainstream diverge.

~~~
lelf
It’s not a syntax, it’s just a function (<>). Also how would you ”improve”
list of records?

~~~
gridlockd
> It’s not a syntax, it’s just a function (<>)

Doesn't matter, it's annoying to type and read. What's wrong with '+'?
(Rhetorical question, _nothing_ is wrong with '+')

> Also how would you ”improve” list of records?

Admittedly, I had not thought of a better solution, but it looks noisy where
supposedly such a language should look "clean".

Perhaps something like this:

    
    
        examples:{title:string, gist:string} = [
              { "Algebraic Data Types", "37c3c97f47a43f20c548" }
              { "Loops", "cfdabdcd085d4ac3dc46" }
              { "Operators", "3044550f29a7c5d3d0d0" }
              { "Records", "b80be527ada3eab47dc5" }
              { "Recursion", "ff49cc7dc85923a75613" }
              { "Do Notation", "47c2d9913c5dbda1e963" }
              { "Type Classes", "1a3b845e8c6defde659a" }
              { "Generic Programming", "3f735aa2a652af592101" }
              { "QuickCheck", "69f7f94fe4ff3bd47f4b" }
          ]

~~~
ulucs
Putting addition and concatenation under the same operator massively backfires
when you start using math libraries. All of the language semantics is thrown
out of the window when you can realistically sum or concatenate the same two
elements, but the operator can only be used for one case (example: python and
numpy).

For the list of examples, you can just use tuples if you want the "clean"
look. There is no need to change the record semantics which is the same in
almost all languages.

~~~
gridlockd
> All of the language semantics is thrown out of the window when you can
> realistically sum or concatenate the same two elements, but the operator can
> only be used for one case (example: python and numpy).

Huh? You can't realistically "concatenate" two numbers and you can't "add" two
strings. You can only concatenate two strings, or a string and an (implicitly
converted) number. You can only add two numbers, or the elements of two number
arrays (or matrices). Plus isn't the "sum operator" (Σ). There generally is no
sum operator, there's a sum function (which works on iterables).

So what's the issue? It doesn't cause problems unless you confuse types, which
shouldn't happen in a statically typed language.

> For the list of examples, you can just use tuples if you want the "clean"
> look.

Is that really true though? Can I initialize an array of records with tuples
that are implicitly named?

> There is no need to change the record semantics which is the same in almost
> all languages.

This is basically C/C++ syntax, which somehow manages to be less verbose than
many supposedly terser languages.

------
srean
I do not do any web related programming but was quite intrigued and impressed
by a language called Opa. Could anyone watching this space comment on what is
happening in the Opa world.

------
darepublic
Scanned the home page for any reference to how you interface with the browser
API in purescript. Is it any different than in js?

~~~
ff_
Most of if is already wrapped in a well-maintained package:
[https://pursuit.purescript.org/packages/purescript-web-
dom/2...](https://pursuit.purescript.org/packages/purescript-web-dom/2.0.0)

But doing FFI and just using JS when needed is very easy:
[https://github.com/purescript/documentation/blob/master/lang...](https://github.com/purescript/documentation/blob/master/language/FFI.md)

So, to answer the question: no, it's exactly as in JS, because _it is_ JS

~~~
dmix
The biggest problem with PureScript right now is so many of the libraries have
little traditional documentation.

They often just include generated module level type/function docs as in the
`purescript-web-dom` one you linked to. Meanwhile the developer just wants a
quick overview and some examples of querying the DOM in order to evaluate it.

I tried using PureScript last year but I was having dependency problems like
crazy. Largely because everything was very alpha and dependency chains were
unreliable.

It's good to see the community maturing, there's still some way to go first,
which is excepted with any new language. I might try it out again this weekend
as I'm a fan of Haskell.

~~~
ff_
Agreed. Documentation is hard in all languages though, and it usually gets
fixed slowly over time as langs mature.

If you had dependency problems you were likely using bower (where dependencies
are "resolved", and this leads to broken states in some cases). You might want
to try a "package set" approach instead - i.e. there's a curated set of
library versions that are known to work together, so "dependency problems"
become impossible for users:
[https://github.com/spacchetti/spago](https://github.com/spacchetti/spago)

------
zumu
What's the deal with being tied to bower as the package manager?

~~~
toastal
It isn't necessarily though. A lot of people are using Spago
([https://github.com/spacchetti/spago](https://github.com/spacchetti/spago)).
Bower is fine though for how they're using it. Often times it'd kill for the
ability to relink libraries locally like bower lets you do in Elm while
working through a PR of an external library for my use-case.

------
lelf
The repo [https://github.com/adkelley/javascript-to-
purescript](https://github.com/adkelley/javascript-to-purescript)

------
mpweiher
Misread as "Make the Leap from JavaScript to PostScript".

Now that I would have been on board with!!

:-)

------
paul7986
What about HypeScript..anyone using that?

------
_bxg1
What distinguishes PureScript from Elm?

~~~
crimsonalucard
type variables, type classes, parametric polymorphism. Elm is similar to
golang missing generics, its a large gaping hole.

------
hkai
Typescript.

