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.
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.
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?
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 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!
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
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.
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.
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.
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 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
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!
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.
what is scary about all these TypeScript, PureScript, Elm, etc, is that for variety of reasons, any one of these can just come and go. coffeescript anyone?
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.
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.
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.
