Seeing these types of experiments are always interesting but just like CoffeeScript it requires learning two languages instead of one [so you an debug] which makes it a hard sale. Why not just write clean JavaScript? I know many want to make JavaScript the assembly language of the web but JavaScript is so much more complex than assembly I'm not sure that's necessarily a good goal to have.

Granted I would love for more languages to be usable on the web; even if I thought JavaScript was the best language it's always good to have competition and alternatives. But I think that has to come through browser support. I wonder how feasible it would be to generate some sort of byte code similar to how Java and others work with the JVM.

I wish a fraction of the effort going into "fixing" javascript went into fixing the real abomination: the DOM API (and CSS). Then everyone would benefit, even people using Dart, Coffeescript, and TypeScript.

I wish people would just realize that JavaScript isn't going anywhere and make the effort to understand it instead of trying to gloss over the quirks of it.

Understanding the key parts of writing JS (closures, scope, GC, etc.) isn't all that hard and it seems like more efforts are geared towards an abstraction layer and/or framework than just learning the language in the first place.

I think it's syntax and familiar looking and feeling environment cheerfully misleads people into thinking they are in a comfort zone, while they thrash around throwing sand in their own eyes, albeit with a familiar looking bucket and shovel.

It's rather condescending to assume the only reason somebody might dislike Javascript is because they didn't understand it.

Condescending yes, but more importantly, entirely wrong.

PureScript developer here. Happy to see this here, and happy to answer any questions.

Care for a little comparation with TypeScript ? If i know TS why should i look at PS ?

(Copied from below) I've written quite a lot of TypeScript, and I generally feel very productive in it, but occasionally I feel like I want more from the type system (type classes, rank-N types, sum types, etc.) and tidier syntax. You might be interested in Bodil Stokke's recent Strange Loop talk, where she discusses why she switched from TypeScript. https://www.youtube.com/watch?v=yIlDBPiMb0o

With some languages, a big part of the selling point is that it's the same or similar to a language the programmer already uses. Clojure and ClojureScript come to mind, or even server-side JavaScript. Now, with ClojureScript, another common selling point is the synergy with react -- something that would appeal even to people not using Clojure (maybe because they're averse to the JVM).

So where is PureScript positioned related to this? Let's say I'm writing a backend in Ruby or Python and not Haskell, why PureScript instead of CoffeScript or sweet.js?

(I'm actually interested in this, not intended as a put-down.)

I think it's definitely possible to put knowledge of Haskell to use in PureScript, but it's not like Fay, Haste, GHCJS etc. where you can copy code verbatim. I think of PureScript as "an environment in which to write principled JavaScript". That requires that, to a certain extent, you should have JavaScript's semantics in the back of your mind while developing. For that price, you get ease of debugging and some tools which you don't have in many other compile-to-JS languages (an expressive type system, type classes, ability to refactor with confidence etc.)

Of course, one of the best things about AltJS is the interoperability with other languages. PureScript won't be the best tool for every case, but it has a simple FFI. It's possible to write complete front-ends in PureScript, but I'd love to see more examples where PureScript is used alongside something else (I've used TypeScript with PureScript successfully, for example).

Is there any particular reason why PureScript was designed with a single number type (so no proper ints)? I know that's how JS sees things, but now with a whole proper type system it would seem like we should have proper numbers? I admit I haven't read the entire docs, is there a way to e.g. have the type checker ensure a number field such as a year in a date isn't assigned a non integer?

It has been discussed before: https://github.com/purescript/purescript/issues/396

The reason I have been against the idea so far is that an integer type is easily accomplished using the FFI and user code. Here is one example (not quite what you're asking for, but hopefully instructive): https://github.com/darinmorrison/purescript-int64

As long as it is efficient and compiler supported (I.e an int add ends up as the proper instruction, and improper assignment ends up as a meaningful compiler error) I think the implementation doesn't matter. Going to Natural numbers and such feels like a separate topic from just having efficient and type safe (modulo overflow) integers.

Consider what it would take, writing in C, to store and compute integers in the "double" type, including range checks after every operation. Unless you go the asm.js route or otherwise ensure that your JIT special-cases integers, constructing range-limited integer types out of JavaScript doubles has a non-trivial cost.

Personally, it surprises me that with all the years of extensions to ECMAScript, nobody has added 1) sized integer types like word32, word64, and so on, and 2) transparent bignums, similar to int/long in Python.

I'm not sure I understand the problem, I meant that in PureScript there would be distinct number types, and the PureScript compiler would forbid me to assign an int field with a double value. The generated JS would be all regular JS "numbers" (ie floating point throughout).

I mean there are several compilers from langs with strong type systems, such as F#->JS with FunScript, and in those, usually the source lang has integers...

What happens when you take two "integer" fields and add or multiply them? The compiler would need to check that the result still fits in an integer.

No compiler in existence makes these kinds of checks on anything except maybe literal values in special cases. What you propose would entail evaluating the program's runtime behavior at compile time. Ensuring anything that gets put in an integer field is an integer is easy assuming you have type annotations on everything.

For the cases you mention the checks would simply be: integer * integer = integer, integer + integer = integer. Problems only arise when real/floating point numbers are introduced and how to handle integer division.

>No compiler in existence makes these kinds of checks

If your claim is that no compiler in existence can make these kinds of checks at compile time, that's not true. Any dependently-typed language can do this (Idris, Coq, Agda, ATS). In fact, even a language with refinement types can do this, like Liquid Haskell.

And a number of languages do these checks at runtime: Ada and Nimrod are two that come to mind.

Assuming you mean two 32 bit integers, the result is a new 32bit integer that may have overflown. The compiler doesn't care in any language I know of.

This looks really cool! Do you currently have any abstractions for interacting with DOM elements?

I'm only a bystander, but I believe PureScript doesn't include data-to-DOM binding. If you want to do it manually, I would look at the Eff monad[1].

It sounds like there are adapters to few popular frameworks, like React [2] and Angular [3].

[1] https://leanpub.com/purescript/read#leanpub-auto-the-eff-mon... [2] https://github.com/purescript-contrib/purescript-react [3] https://github.com/purescript-contrib/purescript-angular

I'm guessing a JS-controlled framework, like React or Mithril, would be a better fit if you choose to use PureScript as a core piece of your app, as they are function-based, like PureScript.

Interesting. For my current project, I don't want to include large frameworks so it looks like this library [1] should do the trick.

[1] https://github.com/aktowns/purescript-simple-dom

There are a few options, but the most fully-formed is probably purescript-react. I'm also interested to see where the virtual-dom bindings go. The last chapter of the book covers how you might go about writing a library for working with DOM elements in PureScript.

If you don't write Web stuff, you can ignore JS completely, and PureScript too.

If you prefer dynamically-typed languages, use them directly (JS, CoffeeScript, etc.)

If you prefer statically-typed languages, you must care about a dynamically-typed language, since every statically-typed language can be thought of as a dynamically-typed language + a machine-checkable safety net. For example, Haskell/ML/etc. are built on Lambda Calculus, C/FORTRAN/etc. are built on machine code. If you're programming for the Web, why not use JS as the dynamic part of your language (the "computational content")?

I didn't want my comment to devolve into an argument about the merits of static vs. dynamic. My comment is really to ask why would I use Typescript for web programming? Where does it fit? It doesn't seem to fit in or fill a need that isn't already possible with any combination of static and dynamic languages used separately. In fact I feel it blurs the separation of concerns between static vs. dynamic.

Do you mean PureScript?

It's been picking up a lot of steam lately! Bodil gave a great talk on it at Strange Loop last week: http://www.youtube.com/watch?v=yIlDBPiMb0o

Here's a gem to use PureScript files with Rails and the asset pipeline. It let's you add and compile PureScript files similar to how CoffeeScript files are added. https://github.com/romaimperator/purescript-rails

Saw two great talks about PureScript at Strange Loop last week, one by the language designer, Phil Freeman, and another by Bodil Stokke. Both the language and — almost equally importantly! — the accompanying book seem really well done to me.

Indeed, the book covers a large set of very interesting topics without ceremony.

What's the advantage over something like TypeScript which is a superset of JavaScript but supports types as well?

If you want types like Java, TypeScript's probably a good choice. However, if you want the flexibility or the guarantees a powerful type system gives you, TypeScript's not going to cut it.

I've written quite a lot of TypeScript, and I generally feel very productive in it, but occasionally I feel like I want more from the type system (type classes, rank-N types, sum types, etc.) and tidier syntax. You might be interested in Bodil Stokke's recent Strange Loop talk, where she discusses why she switched from TypeScript. https://www.youtube.com/watch?v=yIlDBPiMb0o

Or Dart for that matter?

The advantage is that types aren't optional. People actually have to respect them.

Typescript vs Elm? Fight!

(I.e. what are the relative strengths and weaknesses of these two "modern languages targeting JS" offerings?)

I think you meant Purescript vs Elm. disclaimer: I have used neither.

Elm has its own package manager, not sure if that is good or bad!

The biggest difference is that Elm is almost incidentally a similar strongly typed functional programming language and its biggest focus has always been on FRP (functional reactive programming) to simplify UI programming in the browser.

Yes, I meant Purescript.

Just bought the book today ($10 is too low!). After a few nixos hiccups today, so far so good :-)

From the project docs: "Generate simple readable Javascript" - isn't this more of a disadvantage than an advantage? the created Javascript code won't be high performance, which matters a lot in mobile today.

"Simple readable JavaScript" as opposed to the sort of output you might expect from compilers for other Haskell-like languages which attempt to preserve Haskell's semantics. Certainly there are cases where using techniques from pure functional programming can lead to poor performance (monadic recursion jumps to mind), but it is perfectly possible to write fast code using PureScript. And if you really need to squeeze out every last bit of performance, you can always write code in JavaScript and use the FFI.

I can vouch for the real world performance. Phil has used Purescript to dramatically improve the performance of our medical image viewer. It's pretty impressive stuff.

What's monadic recursion?

Consider a recursive function like factorial:

  fact :: Number -> Number
  fact 0 = 1
  fact n = n * fact (n - 1)

This will build stack frames and fail with a stack overflow for large inputs. We can fix this by using tail recursion and an accumulator:

  fact :: Number -> Number
  fact = go 1
    where
    go acc 0 = acc
    go acc n = go (acc * n) (n - 1)

The PureScript compiler will recognize that every recursive call is in tail position, and will convert the function to a while loop.

If we want to perform side-effects during the recursion, we typically use a monad to track the type of side effect in use. For example, we can use PureScript's Eff monad to trace information to the console:

  fact :: Number -> Eff (trace :: Trace) Number
  fact = go 1
    where
    go acc 0 = do
      trace "Done!"
      return acc
    go acc n = do
      trace "Keep going ..."
      go (acc * n) (n - 1)

In the case of the Eff monad, the PureScript compiler employs some special tricks in the optimizer to enable the tail call optimization, so we're still OK. But this is only possible because Eff is defined in the standard library (at least until we implement custom rewrite rules).

In the general case, the compiler only sees applications to the monadic bind function of the underlying monad. For example, if we use the Writer monad instead:

  fact :: Number -> Writer String Number
  fact = go 1
    where
    go acc 0 = do
      tell "Done!"
      return acc
    go acc n = do
      tell "Keep going ..."
      go (acc * n) (n - 1)
  

which is equivalent after desugaring to the following code:

  fact :: Number -> Writer String Number
  fact = go 1
    where
    go acc 0 = tell "Done!" >>= \_ -> return acc
    go acc n = tell "Keep going ..." >>= \_ -> go (acc * n) (n - 1)

This is an example of "monadic recursion" - a recursive function whose return type uses some monad. In this case, the recursive calls are no longer in tail position, so the compiler cannot apply the tail call optimization. The result is that the compiled JavaScript might blow the stack for large inputs.

The point is that idiomatic Haskell code is often not appropriate in JavaScript because of the different semantics, so it might not be appropriate in PureScript either. The good news is that many Haskell idioms have corresponding PureScript idioms (often using the Eff monad).

I wanted to play around with this, maybe you do too...

Install purescript:

https://leanpub.com/purescript/read#leanpub-auto-installing-...

The code, put it in a file named recur.purs (or w/e you want):

    -- recur.purs
    module  where
    
    import Control.Monad.Eff
    import Debug.Trace
    
    -- naive factorial function
    fact :: Number -> Number
    fact 0 = 1
    fact n = n * fact (n - 1)
    
    -- factorial function exploiting tail call optimization by putting function in tail position (at the end) 
    fact' :: Number -> Number
    fact' = go 1
      where
        go acc 0 = acc
        go acc n = go (acc * n) (n - 1)
    
    
    -- use Eff monad to trace information to the console
    fact'' :: Number -> Eff ( trace :: Trace) Number
    fact'' = go 1
      where
        go acc 0 = do
          trace $ "The answer is: " ++ show acc
          return acc
        go acc n = do
          trace $ "(" ++ show acc ++ " * " ++ show n ++ ")" ++ "(" ++ show n ++ " - 1)"
          go (acc * n) (n - 1)
    
    main = fact'' 8

Then to compile it:

    psc recur.purs --output dist/Main.js --main Recur

Hope this is as educational (and fun) for others as it was for me.

Thanks! Another trick I've seen used is `naked' avoiding recursion in your code, and relying on combinators implemented in some optimized lower level code. Would that work with PureScript?

Yes - in fact, that's the approach we encourage for working with immutable arrays: https://github.com/purescript/purescript-arrays

Your minification process should be separate from your build process that's required to run it. This can generate JavaScript that's not a huge pain in the ass to debug, then you as the developer can minify it with existing libraries.

Though I'm not necessarily sure it wouldn't be high performance just maybe a hair slower to load. Then again I don't know how well their generator works.

I find JS a thoroughly unpleasant language to work with. When will we reach the point where JS could be abstracted away entirely? (Just like how I never need to interact with assembly language any more.)

There are several paths:

1. JS as an assembly language. This is what emscripten[0], a LLVM bytecode-to-JS does, by following the asm.js specification[1]. This is for CPU-intensive tasks, not DOM manipulation. You can use any language that has a LLVM frontend.

2. JS as a target language, from a specific, new language. Those include cleaner variants that keep the same semantics (CoffeeScript, TypeScript, maybe Dart, ...) or more innovative ones, such as Elm[2], which is written in Haskell too. I'd say that a big innovation that makes the life easier is FRP (which is at the heart of Elm or React.js).

I fail yet to see what advantages PureScript brings compared to Elm.

0: https://github.com/kripken/emscripten 1: http://asmjs.org 2: http://elm-lang.org/

> I fail yet to see what advantages PureScript brings compared to Elm.

I think they fit different use cases. Elm is excellent at interactive web apps using FRP. PureScript is a little more general purpose and has a few type system features which Elm currently does not (type classes and rank N polymorphism). Also, PureScript's generated code is a bit simpler and doesn't need a runtime library.

Dart

In what ways does CoffeeScript not suit you perfectly?

Not speaking for the parent, CoffeeScript is even worse than Javascript. The killer for me is indentation forming scope. If you accidentally indent your code incorrectly, like when you're copy/pasting from one file to another, you can change the scope of all of the variables within.

The other major problem I have with it is that it encourages us to go back to the class-based patterns that we've been trying to get away from.

Please. Coffee has its problems, but being white-space sensitive is not one of them. It's entirely a matter of personal preference, just like preferring {...} instead of begin...end or using '' instead of "" for strings; it's not even as significant as prefix vs. infix syntax, which does have some practical consequences. You get indentation based blocks in quite a lot of languages, Haskell, F#, Python, Nimrod, MoonScript and others and it works there, I see no reason (knowing them all) for it to be a problem in Coffee particular case (to be honest, Coffee allowing inconsistent indentation in a single file is a bad design decision, though).

You aren't likely to see this again, but in case it helps, the following setting in Sublime Text's key bindings may help you:

``` { "keys": ["super+v"], "command": "paste_and_indent" }, { "keys": ["super+shift+v"], "command": "paste" }, ```

Though you should always be careful when copy/pasting code.

I'm not sure how it encourages classes, I personally didn't even use classes at all for the first long period of my CoffeeScript life. And now only do sparingly.

typescript

For those of you who want to see some code:

https://leanpub.com/purescript/read

I'm new to this but can someone enlighten me about what is the advantage of using this over pure JS?

Type correctness can help eliminate an entire class of bugs (type mismatch bugs) found in dynamically typed languages, or various gotchas with implicit typecasting.

This is where I find programmers who are comfortable with static languages struggle with dynamic languages. There is a lack of understanding and this is yet another language trying to fix something that isn't fundamentally broken.

I think it really depends what you're trying to do. There's definitely a class of problems where the impact of a runtime type error would be low. But there are plenty of other cases where you want to constrain what you or your users can do at compile time.

Thank you. I know Python, JS, and PHP so type correctness is kinda foreign to me.

One thing I couldn't see anywhere - is PureScript strict rather than lazy?

It uses JavaScript's evaluation model - i.e. strict, but you can write lazy code using libraries, such as purescript-lazy.

Interesting, thanks - I've been interested in a language like the Haskell.Next that SPJ described: strict evaluation but with effects controlled by monads. I'll give it a look!

Javascript being clean is your own (possibly misinformed) opinion.

I agree that's a matter of opinions but I think that the OP has a point. JavaScript is easy to understand for everybody coming from C, Java or PHP even if its core is very different from those two languages. Haskell might be cleaner but it's difficult to get for people that used only procedural languages, which are most of the programmers working today (especially if the expected domain for PureScript is web programming, frontend or backend).

There is a functional language called Elixir which runs on the Erlang virtual machine. Elixir has been designed to look like Ruby even if it's very different. That makes Ruby programmers (and maybe Python ones too) feel at ease in their first approaches with the language. When you realize how different the two languages really are you already grokked enough of Elixir to keep you going. There isn't that feeling of "oh my, I can't make it" one might have when looking at code like this http://svn.openfoundry.org/pugs/src/Pugs/Eval.hs when knowing only about C/Java/PHP/Python/Ruby

Anybody knowing Ruby or possibly Python should compare that with this https://github.com/elixir-lang/plug/blob/master/lib/plug/con...

So, my take is that if a language designer wants to create a functional language that will lure really many procedural programmers into it, s/he has to design something that looks like C or Java. PureScript is too much like Haskell (plus I hate indentation-sensitiveness, but that's almost only a subjective matter). Time will tell.

Easy to understand != clean

Javascript has enough implicit behavior and then some to make working with it a nightmare unless you remain extremely diligent with your coding practices. To a large extent, it's been around long enough for this to not be a major problem anymore, but is this an acceptable state of affairs for a language that dominates web programming? I'd expect most people to say "no".

I'd say the target audience for PureScript is probably not "everybody coming from C, Java or PHP", but people who appreciate stronger type systems, and possibly people with a Haskell background.

There are already several JavaScript flavors for the audience you mentioned.

JavaScript has some things in it that shouldn't be used but that's true with almost any language out there. There is no reason you can't write clean, easy to read and understand, code in JavaScript. I'm not sure why you're saying he may be misinformed; you can write really great code in JavaScript.

Markdown code and JavaScript code are both clean. Now people know how to "kill" JavaScript, but it may become the new assembly language.

Get a better employer. I can understand thinking that e.g. existing options are not mature enough, but "never" is a stupid policy.

Quoting myself

> unless a customer asks to do so.

which I agree with.

Since 1986 I already have seen too much technology come and go, to be convinced to use "language of the month" at work.