de_keyboard

> The more ways there are to write in a language, the harder it gets to read the code of someone else using a different style guide, or with different preferences, than you. This matters a whole lot in a language so completely dependent on 3rd party libraries as JS is.

Hmmm, kinda.

The pipe operator enables more readable code, so whilst I agree there would be more ways to do things, the average code readability could well go up.

F# pipes are much less of a departure from plain-old JavaScript than Hack-pipes.

In most western countries it is legal. I'm not sure it should be, given recent technological advances.

Nice resource. It would be good to have cheat-sheets designed specifically for JS and Python developers.

> It reminds me a bit of how in Elm you just suck it up and write the JSON en-/decoders by hand. Annoying at first, but then you get super obvious and maintainable code out of it, which is quite a joy.

The F# take on Elm coders (Thoth.Json) can use reflection to generate them automatically. This is really useful at the prototyping stage.

I think this depends on the relative weights you assign to learning a new language and program correctness.

It's the combination of features which is killer. I don't know of another language that offers all of these:

- Expression orientated

- Lightweight syntax

- Emphasis on immutable data and pure functions

- do-notation (in F# these are called Computation Expressions)

- Type-safety without too many annotations (global type-inference)

- Mainstream ecosystem of libraries (in this case .NET)

- Compile to JavaScript

> The serializers, http servers, etc. are probably not worth the squeeze to force into a functional domain.

I used to think the same, but having now tried FP-style libraries for serializers (Thoth.Json) and HTTP servers (Suave), I think they are far superior to imperative or OOP alternatives. The ability to design these things in a declarative style makes the code much more robust and easier to read.

That City A.M. link mentions Brexit once and negatively - that London is still a good place for start-ups despite Brexit. I wouldn't call that the opposite conclusion.

PoW is the only proof mechanism that has seen real world use for a significant length of time.

This looks like F# but with a noisier syntax. Perhaps it will be more familiar feeling to JS devs?

Looks like a tidy language though, it's just unclear to me what it offers over more established alternatives.

If pot were legal I expect most people would consume it via drinks and edibles. The main disadvantage of these products is controlling dose, and those go away with a well regulated market.

I mean run-time checks that the user must implement.

For example, in JS you might put these all over your code-base:

    if (typeof x !== 'string') {
      throw Error('Expected a string');
    }

I love this style of programming but it does not work well in Python, the language just isn't built for it. TCO is one limitation. Another is that performant Python code sends large chunks of work to native libraries and recursion inside of Python functions is pretty much the opposite of that.

Pattern matching can be done on run-time properties, see F# Active Patterns

Flow types (for JavaScript) can be complied into run-time type-checks.

Properly statically typed languages do not need run-time checks because the compiled code is already proven to be valid by the type-checker.

Microsoft managed to sufficiently standardize / commoditize the hardware running Windows to the point where supporting old devices was fairly easy. Android devices have more in the firmware.

The companies pushing them want to normalize having our every moment captured, logged and analyzed - on their platform.

I think a little bit of OOP-related messiness is easily worth it to be part of a mainstream ecosystem.

F# doesn't have functors but SML and OCaml do. F# has Computation Expressions which (AFAIK) SML does not have; OCaml has PPX extensions. F# has access to .NET ecosstem, JS ecosystem and multi-core. OCaml has easy binding to C but multi-core hasn't quite landed yet. There are a few competing JS compilers for OCaml.

F# is the most mainstream of the 3. If you can live without the fancier type-system features (trust me, you probably can!) it's the easiest ride.

Only when using the government wallet though. I imagine people will have multiple, just like how we already have multiple debit cards, credit cards, online payment apps...

I've always thought the "progressive" position was this:

1. Genetics, upbringing and culture all matter

2. Diversity within an ethnic group is extremely large - often similar magnitude to diversity between ethnic groups

3. Therefore, to judge someone on their ethnic average will be inaccurate at best, offensive at worst

I think that this position has been misconstrued by pop-right / alt-right figures to create a false narrative in the culture wars.

Meson is a big improvement over CMake to be sure, but it doesn't solve the fundamental issues. Same paradigm, nicer syntax.

You must understand the semantics of the monad you are operating in, but both cases are still handled in the do-notation version.

Option types require do-notation / computation expressions to be practical in my view. Otherwise you get the pyramid of doom!

    match x with
    | Some y -> 
      match y.Foo with
      | Some z -> 
        match z.Bar with
        | Some w -> printfn $"{w.Qux}"
        | None -> ()
      | None -> ()
    | None -> ()

Compared to...

    option {
      let! y = x
      let! z = y.Foo
      let! w = z.Bar

      printfn $"{w.Qux}"
    }

Funny quirk in Java, the compiler checks that calls to `opt.get()` occur inside an `opt.isPresent()` branch!

    if (opt.isPresent()) {
      println(opt.get());
    }

I never use Netflix for discovery because the median quality is so low.

Here's my thinking:

1. There is a lot of complexity in building, deploying and maintaining software

2. There is a lot of complexity in understanding a domain and figuring out precise business logic

Often, (1) and (2) are known by different people, from technology and business functions. There is a communication overhead.

We can eliminate the communication overhead if (1) and (2) are known by the same person. But learning to code is hard... so if we make the programming easier (or even "no code") then people who know (2) can easily pick up (1)!

Ultimately though, I'm not convinced that (1) will ever be easy...

One example in the UK: https://www.bikeisbest.com/partners

Expensive but worth it. Brompton designs are far better than the alternatives. They hold their value pretty well too, if it turns out you don't like it.

If you go on big rides in the middle of nowhere then you can't really afford to have components fail on you. I always take a few tools, small parts etc. but if something like a pedal or stem fails I'm walking a long way home. Quality components are made of different materials (e.g. higher grades of Alu) and manufactured using better processes (e.g. cold forging, not stamped) so they are stronger and lighter. I also don't pick the very lightest components since I need durability.

Aside from that, the joy of riding is what gets me out. Many cyclists choose tough hill climbs for added fitness gains and challenge. There is a good kind of difficulty (steep grade somewhere picturesque) and a bad kind (unresponsive bike that doesn't roll well)