HN user

fulltrottle

5 karma
Posts0
Comments9
View on HN
No posts found.

Yeah I've used both quite a lot.

Both languages are pretty similar. ReasonML isn't actually a language but more like a new syntax for Ocaml (Bucklescript on the frontend), kind of like what Coffeescript is to JS.

- Both have row polymorphism and higher kinded types. - Purescript has ad hoc polymoprhism, Ocaml doesn't but it's planned in a future release. Purescript achieves it via typeclasses, future Ocaml will achieve it via modular implicits which is more sound from a type system perspective. - Purescript has higher kinded polymorphisn, Ocaml only has a lightweight version of it via it's module system. - Purescript has better support for type-level programming although awkward, but Ocaml has good interop with Coq -it's written by the same people - Purescript is purely functional, Ocaml isn't although it emphasizes a purely functional approach - Purescript places category theory abstractions first like Haskell does as a core aspect of the language. Ocaml doesn't, although it's standard library has all of the same kinds of functions and there are category theory libraries and everything - Ocaml not just -to-JS, it's also a compiled language, and has had real industrial use as a systems language in the finance industry (Jane Street) - Ocaml's compiler is _insanely_ fast compared to any other compiler I've ever used. I absolutely appreciate it - Future Ocaml will be multicore and have a builtin algebraic effects system, basically like Haskell's extensible effects but without the performance hit or having to muck about with monads - Ocaml has GADTs, polymorphic variants, and a way to extend the language via PPX. Polymorphic variants are awesome - Ocaml's module system is really powerful and amazing

Overall both languages are great, but for almost every use case I'd go with Bucklescript/Ocaml any day. It's type system is pretty simple and easy to learn. Purescript has the same issue as Haskell which is the learning curve: higher kinded polymorphism, typeclasses, enforced purity via "the IO monad", and category theory concepts all add up and take quite a while for people to get used to. And the compiler is really fast. And you can write low level imperative code if you need to for performance. And the type system is really expressive, moreso in my opinion than Purescript's because of the poly variants. And you get like 90% of the benefit of using a language like Haskell and Purescript because of the `option` type and enforced safety via exhaustive pattern matching

I can't wait until Ocaml gets modular implicits and algebraic effects into the core language.

It's weird that that's a thing, considering how there are SO many startups both in Silicon Valley and Shenzen. You would think these companies would poach talent by providing perks like "4 day work week" or "unlimited vacation". The author of the article might have a point. Silicon Valley is starting to figure this out to some extent but China isn't yet

Still I would think that since there's so many companies that these jobs would be extremely cushy. I guess the actual problem is that the label market is so much more saturated than the number of startups that they don't even have to poach talent at all

The idea with CSS was that we would be able to separate content from presentation

I've been a frontend dev close to 5 years now, and recently I read the entire CSS spec front-to-back in scrutinizing detail for a project.

If the goal was really to decouple presentation and content then CSS has failed spectacularly. Having element selectors, attribute selectors, child and sibling selectors, very tightly couples the content with the layout. It also has the ability to affect content by inserting text nodes for example using the 'content' rule.

I'd say one big gotcha that trips up most people is not understanding when a style is valid or not. Certain styles are only valid for certain display types (see the CSS spec). Also look at the non-normative references on W3C for the default style sheet to see what default rules get applied to elements

To really fully keep content and presentation decoupled you have to stay away from those things and use something like css modules or similarly have a one-class-per-component rule.

Sadly, the best argument against UBI is that vast, vast majority of people will not be working full time on F/OSS or quite possible anything else.

There's a reasonable argument to be made that those people that'll end up doing nothing are already doing nothing. They're either unemployed, mooching of someone, or working some completely useless unproductive job that needs a slot to fill, that could easily be replaced by a machine.

As for actually productive people, I think very few of them would actually be happy with sitting around watching TV all day.

+1 on this also. I'm not sure how this would play out. The prices might just normalize for the middle class, as if they ended up getting no UBI at all. But if rent and food prices go up across the board then it'll be as if it has no effect at all.

The upside is that the UBI will still support people that end up with financial shocks -- something unexpected happening in their lives. That little bit could help a lot