4 ms·

Immutability, functional programming, and types. We're already using immutable values in Javascript thanks to React. This takes the form of manually cloning ob

by jasim 9y ago

Immutability, functional programming, and types. We're already using immutable values in Javascript thanks to React. This takes the form of manually cloning objects before mutating them, or using immutable-helpers, or immutable.js. This lets us reason about the data flow easily, and more importantly, allows React's shouldComponentUpdate do dirty check using fast reference equality. Functional programming - in FP languages, all functions are curried by default. So you don't need the awkward `bind` function to use it. Add extremely light weight function definition syntax and tail-call optimizations, and we have a language with first-class functions. Types - The adoption of Flow and TypeScript has brought to light a pent up need for some structure and sanity when writing large codebases. ReasonML is OCaml, and it has a very powerful and sound type system. Since Immutability, functional programming, and Hindley-Milner type systems are becoming ever more necessary to build complex front-ends, it makes a lot of sense to simply use a language that was designed for it. OCaml in its current form has been around for more than 20 years, and the research and other languages that influenced, is even older. It is a fun beautiful language that lets you focus on the shape and structure of your data front and center.

Touche 9y ago
> Types - The adoption of Flow and TypeScript has brought to light a pent up need for some structure and sanity when writing large codebases. Just noting that types have been around in programming longer than 2012 (when TypeScript first came out).
- rco8786 9y ago
  Didn't get the impression OP meant otherwise. Read it more like "large javascript codebases" where types weren't possible before.
  - Touche 9y ago
    Yeah, it's just funny how the JavaScript community is all jumping on the types bandwagon right now and acting like it's some new discovery or something.
    - ricardobeat 9y ago
      Why do you sound aggrieved about it? Types _are_ new for javascript. Until a few years ago there was no way to build for the web using a typed language unless you were using things like GWT or Haxe.
      - Touche 9y ago
        So, there were type languages that compiled to JavaScript.
    - chatmasta 9y ago
      I don't understand this type of negativity. It's possible for someone to be an expert in both JavaScript and OCaml. Or any language. The JavaScript language is both approachable and in wide use, attracting not only novices, but experts from many domains. It seems silly to assume the "JavaScript community" is no more than its lowest common denominator of novice programmers, jumping on bandwagons without any historical context. People are jumping on bandwagons, sure. But every bandwagon needs a driver, who by necessity must be an expert in multiple domains. The people pushing these trends are not naive to their historical context. They simply see practical benefits worthy of experimentation, and they don't let emotional attachments to their knowledge cloud their judgment.
    - chenglou 9y ago
      I work on Reason, so I think I'm relatively unbiased enough to address this. JavaScript's widely popular, disregarding why it's come to be this way. Any language this popular (and with a history of being used in a different context, nonetheless) ends up having warts and being used by folks who are sometimes less skilled. In that regard, "jumping on the types bandwagon like it's some new discovery" is exactly right, because it's indeed lots of people's first language. But I don't see why this should sound so negative. Newcomers are now introduced to types and they're amazed by them. That's welcomed and we shouldn't feel they're taking away our own shiny toy and tainting them or whatever. I think it pays to be nice to beginners. Sure, you don't get the usual quality you're looking for in a niche expert language where communications are atomic, on-point, and lossless, but that's _OK_. All in all, things like a better type system, better language semantics and better paradigms are still worth fighting for.
dsiegel2275 9y ago
Great response. I'd only add a mention of algebraic data types. I learned enough Elm and Haskell to realize the benefit that they bring to a codebase by allowing an expressive way to define the valid structure of an application's data and state.
- idibidiart 9y ago
  I was told that concurrency primitives can be built on top of algebraic data types, so I intend to learn more. I was also told that ReasonML does not yet support algebraic data types. What am I missing?
  - chenglou 9y ago
    I think you meant "algebraic effect", which most mainstream languages don't have: http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multicore/ http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multico... Algebraic data types are a basic feature.
    - idibidiart 9y ago
      Oh yes. Thank you for the correction. The fancy name has kept me away so far... fearing it's yet another monad thing which I have not seen explained in a way that not only makes sense to a 5 year old but far more importantly show clearly and indelibly why it's so important to begin with. Same for any 'math theory' derived concepts. I hope ReasonML won't fall in that 'too smart for the average guy' category. the question I had asked that brought up 'algebraic effects' was: does ReasonML have optimized generator implementation which is an essential high level concurrency primitive. I was told generators and other concurrency primitives can be built on top of algebraic effects.
      - chenglou 9y ago
        Algebraic effects are kinda related to monad. Btw the ReasonML you're talking about is still just a syntax transform; you're really asking whether OCaml/BuckleScript has these implementations. There's no generators; but I do believe they can be built on top of algebraic effects. Regarding jargons: you don't have to worry about that =). Though I think what's more crucial is the way the jargons are conveyed, rather than the meanings themselves. I work in the ReactJS community, and there's basically as many jargons (some of which I myself don't quite understand...) as in FP, yet people seem fine with them. We're still not gonna go "monad this monad that" like you feared. Though if the JS community starts picking up terms like monads in the future thanks to Reason, then all the better.

by jasim 9y ago

Touche 9y ago

> Types - The adoption of Flow and TypeScript has brought to light a pent up need for some structure and sanity when writing large codebases. Just noting that types have been around in programming longer than 2012 (when TypeScript first came out).

rco8786 9y ago
Didn't get the impression OP meant otherwise. Read it more like "large javascript codebases" where types weren't possible before.
- Touche 9y ago
  Yeah, it's just funny how the JavaScript community is all jumping on the types bandwagon right now and acting like it's some new discovery or something.
  - ricardobeat 9y ago
    Why do you sound aggrieved about it? Types _are_ new for javascript. Until a few years ago there was no way to build for the web using a typed language unless you were using things like GWT or Haxe.
    - Touche 9y ago
      So, there were type languages that compiled to JavaScript.
  - chatmasta 9y ago
    I don't understand this type of negativity. It's possible for someone to be an expert in both JavaScript and OCaml. Or any language. The JavaScript language is both approachable and in wide use, attracting not only novices, but experts from many domains. It seems silly to assume the "JavaScript community" is no more than its lowest common denominator of novice programmers, jumping on bandwagons without any historical context. People are jumping on bandwagons, sure. But every bandwagon needs a driver, who by necessity must be an expert in multiple domains. The people pushing these trends are not naive to their historical context. They simply see practical benefits worthy of experimentation, and they don't let emotional attachments to their knowledge cloud their judgment.
  - chenglou 9y ago
    I work on Reason, so I think I'm relatively unbiased enough to address this. JavaScript's widely popular, disregarding why it's come to be this way. Any language this popular (and with a history of being used in a different context, nonetheless) ends up having warts and being used by folks who are sometimes less skilled. In that regard, "jumping on the types bandwagon like it's some new discovery" is exactly right, because it's indeed lots of people's first language. But I don't see why this should sound so negative. Newcomers are now introduced to types and they're amazed by them. That's welcomed and we shouldn't feel they're taking away our own shiny toy and tainting them or whatever. I think it pays to be nice to beginners. Sure, you don't get the usual quality you're looking for in a niche expert language where communications are atomic, on-point, and lossless, but that's _OK_. All in all, things like a better type system, better language semantics and better paradigms are still worth fighting for.

dsiegel2275 9y ago

Great response. I'd only add a mention of algebraic data types. I learned enough Elm and Haskell to realize the benefit that they bring to a codebase by allowing an expressive way to define the valid structure of an application's data and state.

idibidiart 9y ago
I was told that concurrency primitives can be built on top of algebraic data types, so I intend to learn more. I was also told that ReasonML does not yet support algebraic data types. What am I missing?
- chenglou 9y ago
  I think you meant "algebraic effect", which most mainstream languages don't have: http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multicore/ http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multico... Algebraic data types are a basic feature.
  - idibidiart 9y ago
    Oh yes. Thank you for the correction. The fancy name has kept me away so far... fearing it's yet another monad thing which I have not seen explained in a way that not only makes sense to a 5 year old but far more importantly show clearly and indelibly why it's so important to begin with. Same for any 'math theory' derived concepts. I hope ReasonML won't fall in that 'too smart for the average guy' category. the question I had asked that brought up 'algebraic effects' was: does ReasonML have optimized generator implementation which is an essential high level concurrency primitive. I was told generators and other concurrency primitives can be built on top of algebraic effects.
    - chenglou 9y ago
      Algebraic effects are kinda related to monad. Btw the ReasonML you're talking about is still just a syntax transform; you're really asking whether OCaml/BuckleScript has these implementations. There's no generators; but I do believe they can be built on top of algebraic effects. Regarding jargons: you don't have to worry about that =). Though I think what's more crucial is the way the jargons are conveyed, rather than the meanings themselves. I work in the ReactJS community, and there's basically as many jargons (some of which I myself don't quite understand...) as in FP, yet people seem fine with them. We're still not gonna go "monad this monad that" like you feared. Though if the JS community starts picking up terms like monads in the future thanks to Reason, then all the better.