Make the Leap from JavaScript to PureScript

https://javascript.works-hub.com/learn/make-the-leap-from-javascript-to-purescript-c7ac7

by lelf • 7 years ago

105 81 7 years ago

lelf2• 7 years ago

The repo https://github.com/adkelley/javascript-to-purescript

tmountain2• 7 years ago

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

the_duke2• 7 years ago

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.

tmountain2• 7 years ago

Sorry, yes, that was a typo.

sridca• 7 years ago

Don't forget GHCJS, which is really handy as you get to share (Haskell) code between client and server. Here's an example from my own project: https://github.com/srid/Taut

darepublic• 7 years ago

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_5• 7 years ago

Most of if is already wrapped in a well-maintained package: https://pursuit.purescript.org/packages/purescript-web-dom/2...

But doing FFI and just using JS when needed is very easy: https://github.com/purescript/documentation/blob/master/lang...

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

dmix• 7 years ago

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.

Klathmon• 7 years ago

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

bcheung4• 7 years ago

I had this exact same question and couldn't find much out there.

Based on what I have seen ReasonML is being pushed more within the React community and has more of a JS syntax so there is less of an abrupt change in terms of language.

PureScript follows the Haskell syntax that I personally like more and find cleaner and more useful for FP programming.

The ReasonML code I've seen doesn't have as much computer science rigor or abstractions like monads. This means the ReasonML community generally works at a lower level of abstraction compared to the PureScript crowd.

The interop with JS looks a cleaner in PS.

The tooling looks better around ReasonML especially around fast compilation and automatic reloading.

PureScript has a richer type system.

Personally, I would rather use PS but I've studied Haskell a bit already. For people without the Haskell background ReasonML provides an easier transition so it is an easier sell for a team.

jahewson• 7 years ago

PureScript is heavily influenced by Haskell with a focus on purity, monads and lots of abstraction, while Reason is literally OCaml (which has a more pragmatic take on mutability) only they switched the ML syntax for a JS-like syntax.

nobleach• 7 years ago

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.

fulltrottle• 7 years ago

Yeah I've used both quite a lot.

Both languages are pretty similar. ReasonML isn't actually a language but more like a new syntax for Ocaml (Bucklescript on the frontend), kind of like what Coffeescript is to JS.

- Both have row polymorphism and higher kinded types. - Purescript has ad hoc polymoprhism, Ocaml doesn't but it's planned in a future release. Purescript achieves it via typeclasses, future Ocaml will achieve it via modular implicits which is more sound from a type system perspective. - Purescript has higher kinded polymorphisn, Ocaml only has a lightweight version of it via it's module system. - Purescript has better support for type-level programming although awkward, but Ocaml has good interop with Coq -it's written by the same people - Purescript is purely functional, Ocaml isn't although it emphasizes a purely functional approach - Purescript places category theory abstractions first like Haskell does as a core aspect of the language. Ocaml doesn't, although it's standard library has all of the same kinds of functions and there are category theory libraries and everything - Ocaml not just -to-JS, it's also a compiled language, and has had real industrial use as a systems language in the finance industry (Jane Street) - Ocaml's compiler is _insanely_ fast compared to any other compiler I've ever used. I absolutely appreciate it - Future Ocaml will be multicore and have a builtin algebraic effects system, basically like Haskell's extensible effects but without the performance hit or having to muck about with monads - Ocaml has GADTs, polymorphic variants, and a way to extend the language via PPX. Polymorphic variants are awesome - Ocaml's module system is really powerful and amazing

Overall both languages are great, but for almost every use case I'd go with Bucklescript/Ocaml any day. It's type system is pretty simple and easy to learn. Purescript has the same issue as Haskell which is the learning curve: higher kinded polymorphism, typeclasses, enforced purity via "the IO monad", and category theory concepts all add up and take quite a while for people to get used to. And the compiler is really fast. And you can write low level imperative code if you need to for performance. And the type system is really expressive, moreso in my opinion than Purescript's because of the poly variants. And you get like 90% of the benefit of using a language like Haskell and Purescript because of the `option` type and enforced safety via exhaustive pattern matching

I can't wait until Ocaml gets modular implicits and algebraic effects into the core language.

jaequery2• 7 years ago

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

eweise2• 7 years ago

More powerful abstractions that reduce the amount boilerplate compared to Elm.

jaequery2• 7 years ago

Can you provide an example ?

ff_5• 7 years ago

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)

_bxg13• 7 years ago

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

_bxg13• 7 years ago

This is my question every time I see a new language pop up here. If there's nothing obviously novel about its design, its platform, or its community, I don't see the point of further fragmenting what people are using (unless it's just an experimental/learning-experience/for-fun language that isn't intended for production).

the_duke2• 7 years ago

Elm is also inspired by Haskell, but has a (intentionally) very simplistic type system.

It lacks essential abstractions such as type classes, resulting in very boilerplate-heavy code.

Maybe this trade-off has helped it gain adoption and is the right choice for a simple language that purpose built for UI generation. For me it is way too limiting.

bcheung4• 7 years ago

Elm requires the use of the Elm architecture. PS does not.

PureScript can work server-side. Elm is pretty much browser only.

PS has a richer type system. Elm's type system is extremely limited and makes it much harder to model domains because you can't do it generically and often need to write lots of boilerplate.

PS has a higher level of abstraction and expressiveness.

Elm's niche is frontend developers wanting to learn more about FP and get a gentle introduction to the Haskell like syntax.

Elm definitely has the better ecosystem and tooling. It's much easier to learn as well.

But as you learn more about FP and some of the higher level abstractions like monads you will find Elm very limiting.

cryptica2• 7 years ago

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.

UnFleshedOne• 7 years ago

Try writing something in machine code?

adrianN• 7 years ago

Human languages had a few thousand more years of optimization going on. By now they're pretty decent for expressing things people want to say.

feanaro• 7 years ago

A language cannot prevent someone from making stupid mistakes.

Completely prevent all possible mistakes? Of course not.

However, it certainly can make many mistakes either impossible or much rarer.

phailhaus2• 7 years ago

You're making too many extreme claims to be defensible. You might have a point for recent language fads, but choice of language absolutely does have an impact on your work and the nature of the bugs you're going to be dealing with. If you choose to use a language with a poor ecosystem, then you're going to have to build a lot more tools in house that are going to be subpar compared to more vigorously maintained libs and frameworks in another language. If you decide to write in JavaScript, then you're going to introduce bugs that TypeScript would have statically checked against. It all depends on the nature of your problem and what tradeoffs you're willing to make.

sesteel• 7 years ago

It is a complicated area, you might find this paper interesting:

https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf

It tries to measure the defect rates between programming languages. To say it doesn't matter is too simplistic, in my opinion. I think matching the tool to the task is somewhat important, but often, as you suggest, you can get by with suboptimal choices and choose based on familiarity or esthetics. People would probably do better by spending their time learning how to think critically about code rather than learn a new language every year.

penagwin• 7 years ago

It depends on what you're trying to do.

A language without strong types might make tooling more difficult, not catch certain errors at compile time, make refactoring harder, and make working in teams harder. Or it might have little impact on you.

A language without a GC will be more complicated for certain tasks as now you have to manage the memory. It's harder for beginners, and doesnt make sense in many environments. Then again a lack of GC may be necessary if you do embedded work.

A language might let you write in one line of code, while another would take 20 lines for it. Is that more expressive? Maybe it's harder to maintain?

Do you like white space? Maybe you do, maybe you don't.

Many interpreted languages are slower then their native counter parts. Then again if your application doesn't need much compute performance, maybe it's worth it? Or maybe not.

It's all pros and cons. You don't want to make a "hello web!" web application In assembly when ruby/python/etc can do it in a few easy to read and understand lines.

com2kid2• 7 years ago

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.

cryptica2• 7 years ago

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

z3t4• 7 years ago

While the language can prevent certain errors on itself, errors can also be found with static analysis and testing, and prevented with paradigms and experience.

ARandomerDude2• 7 years ago

Best of both worlds:

(let [x 1]

  (if (= x 1)

    ...))

carc1n0gen• 7 years ago

I am personally more likely to forget the : than a second =. Happened all the time when I was writing plsql.

TazeTSchnitzel• 7 years ago

That's why I write all my programs in 16-bit real-mode 8086 assembly using MS-DOS's DEBUG.EXE. Aside from being fired from my job for this destroying my productivity and making my code unreviewable and full of security issues, everything is great, because there's no differences between programming languages at all!

bcheung4• 7 years ago

There's a concept known as linguistic relativity (https://en.wikipedia.org/wiki/Linguistic_relativity) that states that the language affects what thoughts you are capable of having.

We don't program in assembly language because it is very tedious and error prone. Higher level languages absolutely do eliminate classes of errors that are only possible at the assembly language level (accidentally altering the stack and affecting the jump return address for example). Another example would be garbage collection making it impossible to create a certain class of errors.

Another example would be doing long division with roman numerals instead of Arabic. The human brain can only process so much before it becomes overloaded. By "compressing" thoughts using new vocabulary concepts you can reason about ideas that are beyond your normal cognitive limits.

aij• 7 years ago

I've found that being able to think in one programming language even affects the thoughts you have when working in other programming languages.

For example, after learning ML, I started writing much more functional code even when writing Python. I also started using abstract types more, even in C.

emerongi• 7 years ago

And yet there's a thousand vulnerabilities from C/C++ code being used out in the wild, stemming from bad memory management, whereas we don't see those with many other languages.

Yes, there are still other types of bugs that are language-agnostic, but a language definitely can reduce the chance of creating a certain set of bugs in the first place.

PopeDotNinja• 7 years ago

I think of languages at work as dislike and don't dislike. Basically if something gets in my way, I don't like it.

I do love Elixir, but for the kind of work I am doing currently, I'd have a hard time selling the benefits of it over just about any other language. But I dislike Java's verbosity, so unless Java brings something other options lack, I feel like pushing back on too much code being a legit reason to avoid Java.

ddingus2• 7 years ago

Interestingly, English is super expressive and allows for many ad hoc type expressions the be understood with reasonable fidelity.

Many other languages are gendered and or structured, both of which do impact the work, both good and bad.

Great English can be written right along with crazy expression borrowed bits here and there, even words made up on the spot.

Do we need crazy expression in programming?

Technically, no. But many want it and practice it in creative ways not unlike writers do with form, structure and style.

With a story, did readers get value, even with poor understanding, or a reread or two making sense seems to be the bar.

With a program, does it do the job and doe it do so in a consistent way, secure, etc..

A look at things like COBOL, FORTRAN shows us design can impact quality. It is baked in.

Skill matters too.

An inexperienced programmer may produce higher quality earlier and more easily given such an environment. Adept ones can use most anything and do the same.

But, they may also be size coding, played ng in the demoscene as much as they are cranking out business logic and computation.

TL;DR; Language absolutely does impact quality, but so can experience and process. No easy outs, no one size fits all.

willtim• 7 years ago

History is littered with purpose built languages and notation for mathematics, logic, music and law etc. A language guides (or limits) one's thoughts, offering a particular set of abstractions. Functional programming is very close to logic and particularly amenable to mathematical reasoning and static analysis - exactly what one needs in order to safely compose large programs from small ones.

reificator• 7 years ago

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.

Then I have a thought experiment. If language cannot determine the quality of your work, I would request that you write pong in brainfuck, and I will write pong in, let's say, javascript. Then we'll compare the quality of each implementation, and switch languages. Whoever wins in terms of quality in the first round would be expected to be the better developer, and so would win the second round handily.

Now that we've established that the quality of your work does in fact depend on the tools used to implement it, can we please reframe your original point in less absolute terms? Perhaps the programming language is not as important as people claim, and that given two projects in two languages of similar quality, the output should also be of similar quality?

How do we define similar quality? Is incremental improvement a worthwhile goal? Do different tasks require different features? I would much rather write a shader in HLSL than in BASIC.

codelani• 7 years ago

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.

This is false, unless I misunderstand you.

I track ~10,000 programming languages. Are you willing to bet that I can pick one of these languages at random, give you a task, and your output won't be affected by the language I pick?

dmitriid• 7 years ago

Mostly, no. Usually it all comes down to understanding and implementing business requirements correctly. Implementing those is a somewhat straightforward (also tedious) process in any language.

The main inpediment in my opinion is:

- knowing the standard library

- knowing the available libraries

- syntax quirks

in that order.

The main advantages you gain from using a language is familiarity with a language and the three points above.

I will be much more productive in JS or Python than in Haskell just because I’m already familiar with thise two and I’m not familiar with Haskell.

The rest of advantages come from the ability of a language to express a programmer’s thoughts rwadably, concisely and in a maintainable manner (where “maintainable” means “a new colleague coming in to the project six months later”).

crimsonalucard2• 7 years ago

I don't buy this idea that the programming language you use determines the quality of your work.

I don't buy into fads either but this is not a fad. It is common sense. The quality of your own skill and the tools you use affect the overall quality of your work. To say that one has no affect is illogical.

Just look at the extremes of your statement. If it was true, I should be able to write a triple A game in assembly language because assembly language affects the quality of my work. Obviously this is not true. If I tried to do one in assembly language the quality would be subpar.

A language cannot prevent someone from making stupid mistakes.

In Elm it is not possible to have runtime errors. The program cannot crash period. The only type of error you can have in elm is a compile error or logic error.

This is an example of a program preventing stupid mistakes.

automathematics3• 7 years ago

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/

phailhaus2• 7 years ago

Yes, it got us ES6! Languages don't exist in a vacuum. They introduce new ideas, dispense with others, and all languages can learn from what works in the field and what doesn't.

If you're working on a personal project, it might be a good idea to try out PureScript and learn from what it has to teach!

automathematics3• 7 years ago

Yay new ECMA standards! Classes/decorators/scope/arrow functions have made my life SO MUCH BETTER the last 5 years

ARandomerDude2• 7 years ago

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.

automathematics3• 7 years ago

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.

bcheung4• 7 years ago

The JS community is adopting more and more concepts but a lot of it has to do with the syntax. If the syntax is too verbose people just won't use it. FP is much easier when working with a language based off the lambda calculus (Haskell, Elm, PureScript, etc). Currying, partial application, and point-free composition is overly verbose in JS. JS has adopted the concepts but they are not used very often because of the messy and noisy syntax.

srean• 7 years ago

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.

_bxg13• 7 years ago

What distinguishes PureScript from Elm?

crimsonalucard2• 7 years ago

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

kadblas• 7 years ago

A resource that covers more of these questions is covered here: https://github.com/JordanMartinez/purescript-jordans-referen... 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...

See these repos for an example of the language in action: - https://github.com/jordanmartinez/purescript-jordans-referen... - https://github.com/jordanmartinez/learn-halogen - https://github.com/thomashoneyman/purescript-halogen-realwor...

mpweiher• 7 years ago

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

Now that I would have been on board with!!

:-)

gridlockd5• 7 years ago

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

http://try.purescript.org/?session=60f1839b-bd82-d9af-75ef-d...

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.

lelf2• 7 years ago

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

gridlockd5• 7 years ago

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" }
      ]

paul7986• 7 years ago

What about HypeScript..anyone using that?

Leace• 7 years ago

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

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

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

huy-nguyen• 7 years ago

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.

kepano• 7 years ago

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/

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

zumu• 7 years ago

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

toastal• 7 years ago

It isn't necessarily though. A lot of people are using 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.

hkai• 7 years ago

Typescript.

Make the Leap from JavaScript to PureScript

Related Stories