Live data from Hacker News

The Weakness of the .NET OSS Ecosystem

aaronstannard.com

201–210 of 215 posts

Re: The Weakness of the .NET OSS Ecosystem

#201

Earlier quoted context omitted.

> I think tail call conversion to iteration You cannot convert a tail call to an iteration in a generic case. Consider the following: `let f g x = g x` Here, call `g x` is a tail call, and you've no idea what `g` is, so you cannot statically inline it or convert to a loop. > JITs are free to inline beyond that as much as they want JITs are primitive and do not have much time to do anything interesting. Inlining is ve…

How is a "proper tail call" implemented if you aren't talking about conversion to iteration? I found the following article helpful. http://www.drdobbs.com/jvm/tail-call-optimization-and-java/2...

Usually it is implemented by reshuffling stack frame + jumping to the call destination. See how it is done in .NET, for example.

Do not confuse tail recursion, which is the least interesting narrow case of a tail call, with tail calls in general.

Re: The Weakness of the .NET OSS Ecosystem

#202

Earlier quoted context omitted.

> I think tail call conversion to iteration You cannot convert a tail call to an iteration in a generic case. Consider the following: `let f g x = g x` Here, call `g x` is a tail call, and you've no idea what `g` is, so you cannot statically inline it or convert to a loop. > JITs are free to inline beyond that as much as they want JITs are primitive and do not have much time to do anything interesting. Inlining is ve…

> Everyone who ever tried implementing any ML-like language on top of JVM failed miserably. How is "ML-like" defined here? AFAIK, Haskell is usually considered "ML-like", and Frege is a Haskell dialect implemented on the JVM.

Haskell is nowhere near an ML-like language, it's lazy, while ML is eager. And Frege is nice and all that, but it's very far from being efficient, nothing close to F# performance.

Re: The Weakness of the .NET OSS Ecosystem

#203
post #142

Earlier quoted context omitted.

> There is a distinct lack of OSS in .NET. I've been trying to find a project to contribute to among the graveyard on Github. However, I think the author falls flat explaining the why. Simple, Microsoft killed it with the transition to .NET. People have forgotten just how extensive both the open and paid ecosystems were around Visual Basic 6 circa 1999-2001. Those ecosystems were huge --they absolutely dwarfed open s…

The switch from older (VB6, etc) model to .NET could be compared to the switch from Python 2 to 3, only MS didn't wuss out and actually made the braking change instead of dragging everything out. You can call it "stabbing". I'd call it "necessary progress". Just because an ecosystem is large doesn't mean it's good. I once tried to switch the automation in our team from batch files to Ruby. Huge mistake. Try finding a…

> The switch from older (VB6, etc) model to .NET could be compared to the switch from Python 2 to 3, only MS didn't wuss out and actually made the braking change instead of dragging everything out. You can call it "stabbing". I'd call it "necessary progress".

To what end?

There were billions of lines of VB6 code that got orphaned (possibly trillions). Lots of businesses simply stopped at WinXP/VB6 for this reason--I suspect this is more responsible for the continued existence of XP than anything else (hardware drivers are probably the other).

So, we now have obsolete code along with security nightmares frozen in amber and in return Microsoft killed their developer ecosystem and lost a bunch of revenue because people simply stopped in place or moved to non-Microsoft ecosystems.

Who benefited? I'm sure some manager got great numbers for a a year or two while some fraction of the developers had to upgrade. Of course, nobody measured how many developers were lost in that transition.

Re: The Weakness of the .NET OSS Ecosystem

#204
post #180

Earlier quoted context omitted.

"polyglot microservice architectures" eh? Hey Bill! We've got 20 years of legacy code that handles everything from Arrivals Boards to seat assignments in 1627 different aircraft configurations. We got a room full of .NET devs downstairs. How about we re-write everything in multiple languages! Remember that time we went down for two days because we muffed up our NET 2.0 to 4.0 migration? Imagine how much fun we'll hav…

Here's the thing: literally none of that is right. You had to assume a lot of facts not in evidence to be that much of a jerk. It was a big task. But you did it! - Almost every developer was converted to .NET to work there, because Microsoft's credibility among startup-focused developers is not great outside of a few specific tools like SQL Server. It's a lot easier to get enough hands to get the job done when you le…

Specific question: What kind of load needs scaling within seconds? If it's so sensitive why not have extra capacity available?

Re: The Weakness of the .NET OSS Ecosystem

#205

Earlier quoted context omitted.

How is a "proper tail call" implemented if you aren't talking about conversion to iteration? I found the following article helpful. http://www.drdobbs.com/jvm/tail-call-optimization-and-java/2...

Usually it is implemented by reshuffling stack frame + jumping to the call destination. See how it is done in .NET, for example. Do not confuse tail recursion, which is the least interesting narrow case of a tail call, with tail calls in general.

Why can't you modify a JVM to do this? I don't get it.

Re: The Weakness of the .NET OSS Ecosystem

#206

Earlier quoted context omitted.

Usually it is implemented by reshuffling stack frame + jumping to the call destination. See how it is done in .NET, for example. Do not confuse tail recursion, which is the least interesting narrow case of a tail call, with tail calls in general.

Why can't you modify a JVM to do this? I don't get it.

Of course you can (but you have to add another instruction or an instruction prefix). But Oracle won't ever do it.

Re: The Weakness of the .NET OSS Ecosystem

#207

Earlier quoted context omitted.

> Everyone who ever tried implementing any ML-like language on top of JVM failed miserably. How is "ML-like" defined here? AFAIK, Haskell is usually considered "ML-like", and Frege is a Haskell dialect implemented on the JVM.

Haskell is nowhere near an ML-like language, it's lazy, while ML is eager. And Frege is nice and all that, but it's very far from being efficient, nothing close to F# performance.

I don't think you can say "Haskell is nowhere near an ML-like language" based on just lazy vs eager evaluation.

See here[0]:

> Since Haskell is inevitably an ML (descending from Lazy ML) derivative, one might begin by pointing out the similarities:

    - First-class support for algebraic datatypes (disjoint unions)
    - Pattern matching on primitive and custom values
    - Arbitrarily higher order functions
    - Type synonyms
    - Hindley-Milner Type Inference
    - Parametric Polymorphism (define arbitrary Functors etc.)
    - Ad-hoc polymorphism (Haskell through type classes, SML through modules)
    - scorn of inclusion polymorphism (sub-type relations, a la object-wise inheritance)
    - Monads (and other exotic algebraic structures)—"Haskell has monads" is a common claim of superiority, but the reality is that at the language level a monad is nothing more than an abstraction pattern, and hence every language (can) have monads. Including a monad or not in any given language is a library-level decision.
> While the bread-and-butter language features may be similar, building software in Haskell vs SML is actually quite a different affair:

So we can see a lot in common there.

0: http://www.quora.com/What-are-the-key-differences-between-Ha...

Re: The Weakness of the .NET OSS Ecosystem

#208

Earlier quoted context omitted.

Haskell is nowhere near an ML-like language, it's lazy, while ML is eager. And Frege is nice and all that, but it's very far from being efficient, nothing close to F# performance.

I don't think you can say "Haskell is nowhere near an ML-like language" based on just lazy vs eager evaluation. See here[0]: > Since Haskell is inevitably an ML (descending from Lazy ML) derivative, one might begin by pointing out the similarities: - First-class support for algebraic datatypes (disjoint unions) - Pattern matching on primitive and custom values - Arbitrarily higher order functions - Type synonyms - Hi…

> based on just lazy vs eager evaluation.

It's not "just", it's fundamental. We're talking about an efficient implementation, remember? And therefore the underlying execution semantics is the single most important thing for classifying languages. The rest that you listed is very high level, consider it syntax sugar. It is all lowered down long before any of the important optimisations start to kick in.

> So we can see a lot in common there.

Not that much. Just think of the deeply fundamental difference between SECD and, say, STG.

Re: The Weakness of the .NET OSS Ecosystem

#209
post #22

A good chunk of that is the "invented here syndrome". With EF, WPF, ASP MVC, MEF, etc, plus annual MSBuild conferences, .Net has far more internally-developed ecosystem than Java. Which tends to promote the idea that the MS way is the right way, and if I need something else I must be doing something wrong (or I need to wait till next year). Perhaps MS should just kill off all these frameworks and force the community…

To clarify, by "invented here syndrome", I meant for the MS shops / MS consultancies. Rather than building frameworks themselves, they search for off-the-shelf solutions provided by MS or a partner. The managers at those shops think "the MS way is the right way; don't 'invent here'".

Re: The Weakness of the .NET OSS Ecosystem

#210
post #112

Seems to me its more on the people who solve hard problems than on the current crop of .NET developers - if you are writing a complex game/MMO, AI system or what have you, and you choose to do so in Java, C++ or similar when C# might be the better option, the faults on you not the .NET community. If the whole pool of developers world wide was considered as a big pie, and a certain section of that do these 'hard probl…

(Not directly addressing what you're saying.) A few MMOs have been written using .NET. https://gamedev.stackexchange.com/questions/10247/mmos-based...

As well as a tonne of games in general, which I'd argue are 'hard problems' as well. Pillars of Eternity, Endless Legend etc. Though of course none of those are OSS. Would be nice if at least parts of them were as it would certainly help indie game devs like me :)
Post reply on HN