On the .Net VM you’re describing F#, mostly by virtue of being based on OCaml.
Contrasted with TypeScript and C#, F# is smaller, more expressive, stricter, with mature pattern matching and type resolution baked in from the ground up. F# was years ahead of the major languages on what are increasingly looking like ‘the basics’ around ADTs and immutability in modern distributed computing. OCaml and F# capture the linguistic high points of VB, Delphi, and C# with a broad spectrum of OOP(-lite) approaches, and have led those languages by decades on functional constructs that result in meaningfully tighter code. With the benefit of hindsight some approaches clearly map better to cloud computing and system verification.
F# also sits parallel to lots of living C#, objectively we see ‘less is more’. Less code per line, fewer lines per solution, terser and more LLM-efficient language. Error rates and refactoring costs are also meaningfully better IME, but harder to quantify in general terms.
Microsoft’s market position is reliant on Linux and access to Linux development to keep Azure competitive. Cross-platform capabilities on the .Net VM are critical to compete with the JVM and associated databases. C# has been windows-first for a while, but the core cross-platform capabilities are not going to disappear, the tooling is all CLI based/capable now, the entanglements tend to be platform and service based.
That said, F# was years ahead of C# in features C# is still chasing, and is driven mostly by the open source community. That community is more in academic and finance areas where Linux-first is common. The language is standardized and plugged into VM improvements over time.
Frankly, I see the lesser degree of entanglement with MS corporate interests as a boon for the language and its ecosystems long-term utility.
From what I understand, LSP support for c# isn't very good, and is from third parties, not MS themselves, because they want you to us Visual Studio on Windows.
The problem is that it's closed source, and its license specifically prohibits its use with anything other than VSCode. Unfortunately, this is becoming the usual modus operandi for first-party Microsoft extensions for VSCode for all the talk about how they "love open source".
About a year ago I made an ChatGPT and Claude based hobo RAG-alike solution for exploring legal cases, using document creation and LLMs to craft a rich context window for interrogation in the chat.
Just maintaining a basic interaction framework, consistent behaviours in chat when starting up, was a daily whack-a-mole where well-tested behaviours shift and alter without rhyme or reason. “Model whispering” is right. Subjectively it felt like I could feel Anthropic/OpenAI engineers twiddling dials on the other side.
Writing code that executes the same every time has some minor benefits.
Humans are reliably unreliable. Some are lazy, some sloppy, some obtuse, some all at once. As a tech lead you can learn their strengths and weaknesses. LLMs vacillate wildly while maintaining sycophancy and arrogance.
Human egos make them unlikely to admit error, sometimes, but that fragile ego also gives them shame and a vision of glory. An egotistical programmer won’t deliver flat garbage for fear of being exposed as inferior, and can be cajoled towards reasonable output with reward structures and clear political rails. LLMs fail hilariously and shamelessly in indiscriminate fashion. They don’t care, and will happily argue both sides of anything.
Also that thing that LLMs don’t actually learn. You can threaten to chop their fingers off if they do something again… they don’t have fingers, they don’t recall, and can’t actually tell if they did the thing. “I’m not lying, oops I am, no I’m not, oops I am… lemme delete the home directory and see if that helps…”
If we’re going to make an analogy to a human, LLMs reliably act like absolute psychopaths with constant disassociation. They lie, lie about lying, and lie about following instructions.
I agree LLMs better than your average junior first time following first directives. I’m far less convinced about that story over time, as the dialog develops more effective juniors over time.
You can absolutely learn LLMs strengths and weaknesses too.
E.g. Claude gets "bored" easily (it will even tell you this if you give it too repetitive tasks). The solution is simple: Since we control context and it has no memory outside of that, make it pretend it's not doing repetitive tasks by having the top agent "only" do the task of managing and sub-dividing the task, and farm out each sub-task to a sub-agent who won't get bored because it only sees a small part of the problem.
> Also that thing that LLMs don’t actually learn. You can threaten to chop their fingers off if they do something again… they don’t have fingers, they don’t recall, and can’t actually tell if they did the thing. “I’m not lying, oops I am, no I’m not, oops I am… lemme delete the home directory and see if that helps…”
No, like characters in a "Groundhog Day" scenario they also doesn't remember and change their behaviour while you figure out how to get them to do what you want, so you can test and adjust and find what makes them do what you want and it, and while not perfectly deterministic, you get close.
And unlike humans, sometimes the "not learning" helps us address other parts of the problem. E.g. if they learned, the "sub-agent trick" above wouldn't work, because they'd realise they were carrying out a bunch of tedious tasks instead of remaining oblivious that we're letting them forget in between each.
LLMs in their current form need harnesses, and we can - and are - learning which types of harnesses work well. Incidentally, a lot of them do work on humans too (despite our pesky memory making it harder to slip things past us), and a lot of them are methods we know of from the very long history of figuring out how to make messy, unreliable humans adhere to processes.
E.g. to go back to my top example of getting adherence to a boring, reptitive task: Create checklists, subdivide the task with individual reporting gates, spread it across a team if you can, put in place a review process (with a checklist). All of these are techniques that work both on human teams and LLMs to improve process adherence.
That completely glosses over the actual behaviour of Microsoft, and ignoring the kinds of career, business, project, and reputational damage those tactics did.
MS’s attacks on open source, open formats, and free software impacted and still impact democracies, developing nations, general computing capabilities, and create vast market inefficiencies. Looking at it as pure tech misses the forest for the trees. The corruption of the Office OpenXml process alone is a daily pox on the developing world. The tax impact of those entanglements is recurrent, and frequently hurts education and healthcare.
Also: if someone got burnt by some industry jerks and have had to deal with the fallout for decades, “it was 20 years ago” completely misstates the problem. Some BS was started 20 years ago, sure, but with daily crap-bowls that needed to be eaten every day in between. Entire careers have fallen into those cracks, armies of IT staff forced into suboptimal and broken workflows to satisfy decisions based on establishing and abusing monopolies.
Breaking a spine, even years and years ago, impacts the every day. Bitterness can be well deserved with an understanding of what was lost.
You're just throwing out a lot of vague statements. You're not helping your case. What specifically did Microsoft do to open source, open format and free software? You're making some huge accusations that Microsoft made some decision that impacts democracies today. Such as?
How is Open OfficeXML a daily pox? Why not use ODF if it's such a disease?
Fallout from what exactly? Again this vague language is not helpful. What exactly was lost 20 years ago?
The MS of today is actively reaping the benefits of the EEE & openly shady business years.
Their behavioural changes can be framed as an intentional reformation, but also as exhausting high-value targets, losing monopolies, and settling into profitable equilibrium out of necessity.
Modern competitors to MS are effectively immune to MS-EEE, in some cases by being way better at every aspect of it (MS IE is now delivered by Google based on forked Apple tech, and Office uses React, for quick examples…). MS pivoted to Azure-entanglements for their entrenched customers, which remains highly profitable, but have also had a marked decrease in engineering clout in certain key areas and still have a fragmented client/GUI ecosystem.
I’d contend they haven’t changed, they’re just cornered in ways they never were before so we see different behaviour. If MS controlled iOS or Facebook or WebKit or Search we’d see more classic plays reminding us who owns what.
I think that transition, from OS/Desktop company to a Cloud Services Provider, is where the rot comes from.
The financial incentives are to upsell incompetent IT departments onto forever subscriptions. The poor products lead to fat over-engineering in the cloud and huge running bills that are very hard to undo. Sloppy LLM integrations, and sloppy LLM advice about IT needs, would seem to feed into that same strategy.
Engineer: “It will take me two days [of work].” Sales:”We will have your fix ready in three calendar days [today + 2].”
Actual work that week gives employee 3 hours of non-meeting time, each daily meeting adds 0.5 hours of high-urgency administrative work. Friday’s we have a mandatory all-hands town halls…
Repeat that cycle for every customer facing issue, every demo facing issue, and internal political issue and you quickly drive deep frustrations and back talking.
I think there’s a fundamental truth: no one in their right minds, not even motivated engineers, actually hears anything but calendar when getting “days” estimates. It’s a terrible misrepresentation almost all the time, and engineers do a disservice when they yield to pressure to deliver them outside the broader planning process.
Project schedules should be the only place that time commitments come from, since they’re informed with necessary resource availability.
This specification argument seems to boil down to: what if we used Haskell to describe systems to LLMs?
Many of our traditional functional languages, ML family in particular, let you write hyper concise expressions (pure math if you’re in to that sort of thing), craft DSLs of unlimited specifiable power (‘makeTpsReportWith “new cover page format”’), and also in natural language (function names like `emptied cart should have zero items`).
I think if we did that and leveraged the type systems of those languages and the systematic improvements we see from ADTs and pattern matching in those languages, combined with a specification first approach like TDD, that we’d have a great starting point to have an LLM generate the rest of the system perfectly.
… yes, that is just writing Haskell/OCaml/F# with extra steps.
… yes, that level of specification is also the point with those languages where your exploratory type-diddling suddenly goes ‘presto’ and you magically have a fully functioning system.
I guess I’m old-fashioned, but sometimes I wonder if compilers are good for what they’re good for.
Contrasted with TypeScript and C#, F# is smaller, more expressive, stricter, with mature pattern matching and type resolution baked in from the ground up. F# was years ahead of the major languages on what are increasingly looking like ‘the basics’ around ADTs and immutability in modern distributed computing. OCaml and F# capture the linguistic high points of VB, Delphi, and C# with a broad spectrum of OOP(-lite) approaches, and have led those languages by decades on functional constructs that result in meaningfully tighter code. With the benefit of hindsight some approaches clearly map better to cloud computing and system verification.
F# also sits parallel to lots of living C#, objectively we see ‘less is more’. Less code per line, fewer lines per solution, terser and more LLM-efficient language. Error rates and refactoring costs are also meaningfully better IME, but harder to quantify in general terms.
reply