littlelogs

Keep a social journal of your work progress as you make and learn things.

rhitakorrr
rhitakorrr

Time for a mega, 3 weeks #laterlog. [1/2]

I just finished a dev session on the #MidnightMurderParty editor, so I’ll start there. When I started learning #PureScript earlier this month, it was all confusion, overwhelming UI library choices, and packages that were lacking. Simultaneously learning this language and developing an application in it has been quite the ride.

But it’s been fun. The learning curve was (and still is) much steeper than #Elm’s, but as I learn this language, I’m coming to appreciate how much freedom its complexity gives me. The massive boilerplate which is rampant in Elm code hardly exists here, from what I’ve seen, because most of it gets abstracted away.

I’ve now gotten most of the old editor screens coded (though not fully #functional, ha-ha) and have added some new features, namely Google login and Drive Filepicker, so I no longer have to download a Docs file, open it in a text editor, copy the HTML, and paste it into the editor. I just pick a file in the editor and go.

larouxn
larouxn

Omg, no more gist content garbage. Yes please.

28 April

josh
josh

And I thought elm had a steep learning curve! PureScript is essentially Haskell for javascript, right? Is it the haskellyness that makes it hard to pick up?

28 April

rhitakorrr
rhitakorrr

@josh - yeah, it’s basically compile-to-JS Haskell plus some changes/improvements. Where Elm is aimed at JS devs and strives to become simpler as it evolves, PureScript remains just about as complex as Haskell. Understanding the language itself wasn’t too bad, since I’m familiar with Haskell and a lot of functional concepts already, but starting a project with it was where it got hairy.

In Elm, there’s generally one right way to do everything. The Elm Architecture (TEA) is basically a framework built right into the language itself. You know how that works, you know how Elm works. There is a core set of go-to packages that just work, plus a repository of user packages with guaranteed safety. But PureScript is a general purpose language, and there are tons of different UI libraries you could use to write your app. You could even make one yourself if you wanted to. There are a couple PureScript libraries that even implement The Elm Architecture, so you can basically write Elm in PureScript. Kind of neat.

28 April

rhitakorrr
rhitakorrr

The other thing is there’s no hand-holding in PS. If you want to FFI with JS, you can write foreign functions that are basically one-to-one translations from JS to PureScript. When you do this, the type system has to trust you, meaning you can introduce impurity into the language. However, if you use this correctly, you avoid the nasty unwieldiness of Elm ports and can make much more natural bindings to the outside world. You can even define your own effect types to indicate within the type system what effects your code is introducing.

Ultimately, PureScript (a) is a much more complicated language than Elm (knowing Haskell helps a lot here), (b) has a ton of options and isn’t at all obvious where you should start (I basically picked a UI library and ran with it), and (c) assumes you know what you’re doing (you really need to understand what’s going on when handling “unsafe” code).

The people in the PS Slack channel are really cool, too, and are always around to answer questions.

28 April

josh
josh

Ah sure, good comparison, thanks! I still find haskell fairly intimidating so I like elm’s “one true way” approach with the architecture. But I can see how graduating to PureScript would give you a lot more to work with.

28 April

rhitakorrr
rhitakorrr

I still find Haskell fairly intimidating! Elm’s “one true way” approach is nice since Elm is designed with the purpose of developing web UIs, and it’s quite good at that. It makes it really easy to start writing your app without getting lost in a sea of options. Unfortunately, in making the language simple, Evan decided that abstractions like typeclasses were unnecessary, so you end up with a lot of boilerplate code and functions that aren’t as reusable as they could/should be. But aside from that, it’s come a long way since we last talked about it (which I think was on one of my first posts here!) and has matured into a very usable language.

28 April