A tour of F# with Phillip Carter

Download this episode

Download Video

Download captions

Download Captions


Phillip Carter takes us on a tour of F#, following the plan of the Tour of F# doc topic.




Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image

      this is bad

    • User profile image

      The second link to the docs is broken.

    • User profile image

      @Naveenkumar: It's not an intro for a beginner, that's for sure. But otherwise, it's not bad at all.

    • User profile image

      basically a nice introduction.

      i would suggest, if you try to teach something, you should avoid any distractions from the core topic to make it easier to concentrate on the stuff you want to show. its cute that visual studio code can now also handle F# mostly,but if its obviously unfinished in a way that every second minute it misunderstands the language in the editor and shows errors that dont exist or claims everything is fine although it isnt...just use visual studio for the demo where it works correctly and add as a comment that visual studio code can also more or less already handle it. by using VS-code you just distract from the F#-demo by fighting the editor all along the demo.

      further- dont make type-annotations a thing of taste that different "camps" do or dont, in the shown case its a thing of quality thats easy to explain. you can translate "the compiler infering the type" by "the compiler guessing the type". in many cases the compiler can only guess...if you have no numbers at all in a simple equation, it will likely assume int for the type, once you write a number with a comma it will assume its float, same if you use a sine or cosine where it knows the return type. so if you create a library with a function inside, thats only consumed by others using that library, it is extremely easy that some time later you slightly modify the function, and accidentially make the compiler infere another type for the return value. you wont even notice, your library will compile perfectly fine. it will then only explode in the face of the consumer of your library once he tries to compile and in his code all over the place red lines start to appear. so simply annotating your return type in a function is a very helpfull safety feature that helps you prevent breaking your code without even noticing it.

    • User profile image

      @sokhaty:Link fixed. Thanks for the heads up

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.