It's a force multiplier when you have a small team of strong developers.
248 karma · joined November 3, 2022
It's a force multiplier when you have a small team of strong developers.
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.
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...
> 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?
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.
> You can still make it work by adding it to the prototype
This is exactly what we want to avoid!
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.The F# version of the proposal was probably the simplest choice.
Personally, I think that FP could be a great fit, but we first need to come up with architectures that solve real game development problems. We have to do this with small scale experiments first (game jams are perfect for this) and then scale up only if they succeed.
This project is exactly that - kudos to the author.
A Pythonic implementation would use loops and mutation.
We don't really know where AI will be useful in a business sense yet (the apps with users are losing money) but a good bet is that incumbent platforms stand to benefit the most once these uses are discovered. What Meta is doing is making it easier for other orgs to find those use-cases (and take on the risk) whilst keeping the ability to jump in and capitalize on it when it materializes.
As for X-Risk? I don't think any of the big tech leadsership actually beleive in that. I also think that deep down a lot of the AI safety crowd love solving hard problems and collecting stock options.
On cost, the AI hype raises Met's valuation by more than the cost of engineers and server farms.
I could see Microsoft keeping things open too. So far they have done OK with GitHub and NPM.
Here is a hello world server that fetches all of its own dependencies - just 3 lines!
#r "nuget: Suave, 2.6.2"
open Suave
startWebServer defaultConfig (Successful.OK "Hello World!") $$$$$$ income on $$$ costs
to $$$ income on $ costs