1,047 karma · joined April 23, 2016
The author begins by replacing a language feature, the . operator, with a pipe() function. After that they swap out exceptions for Result, null/undefined for Maybe, Promise with Task, and the final code ends up becoming an obfuscated mess of wrapper functions and custom control flow for what you could write as:
fetch(urlForData)
.then(data => data.json())
.then((notifications) =>
notifications.map((notification) => ({
...notification,
readableDate: new Date(notification.date * 1000).toGMTString(),
message: notification.message.replace(/</g, '<'),
sender: `https://example.com/users/${notification.username}`,
source: `https://example.com/${notification.sourceType}/${notification.sourceId}`,
icon: `https://example.com/assets/icons/${notification.sourceType}-small.svg`,
})
)
.catch((err) => { console.log(err); return fallback });
This post has nothing to do with functional programming, this is a poor monad tutorial.
Probably a lot. Most of the operations on basic types like strings rely on C# methods rather than being implemented in the corresponding module like in OCaml (e.g. `String.split_on_char ' ' "a b c"` in OCaml vs `"a b c".Split(' ')` in F#). Type annotations on function parameters are required much more often because the compiler can't infer object types from a method call. Obviously you'll have very different libraries for doing the same things, and you'll be interacting with C# libraries a lot. Some language features like objects or binding operators exist in both languages but have very different syntax and differing semantics, and others like local opens and functors just don't exist in F#. F# also defaults to a "light" indentation-based syntax and I think the old OCaml-like syntax is either unsupported or hidden behind a compiler directive, and you'll probably want to rename identifiers from snake_case to camelCase.
> how good is the language support experience in vscode?
There's two competing LSP implementations for F#. Ionide works, but it's slow and it crashes and reports old errors for code you've just rewritten very often in my experience. fsharp-language-server seems to be a bit better in some aspects, but I haven't ever gotten it to work in VS Code.
> Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
If we apply this law backwards, microservices reflect an organizational structure with many teams working on different things so they'd make more sense in that context rather than within a small team.
On that note: I read The Soul of a New Machine a while ago, which is about a team of engineers designing a computer with a new architecture at the end of the 70s, and while it didn't go into the specifics of how the CPU was implemented it mentioned features such as different layers of cache between the CPU and the RAM, out-of-order execution, instruction prefetching and branch prediction. You'd be surprised at how many things in computers have already been around since the 60s.
https://github.com/steinuil/SatouinDp/blob/master/DisplayDev...
One thing I never figured out was how to map the displays you get from EnumDisplayDevices to the names you see in the display settings, or how to list them in a consistent order.
Eye contact is very important in small ensembles especially when there isn't a director to synchronize breathing and cues with other voices or instruments who share your part, though in a lot of cases you can go by ear just listening to the other parts.
In this setting, when there is a director their basic role in a performance is to keep the tempo regular and direct rallentando and accelerando, and to remind you of cues, dynamics, and other things they might've discussed during rehearsals. During rehearsals their role is also to set the mood of a piece of music and get everybody to match it, because obviously if all the musicians have a different idea of how it should sound and feel it's not gonna be a very good performance, and in a concert they can reinforce that mood through body language.
In larger choir or orchestra's the director's role to keep the tempo becomes extremely important because you just can't rely on what you hear from the section that's sitting on the other side of the church or of the concert hall; by the time the sound gets to your ears there'll be a few ms of delay and you'll already be primed for starting late, so you have to maintain eye contact or have a "leader" in your section who will do it and to whom you'll refer for cues.
Maybe this could be solved by a hooks "standard library" that provides generally useful hooks like useTimeout and a useMemo that is actually stable as mentioned in @purplerabbit's comment.
I'm curious about one thing though: unless you're passing a parameter that introduces an additional effect F into the function, what's the point of making it generic over the effect set? In a language with typed effects, all effects that could be performed by a function would already be known, so letting a unit function `fn get_user<F>() ->{F} T` where i.e. `F: DiagnosticData -> ()` decide which instance of an effect that takes a DiagnosticData and yields unit, as opposed to `fn get_user<F>(g: () ->{F} ()) ->{F} User` where the effect is clearly introduced by `g`, seems a bit overkill to me.
EJS is not "anything", imo. I'd probably feel at home with it since I've used a bit of ERB, but despite how simple it looks there's some gotchas, syntax highlighting is always going to be an issue, and making those widgets modular is going to require at least some conventions to be used, and at worst some helpers that will eventually start looking like a framework (of course this depends on the scope of the project). Also, bundle size for EJS is not mentioned.
That's precisely what ML is. Though to be fair, interviewing done by real humans is also largely based on cargo culting.
I'm more or less using Alexis King's definition of "parsing" here, as described in this post: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...