15 ms·

Functional Programming in OCaml

271 points by lelf 8y ago

xvilka 8y ago
OCaml 4.08 should be released quite soon with better error messaging, matter of month or two, I think. Too bad the expected GDB/DWARF integration didn't land in time. Hopefully next release...
- badfrog 8y ago
  Here's a Twitter thread listing some of the other upcoming improvements: https://twitter.com/etiennemillon/status/1095250528467079169 https://twitter.com/etiennemillon/status/1095250528467079169
- agumonkey 8y ago
  I like how, in this decade of Major Release every 6 monthes, OCaml still aggregates tiny version bumps slowly but surely :)
jaytaylor 8y ago
It took a lot of clicks to get beyond the preamble and into the the substantive part: http://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/basics/interacting.html http://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/bas...
- ngcc_hk 8y ago
  I usually turn on colour filter and cannot find the click arrow initially. But those preamble seems okish for once. But good to have a shortcut. Static functional ... lisp?
  - yawaramin 8y ago
    https://v1.realworldocaml.org/v1/en/html/the-compiler-backend-byte-code-and-native-code.html#the-untyped-lambda-form https://v1.realworldocaml.org/v1/en/html/the-compiler-backen...
  - laylomo2 8y ago
    It often feel like a statically typed lisp with much less in the way of macros.
jonahx 8y ago
What reasons are there for choosing OCaml over Haskell, either from a learning perspective or a practical one?
- nv-vn 8y ago
  OCaml is more of a multi-paradigm language than Haskell. It's not purely functional, so you can easily fallback into imperative code if you need (you can use mutable variables, I/O, mutable arrays, hashmaps, for loops, while loops, etc.). It's also object-oriented (though this feature is not widely used) and has a very powerful module system that few other languages can compare to. What I like about it from a learning perspective is that it makes a transition into functional programming much simpler than it would be with Haskell, where you have to completely change the way you program from the very beginning.
  - moocowtruck 8y ago
    haskell is great at being imperative too look at chris done's work on xml parsing haskell and c; nice example
    - robert_tweed 8y ago
      I'm not sure why you're being downvoted. I don't know Haskell, but I had a look for the parser you mentioned and it does appear at first glance to use a fairly imperative-looking style, with loops and pointers into mutable data: https://github.com/ocramz/xeno/blob/master/src/Xeno/DOM.hs https://github.com/ocramz/xeno/blob/master/src/Xeno/DOM.hs I would be interested in an analysis of this code from anyone who actually does know Haskell in case I'm misreading it.
- fiddlerwoaroof 8y ago
  I believe OCaml isn’t as strict about side-effects as Haskell, so if you don’t want the side-effect ceremony Haskell sort of forces on you, OCaml might be a good choice. Also, OCaml is strict by default and had a fairly good compiler.
yawaramin 8y ago
From http://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/intro/ocaml.html http://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/int... : > Milner received the Turing Award in 1991 in large part for his work on ML. The award citation includes this praise: "ML was way ahead of its time. It is built on clean and well-articulated mathematical ideas, teased apart so that they can be studied independently and relatively easily remixed and reused. ML has influenced many practical languages, including Java, Scala, and Microsoft's F#. Indeed, no serious language designer should ignore this example of good design." What does 'award citation' mean in this context? Surely it can't mean the blurb around the original award back in '91.
- chillee 8y ago
  It seems that award citation isn't exactly correct. See https://amturing.acm.org/award_winners/milner_1569367.cfm https://amturing.acm.org/award_winners/milner_1569367.cfm for where the blurb can be found. It appears to be part of a biography that one can find for every Turing award winner. It's unclear when these blurbs were written or for what specific purpose.
- DavidTNcl 8y ago
  > 1991 !?! Java, F# and Scala didn't exist then.
melling 8y ago
There’s also a new version of Real World OCaml under development: http://dev.realworldocaml.org/toc.html http://dev.realworldocaml.org/toc.html
- 4thaccount 8y ago
  Thanks for pointing this out. I read through bits of it last night.
badfrog 8y ago
The lecture slides from previous semesters of the course linked from the book are also a great, and somewhat more conversational, resource for learning Ocaml.
philonoist 8y ago
How does Ocaml compare to F# in expressing functional paradigm?
- badfrog 8y ago
  From Wikipedia: > F# is a member of the ML language family and originated as a .NET Framework implementation of a core of the programming language OCaml So F# is based on OCaml and is very similar.
  - philonoist 8y ago
    I apologize for not being clear. Which one is more expressive of functional paradigm?
- 4thaccount 8y ago
  F# uses a lot of OCaml syntax and is quite similar in many regards. Where they differ is F# is written on top of .NET, so users probably drop into the OO paradigm more often than they might in OCaml.
  - philonoist 8y ago
    I apologize for not being clear. Which one expresses functional paradigm more?
    - 4thaccount 8y ago
      I'm a novice in both, but my general impression is that they are so close in this regard as to not matter a whole lot as far as practical matters go. An expert can of course get detailed on the minutiae. Put another way, OCaml only works on Windows via MinGW if I recall correctly. While that isn't a problem for most folks, I prefer to steer clear and only use a language on a platform with a significant number of users. Python is used extensively on Windows, Mac, Linux, ARM...etc, so I'll use it on any of those machines. I would guess nearly all OCaml use is done via Linux and next to zero on Windows, so I avoid it on Windows (not worth the effort). F# on the other hand has some support from Microsoft (not a ton, but enough) and a decent amount from the community with some neat innovations (at least I think they are) like type providers. It has full .NET interop when you need it. Most of the syntax and method of using pattern matching everywhere is the same between them. The difference with F# that I find annoying is that I'm not super familiar with C#, so the times when you need to call .NET (Ex: iterating through a directory) directly, it is super obvious for someone with C# experience, but involves lots of digging through horrid Microsoft doc for me where only C# and VB.NET is covered 80% (I just made up that number, but F# is the least documented of the three official Lang's) of the time.
jasim 8y ago
Have you ever had one of those notepads with the kind of paper that made you want to write something, anything, even though you had nothing to write about? OCaml is just like that to me. I stroll through the internet aimlessly and I find a page that mentions OCaml and my eyes light up; I see an .ml file and savor how it looks - functions written with great economy of expression, pattern matching through which data flows in well-defined pathways, abstract data types forming a network of rugged pipes and girders that makes invalid states impossible; and .mli files that presents modules like classic prose -- no hedges, contortions, or obscurities that undercut the reader's ability to understand the flow of data and the pathways through which it flows. "Expression, carrying the elegance that comes from compressed energy, is like a perfectly tuned stringed instrument: the strings are taut to exact degrees to correspond to exact pitches that stand in exact relations to one another. The pitches and their relations exist before the strings are tuned. Each string is tuned to a pitch and the results are judged by comparison to this pre-existing reality. A musician tuning an instrument is not finished until everything is exactly right, but once it is exactly right, there is simply nothing left to do." -- Clear and Simple as the Truth: Writing Classic Prose, Thomas, Turner.
- deleted 8y ago
  [deleted]
- iaabtpbtpnn 8y ago
  Seriously, it is so good. I wish I could still program in OCaml professionally, as I did in the past.
- arcturus17 8y ago
  OCaml is the coolest language I’ve ever used. It’s the backbone of Harvard’s Intro to CS II, where they explain programming language paradigms with a heavy emphasis on the functional. OCaml’s expressiveness really shines through - I remember fondly how small yet powerful the language feels. Unfortunately, I don’t know what to build with it... I’m the kind of person that builds projects for professional advancement, which curtails my creativity. I’ve thought of making a simple web server. Or maybe learning ReasonML. Any suggestions welcome.
badfrog 8y ago
Does anybody think ReasonML will become more popular than plain OCaml outside of front end web development?
- yawaramin 8y ago
  Yes.
  - badfrog 8y ago
    Just because of FB support, or are there other reasons?
    - yawaramin 8y ago
      I think because of community interest and the need for a good general-purpose, efficient language. Here are some interesting community-developed projects: - A cross-platform native-compiling GUI library with a React-influenced design: https://github.com/revery-ui/revery https://github.com/revery-ui/revery - A lightning-fast Node version manager: https://github.com/Schniz/fnm https://github.com/Schniz/fnm - Erlang-like multicore actors: https://github.com/ostera/reactor https://github.com/ostera/reactor That said, it's early days and the ecosystem has to (and will) mature a lot.
      - badfrog 8y ago
        > the need for a good general-purpose, efficient language Is the implication that plain OCaml is not good?
        yawaramin 8y ago
        No, but realistically it's not very accessible (general-purpose). If people go for OCaml that's great, it's an amazing language and it's obviously the same language. But the ReasonML focus has been on developer experience and it's showing.
fxfan 8y ago
What is peoples experience with bucklescript and reasonML? How are the platforms, libraries and future direction?
- a-saleh 8y ago
  I am playing around with it. Right now I am trying to work my way through 99 problems [1], but using the ReasonML syntax [2] I am quite far from using it professionally (or in anger, as they say), but my next toy-project/game will probably use ReasonML or ocaml. ReasonML project tries to make most things work out of the box for particular purpose. It targets mostly frontend-devs and maybe node-js devs. I.e. I played around with buckle-script, and having it set-up on my machine was literaly just typing `npm i -g bs-platform` and adding reason-vscode extension to my visual studio code. What I really like is the recent-is addition of esy.sh [3] that helps with compiling ReasonML trough ocaml to binary executables (previously mostly the buckle-script compilation to js worked out of the box) Syntax is nicely familiar, type-error messages are approaching Elm-level of awesome a everything works, as long as you don't stray too much from the beaten path. If you do stray, it can get awkward. Sometimes I didn't know if I should read documentation for reason, bucklescript or some other part of the underlying ocaml toolchain. Two examples: First I played around with redoc [4] beautiful tool for generating documentation that contains embedded, compiled-to-js, executable code samples. But I could not compile my document, even though it looked like the example in the repo, I was getting an error about function not being present in a module. After several hours I realize, that the example documentation was compiled with previous version of the tool, and that with lates instead just calling Module.f() I need to be calling PackageName.Module.f() Second, I wanted to use esy.sh to work on those 99 problems. And I wanted to write tests for my solutions. I google around and find an ocaml unit-testing library [5] and it took me about an hour to figure out how to configure it. In the end it wasn't hard, it just took me quite some time to notice esy.sh is using dune [6] build system underneath and that I need to change the dune configuration files. I probably wouldn't need to do this for other libraries, but test-framework was using the ocaml extension-points (something like macro-system) and you needed to enable it in the build-config. So far I still like it and it is not more complicated than dealing with other js-ecosystem frameworks :-) But going from node.js ecosystem to golang at work, I would preffer the go-style "just run this binary and you are fine" to js-ecosystem style "here is a rube-goldberg machine of build-systems". [1] https://ocaml.org/learn/tutorials/99problems.html https://ocaml.org/learn/tutorials/99problems.html [2] https://reasonml.github.io/docs/en/overview https://reasonml.github.io/docs/en/overview [3] https://esy.sh/ https://esy.sh/ [4] https://github.com/jaredly/redoc https://github.com/jaredly/redoc [5] https://github.com/janestreet/ppx_inline_test https://github.com/janestreet/ppx_inline_test [6] https://dune.build/ https://dune.build/
adjkant 8y ago
Since there are a lot of questions regarding language choice for functional languages here, I think I'd be good to share my experience here. I've learned from the ground up (since college) in a functional style through HtDP [1] and have used Racket (not just the teaching languages) and OCaml a good deal at this point. Some notes on my experiences with functional languages: OCaml The Good: - Incredibly powerful data matching/construction - Typing gives good runtime guarantees The Bad: - The actual type checking messages from the compiler aren't very fun to wrangle with - Parens being optional but then sometimes being needed for data constructions adds to confusion along with types - There are a lot of other quirks that I only see occasionally but pull me out of ever thinking "this is the language I want to code in mainly". Things like being required to define mutually recursive functions in the same define clause, chained together with "and". The ambiguity of the need for semicolons, similar to parens. I won't detail them all here, but the quirks sum to something just large enough to be quite annoying to use. Summary: It can be beautiful to work with until it snaps you right out of it. At this point I'm not thrilled to work in it, but I'm not mad either and will probably see the day I write more of it. Racket The Good: - For me, the most readable. I'm not sure if this is a reflection of learning it first, but there's something so clean about it. While you can always drop into the more complex, the core basics read very well. - Incredibly powerful macros. They are much more syntactically complex and resources for learning the ins and outs are hard to find, but once you get them, the world is your oyster. The Bad: For whatever reason, all of the practical packages you want simply don't exist yet, or if they do, break the cleanness bare Racket gives you in ways you probably shiver looking at. It's my only real negative, but the implication basically is that for any serious project, unless I want to write the tooling I want myself from the ground up, it's basically not an option. What really sucks about this the most to me is that of all the languages, writing good libraries for Racket is the easiest given the powerful macro tooling. All the bare bones are there, they just need to be composed together ands abstracted the right amount while keeping the simplicity that makes Racket beautiful. When said aloud, it's a big ask. But IMO Python has done so well accomplishing this with things like requests, flask, etc - what's stopping Racket? Oh, and the IDE (DrRacket), while deceptively powerful, still needs a competitor badly. I'd love to see a Jetbrains IDE for Racket, though of course I know that's not happening anytime soon. Summary: I wish I could write everything in it, but the tooling and IDE just aren't there. Currently my focus is actually now on that tooling itself [2]. Functional languages I've looked at but have not written anything serious in: Haskell: I get the appeal from a theory perspective, but the readability for me is absolutely terrible. Things are more verbose where they shouldn't be and too terse in the reverse. I haven't spent enough time to comment any further, but that alone was enough to steer me to explore other functional language options. Clojure: The community seems great and I am excited it's gaining traction (and building out that tooling that Racket is sorely missing), but I wonder why these two have to be separated from each other. At the core of the language, it seems to me on cursory glance that clojure's syntax is just ever so slightly worse than Rackets, though less annoying than the quirks of OCaml. I can't help but wonder what would be if the clojure community instead wrote tooling for Racket (and some do!). For everyone involved closely with Clojure, I'd love to hear more about why it needed its own language. I know being on the JVM was big, but beyond that I'm pretty fuzzy. Functional Programming in general: While there are cases where imperative and object oriented programming make sense, I truly wish a day comes where the word mutation is taboo, imperative style is used sparingly when needed, and code readability and library design is valued above all else in industry. And there are good developments with things like Clojure, Redux, and the big languages embracing functional style more. Still, the difference of how I program in each style is truly incredible, and while my code is objectively better in the functional style, I currently rarely get to use it for projects, professional or personal. To anyone who hasn't tried functional programming, I couldn't recommend it enough. HtDP or this book both seem like good places to start. [1] https://www.htdp.org/2019-02-24/index.html https://www.htdp.org/2019-02-24/index.html [2] In an attempt to improve the tooling to Racket itself, I am working on two libraries: A web framework and a basic ORM for structures. Both are in highly unstable condition at the moment so it is not recommended to try and contribute to them at this point, but I am targeting May to have stable 1.0 releases. hopefully expect to see a Show HN :) They are loosely inspired by Flask / SQLAlchemy, meant to address similar things in Racket. Links at [3] and [4] [3] https://github.com/adjkant/web-sourcery https://github.com/adjkant/web-sourcery [4] https://github.com/adjkant/sql-sourcery https://github.com/adjkant/sql-sourcery [5] Syntax Example for [3] and [4] together: https://github.com/adjkant/web-sourcery/blob/master/examples/0-0-1-example.rkt https://github.com/adjkant/web-sourcery/blob/master/examples...
playing_colours 8y ago
I like the font of titles, can anyone advise what font it is?
- ericbb 8y ago
  I think it's "Play": https://fonts.google.com/specimen/Play https://fonts.google.com/specimen/Play
Shmebulock 8y ago
Is there a PDF of this?
teacpde 8y ago
Interesting that the comments here are mostly around OCaml while the introduction states > You might think this course is about OCaml. It's not. > This course is about making you a better programmer.

271 points by lelf 8y ago

OCaml 4.08 should be released quite soon with better error messaging, matter of month or two, I think. Too bad the expected GDB/DWARF integration didn't land in time. Hopefully next release...

badfrog 8y ago
Here's a Twitter thread listing some of the other upcoming improvements: https://twitter.com/etiennemillon/status/1095250528467079169 https://twitter.com/etiennemillon/status/1095250528467079169
agumonkey 8y ago
I like how, in this decade of Major Release every 6 monthes, OCaml still aggregates tiny version bumps slowly but surely :)

jaytaylor 8y ago

It took a lot of clicks to get beyond the preamble and into the the substantive part: http://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/basics/interacting.html http://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/bas...

ngcc_hk 8y ago
I usually turn on colour filter and cannot find the click arrow initially. But those preamble seems okish for once. But good to have a shortcut. Static functional ... lisp?
- yawaramin 8y ago
  https://v1.realworldocaml.org/v1/en/html/the-compiler-backend-byte-code-and-native-code.html#the-untyped-lambda-form https://v1.realworldocaml.org/v1/en/html/the-compiler-backen...
- laylomo2 8y ago
  It often feel like a statically typed lisp with much less in the way of macros.

jonahx 8y ago

What reasons are there for choosing OCaml over Haskell, either from a learning perspective or a practical one?

nv-vn 8y ago
OCaml is more of a multi-paradigm language than Haskell. It's not purely functional, so you can easily fallback into imperative code if you need (you can use mutable variables, I/O, mutable arrays, hashmaps, for loops, while loops, etc.). It's also object-oriented (though this feature is not widely used) and has a very powerful module system that few other languages can compare to. What I like about it from a learning perspective is that it makes a transition into functional programming much simpler than it would be with Haskell, where you have to completely change the way you program from the very beginning.
- moocowtruck 8y ago
  haskell is great at being imperative too look at chris done's work on xml parsing haskell and c; nice example
  - robert_tweed 8y ago
    I'm not sure why you're being downvoted. I don't know Haskell, but I had a look for the parser you mentioned and it does appear at first glance to use a fairly imperative-looking style, with loops and pointers into mutable data: https://github.com/ocramz/xeno/blob/master/src/Xeno/DOM.hs https://github.com/ocramz/xeno/blob/master/src/Xeno/DOM.hs I would be interested in an analysis of this code from anyone who actually does know Haskell in case I'm misreading it.
fiddlerwoaroof 8y ago
I believe OCaml isn’t as strict about side-effects as Haskell, so if you don’t want the side-effect ceremony Haskell sort of forces on you, OCaml might be a good choice. Also, OCaml is strict by default and had a fairly good compiler.

yawaramin 8y ago

From http://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/intro/ocaml.html http://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/int... : > Milner received the Turing Award in 1991 in large part for his work on ML. The award citation includes this praise: "ML was way ahead of its time. It is built on clean and well-articulated mathematical ideas, teased apart so that they can be studied independently and relatively easily remixed and reused. ML has influenced many practical languages, including Java, Scala, and Microsoft's F#. Indeed, no serious language designer should ignore this example of good design." What does 'award citation' mean in this context? Surely it can't mean the blurb around the original award back in '91.

chillee 8y ago
It seems that award citation isn't exactly correct. See https://amturing.acm.org/award_winners/milner_1569367.cfm https://amturing.acm.org/award_winners/milner_1569367.cfm for where the blurb can be found. It appears to be part of a biography that one can find for every Turing award winner. It's unclear when these blurbs were written or for what specific purpose.
DavidTNcl 8y ago
> 1991 !?! Java, F# and Scala didn't exist then.

melling 8y ago

There’s also a new version of Real World OCaml under development: http://dev.realworldocaml.org/toc.html http://dev.realworldocaml.org/toc.html

4thaccount 8y ago
Thanks for pointing this out. I read through bits of it last night.

badfrog 8y ago

The lecture slides from previous semesters of the course linked from the book are also a great, and somewhat more conversational, resource for learning Ocaml.

philonoist 8y ago

How does Ocaml compare to F# in expressing functional paradigm?

badfrog 8y ago
From Wikipedia: > F# is a member of the ML language family and originated as a .NET Framework implementation of a core of the programming language OCaml So F# is based on OCaml and is very similar.
- philonoist 8y ago
  I apologize for not being clear. Which one is more expressive of functional paradigm?
4thaccount 8y ago
F# uses a lot of OCaml syntax and is quite similar in many regards. Where they differ is F# is written on top of .NET, so users probably drop into the OO paradigm more often than they might in OCaml.
- philonoist 8y ago
  I apologize for not being clear. Which one expresses functional paradigm more?
  - 4thaccount 8y ago
    I'm a novice in both, but my general impression is that they are so close in this regard as to not matter a whole lot as far as practical matters go. An expert can of course get detailed on the minutiae. Put another way, OCaml only works on Windows via MinGW if I recall correctly. While that isn't a problem for most folks, I prefer to steer clear and only use a language on a platform with a significant number of users. Python is used extensively on Windows, Mac, Linux, ARM...etc, so I'll use it on any of those machines. I would guess nearly all OCaml use is done via Linux and next to zero on Windows, so I avoid it on Windows (not worth the effort). F# on the other hand has some support from Microsoft (not a ton, but enough) and a decent amount from the community with some neat innovations (at least I think they are) like type providers. It has full .NET interop when you need it. Most of the syntax and method of using pattern matching everywhere is the same between them. The difference with F# that I find annoying is that I'm not super familiar with C#, so the times when you need to call .NET (Ex: iterating through a directory) directly, it is super obvious for someone with C# experience, but involves lots of digging through horrid Microsoft doc for me where only C# and VB.NET is covered 80% (I just made up that number, but F# is the least documented of the three official Lang's) of the time.

jasim 8y ago

Have you ever had one of those notepads with the kind of paper that made you want to write something, anything, even though you had nothing to write about? OCaml is just like that to me. I stroll through the internet aimlessly and I find a page that mentions OCaml and my eyes light up; I see an .ml file and savor how it looks - functions written with great economy of expression, pattern matching through which data flows in well-defined pathways, abstract data types forming a network of rugged pipes and girders that makes invalid states impossible; and .mli files that presents modules like classic prose -- no hedges, contortions, or obscurities that undercut the reader's ability to understand the flow of data and the pathways through which it flows. "Expression, carrying the elegance that comes from compressed energy, is like a perfectly tuned stringed instrument: the strings are taut to exact degrees to correspond to exact pitches that stand in exact relations to one another. The pitches and their relations exist before the strings are tuned. Each string is tuned to a pitch and the results are judged by comparison to this pre-existing reality. A musician tuning an instrument is not finished until everything is exactly right, but once it is exactly right, there is simply nothing left to do." -- Clear and Simple as the Truth: Writing Classic Prose, Thomas, Turner.

deleted 8y ago
[deleted]
iaabtpbtpnn 8y ago
Seriously, it is so good. I wish I could still program in OCaml professionally, as I did in the past.
arcturus17 8y ago
OCaml is the coolest language I’ve ever used. It’s the backbone of Harvard’s Intro to CS II, where they explain programming language paradigms with a heavy emphasis on the functional. OCaml’s expressiveness really shines through - I remember fondly how small yet powerful the language feels. Unfortunately, I don’t know what to build with it... I’m the kind of person that builds projects for professional advancement, which curtails my creativity. I’ve thought of making a simple web server. Or maybe learning ReasonML. Any suggestions welcome.

badfrog 8y ago

Does anybody think ReasonML will become more popular than plain OCaml outside of front end web development?

yawaramin 8y ago
Yes.
- badfrog 8y ago
  Just because of FB support, or are there other reasons?
  - yawaramin 8y ago
    I think because of community interest and the need for a good general-purpose, efficient language. Here are some interesting community-developed projects: - A cross-platform native-compiling GUI library with a React-influenced design: https://github.com/revery-ui/revery https://github.com/revery-ui/revery - A lightning-fast Node version manager: https://github.com/Schniz/fnm https://github.com/Schniz/fnm - Erlang-like multicore actors: https://github.com/ostera/reactor https://github.com/ostera/reactor That said, it's early days and the ecosystem has to (and will) mature a lot.
    - badfrog 8y ago
      > the need for a good general-purpose, efficient language Is the implication that plain OCaml is not good?
      - yawaramin 8y ago
        No, but realistically it's not very accessible (general-purpose). If people go for OCaml that's great, it's an amazing language and it's obviously the same language. But the ReasonML focus has been on developer experience and it's showing.

fxfan 8y ago

What is peoples experience with bucklescript and reasonML? How are the platforms, libraries and future direction?

a-saleh 8y ago
I am playing around with it. Right now I am trying to work my way through 99 problems [1], but using the ReasonML syntax [2] I am quite far from using it professionally (or in anger, as they say), but my next toy-project/game will probably use ReasonML or ocaml. ReasonML project tries to make most things work out of the box for particular purpose. It targets mostly frontend-devs and maybe node-js devs. I.e. I played around with buckle-script, and having it set-up on my machine was literaly just typing `npm i -g bs-platform` and adding reason-vscode extension to my visual studio code. What I really like is the recent-is addition of esy.sh [3] that helps with compiling ReasonML trough ocaml to binary executables (previously mostly the buckle-script compilation to js worked out of the box) Syntax is nicely familiar, type-error messages are approaching Elm-level of awesome a everything works, as long as you don't stray too much from the beaten path. If you do stray, it can get awkward. Sometimes I didn't know if I should read documentation for reason, bucklescript or some other part of the underlying ocaml toolchain. Two examples: First I played around with redoc [4] beautiful tool for generating documentation that contains embedded, compiled-to-js, executable code samples. But I could not compile my document, even though it looked like the example in the repo, I was getting an error about function not being present in a module. After several hours I realize, that the example documentation was compiled with previous version of the tool, and that with lates instead just calling Module.f() I need to be calling PackageName.Module.f() Second, I wanted to use esy.sh to work on those 99 problems. And I wanted to write tests for my solutions. I google around and find an ocaml unit-testing library [5] and it took me about an hour to figure out how to configure it. In the end it wasn't hard, it just took me quite some time to notice esy.sh is using dune [6] build system underneath and that I need to change the dune configuration files. I probably wouldn't need to do this for other libraries, but test-framework was using the ocaml extension-points (something like macro-system) and you needed to enable it in the build-config. So far I still like it and it is not more complicated than dealing with other js-ecosystem frameworks :-) But going from node.js ecosystem to golang at work, I would preffer the go-style "just run this binary and you are fine" to js-ecosystem style "here is a rube-goldberg machine of build-systems". [1] https://ocaml.org/learn/tutorials/99problems.html https://ocaml.org/learn/tutorials/99problems.html [2] https://reasonml.github.io/docs/en/overview https://reasonml.github.io/docs/en/overview [3] https://esy.sh/ https://esy.sh/ [4] https://github.com/jaredly/redoc https://github.com/jaredly/redoc [5] https://github.com/janestreet/ppx_inline_test https://github.com/janestreet/ppx_inline_test [6] https://dune.build/ https://dune.build/

adjkant 8y ago

Since there are a lot of questions regarding language choice for functional languages here, I think I'd be good to share my experience here. I've learned from the ground up (since college) in a functional style through HtDP [1] and have used Racket (not just the teaching languages) and OCaml a good deal at this point. Some notes on my experiences with functional languages: OCaml The Good: - Incredibly powerful data matching/construction - Typing gives good runtime guarantees The Bad: - The actual type checking messages from the compiler aren't very fun to wrangle with - Parens being optional but then sometimes being needed for data constructions adds to confusion along with types - There are a lot of other quirks that I only see occasionally but pull me out of ever thinking "this is the language I want to code in mainly". Things like being required to define mutually recursive functions in the same define clause, chained together with "and". The ambiguity of the need for semicolons, similar to parens. I won't detail them all here, but the quirks sum to something just large enough to be quite annoying to use. Summary: It can be beautiful to work with until it snaps you right out of it. At this point I'm not thrilled to work in it, but I'm not mad either and will probably see the day I write more of it. Racket The Good: - For me, the most readable. I'm not sure if this is a reflection of learning it first, but there's something so clean about it. While you can always drop into the more complex, the core basics read very well. - Incredibly powerful macros. They are much more syntactically complex and resources for learning the ins and outs are hard to find, but once you get them, the world is your oyster. The Bad: For whatever reason, all of the practical packages you want simply don't exist yet, or if they do, break the cleanness bare Racket gives you in ways you probably shiver looking at. It's my only real negative, but the implication basically is that for any serious project, unless I want to write the tooling I want myself from the ground up, it's basically not an option. What really sucks about this the most to me is that of all the languages, writing good libraries for Racket is the easiest given the powerful macro tooling. All the bare bones are there, they just need to be composed together ands abstracted the right amount while keeping the simplicity that makes Racket beautiful. When said aloud, it's a big ask. But IMO Python has done so well accomplishing this with things like requests, flask, etc - what's stopping Racket? Oh, and the IDE (DrRacket), while deceptively powerful, still needs a competitor badly. I'd love to see a Jetbrains IDE for Racket, though of course I know that's not happening anytime soon. Summary: I wish I could write everything in it, but the tooling and IDE just aren't there. Currently my focus is actually now on that tooling itself [2]. Functional languages I've looked at but have not written anything serious in: Haskell: I get the appeal from a theory perspective, but the readability for me is absolutely terrible. Things are more verbose where they shouldn't be and too terse in the reverse. I haven't spent enough time to comment any further, but that alone was enough to steer me to explore other functional language options. Clojure: The community seems great and I am excited it's gaining traction (and building out that tooling that Racket is sorely missing), but I wonder why these two have to be separated from each other. At the core of the language, it seems to me on cursory glance that clojure's syntax is just ever so slightly worse than Rackets, though less annoying than the quirks of OCaml. I can't help but wonder what would be if the clojure community instead wrote tooling for Racket (and some do!). For everyone involved closely with Clojure, I'd love to hear more about why it needed its own language. I know being on the JVM was big, but beyond that I'm pretty fuzzy. Functional Programming in general: While there are cases where imperative and object oriented programming make sense, I truly wish a day comes where the word mutation is taboo, imperative style is used sparingly when needed, and code readability and library design is valued above all else in industry. And there are good developments with things like Clojure, Redux, and the big languages embracing functional style more. Still, the difference of how I program in each style is truly incredible, and while my code is objectively better in the functional style, I currently rarely get to use it for projects, professional or personal. To anyone who hasn't tried functional programming, I couldn't recommend it enough. HtDP or this book both seem like good places to start. [1] https://www.htdp.org/2019-02-24/index.html https://www.htdp.org/2019-02-24/index.html [2] In an attempt to improve the tooling to Racket itself, I am working on two libraries: A web framework and a basic ORM for structures. Both are in highly unstable condition at the moment so it is not recommended to try and contribute to them at this point, but I am targeting May to have stable 1.0 releases. hopefully expect to see a Show HN :) They are loosely inspired by Flask / SQLAlchemy, meant to address similar things in Racket. Links at [3] and [4] [3] https://github.com/adjkant/web-sourcery https://github.com/adjkant/web-sourcery [4] https://github.com/adjkant/sql-sourcery https://github.com/adjkant/sql-sourcery [5] Syntax Example for [3] and [4] together: https://github.com/adjkant/web-sourcery/blob/master/examples/0-0-1-example.rkt https://github.com/adjkant/web-sourcery/blob/master/examples...

playing_colours 8y ago

I like the font of titles, can anyone advise what font it is?

ericbb 8y ago
I think it's "Play": https://fonts.google.com/specimen/Play https://fonts.google.com/specimen/Play

Shmebulock 8y ago

Is there a PDF of this?

teacpde 8y ago

Interesting that the comments here are mostly around OCaml while the introduction states > You might think this course is about OCaml. It's not. > This course is about making you a better programmer.