Svelte hype & Purescript perspective

Chat
#1

Lately I’ve been experimenting with svelte as an alternative to react, I’ve seen some presentations and it seems to me that these low-entry programming languages are much more suitable for real-world projects because they don’t force you to think ahead.

Svelte is particularly interesting cause it’s geared towards performance a lot, the generated code is optimized imperative.

Which made me think… I know Purescript suffers from performance issues, perhaps not so much today, but I definitely saw this issue pop up in the past. I personally don’t know what’s the impact of having deep nested functions when it comes to run performance. I haven’t looked deeply in it, but I guess one of these huge functions would be the main function, right? Cause the operation in the Monad is through piping one result to the next function and so on.

I’m wondering if it wouldn’t be a better approach for Purescript to generate optimized JavaScript code instead of trying to translate the Purescript code 1-to-1. I wouldn’t know how to even begin to make this, but I’m sure some smart people out there can think of ways to do it based on the Purescript AST :slight_smile:

What’s your thought on this? I personally would really like to use Purescript in production at some point, but I’m still a super beginner barely understanding the surface.

It’s in real-world application where you have to know advanced concepts that you can’t just skip over which makes the language have a pretty high-entry level. I’m not sure how the bar could be lowered.

Well actually I do have one idea. @thomashoneyman maybe you’d be interested in this :). So one approach I think would be really beneficial is to have a repo with a real world fairly complex example that is built up from scratch, step by step, with tags on Github. I’d say that this would be even better than having a complete explanation of an implemented app cause you can see the app evolve with each step of the implementation.

There are a few advanced topics that someone like me has to spend lots of time understanding like:

  • type equality for using eg. type with type classes
  • how to tackle GADTs which isn’t as trivial as in Haskell
  • functional dependency… basically you have to know how the compiler works here a bit in order to understand how and when to use it
  • existential type for modeling types with private data
  • not to mention some type level programming which would be beneficial if working on frameworks and libraries
  • different run models: ReaderT/MTL/Free Tagless/Free Monads/Extensible Effects

I’d wager that most beginners will have a hard time understanding these topics.

Well I thought I’d stick with Svelte, but I digressed into learning some advanced Purescript topics :slight_smile:

7 Likes
#2

That would be pretty sweet to have, but the maintenance burden could be high if an update requires resolving merge conflicts through many layers of tags.

We have no shortage of opportunities for creating more learning materials. I’m curious what the community thinks will have the greatest benefit per effort ratio (although that discussion might be more appropriate for another thread).

#3

To be honest I don’t even know how you’d update tags (they’re based on specific commits right?).

Well I guess I was thinking of branches really, but chose to write about tags instead :). This approach isn’t anything new, I’ve seen it used quite successfully in other tutorials. You get the repo and have branches like:

  • part-00
  • part-01
  • ...
  • part-xx

With master being the full implementation with instructions or something like that. It’s definitely more work than just having the implementation, but I feel like something of this nature would be really great for people coming to FP concepts as you see them developed step-by-step.

One of these approaches is in Make the Leap from JavaScript to PureScript breaking it down by folders instead of branches/tags. Either way, the technical implementation is kind of besides the point. The main idea is to have an app that covers some ground and being presented setp-by-step as a learning resource.

1 Like
#4

There is no shortage of ways to improve the performance of PureScript without making the generated code an unreadable mess that barely corresponds to the original code. For example, take a look at https://github.com/purescript/purescript/pull/3915. This PR improves both the performance (this PR is a huge win for mtl-style code and probably for typeclass-heavy code in general) and the readability of the generated JS without getting too different from the original PureScript code.

As for why many optimizations are not implemented, I’m not sure about the rationale of the whole team, but here’s how @garyb justifies it.

1 Like
#5

Thanks for the links, good points all around.

1 Like
#6

I think that post of mine is still a reasonably good summary of the state of things. Please excuse the salty tone, I was just very fed up of being repeatedly misrepresented as not caring about performance. :wink:

Unfortunately, the state of optimisation is pretty much the same as it was then too, which is to say, “not really optimised at all”. Nate did start a project but neither of us have had the time or energy to do anything with it still.

I personally don’t really really run into performance issues (aside from some situations where a different data structure would be more appropriate, etc.). I’m still interested in working on this stuff one day™ though.

9 Likes
#7

That sounds very reasonable to me :). I mean it’s expect out of the bowls of the internets to get frustrated with some people. It helps a lot if you can detach yourself, but yeah it’s pretty hard with projects you personally invest in.

This is more like an explorative chat. I wonder if studied people in FP think that you could get optimized imperative code. I mean, I thought Haskell does something like that as I’m aware of. It’s about as fast as C or C++ in some benchmarks I saw some long time ago.

Perhaps one day :tm: I may be able to contribute with more than chat myself :slight_smile:, I’m pretty fascinated by FP as a programming branch

2 Likes
#8

I would love to work on the compiler too! It just seems pretty daunting to get into. But I have that “One Day TM” in my mind too

2 Likes