brandonspark

but still along the same lines as "safer". the stresses are different, "safer" has the stress as "SAY-fer" and "secure" has the stress as "sih-KYOOR". the latter sounds more similar (and rhymes better) with "more", the originator of the phrase "less is more"

missed opportunity for "less is secure"

I see. This is indeed the in-depth breakdown I was looking for, thank you.

I was hoping this article would be a little more concrete, but it seems that it largely is talking about the takeaways about functional programming in a philosophical, effort-in vs value-out kind of way. This is valuable, but for people unfamiliar with functional programming I'm not sure that it gives much context for understanding.

I agree with the high-level, though. I find that people (with respect to programming languages) focus far too much on the specific, nitpicky details (whether I use the `let` keyword, whether I have explicit type annotations or type inference). I find the global, project-level benefits to be far more tangible.

"Opengrep"? But `grep` is already free...

thank you!

There's no reason this couldn't be done. Indeed, in OCaml (which I am more familiar with), you could easily define:

```ocaml

type 'a nonempty = Single of 'a | Cons of 'a * 'a nonempty

```

This would be the type of lists that contain one or more elements of the type parameter.

I think it's just convention that typically, when we talk about lists, we are interested in the empty case as well. Finding "all X that satisfy P in Y", as a general computational problem, is _very_ common (consider: filtering a list, querying for a predicate in a collection, finding sequences of moves in a search space), and generally could result in an empty list as a possible output.

In a non-practical sense, if you want the type theory, another reason is you can think of `[a]` as the free monoid on the collection of `a`. In other words, strings of elements of `a`, joined via concatenation. This monoid requires a unit, which is the empty list.

This one makes sense to me, since lists are way more canonically used than arrays in functional languages. I rarely find myself constructing array literals -- I'm far more likely to simply convert from a list.

Though, I agree the semicolon delimiting is regrettable.

Haha, maybe. I'm not looking to earn any money from this, though. Time is the bigger constraint in my life at the moment.

If you get to around lecture 9, a classic example I always tell people to start with is a calculator!

For instance, here's the SML code for it:

``` datatype exp =

    Num of int

  | Plus of exp * exp

  | Minus of exp * exp

  | Times of exp * exp

  | Div of exp * exp

```

Implement the function `eval : exp -> int`, which evaluates the expression as best as it can. Assume no division by zero.

Extra credit: Can you implement `eval' : exp -> int option`, that returns `SOME n` if the expression evaluates, and `NONE` if it divides by zero?