mdm12
mdm12 on Hacker News
One option is dependent pairs, where one value of the pair (in this example) would be the length of the array and the other value is a type which depends on that same value (such as Vector n T instead of List T).
Type-Driven Development with Idris[1] is a great introduction for dependently typed languages and covers methods such as these if you're interested (and Edwin Brady is a great teacher).
[1] https://www.manning.com/books/type-driven-development-with-i...
We're not done building the boring stuff or solving the hard problems either. One is, well, boring and the other is...hard. Easy enough to proxy out prompts to OpenAI for your next funding round, though.
Other languages that make heavy usage of non-ASCII Unicode characters (such as Lean) often have tooling support such that one can type '\' along with some combination of ASCII characters to generate characters like '≈', '≠' and 'ƒ'. Along with searchable documentation for the whole mapping of shorthand codes to the mapped Unicode values, of course.
Code is read more than written, so I have grown to appreciate programming languages that lean into non-ASCII characters for semantic clarity :)
In event sourced systems, you project the event stream into read models, of which there can be many (relational, time series, etc.) If you're familiar with functional programming, it is essentially a fold operation over the stream of events into a single state.
Having worked with event sourced systems in the past, there are benefits in having a persisted explicit event history, but there is much added complexity (how do those read models actually get generated? how do you version the model? do you have snapshots of your read models?). In my experience, the additional complexity was not worth it for most contexts in which the pattern was applied...
Enjoy your F# journey! I have yet to find a more ergonomic, practical language for daily use :)
It may be sacrilege to say this, but I have adopted Retool in my organization for the purposes of quick-and-dirty internal apps that are essentially thin GUIs around internal data stores. It has worked out well for us and even stodgy backend engineers like myself can be productive with it.
Congratulations on the publication! As a dabbler in strictly typed functional programming languages like Scala and F#, I have always been curious about proof-oriented languages such as Coq or Agda, but found it difficult to justify the time investment. Lean seems to position itself as a theorem proving language that also supports general-purpose programs. Looking forward to digging into your book!
We already have students using AI to generate answers for homework and teachers using automation to grade it. I would say we are already there.
I have seen this process described elsewhere as 'reverse system design', and it is my preferred approach to evaluating senior candidates as well.
Sounds like Gleam[0] would be up your alley :) As an F# guy myself, I am hoping it pans out, as I miss the BEAM platform!
[0] https://gleam.run/
Posted by
mdm12 on Saturday February 11, 2023 @06:54AM
from the cs.brown.edu dept.
My understanding is that the 'linear' terminology derives from the field of Linear Logic[1]. But, I am by no means an expert on theoretical computer science etymology!
[1] https://en.wikipedia.org/wiki/Linear_logic
In my perusals into the Haskell ecosystem, discovering Hoogle[1] was definitely a revelation on the power of a strongly-typed language. Sometimes, you know the _shape_ of the thing you are looking for, but not the name. The ability to search a repository of packages for all functions conforming to a certain type signature (e.g., (a -> Bool) -> [a] -> [a]) is a superpower.
[1] https://hoogle.haskell.org/
Not a dumb question at all!
The short answer is that a category also satisfies two rules: every object has an arrow to itself (identity) and if there are two arrows (a->b) and (b->c) there is an arrow (a->c) (associativity).
Other abstractions such as functors (mappings between categories) are built upon this relatively simple foundation. You can also think about categories of categories (they can be considered an object, after all!), and so on and so forth.
Some complain about the generality of Category Theory ('It is a theory about everything and nothing!'), but its generality makes it compelling for some for study.
F# 6.0 added the 'task' computation expression, which is much more performant than the F# 'async' methods. It also makes interop with C# projects and libraries simpler, as is uses the same mechanism that C#'s async/await does. I have used it in production workflows without major performance issues FWIW.
Good on you for taking the road less traveled! I don't have the guts to pursue 'real' entrepreneurship like yourself, but I appreciate those who do!
Now if we can only convince VCs that 'web3' really means 'we host the servers again' and not that other nonsense.
> In Q2 alone, we added approximately 10,000 Googlers...
Maybe it is okay to slow hiring if 'normal' is ten thousand new hires in three months
It was the only data point I could find, but fair point. I amended my comment for pedantic's sake :)
Yes, this trivialization of modern software development is annoying. Yes, we are modern-day plumbers. Turns out, plumbing can be hard.
And save as much as you possibly can. Nothing beats gaining financial independence to avoid employer dependence.
As I like to say, design patterns for strongly-typed functional programming languages is essentially category theory. What matters, from a practical point of view, is that you know how to effectively use such patterns when decomposing systems to smaller parts (aka, functions) and composing them (monads et. al.).
This was unfortunate timing given the greater macroeconomic environment and other BNPL players getting taken to the woodshed. No surprise, then, that Affirm sees yet another hit (-4% today) down to $24 from their $176 highs...
Healthcare is another safe bet.
I am sure you have heard this before, but F# sounds like it would be right up your alley. It has sane defaults (non-nullability, algebraic data types, etc.) while still targeting the CLR, enabling the usage of any normal C#/.NET library to be used within your application. Granted, there's _some_ friction going between C# and F#, but that is a small price to pay (IMO).
Fundamentals matter again. It would be more cathartic if my portfolio wasn't down as much as it was!