Resources for learning a Functional Programing Language

Elm
https://guide.elm-lang.org/

OCaml
https://dev.realworldocaml.org/

Haskell
http://learnyouahaskell.com/chapters

https://www.youtube.com/watch?v=iSmkqocn0oQ what is your guys think of this @frectonz

The video shows a bunch of language designers discussing their craft and talking about the tradeoffs various languages make.

The video is not meant to be a damnation of Haskell despite the click-bait title "Haskell is useless".

The definition of "use" Simon is talking about here, is actually being able to perform side effects, which one can define as modifying state outside of your program or depending on state outside your program.

Examples of side effects are IO operations, like
  - Reading and writing to disk
  - Opening network connections and making requests
and also things like random number generation, which make functions non deterministic.

Haskell is considered "useless" in this video because it doesn't allow you to make this side effect operations, because it's trying to be fully deterministic. The realization the peeps are talking about is that actually side effects are the whole point people write programs for, like you wanna make some request to server and show the response or you wanna read data from a file and do some computation on it, and Haskell by disallowing those things, it has made itself "useless"

But that's not really right in the current situation, because Haskell does allow you to do side effects but they do have their own structure of how one handles side effects which are called monads.

And btw Simon is one of the people that actually created Haskell.

And another note
Rust is actually the result of C/C++ folks trying to move closer to the Nirvana land he described in the video.

PS: I am not really a haskell guy, the last time I wrote haskell, is probably more than 2 years ago. I just thought I would share my views since you mentioned me.

I completely agree.

[the tweet]

Capitalism is the only economic system that ensures human progress. It is one of the true super powers of humanity.

It holds societies together.
It even aligns nations to prosper together.

It is magnificent.

Notes

1. Don't use strings.Split() to split white space, instead use strings.Fields(), read more about it in the golang docs.
2. If you are iterating over an array while you are modifying it, do not use ranges, just do a regular for loop and use indexes.

There has been a sudden uptake in subscribers of this channel, I think it's the similar channels thing that's causing it.

Here is another tech telegram channel for yall.
I think he mainly does ios stuff,
Checkout his channel

@storyOfXcode

In my experience golang is a pretty meh language but no variable shadowing thing annoys me a lot.

Go needs to implement variable shadowing.

While you are programming you have some mental model of the data you're working on, let's say it's a list of numbers and you wanna sum them up.

Ok so the flow of the program is

1. You ask the user to provide the numbers. Let's say that the numbers are separated by commas.

You store the numbers in a variable you called nums

nums := getInput()

This will be holding our numbers as a comma separated string.

getInput is not a function in go, I just forgot how you read from stdin in go.

2. You split the input you got on commas, to extract the individual numbers you got.

Here's where things go wrong in a programming language that doesn't have variable shadowing. Ideally you would be able to do this

nums := getInput()
nums := strings.Split(nums, ",")

Instead you have to do this

nums := getInput()
numsSplit := strings.Split(nums, ",")

So what's the big deal, notice when I was talking about the "numbers" I was calling them "numbers" all the time, no matter what kind of data type they happen to be at the current stage. Notice how they were transformed from a comma separated string, into an array of strings, but we would still refer to them as "numbers".

That's why variable names are helpful, they name the higher order way we think about the data.

If go had variable shadowing we would still be able to call the array of strings we got after splitting it, nums and we wouldn't have needed to come up with the name numsSplit.

There is a reason why I am using the word "shadowing" here. You might be asking why not just re-assign the variable, like what we do in dynamic languages. That's not what I am talking about, re-assigning the variable would only change the data it's holding on to, shadowing would let you change both the data and type.

In vscode terms when I hover on nums from the first step, I should see string, in the second step nums would be []string.

3. At this point you would iterate over the nums and convert them from a string to an int.

With variable shadowing, you would still call this nums but now it would be holding on to a []int (an array of ints).

Without variable shadowing, you would be forced to come up with a new variable name like numsArray or even numsAsInts or sth like that.

4. In the last step you would just sum up numbers.

It's crazy how much we unironically say

"Constant Variable"

😂

"You can't tell kids to follow their dreams when their dreams suck." 😂

Only manged to do part 1 today.
I couldn't get part 2 to work, maybe i will try it again in the weekends or sth.

I did today's puzzle in Rust.

[Part 1 Solution] [Unfinished Part 2 Solution]