speakezai.bsky.social
Intelligent, Resilient Platform Services for the modern technology landscape #dotnet #fsharp #ai #ml #graph #vector #postgres #linux #iot #cloud #datasecurity #ethicalOSS #ethicalAI #resiliency #sustainability
205 posts
232 followers
109 following
Regular Contributor
Active Commenter
comment in response to
post
Great write-up! I also really enjoyed this quip from Mads Torgersen - this link drops right into the interesting part... 💽 youtu.be/CLKZ7ZgVido?...
comment in response to
post
Middle management will either have to get with the program or risk being written out of the script.
comment in response to
post
It depends on the model, and there's no magic cure. The point is that in the fullness of time, certain strong suits of well-made coding models will yield better testing and refactoring. It's more of a factor of velocity with value rather than simply succumbing to the whims of glory chasers.
comment in response to
post
*That* is the BS I can't wait for #AI to dismiss - glory-chasing middle-managers making hay for 🩹 "fixes" toward their next promotion while leaving landmines 💥 in their wake. 💣
comment in response to
post
Yeah but that's just "job security" 😉
comment in response to
post
Insert "Men will literally spend years doing ... instead of going to therapy" joke here.
comment in response to
post
And while we're here - it's worth noting that C# devs will spend months bike shedding some semblance of F#-ness into C# - look at language-ext and the "home-grown" borrowings.
No one ever bothered to ask if it would simply be more efficient to learn F# enough to use those features with interop. 💡
comment in response to
post
As a point of order we should say we were dead-set against using React until recently as 1) it's not *actually* a reactive framework, and 2) it's a total pig to deal with in deploying to the desktop. But there *is* something to be said for dealing within the confines of a well-worn pattern. So YMMV.
comment in response to
post
I think he meant "comfortable enough" 😜 [poke poke]
comment in response to
post
Or... *or* use a language ecosystem that has the versatility of first-principle fidelity blended nicely with grounded utility... from domain modeling to driving GPUs #fsharp 😉
comment in response to
post
FWIW - middle management could be the first to be replaced by #AI - if all they do is walk from meeting to meeting with an Excel sheet and ask "is it done yet?".
comment in response to
post
We'll wait four years like Microsoft waited 4 years to support F# markdown in Teams.
comment in response to
post
Also worth considering brandewinder.com/2025/01/08/c...
comment in response to
post
There are some pretty huge blind spots in that doc, namely the influence of F# on reactive extensions (Rx) that proliferated to nearly every language system on the planet. (p 50) fsharp.org/history/hopl...
comment in response to
post
Our position is that it's "the price of freedom" in being out from under the yoke of a monopolistic entity.
comment in response to
post
That makes more sense. Some of this dovetail into observations around MSFT making everything about Azure and everything else left to it's own devices. Fragmentation is a natural result. @sergeytihon.com helps tremendously but that too is a symptom of fragmentation. 😶🌫️🤗
comment in response to
post
None of what you wrote makes any objective sense. The #rust ecosystem is awash with divergent choices. #csharp has been feeding its new feature frenzy by cannibalizing #fsharp (poorly) for years. People miss that well-founded early choices are better for software than control later in lifecycle. 🤔
comment in response to
post
comment in response to
post
You can throw up your hands at the first point of friction and stop, or you can let natural curiosity do some work and find answers everywhere. discord.gg/R6n7c54
comment in response to
post
We think that short answer is "sort of". 😉 While TorchSharp is the back end there are things going on "under the hood" with auto-differentiation (AD) probabilistic programming capabilities that aren't in TorchSharp. This is the seminal research that inspired DiffSharp. www.jmlr.org/papers/volum...
comment in response to
post
Please don't mention reflection. Then all the C# devs will show up... 🤠
comment in response to
post
💯 spot on... And to add to that - the Jensen Huang "scare" quote implying "don't learn to program" (paraphrasing) he was saying in the *full* quote to focus on hard sciences/engineering instead.
We emphasize that F# is very well suited to the world of GBNF grammars and AST model training for code.
comment in response to
post
Our own theory is consistent with this - there's a sliding scale that as the language/ecosystem demands deeper understanding, it sheds casual users. That's 🆗
There will be other bursts of interest, and we're sure that the "AI" hype train will be part of the next wave of look-ee-loos. 👀
comment in response to
post
The early history of F# PDF talked about this a bit. Really fascinating! fsharp.org/history/hopl...
comment in response to
post
I see that question and R and dplyr jump to mind - but not sure if that's what you're looking for...
comment in response to
post
What about BLASForge? ⚒️🔥
comment in response to
post
That would be amazing (and yes a more jazzy name is probably the first PR 😇 ). Our original plan is to stay pretty close to in-place code for our internal POCs. That said... finding a new repo home will probably require someone who can fork into that "landing" space.
comment in response to
post
Check out pp 25-30 of this doc where all three of those tech ecosystems were interacting much more than today... fsharp.org/history/hopl...
comment in response to
post
Much of our work is exploratory - and local-first by design - with VPS deployment as an option. One project digs into WikiSQL (a Salesforce project, of all things) to transform training data into FROM-first query patterns and eventually supporting SQL-2023 style Cypher queries (targeting DuckPGQ)
comment in response to
post
BuffSharp would be a great name! 🦾
Honestly - we're toying with the idea of building a new backend for LlamaSharp to interface with Tenstorrent hardware and the *natural* next Q was "should we do the same with DiffSharp?". So perhaps that will be a natural cleave point for forking and renaming.
comment in response to
post
...reason other than he's already worked for to massively anti-competitive companies (Apple and Google) and for some reason developed a blind spot for looking into the research work sponsored by a third... even though he goes to some length to heap praise on OCaml in those interviews. 😇🫢
comment in response to
post
We passed this around the virtual room when it landed, and now enjoying reading it all over again! There's been a recent spate of online interviews with Chris Lattner on his work with MLIR and Mojo and can't help but think he's "banging his shin against the coffee table" over and again for little
comment in response to
post
Our view in only from the outside perspective - of seeing WalMart attempt to acquire its way into e-commerce relevancy through many companies like Jet and squandering them similarly. It would be interesting to know more about the inside story if only as a cautionary tale.
comment in response to
post
This is a great article! Our take is that F# came close to an inflection point with Jet, but was *stunted* by the WalMart acquisition. Once that opportunity was squandered it took the wind out of #fsharp 's sails. But we also believe that "AI" will be its next great opportunity to shine. ✨
comment in response to
post
Here's another higher-level discussion that I also enjoyed. MLIR is a really interesting project, BTW. It has some really interesting potential to be that translation layer to put *any* high-level code onto custom hardware. youtu.be/ovYbgbrQ-v8?...
comment in response to
post
This is 💯 the correct perspective - and also why game developers get lost in their own world-building. They don't care about anyone but *they themselves* being able to read their own coding "style". I can spot a former game coder in a heartbeat with obtuse personal prefs polluting a code base.
comment in response to
post
Pay attention to all that Chris Lattner has to do to work around Python, solving the wrong problem at the wrong layer of abstraction. He pretends now that they planned on writing their own high-level language, but originally they were just going to use Python over MLIR/LLVM youtu.be/JRcXUuQYR90?...
comment in response to
post
Typical game programmer - a wrong argument to suit their myopia. Python is legitimately a cancer on Machine Learning and "AI" as is popular today - but not because of space-scoped code representation. Back in the late 80s I wrote "one line" C applications as an exercise in uni. Not good for humans.