I have just been requested to commute three days a week 135 miles away each way from my home (I have not moved) to an office I was never required to attend before the pandemic starting end of September.
If anyone needs remote product/infrastructure/platform engineering or backend developer who has 15 years cloud deployment experience and data center to cloud migration experience, email me on spotter@referentiallabs.com.
A great example of how cool PureScript backend optimizer is - The PureScript code makes multiple map and filter calls and also calls into two functions with complicated logic. The generated output shows that the PS code was aggressively inlined into a tiny bit of JS code -
This is why I've considered #PureScript as a decent alternative to #Haskell, but it's overly centered on the web and Node.js (it has a Go/C++ backend, but it's never a first-class citizen), and the lack of momentum due to the size of the community makes me scared to bet on it. 😇
Rant: I personally find #OCaml to be in a weird space where you don't have as great a type system as Haskell's, and don't even get safety from arbitrary mutation. Atleast #Rust gives me things that #Haskell doesn't.
A strict Haskell, with some warts removed would go a long way towards fixing Haskell's image problems. #PureScriptis that Haskell, but it gets dismissed as something solely for the web. A mature native backend for PureScript would be amazing as well.
For anyone wondering how to use ts-bridge to create more type-safe contracts for calling #TypeScriptfrom#PureScript (and not the other way around as described in the docs), the developer put up a blog post on that:
Alright, day 4 of #adventofcode in #purescript done. It was actually easier than day 3; day 3 input was harder to parse since the positions of tokens mattered.
I don't know about other stuff but AoC is really cool for learning languages from scratch. I've used PureScript about 5 years go so I'm not a complete beginner but I can still feel my proficiency increase with each day.
One thing that's unfortunate about PureScript is that it's really amenable to golfing and I'm too weak to resist.
I'm a software developer working in the #video streaming space. Specifically, I've been working on Media over QUIC (MoQ), #WebRTC, and other "ultra low latency" technologies. I write #PureScript, #Erlang, and #Rust at work these days.
I'm still living the #RemoteLife and now work for a distributed London-based company from the woods of #Michigan.
In my free time I enjoy #hiking and playing games with my family, and playing with radio waves.
Basically, I understand the concepts of functional programming quite well and can also programme #purescript or #haskell relatively confidently. But when it comes to #typelevel programming, I haven't quite got over this threshold yet. I would really like to understand everything better and learn more in this area, because many cool libraries are based on it.
#PureScript is almost the perfect #Haskell replacement. Not only for the things it brings to the table, but also for the things it does not.
I mean actual features missing from PureScript and not gotchas like no historical baggage!
Some examples below. All of them are good for simplicity and newbie friendliness!
No laziness.
Laziness makes it harder to reason about performance. There are easy workarounds for most common usecases for laziness, and employing clever laziness tricks is usually not worth the cost of complicating the codebase.
PureScript's TCO only works in special cases. Normally you wouldn't even need to deal with this because existing implementations of functions like map, foldr etc. are already tail recursion safe. For the rare cases when you need to manually recurse, you can use tailRec and tailRecM to ensure stack safety.
No special syntax or support for linked lists. Strings are not simply lists of chars.
This could potentially be put in the "no historical baggage" category. But I feel that a lot of people, especially newbies, view the special treatment of lists and strings as a plus for Haskell.
However, the focus on lists causes massive confusion for newbies when they are encouraged to use types like Vector and Text in production instead. The special inbuilt syntax also is an active impediment for learning (for example, how do you refer to the higher kinded List type when deriving an instance? It's a mental leap to get to [] in instance Foo [] where).
No special syntax for Tuples.
Much of what was said for lists also applies to tuples. The special syntax is confusing to newbies and causes code complications. For example, each length of tuple is a separate type, and typeclasses in Haskell need to derive instances for each separately. They usually derive instances for tuples only up to length 7.
In addition, it's rarely needed. I am yet to find a usecase for tuples where PureScript's wonderful support for records doesn't suffice. I thought one such usecase was case matching on multiple values (case (v1, v2) of ...), but PureScript supports multi case match for this exact usecase and avoids unnecessary boxing (In PureScript you would write case v1, v2 of ...).
A weird thing about being 50 is that there are programming languages that I've used regularly for longer than some of the software developers I work with have been alive. I first wrote BASIC code in the 1980s. The first time I wrote an expression evaluator--a fairly standard programming puzzle or homework--was in 1990. I wrote it in Pascal for an undergraduate homework assignment. I first wrote perl in the early 1990s, when it was still perl 4.036 (5.38.2 now). I first wrote java in 1995-ish, when it was still java 1.0 (1.21 now). I first wrote scala, which I still use for most things today, in 2013-ish, when it was still scala 2.8 (3.4.0 now). At various times I've been "fluent" in 8086 assembly, BASIC, C, Pascal, perl, python, java, scala; and passable in LISP/Scheme, Prolog, old school Mathematica, (early days) Objective C, matlab/octave, and R. I've written a few lines of Fortran and more than a few lines of COBOL that I ran in a production system once. I could probably write a bit of Haskell if pressed but for some reason I really dislike its syntax so I've never been enthusiastic about learning it well. I've experimented with Clean, Flix, Curry, Unison, Factor, and Joy and learned bits and pieces of each of those. I'm trying to decide whether I should try learning Idris, Agda, and/or Lean. I'm pretty sure I'm forgetting a few languages. Bit of 6502 assembly long ago. Bit of Unix/Linux shell scripting languages (old enough to have lived and breathed tcsh before switching to bash; I use fish now mostly).
When I say passable: in graduate school I wrote a Prolog interpreter in java (including parsing source code or REPL input), within which I could run the classic examples like append or (very simple) symbolic differentiation/integration. As an undergraduate I wrote a Mathematica program to solve the word recognition problem for context-free formal languages. But I'd need some study time to be able to write these languages again.
I don't know what the hell prompted me to reminisce about programming languages. I hope it doesn't come off as a humblebrag but rather like old guy spinning yarns. I think I've been through so many because I'm never quite happy with any one of them and because I've had a varied career that started when I was pretty young.
I guess I'm also half hoping to find people on here who have similar interests so I'm going to riddle this post with hashtags:
@abucci I didn't write an interpreter until college, but I also started with BASIC in the 80s.
Currently writing #haskell for work and #purescript (and Haskell) when I'm not on the clock. Previously did everything from PHP or PowerBuilder to C and C++ to Java and Scala or C#.
Really want a practical language based on Graded Modal Dependent Type Theory so putting some of my spare cycles into playing with that. Interested in having safe+easy lexical capture AND GC-free execution regions.
Best tip I have is to pay more attention to the 'forall's. Compose / . / <<< "fixes" the 'forall', which can cause type checking to fail elsewhere or, if "a" is higher-rank, there (it forces "b" to be monomorphic; higher-rank "a" might require a polymorphic "b'). Application / '$' (in GHC) doesn't "fix" the forall.
I think the difference might be "deeper", but for me it's able where the "choice" for the forall is made.
I think next time I might not start in the middle of a large project. Needs to be more like Joy of Painting and start with a blank "canvas". Probably just grab a problem from the cyber-dojo and plug at it.
Let me know if the music is too loud or the font to unreadable.
Note to self: type variables in #purescript and #haskell cannot be bound to partially applied type synonyms.
If you try to do so, in a sufficiently polymorphic way, you'll get very confusing type errors as the checker attempts to solve things with the variable bound to the "head" of the (parametrically expanded) type alias.
Last night it was (forall r. (forall f. Foldable1 f => f a -> r) -> r) and tonight it was (a -> Term a). Introducing a newtype can help, but beware impredicativity.