PureScript 0.13 Release(github.com)
github.com
PureScript 0.13 Release
https://github.com/purescript/purescript/releases/tag/v0.13.0
38 comments
Coffeescript did not offer anything but different syntax. It hasn't improved the semantics of the language. Some people liked it and some didn't.
Elm, PureScript, and Clojurescript are fundamentally different languages. Javascript today has bloated, and it keeps growing. Experienced developers tend to dislike it. Newbie developers struggle with it. It is no longer "a small language with a low entry barrier". ECMAScript specification is already bigger than Java's.
PLs of today and the next couple of decades will be striving for optimizing for programmer's productivity, performance, or correctness of the program. Javascript today does not fit in any of these categories. So it is only natural - the trend of using alt-js langs will only grow.
Elm, PureScript, and Clojurescript are fundamentally different languages. Javascript today has bloated, and it keeps growing. Experienced developers tend to dislike it. Newbie developers struggle with it. It is no longer "a small language with a low entry barrier". ECMAScript specification is already bigger than Java's.
PLs of today and the next couple of decades will be striving for optimizing for programmer's productivity, performance, or correctness of the program. Javascript today does not fit in any of these categories. So it is only natural - the trend of using alt-js langs will only grow.
Typescript is essentially just javascript with types. The compiler just checks and then takes the types out. So with typescript, if you need to migrate away, you just take your compiler output, and ditch your .ts files. The output is generally just as readable as the input.
I noticed a few languages removing support for octal and binary literals. I wonder why. I find them useful and the parser overhead seems minimal to keep them around.
We found no usages of it in the wild. If there is real-world need for them, we'll consider adding them back.
FWIW I use binary literals a bunch in python, either when working with binary file formats or with bitfields.
Yes, I'm not saying there aren't usages for them in general, but PureScript currently occupies a niche that doesn't get down to the level of binary file formats. This change is more about "only supporting what we need to right now", rather than "we don't like binary literals". As noted elsewhere, it's not difficult to add support for them when we need to.
Generally developers tend to either (1) misunderstand them when they encounter them in the wild or (2) accidentally invoke them. (I believe multiple languages have had issues with '04' being treated as an octal, which works fine and doesn't trigger developer notice until they encounter '09' in the wild).
Whether these are VALID concerns I won't take a stance on - just saying these are the reasons I've seen cited.
Whether these are VALID concerns I won't take a stance on - just saying these are the reasons I've seen cited.
Why not use 0x,0b, and 0o for hex, binary, and octal literals? I never liked the fact that a number starting with 0 was treated as octal.
OCaml does just that; it might have been the first language to have 0b and 0o prefixes for binary and octal literals.
https://discuss.ocaml.org/t/the-origin-of-the-0b-01-notation...
https://discuss.ocaml.org/t/the-origin-of-the-0b-01-notation...
Yeah, it never made sense to me not to include those, given how simple it is.
The typical octal literal syntax I've seen uses a 0 prefix. This gives rise to quite a few gotchas, as most people think of leading 0's as being non-value-changing. Maybe 0o12345670?
Yeah, I agree that it's not a good syntax. I do think 0o is a good prefix though.
What happened to the original author of PS?
https://github.com/purescript/purescript/graphs/contributors
https://github.com/purescript/purescript/graphs/contributors
I don't speak for Phil, but I do work with him at Lumi where we use PureScript for almost all frontend. It's been really fun to show that PureScript can be used successfully in production.
You can see some of our tutorials and open source projects here: https://www.lumi.dev
You can see some of our tutorials and open source projects here: https://www.lumi.dev
Life! :)
He still uses PS and chimes in on some issues, but doesn't really have time to work on the compiler anymore: https://twitter.com/paf31/status/941745900426215424
He still uses PS and chimes in on some issues, but doesn't really have time to work on the compiler anymore: https://twitter.com/paf31/status/941745900426215424
Like many of us, he had children and couldn't keep up with the workload, so he took a step back. Fortunately there is a very active community working on PureScript!
Are there other languages that make an opinion on tabs/spaces? This seems nice.
> The only whitespace now allowed in code is ASCII space and line endings. Since you must use indentation to format PureScript code (unlike Haskell), we felt it was best to be more restrictive in what you can write instead of allowing potentially confusing behavior (implicit tab-width, zero-width spaces, etc). You can still use unicode whitespace within string literals.
I’m also wondering about the removed literals.
> The only whitespace now allowed in code is ASCII space and line endings. Since you must use indentation to format PureScript code (unlike Haskell), we felt it was best to be more restrictive in what you can write instead of allowing potentially confusing behavior (implicit tab-width, zero-width spaces, etc). You can still use unicode whitespace within string literals.
I’m also wondering about the removed literals.
F# doesn't allow tabs unless you use a compiler directive
Zig doesn't allow tabs in source code—which is a bit odd, since they don't have significant whitespace.
I think Elm have similar rules, the official code format tool is very opinionated.
I can attest to that, elm-format is an excellent tool and it is great to have a standard code formatter, one less thing to worry or argue over when writing code!
If PureScript is Haskell, TypeScript is ML
Lately, TypeScript has become more scalable across existing npm libraries and also introduced new advanced types. It looks like Microsoft guys learned a lot from C# and F# type system and feedback from their users
https://www.typescriptlang.org/docs/handbook/advanced-types....
Lately, TypeScript has become more scalable across existing npm libraries and also introduced new advanced types. It looks like Microsoft guys learned a lot from C# and F# type system and feedback from their users
https://www.typescriptlang.org/docs/handbook/advanced-types....
This comparison is flawed, imo.
Typescript is Javascript with a relatively advanced type system (mapped types, type guards, etc) on top, but is still very much constrained by Javascript fundamentals and syntax.
The type system evolution was primarily driven by the need to create valid typings for the existing JS ecosystem, and this noticeably shapes the capabilities.
This is the right choice for the language, but I can't see how it resembles the ML family much.
Typescript is Javascript with a relatively advanced type system (mapped types, type guards, etc) on top, but is still very much constrained by Javascript fundamentals and syntax.
The type system evolution was primarily driven by the need to create valid typings for the existing JS ecosystem, and this noticeably shapes the capabilities.
This is the right choice for the language, but I can't see how it resembles the ML family much.
I think that's a decent analogy, to an extent. Of course there's always Reason, which is actually ML.
https://reasonml.github.io
https://reasonml.github.io
Once you get a taste for higher kinded types (aka: type constructors), there is no going back! PureScript is fantastic language with an active an open community. Best place to start (IMHO) is https://github.com/lumihq/purescript-react-basic You can pretty quickly get a react app up and running
Don't get me wrong. I love PureScript and HKT but the fact that it requires complete buyout to Purescript ecosystem overwhelms my team members and becomes a hard sell. To build a PS layer on top existing JS libraries isn't straight forward. Now that they introduced so many breaking changes, it will take time for other PS libraries to catch up. May be I might go back to PS when 1.0 release happens and I hope many things are stable including libraries which I need in day to day full stack development.
Typescript in the last couple of years introduced a nice way to compose types and ways to get rid of many other common JS gotchas. They have type definitions for almost all the usable npm libraries, which helps you jump-start the development.
Typescript in the last couple of years introduced a nice way to compose types and ways to get rid of many other common JS gotchas. They have type definitions for almost all the usable npm libraries, which helps you jump-start the development.
It really didn't take long for libraries to catch up, we already released a Package Set compatible with 0.13, two days after the release. That's a set of the most used ~200 libraries in the ecosystem.
https://github.com/purescript/package-sets/releases/tag/psc-...
https://github.com/purescript/package-sets/releases/tag/psc-...
Yeah I agree with @ff_57 here - the "breaking changes" really aren't a big deal, and don't effect many libraries. With the existing tool chain you will know immediately if a library has any of these incompatibilities, and if it does, the fix is likely some white space issue, which is trivial to fix.
I had the impression:
ClojureScript == Lisp
PureScript == Haskell
Reason == ML
TypeScript == C#
ClojureScript == Lisp
PureScript == Haskell
Reason == ML
TypeScript == C#
Yes. I agree. It was started like this.
But now Typescript 3.5 is also influenced by F# which is close to ML.
Just look at those advance types and their allowed composition which Typescript supports in its latest release and you will understand.
But now Typescript 3.5 is also influenced by F# which is close to ML.
Just look at those advance types and their allowed composition which Typescript supports in its latest release and you will understand.
Yes, feels kinda overloaded to me...
> If PureScript is Haskell, TypeScript is ML
If you want ML, why not OCaml with js_of_ocaml or BuckleScript?
If you want ML, why not OCaml with js_of_ocaml or BuckleScript?
Anders Hejlsberg, who created C#, has been heading up the Typescript team at Microsoft.
Syntax question, after looking at a couple of examples: Long wished more languages had a ‘where’ clause (suspect it could be really nice to have in Python), but why the ‘where’ at the end of the initial ‘module’ line? I guess it’s doing something consistent, but it does look a bit odd
It's something that comes from Haskell. The `where` keyword always starts a new layout/indentation context. It's not strictly necessary and there are ways around it, so it's just a point of consistency.
i'd tread very carefully and wisely before choosing any one of these paths.
it only makes sense imo if you come from Haskell, Clojure, or some other ML background to have an explicit interest in these languages.