4 ms·

Learning OCaml will teach you the languages and concepts of the next 5 to 10 years of mainstream programming languages. E.g., here's a TC39 proposal to add decl

Learning OCaml will teach you the languages and concepts of the next 5 to 10 years of mainstream programming languages. E.g., here's a TC39 proposal to add declarations to conditionals: https://github.com/tc39/proposal-Declarations-in-Conditionals https://github.com/tc39/proposal-Declarations-in-Conditional... It says, in the 'Future Work' section: > This could be extended to allowing multiple names to be initialized (such as through destructuring) with a "normal" conditional to be written after the assignment with a ; (similar to a for). if (let x = 1, y = 2; x || y) { /* ... */ } if (let {x, y} = data; x && y) { /* ... */ } Meanwhile, OCaml from day one: if let x = true in let y = true in x || y then ... if let { x; y } = data in x && y then ...

Zababa 5y ago
Some other examples: immutable records and tuples in JS, records in Java and C#; pattern matching in Java and C#, stage 1 in JS; algebraic data types with sealed classes coming in Java, and used a lot in Rust.
yodsanklai 5y ago
> Learning OCaml will teach you the languages and concepts of the next 5 to 10 years of mainstream programming languages I think this assertion was true 20-25 years ago. Less so now.
- kupopuffs 5y ago
  Agree. Some did it better, but languages have caught up. Even the C you learned in school has evolved
  - yawaramin 5y ago
    Evolution comes at great cost though. Languages have to find ways to add new functionality while preserving backward compatibility. And the cost is great in human terms as well. Python added a walrus operator after so much fighting that Guido van Rossum decided to resign as BDFL. Meanwhile, OCaml doesn't even need an explicit new feature for that, because it's expression-oriented from day one. Not to forget that when languages pile on features over the course of years, they effectively split their users into 'old-style' and 'new-style' codebases, where people need to worry about what features are usable with what versions of the language. It's a huge mess.
    - pjmlp 5y ago
      There is a very relevant detail many people forget when talking about programming languages, they are software products, no different than trying to sell a new version of a word processor or vector design application. For some people Word 1.0 for MS-DOS is all they need, whereas others won't do without the latest set of Office 365 features, same applies to programming languages, as per application architecture, software design tooling and deployment scenarios.
- lpage 5y ago
  On the currently in OCaml and ahead of the time front: * GADTs * Row polymorphism with inference * First-class modules * Let binding operators, e.g., let* for monadic binding On the coming soon to OCaml (hopefully) and way ahead front: * Algebraic effects * Modular implicits
  - okkdev 5y ago
    Can you explain or direct me to resources on what these are/do?
    - lpage 5y ago
      * GADTs: generalized algebraic data types. As the name suggests, GADTs broaden the set of type-level constraints that one can encode using ADTs. A canonical example involves using GADTs to strongly type an AST and evaluator function s.t. attempting to construct or operate on an invalid AST, e.g., one that represents addition between a boolean and an integer, is a compile-time error [1]. Another great tutorial on GADTs is [2]. * Row polymorphism: statically type-checked duck types, for lack of a better description. In dynamic languages like python or javascript, it's common to pass dict or dict-like objects to functions and have them extract the key/value pairs that they need. Row polymorphism lets you have your cake and eat it too by enforcing enough structure to ensure that functions only receive records containing all relevant keys — without requiring that functions take a specific concrete type. * First-class modules: another tool for type-level programming and modularity. I won't say much since it's hard to understand why you want and at times need them until you've organically come across a use-case for them. Once you do, you'll wish that other languages had them. Here's a resource, though: [4]. * Let binding operators: these let you define your semantics for binding values to variables. A common use-case is defining let* as the monadic bind operator for some type: let (let*) x f = bind x f, after which writing monadic functions is way more pleasant syntax-wise. In contrast to the other items on this list, this is pure syntactic sugar but incredibly impactful [5]. * Algebraic effects: the conceptual root of concepts such as generators (yield), async/await, and checked assumptions. Informally, they're (among other things) a way to encapsulate computation and jump around code like a goto statement, but in a more structured and type/memory-safe way [6]. * Modular implicits: these allow (among other things) ad-hoc polymorphism, meaning that the same operator, e.g. (+), can operate on both integers and floats. That's the oft-cited use-case, and it sounds pedestrian, seeing as most mainstream languages with weaker type systems have it. There's more to it than that [7]. Haskell and Scala have type classes and implicits as mechanisms for ad-hoc polymorphism, but modular implicits (if implemented) seem to strike a nice balance between readability, flexibility, and transparency. [1]: https://blog.mads-hartmann.com/ocaml/2015/01/05/gadt-ocaml.html https://blog.mads-hartmann.com/ocaml/2015/01/05/gadt-ocaml.h... [2]: https://sketch.sh/s/yH0MJiujNSiofDWOU85loX/ https://sketch.sh/s/yH0MJiujNSiofDWOU85loX/ [3]: https://stackoverflow.com/questions/48092739/what-are-row-types-are-they-algebraic-data-types https://stackoverflow.com/questions/48092739/what-are-row-ty... [4]: https://dev.realworldocaml.org/first-class-modules.html https://dev.realworldocaml.org/first-class-modules.html [5]: https://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-syntax.html https://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-... [6]: https://overreacted.io/algebraic-effects-for-the-rest-of-us/ https://overreacted.io/algebraic-effects-for-the-rest-of-us/ [7]: https://arxiv.org/pdf/1512.01895.pdf https://arxiv.org/pdf/1512.01895.pdf
jolmg 5y ago
Reminds me of how lambdas got added to mainstream languages like Python, Java, and C++, when various other languages like Lisp, Smalltalk, SML, etc. had had them decades before.
- pjmlp 5y ago
  Yep, LINQ is nothing new for anyone that has used Smalltalk collections for example.
andi999 5y ago
5-10 years ahead? So they introduced multiprocessor support in like 2006? (taking c++ 11 as a reference point). That would have been pretty awesome.
- yawaramin 5y ago
  That sounds about right, given that you can do multiprocessing pretty easily in OCaml by forking. They even provide a convenience function directly in the standard library, Unix.establish_server, that forks a new process to handle requests.
  - andi999 5y ago
    Forks on windows works in ocaml?
    - yawaramin 5y ago
      Nope, but you can use Unix.create_process. Which is admittedly not as convenient, but that's Windows for you.
      - pjmlp 5y ago
        fork() if a POSIX thing, and Windows is not the only non-POSIX OS around. Also fork() doesn't work consistenly across POSIX implementations regarding threads and signals.
        yawaramin 5y ago
        But the OCaml documentation for 'Unix.fork' says that it's not implemented on Windows. It doesn't mention any other OS.
        pjmlp 5y ago
        I don't care about OCaml documentation, my point was about "Which is admittedly not as convenient, but that's Windows for you.", and UNIX versus other platforms in general.

Zababa 5y ago

Some other examples: immutable records and tuples in JS, records in Java and C#; pattern matching in Java and C#, stage 1 in JS; algebraic data types with sealed classes coming in Java, and used a lot in Rust.

yodsanklai 5y ago

> Learning OCaml will teach you the languages and concepts of the next 5 to 10 years of mainstream programming languages I think this assertion was true 20-25 years ago. Less so now.

kupopuffs 5y ago
Agree. Some did it better, but languages have caught up. Even the C you learned in school has evolved
- yawaramin 5y ago
  Evolution comes at great cost though. Languages have to find ways to add new functionality while preserving backward compatibility. And the cost is great in human terms as well. Python added a walrus operator after so much fighting that Guido van Rossum decided to resign as BDFL. Meanwhile, OCaml doesn't even need an explicit new feature for that, because it's expression-oriented from day one. Not to forget that when languages pile on features over the course of years, they effectively split their users into 'old-style' and 'new-style' codebases, where people need to worry about what features are usable with what versions of the language. It's a huge mess.
  - pjmlp 5y ago
    There is a very relevant detail many people forget when talking about programming languages, they are software products, no different than trying to sell a new version of a word processor or vector design application. For some people Word 1.0 for MS-DOS is all they need, whereas others won't do without the latest set of Office 365 features, same applies to programming languages, as per application architecture, software design tooling and deployment scenarios.
lpage 5y ago
On the currently in OCaml and ahead of the time front: * GADTs * Row polymorphism with inference * First-class modules * Let binding operators, e.g., let* for monadic binding On the coming soon to OCaml (hopefully) and way ahead front: * Algebraic effects * Modular implicits
- okkdev 5y ago
  Can you explain or direct me to resources on what these are/do?
  - lpage 5y ago
    * GADTs: generalized algebraic data types. As the name suggests, GADTs broaden the set of type-level constraints that one can encode using ADTs. A canonical example involves using GADTs to strongly type an AST and evaluator function s.t. attempting to construct or operate on an invalid AST, e.g., one that represents addition between a boolean and an integer, is a compile-time error [1]. Another great tutorial on GADTs is [2]. * Row polymorphism: statically type-checked duck types, for lack of a better description. In dynamic languages like python or javascript, it's common to pass dict or dict-like objects to functions and have them extract the key/value pairs that they need. Row polymorphism lets you have your cake and eat it too by enforcing enough structure to ensure that functions only receive records containing all relevant keys — without requiring that functions take a specific concrete type. * First-class modules: another tool for type-level programming and modularity. I won't say much since it's hard to understand why you want and at times need them until you've organically come across a use-case for them. Once you do, you'll wish that other languages had them. Here's a resource, though: [4]. * Let binding operators: these let you define your semantics for binding values to variables. A common use-case is defining let* as the monadic bind operator for some type: let (let*) x f = bind x f, after which writing monadic functions is way more pleasant syntax-wise. In contrast to the other items on this list, this is pure syntactic sugar but incredibly impactful [5]. * Algebraic effects: the conceptual root of concepts such as generators (yield), async/await, and checked assumptions. Informally, they're (among other things) a way to encapsulate computation and jump around code like a goto statement, but in a more structured and type/memory-safe way [6]. * Modular implicits: these allow (among other things) ad-hoc polymorphism, meaning that the same operator, e.g. (+), can operate on both integers and floats. That's the oft-cited use-case, and it sounds pedestrian, seeing as most mainstream languages with weaker type systems have it. There's more to it than that [7]. Haskell and Scala have type classes and implicits as mechanisms for ad-hoc polymorphism, but modular implicits (if implemented) seem to strike a nice balance between readability, flexibility, and transparency. [1]: https://blog.mads-hartmann.com/ocaml/2015/01/05/gadt-ocaml.html https://blog.mads-hartmann.com/ocaml/2015/01/05/gadt-ocaml.h... [2]: https://sketch.sh/s/yH0MJiujNSiofDWOU85loX/ https://sketch.sh/s/yH0MJiujNSiofDWOU85loX/ [3]: https://stackoverflow.com/questions/48092739/what-are-row-types-are-they-algebraic-data-types https://stackoverflow.com/questions/48092739/what-are-row-ty... [4]: https://dev.realworldocaml.org/first-class-modules.html https://dev.realworldocaml.org/first-class-modules.html [5]: https://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-syntax.html https://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-... [6]: https://overreacted.io/algebraic-effects-for-the-rest-of-us/ https://overreacted.io/algebraic-effects-for-the-rest-of-us/ [7]: https://arxiv.org/pdf/1512.01895.pdf https://arxiv.org/pdf/1512.01895.pdf

jolmg 5y ago

Reminds me of how lambdas got added to mainstream languages like Python, Java, and C++, when various other languages like Lisp, Smalltalk, SML, etc. had had them decades before.

pjmlp 5y ago
Yep, LINQ is nothing new for anyone that has used Smalltalk collections for example.

andi999 5y ago

5-10 years ahead? So they introduced multiprocessor support in like 2006? (taking c++ 11 as a reference point). That would have been pretty awesome.

yawaramin 5y ago
That sounds about right, given that you can do multiprocessing pretty easily in OCaml by forking. They even provide a convenience function directly in the standard library, Unix.establish_server, that forks a new process to handle requests.
- andi999 5y ago
  Forks on windows works in ocaml?
  - yawaramin 5y ago
    Nope, but you can use Unix.create_process. Which is admittedly not as convenient, but that's Windows for you.
    - pjmlp 5y ago
      fork() if a POSIX thing, and Windows is not the only non-POSIX OS around. Also fork() doesn't work consistenly across POSIX implementations regarding threads and signals.
      - yawaramin 5y ago
        But the OCaml documentation for 'Unix.fork' says that it's not implemented on Windows. It doesn't mention any other OS.
        pjmlp 5y ago
        I don't care about OCaml documentation, my point was about "Which is admittedly not as convenient, but that's Windows for you.", and UNIX versus other platforms in general.