5 ms·
It's unlikely, but it would be great if Microsoft would take ownership of the .Net port of Clojure. If there are two official object-oriented languages in the .
by jimmcslim 10y ago
It's unlikely, but it would be great if Microsoft would take ownership of the .Net port of Clojure. If there are two official object-oriented languages in the .Net stable; C# and VB.NET, why not two official functional as well; F# and Clojure?
Given Arcadia, the Clojure bridge to Unity, and Microsoft's interest in Unity via its Unity Tools, there might be some synergy there.
- nothrabannosir 10y agoC# and vb.Net are not so much two languages as they are two grammars for the same language. Their ASTs are practically equivalent, bar some minor vb idiosyncrasies, holdouts from the VB6 days. I would be surprised if there were any organizational overhead to speak of for MS in maintaining the two. Clojure and F# are fundamentally, semantically different. (not arguing for or against, just giving some background)
- cm2187 10y agoYou seem to completely discount muscle memory. Muscle memory is why microsoft opted for curly brackets for C#, to make it familiar to java and c developers. Muscle memory is raw productivity. It does matter. Particularly for a population where a large part (including me) are not professional developers and do not have the time to learn new languages. The time you spend outside of your job learning new languages, is the time we spend doing some programming outside of our job.
- marssaxman 10y agoI would be surprised if there were any organizational overhead to speak of for MS in maintaining the two. I sure wouldn't, because I worked on the VB.NET compiler team back in 2008-2009, and "organizational overhead" was pretty much the whole game. The VB and C# compilers were completely separate codebases, managed by parallel but non-overlapping teams of engineers. We never touched the C# compiler's codebase, and the C# people never touched VB. (I did once read through a piece of the C# compiler source code, to see how they'd implemented a feature I was supposed to be reimplementing for VB, so I could be sure to use the same semantics: but that was it.) We had lots of meetings, though. Oh, god, so many meetings. So much time burned keeping all those parallel projects in sync. Whatever commonality the languages have occurs through endless soul-crushing hours of almost-pointless meetings sorting out how these two separate pieces of software are both going to be modified to do pretty much the same thing, with almost exactly the same syntax. Every new feature had to be designed twice over, implemented twice over, tested twice over, and documented twice over. They may look like twin languages, but the illusion is maintained via massive, ongoing investment of sheer brute force man-hours. Maybe things have changed since I was there, but it's really difficult to imagine how that could happen. The VB compiler was effectively legacy code, a horrible creaky mess of ancient patched-together bullshit, and nobody wanted to touch it any more than necessary for fear of breaking something. Refactoring was totally out of the question. I cannot imagine an organization as sclerotic as devdiv managing to rally the effort it would take to rewrite it - safely! - such that the VB and C# codebases could be combined far enough that they would no longer need to have a separate VB compiler team.
- deleted 10y ago[deleted]
- pzone 10y agoThis is one of the most fascinating "how the sausage is made" posts I've read on HN.
- svick 10y agoThey did rewrite both compilers, it's called Roslyn. And in Roslyn, C# and VB share some code, but a lot of the code is still separate even in the rewritten compilers.
- ledgerdev 10y ago> It's unlikely, but it would be great if Microsoft would take ownership of the .Net port of Clojure. Yes please. Maybe not join the direct CLR port, but rather a "clojure like" language implemented in fsharp, with repl/interactive development, a bit more syntax, immutable data, amenable to dotnet native, and fix clojure warts like bloated core namespace, startup issues, etc..