tinyspacewizard

8 か月前議論

Start-ups should strongly consider F#.

It's a force multiplier when you have a small team of strong developers.

9 か月前議論

What should we use instead?

9 か月前議論

> Why two cloud providers? Initially we used only DigitalOcean, but a data intensive SaaS like tap needs a lot of cloud resources and AWS have a generous $1,000 credit package for self-funded startups.

So some Kubernetes experts migrated to AWS for $1k in credits. This is madness. That's weeks of migration work to save the equivalent of a day of contracting.

tinyspacewizard

9 か月前議論

> Of course you can inspect it: open the source code you wrote and read it. Also, don't write the code you don't want to be executed?

This is not what they meant by inspection.

What they mean is that you can write a function, in Haskell, that given a value in the DSL, it returns the list of all requests it will perform on execution.

This can be useful for tests, security, caching, performance, debugging...

tinyspacewizard

9 か月前議論

This seems like a cool article, but it isn't readable without Haskell background knowledge.

> For an intuition why this is true, consider that the constant functor Const r has an Applicative instance whenever r is a monoid, because pure stores a mempty value and (<*>) combines the held values with (<>). For a fun exercise, implement runAp_ in terms of runAp and Const.

Really?

tinyspacewizard

9 か月前議論

Weird feeling knowing that an ecommerce / wallet store has employees with more advanced programming knowledge than most financial institutions.

tinyspacewizard

9 か月前議論

1. Wrapping is more code than using a built-in pipe operator

2. There is a run-time overhead to wrapping

IMO a design goal of programming langauges should be for the most readable code to also be the most performant.

Language features tend to be controversial until they are mainstream.

tinyspacewizard

9 か月前議論

There is more than one proposal; the F#-style one doesn't have the (weird) placeholder syntax.

> You can still make it work by adding it to the prototype

This is exactly what we want to avoid!

tinyspacewizard

9 か月前議論

Pipes are great where you want to chain several operations together. Piping is very common in statically typed functional langauges, where there are lots of different types in play.

Sequences are a common example.

So this:

    xs.map(x => x * 2).filter(x => x > 4).sorted().take(5)

In pipes this might look like:

    xs |> map(x => x * 2) |> filter(x => x > 4) |> sorted() |> take(5)

In functional languages (of the ML variety), convention is to put each operation on its own line:

    xs 
    |> map(x => x * 2) 
    |> filter(x => x > 4) 
    |> sorted() 
    |> take(5)

Note this makes for really nice diffs with the standard Git diff tool!

But why is this better?

Well, suppose the operation you want is not implemented as a method on `xs`. For a long time JavaScript did not offer `flatMap` on arrays.

You'll need to add it somehow, such as on the prototype (nasty) or by wrapping `xs` in another type (overhead, verbose).

With the pipe operator, each operation is just a plain-ol function.

This:

    xs |> f

Is syntactic sugar for:

    f(xs)

This allows us to "extend" `xs` in a manner that can be compiled with zero run-time overhead.

tinyspacewizard

9 か月前議論

Sad that the pipe operator proposal seems to have stalled.

The F# version of the proposal was probably the simplest choice.

tinyspacewizard

2 年前議論

Python is really bad at recursion (part of why it's not appropriate for functional programming), so perhaps an unfair benchmark?

A Pythonic implementation would use loops and mutation.

tinyspacewizard

投稿

Tying the Knot

Zippers: Making Functional "Updates" Efficient (2010)

コメント