DEV Community: Karanveer Singh

Studying Programming vs Making Programs

Karanveer Singh — Fri, 10 Mar 2023 07:25:08 +0000

The Dreadful Timed-Coding Challenge

I've been applying to new software developer jobs recently, and getting some interviews which provide a code challenge to complete online. I'm able to complete those challenges, but still get rejected. However, no one ever tells you why they rejected your application, so it's up to you to figure out what to improve, and how.

Upon reflection, I found I dreaded the timed coding challenge. I looked back on my programming experience for the last 5 years. I solved some pretty big problems at work and even on personal projects, all on a tight deadline. So why was there this lack of confidence? Looking at problems on HackerRank and LeetCode, I felt like I was back in my old CS classes, when data-structures and algorithms (DS & A) were fresh on my mind but still largely theoretical bits of information. My relationship to DS & A had changed over the years I'd been a practitioner in an enterprise company.

The data-structures I used at work were simply what aligned most closely to the manner in which the data was used, without being super-concerned about efficiency or optimization. I used Lists, Dictionaries, Sets and Generators in Python, and just Lists and HashMaps in Java. I sometimes needed to implement a custom class to encapsulate a set of behaviors and related data. But, oddly enough, I never needed my own linked list for any program at work, because there simply wasn't the need for it.

Skill acquisition, from my own personal experience, is like a 3D spiral. In the horizontal dimension, at opposite ends, you have the fundamentals of the craft and practical application. In the vertical dimension, you have your experience, going from nil to mastery, bottom to top. As time goes on, you go up in experience. The smooth spiral motion only occurs when you revisit fundamentals and practical application, over and over again, but with the insight of more experience.

Thinking about this, I finally realized what had happened and where the fear and the dread came from. My spiral was messed up because I didn't revisit the fundamentals of my craft. I'd let my ego blind me from the harsh truth of it.

An Art Teacher's Advice

The other day, I picked up a book on my art training bookshelf, The Natural Way to Draw, by Kimon Nikolaides. Whenever I'm not programming, or reading fiction, I like to spend my energy on improving my drawing skills.

This book was what I used for art training many years ago. I keep going back to its exercises and drawing schedule it provides. Each chapter contains 15 hours' worth of drawing exercises, and even after all these years, I haven't been able to get past the 3rd chapter. But giving up is not an option for me and I started all the way from the beginning, once again.

I've read the introduction over a dozen times, very carefully, in the years that I've had the book. As I've risen in the spiral of mastery, I started to better understand the seriousness of the meaning behind his words. Here's the paragraph that really struck me this time.

There is a vast difference in drawing and making drawings. The things you will do - over and over again - are but practice. They should represent to you only the result of an effort to study, the by-product of your mental and physical activity. Your progress is charted, not on paper, but in the increased knowledge with which you look at life around you.

This is timeless. I know I've been guilty of putting too much stock on making quality stuff, even though I didn't have enough practice of fundamentals to pull it off. What Kimon is saying here is so important that you should read and re-read the paragraph. Substitute programming for drawing. Then you'll realize difference he's talking about.

As programmers, we work at our day jobs building useful features and enhancements. Those project-based tasks come under making programs. Working on pure coding problems on online platforms like LeetCode or HackerRank, or even just reading about and practicing fundamental DS & A stuff, those come under programming. The beginner's (or even the advanced) programmer's mistake is confusing the latter with the former. When I was struggling with a coding challenge, I felt like I was not measuring up to my self image of constant excellence, which I've created and maintained in my workplace. This was so wrong of me to do, and something you'd never do to anyone but yourself.

I was so involved in making programs that I put off revisiting, and studying programming, erroneously thinking I didn't need to. One should always be conscious of the difference and approach each with the appropriate mindset.

Past the Ego's Fear

Everything in life is related. The most commonplace things can inspire contemplation into the greatest truths. By putting my fear of coding challenges under a microscope, I was able to uncover unpleasant truths about my unconscious lack of kindness towards my self.

In my art practice, I can never do a good drawing when I intend to show it off on Instagram for likes and appreciation, which makes my ego feel good. When I draw in my sketchbook for myself, I create strokes of genius which makes me wonder why I'm ever doing anything else at all. Here, I didn't draw for my ego which is always hungry for rewards at the end of any task, but simply enjoyed the process of creating which is the only reward my deeper self ever needed.

The job application process makes it difficult to not be your ego. After all, you're constantly describing your achievements, victories, accolades and skills. Your ego tends to flare up when you do that. You start to identify your Self with your work. I've found through both my art and programming practice, this is never healthy. You are never your work. You are not your resume or your achievements, or failures. You're not even your name on the resume. You never were.

But for practicality's sake, we have a body and need to function with it in the world. I want a job to live well, and maybe buy a PSVR2 and play Resident Evil 8 on it! To get the job, I need to present myself with confidence, which comes from skill. For building the skills as a programmer, I follow Kimon Nikolaides' advice.

I do coding practice as an effort to study the fundamentals of the craft. Whatever code I produce in that time, the quality doesn't matter. Did I solve the coding challenge? Don't care. Was the by-product of my time any good? Doesn't matter. It was the experience that I walk away with that matters. The thoughts, the joy, the struggle, the lessons learned, all intangible but unmistakably real benefits, real memories and experience that I accumulate.

I now structure my programming study just like my art studies. I'm learning to put off the ego, and be comfortable being without it, and just put my attention on the process because that's where it should be.

Being in the process of drawing in my sketchbook, painting on canvas, and pumping iron at the gym is where the fun is. I'm not afraid of coding problems anymore. I enjoy them, simply because I enjoy being in the process of programming. I know that if I simply focus on the problem to be solved instead of my ego's reactions, I'll be okay.

Binary Ops and Gene Compression in Go

Karanveer Singh — Wed, 24 Aug 2022 18:47:00 +0000

I've been reading Classic Computer Science Problems in Python by David Kopec to review CS algorithms.

One of the first problems is gene compression where the goal is to encode a string of nucleotides ("ACGTA...") into binary to reduce it's size in memory.

Compressed data is great because there's less stuff to download and upload, while receiving the same information content.

The property of nucleotides being limited to the set of four letters 'A', 'C', 'G' and 'T' makes it suitable to encode it using simple integers - 0, 1, 2, 3.
Storing numbers is more memory-efficient than storing strings, which are collections of bytes representing unique characters in UTF-8 or ASCII.

While the book implements the compression/decompression algorithm in Python, I thought it would be a good learning exercise to write it in Go and provide an overview of binary numbers.

Binary Basics

We normally use base 10 integer values to represent numbers in most situations. However, base 10 is unwieldy when you want to model data using hardware such as switches in an on/off state.
But base 2 can easily be modeled using switches, and is a natural fit for computers.

Decimal	Base 2 Expansion	Binary
0	0 (2⁰)	0
1	1 (2⁰)	1
2	1 (2¹) + 0 (2⁰)	10
3	1 (2¹) + 1 (2⁰)	11
...	...	...
7	1 (2²) + 1 (2¹) + 1 (2⁰)	111
8	1 (2³) + 0 (2²) + 0 (2¹) + 0 (2⁰)	1000

The coefficients of the powers give the binary representation of the decimal number.

Binary Ops in Go

We can have some fun with binary in Go.
Binary literals are written with a 0b prefix such as 0b101.

Binary ops playground

package main

import "fmt"

func main() {
    fmt.Println(0b11) // 3

    fmt.Println(0b11 == 3)   // true
    fmt.Println(0b1000 == 8) // true

    // Left shift moves the bits to the left, introducing 0s on the right,
    // increasing the number
    fmt.Println(0b10 << 1)         // 4 i.e 100
    fmt.Println(0b1 << 2)          // also 4
    fmt.Println(0b1<<2 == 0b10<<1) // true

    // Right shift moves the bits to the right, losing columns and reducing the number.
    fmt.Println(0b011>>1 == 1)  // true
    fmt.Println(0b1111 >> 2)    // 3 i.e. 11
    fmt.Println(0b1110>>2 == 3) // true

    // ANDing with & produces a 1 where both columns are 1, else 0.
    fmt.Println(0b110&0b100 == 0b100) // true
    fmt.Println(0b01&0b00 == 0)       // true

    // ORing with | produces a 1 where either column or both are 1, else 0.
    fmt.Println(0b11|0b01 == 0b11)    // true
    fmt.Println(0b100|0b011 == 0b111) // true

    // ExclusiveORing with ^ produces a 1 only where columns are unequal, else 0.
    fmt.Println(0b11^0b00 == 0b11)  // true
    fmt.Println(0b100^0b101 == 0b1) // true
}

Gene Compression Algorithm

Binary operations really shine when applied to the gene compression problem.

Lets get started.

mkdir geneCompression
cd geneCompression

Create a main.go file with a type CompressedGene.

package main

type CompressedGene struct {
    bits int
}

We'll create a constructor function, and a compress private method that's called within the constructor to store the gene as the bits field.


func (cg *CompressedGene) compress(gene string) error {
    cg.bits = 1 // sentinel value so we can store 00 and 01 as first nucleotide
    for _, nucleotide := range strings.ToUpper(gene) {
        cg.bits = cg.bits << 2 // left shift by 2 to introduce 00
        switch nucleotide {
        case 'A':
            cg.bits |= 0b00
        case 'C':
            cg.bits |= 0b01
        case 'G':
            cg.bits |= 0b10
        case 'T':
            cg.bits |= 0b11
        default:
            return fmt.Errorf("Invalid nucleotide: %c", nucleotide)
        }
    }
    return nil
}

// NewCompressedGene provides a compressed gene struct reference.
func NewCompressedGene(gene string) (*CompressedGene, error) {
    cg := CompressedGene{}
    err := cg.compress(gene)
    if err != nil {
        return nil, err
    }
    return &cg, nil
}

For compression, we start out with a 1 as a sentinel value. Starting with 0 would make us lose genes if we added 00 or 01 as the first elements since leading zeros are ignored in binary expressions.

A left shift is performed to create two columns to store the gene. We use the or equals |= operator to change the value of the rightmost bits according to the gene and store it.

Decompression will be the inverse of the compression method.

// Decompress expands the bits into a string.
func (cg *CompressedGene) Decompress() (string, error) {
    gene := ""

    // bitLength - 1 to ignore sentinel value
    for i := 0; i < bitLength(cg.bits)-1; i += 2 {
        rightShifted := cg.bits >> i
        fmt.Printf("Rightshifted by %d - %b\n", i, rightShifted)

        // get the two rightmost bits
        rightPair := rightShifted & 0b11

        switch rightPair {
        case 0b00:
            gene += "A"
        case 0b01:
            gene += "C"
        case 0b10:
            gene += "G"
        case 0b11:
            gene += "T"
        default:
            return "", fmt.Errorf("Invalid bits: %d", rightPair)
        }
    }
    return reverse(gene), nil
}

func bitLength(n int) int {
    return int(math.Floor(math.Log2(float64(n))) + 1)
}

func reverse(s string) string {
    r := []rune(s)
    for i, j := 0, len(r)-1; i < len(r)/2; i, j = i+1, j-1 {
        r[i], r[j] = r[j], r[i]
    }
    return string(r)
}

We use the bitLength helper function to determine the number of bits in the integer value, and the reverse function to reverse the expanded string. Since we are going right to left, turning bits into genes, the string we build is the reverse of the original. That's why the final step of reversing the string is needed.

We can test everything works as expected!

func main() {
    gene := "ACGT"
    fmt.Printf("Original gene: %s\n", gene)
    compressed, err := NewCompressedGene(gene)
    if err != nil {
        log.Fatalln(err)
    }
    fmt.Printf("Bits: %b\n", compressed.bits)
    decompressed, err := compressed.Decompress()
    if err != nil {
        log.Fatalln(err)
    }
    fmt.Printf("Matches original gene: %v\n", decompressed == gene)
}

go run main.go
Original gene: ACGT
Bits: 100011011
Rightshifted by 0 - 100011011
Rightshifted by 2 - 1000110
Rightshifted by 4 - 10001
Rightshifted by 6 - 100
Matches original gene: true

The only issue with this algorithm is that it fails for large string sequences.

If you change the gene value, and rerun - we'll get quite unexpected results.

func main() {
    gene := strings.Repeat("TAGGGATTAACCGTTATATATATATAGCCATGGATCGATTATATAGGGATTAACCGTTATATATATATAGCCATGGATCGATTATA", 100)
    compressed, err := NewCompressedGene(gene)
    if err != nil {
        log.Fatalln(err)
    }
    fmt.Printf("Bits: %b\n", compressed.bits)
    decompressed, err := compressed.Decompress()
    if err != nil {
        log.Fatalln(err)
    }
    fmt.Printf("Matches original gene: %v\n", decompressed == gene)
}

Large gene strings will cause this algorithm problems because our bits int field will easily overflow once we reach its 64 bit limit! The int type in go is 32 bits or 64 bits depending on the underlying system. But we definitely don't want that limitation, so we'll have to leverage the mighty big.Int.

Using `big.Int`

The big.Int type won't support the binary operation symbols like & and << but it comes with methods that do the same thing.
We can use Or, And, Lsh (left shift), and Rsh (right shift) methods for our logic.

// CompressedGene models a compressed format gene sequence
type CompressedGene struct {
    bits *big.Int
}

func (c *CompressedGene) compress(gene string) error {
    c.bits = big.NewInt(1) // sentinel value

    for _, nucleotide := range strings.ToUpper(gene) {
        c.bits.Lsh(c.bits, 2)
        switch nucleotide {
        case 'A':
            c.bits.Or(c.bits, big.NewInt(0b00))
        case 'C':
            c.bits.Or(c.bits, big.NewInt(0b01))
        case 'G':
            c.bits.Or(c.bits, big.NewInt(0b10))
        case 'T':
            c.bits.Or(c.bits, big.NewInt(0b11))
        default:
            return fmt.Errorf("Invalid nucleotide: %c", nucleotide)
        }
    }
    return nil
}

// Decompress expands the compressed bit sequence into
// a string of nucleotides A,C,G,T.
func (c *CompressedGene) Decompress() (string, error) {
    gene := ""

    // bitlen - 1 to ignore sentinel value
    for i := 0; i < c.bits.BitLen()-1; i += 2 {
        rightShifted := &big.Int{} // local value to not mutate the original
        rightShifted.Rsh(c.bits, uint(i))
        // Getting the two, rightmost bits.
        rightBits := (rightShifted.And(rightShifted, big.NewInt(0b11))).Uint64()
        switch rightBits {
        case 0b00:
            gene += "A"
        case 0b01:
            gene += "C"
        case 0b10:
            gene += "G"
        case 0b11:
            gene += "T"
        default:
            return "", fmt.Errorf("Invalid bits: %d", rightBits)
        }
    }
    return reverse(gene), nil
}

The constructor remains the same.

Let's adjust the main function to print out the byte sizes so we can judge the value of this compression algorithm.

func main() {
    s := strings.Repeat("TAGGGATTAACCGTTATATATATATAGCCATGGATCGATTATATAGGGATTAACCGTTATATATATATAGCCATGGATCGATTATA", 100)
    c, err := NewCompressedGene(s)
    if err != nil {
        log.Fatalln(err)
    }
    fmt.Printf("String bytes: %d\n", len([]byte(s)))
    fmt.Printf("Compressed bytes: %d\n", len(c.bits.Bytes()))
    d, err := c.Decompress()
    if err != nil {
        log.Fatalln(err)
    }
    fmt.Printf("Matches original gene: %v\n", d == s)
}

go run main.go
String bytes: 8600
Compressed bytes: 2151
true

There we go! We saved quite a bit of memory by encoding the genes to a big int.
By implementing this algorithm in Go, we've learned about Go's big.Int type and applying binary operations to encode data for compression.

For me, this was a fun demonstration of just how interesting computing problems can be, and the ingenious ways in which they can be solved.

I can't wait to discover and implement the rest of the algorithms in the book!

Introduction to Paket for F#

Karanveer Singh — Thu, 09 Jun 2022 20:40:13 +0000

F# has a great dependency management tool called Paket.
It's easy to setup and use, whether you're working with F# projects or F# scripts.

In this blog post, we'll create a solution, and project from the ground up using Paket for dependency management. We'll then convert our F# cli app into a .fsx script.

You can find the completed code at this repository:
https://github.com/karanveersp/paket-guide

Paket Overview

Paket is a dependency management tool similar to npm in node, and pip in python.
It can be used to reference NuGet packages, files on GitHub, or any HTTP accessible file.

With a few cli commands (outlined below), you can easily add and update dependencies for your F# project. While dependencies for F# projects are easy enough to manage using NuGet and IDE features,
managing dependencies for F# scripts is challenging.

That's where I feel Paket really shines, and streamlines the process of acquiring and consuming libraries from .fsx scripts.

You can find the official docs here: https://fsprojects.github.io/Paket/

Initializing a Project

We are going to create a solution and a project to compute and display the size of a given directory in gigabytes.
It's a simple enough program which doesn't really need any external libraries to write.

However, I found a nice library we can use to output colorful text using printfn. The library is located here: https://www.nuget.org/packages/BlackFox.ColoredPrintf/

Basically, we'll output the result in one color, and any errors in red.

The following steps are pretty generic which can be referenced for initializing any Paket-based project.

1 - Create a new directory and initialize a solution.

   mkdir PaketGuide
   cd PaketGuide
   dotnet new sln

2 - Install Paket as a local tool.

   dotnet new tool-manifest
   dotnet tool install paket
   dotnet tool restore

3 - Initialize Paket. This generates a file that will contain references to our dependencies.

   dotnet paket init

4 - Initialize a git repository, and create a .gitignore file with the following entries.

   git init

   # Paket
   .paket/
   paket-files/

5 - Create a F# console project and include it in the solution.

   dotnet new console -lang F# -o DirectorySizeCli
   dotnet sln add --project DirectorySizeCli\DirectorySizeCli.fsproj

Paket Files

There are three important files to be aware of to use Paket.

paket.dependencies - Specifies dependencies and versions for entire codebase. Resides in solution root (same level as .sln file).
paket.references - Specifies a subset of dependencies for a project in a solution. Resides in project root (same level as .fsproj file).
paket.lock - A lock file generated by Paket. It contains all the versions of all transitive dependencies which can be used to get reproducible builds.

The paket.dependencies and paket.references files can be manually edited.
The paket.lock file should be left alone and only edited by Paket.

These three files should be committed into source control.

Commands Cheat Sheet

The following table summarizes the most important commands.

Command	Description
`dotnet paket init`	Generate a new `paket.dependencies` file.
`dotnet paket add`	Add a new dependency. By default, it is added to the solution, and then referenced from a project via a `paket.references` file. Creates a `paket.dependencies` file as well.
`dotnet paket install`	Run after updating `paket.dependencies` file with new package references. Updates lock file, and refreshes all projects that specify paket dependencies to import references.
`dotnet paket update`	Updates references to latest versions of all dependent packages.
`dotnet paket restore`	Takes current `paket.lock` file and updates all projects to reference correction versions of NuGet packages. Should be called by your build script.
`dotnet paket outdated`	List dependencies that have updates.
`dotnet paket generate-load-scripts --framework net6.0`	This command is used to generate include scripts which can be loaded in `.fsx` files or F# interactive.

Directory Size App

We're going to write a simple app to print the size of a given directory.

open System
open System.IO
open System.Linq

/// Converts bytes to gigabytes
let toGb numBytes = (float numBytes) * 1e-9

/// Returns the size of a directory in gigabytes.
let getDirectorySize dirPath =
    DirectoryInfo(dirPath)
        .EnumerateFiles("*", SearchOption.AllDirectories)
        .Sum(fun fi -> fi.Length)
    |> toGb

let dirPath = Environment.GetCommandLineArgs().[1]

try
    dirPath
    |> getDirectorySize
    |> sprintf "The size is: %.3f gb"
    |> printfn "%s"
with
| :? DirectoryNotFoundException as ex -> printfn $"{ex}{ex.StackTrace}"

The two functions at the start do our heavy lifting. We create a simple pipeline from the command line argument to print the directory size.

A try...with block is added to detect invalid directories. If the provided directory isn't found, the exception and stack trace are printed.

It's a useful app but a bit boring! Some color ought to spice it up. Lets use Paket to add the following dependencies to our project.

dotnet paket add BlackFox.ColoredPrintf --version 1.0.5
dotnet paket add FSharp.Core --version 6.0.1

This will add an entries to the paket.dependencies and paket.references files.

You can remove the extra frameworks if you'd like to keep things minimalistic.

The paket.dependencies file should look like this.

source https://api.nuget.org/v3/index.json

storage: none
framework: net6.0
nuget BlackFox.ColoredPrintf 1.0.5
nuget FSharp.Core 6.0.1

Run dotnet restore inside your DirectorySizeCli project directory.
We're ready to dive into some color!

Lets create a new .fs file for our Console module.

If you're using VSCode with the ionide extension as I am, then you can use it to add a new file above Program.fs.

The ColoredPrintf library allows specifying the foreground and background colors using a very concise syntax.

colorprintfn "$red[Hello!]"

The above function will print a red Hello! in the terminal. If you want to change the background, it can be included with a semicolon.

colorprintfn "$red;yellow[Hello!]"

It produces output like the following.

We want some functions that will take a string and output a string in some conventional color that corresponds to the type of message. Include this in Console.fs.

module Console

open BlackFox.ColoredPrintf

let complete = colorprintfn "$magenta[%s]"
let ok = colorprintfn "$green[%s]"
let info = colorprintfn "$cyan[%s]"
let warn = colorprintfn "$yellow[%s]"
let error = colorprintfn "$red[%s]"

Back in Program.fs, open the new Console module, and replace the printfn function with the Console counterparts.

open Console

//...

try
    dirPath
    |> getDirectorySize
    |> sprintf "The size is: %.3f gb"
    |> Console.info
with
| :? DirectoryNotFoundException as ex -> Console.error $"{ex}{ex.StackTrace}"

Run the code using a directory of your choosing as a command line argument.

dotnet run C:\users\karan\csharp

Now that cyan looks sweet!

Lets run a test for the exception case. What a glorious wall of red...

Dependencies in Scripts

Managing dependencies for F# and C# projects is straightforward using the above commands.
But what if you write some F# scripts (.fsx files) which need to use external packages?
Those can be directly invoked using dotnet fsi myscript.fsx and are often sufficient for simple tasks that don't need the full project structure.

Paket offers a command to generate F# and C# include scripts that reference installed packages. These include scripts can be used in F# Interactive (FSI) or .fsx files to load packages.

When the dotnet paket generate-load-scripts command is run, it creates .fsx files under .paket/load/.

The generated load scripts reference DLLs from installed packages using #r preprocessing directives.
Those are tedious to write, and Paket helps us out here.

The dotnet paket generate-load-scripts command only works after packages have been restored. But we don't want to keep re-running this command whenever we add a new package.

To generate load scripts when installing packages, place generate_load_scripts: true at the top of the paket.dependencies file.

generate_load_scripts: true
source https://api.nuget.org/v3/index.json

storage: none
framework: net6.0
nuget BlackFox.ColoredPrintf 1.0.5
nuget FSharp.Core 6.0.1

In a .fsx file you can then reference the external package.

#load @".paket/load/BlackFox.ColoredPrintf.fsx"

open BlackFox.ColoredPrintf

Lets create two files in our solution root, Console.fsx and DirSize.fsx.

Add the following into Console.fsx.

#load @".paket/load/BlackFox.ColoredPrintf.fsx"

module Console =
    open BlackFox.ColoredPrintf

    let complete = colorprintfn "$magenta[%s]"
    let ok = colorprintfn "$green[%s]"
    let info = colorprintfn "$cyan[%s]"
    let warn = colorprintfn "$yellow[%s]"
    let error = colorprintfn "$red[%s]"

DirSize.fsx loads this Console.fsx script. Note that our command line arg index is incremented by 1.
This is because FSI script arguments contain the fsi program itself, and the script as the first two arguments.
The command line arg is the third argument, so index 2.

Example: fsi script.fsx arg1 arg2...

#load "Console.fsx"

open Console
open System
open System.IO
open System.Linq


/// Converts bytes to gigabytes
let toGb numBytes = (float numBytes) * 1e-9

/// Returns the size of a directory in gigabytes.
let getDirectorySize dirPath =
    DirectoryInfo(dirPath)
        .EnumerateFiles("*", SearchOption.AllDirectories)
        .Sum(fun fi -> fi.Length)
    |> toGb

let dirPath = Environment.GetCommandLineArgs().[2]

try
    dirPath
    |> getDirectorySize
    |> sprintf "The size is: %.3f gb"
    |> Console.info
with
| :? DirectoryNotFoundException as ex -> Console.error $"{ex}{ex.StackTrace}"

You can run the script using dotnet fsi to make sure the output is the same as the CLI app.

dotnet fsi DirSize.fsx C:\users\karan\csharp

Conclusion

We've just built a project using Paket from scratch, and used a script to load a dependency.

I know that when I got started using F# scripts, importing libraries was incredibly awkward. Using pip with Python was just smoother and easier, so I just gave up. Once I discovered Paket, I was able to take my F# scripts as far as any Python script.

This was a basic example using NuGet, but I'm eager to explore the ability to reference files on GitHub and how easy that makes sharing libraries. Great topic for a future post.

I hope that this blog post helps you become confident with using Paket and F#.

Happy scripting!