kvb

By this standard, who is innovative? Wasn't the Macintosh a reaction to the work at Xerox PARC? Wasn't the iPod a reaction to the existing MP3 players on the market? Wasn't Google a reaction to AltaVista et al.? Everyone takes inspiration from the products that have come before.

Given the content, I can't tell if the allusion to the disastrous Chinese Cultural Revolution is intended or not. It seems more like Cringely's actually talking about changing Microsoft's culture, which makes the title quite poor.

Is there anything in the article to justify the headline, or is this just clickbait (I read the article, but it just seemed to be a groundless rant)? Are all techrights articles this low quality? (Full disclosure, I'm a Microsoft employee)

Can you expand on why you view Roundup as harmful? Without it, what methods would farmers be using instead, and would these be more environmentally friendly?

Technically, I believe that value types with the same layout could share implementations (though I don't believe this is implemented). In any case, if you don't have generics you have to do the same thing by hand anyway (e.g. create an IntList type, a DoubleList type, etc.), so I can't see how that's any better. More likely, I think, is that Go doesn't do JIT compilation, so there would be some challenges getting a comparable implementation built on Go's runtime. But .NET's new native toolchain solves the same problem, so it's clearly not insurmountable.

I think the blub paradox applies to everyone. Unless you spend time using a feature in earnest, it is easy to convince yourself that it's not valuable. Do you have reason to disagree?

I'm not advocating adding every feature introduced in that span, only the ones that are not problematic. As a specific example, what's the downside to disjoint unions? They add minimal complexity while adding a ton of safety. I'm not aware of any argument that they are either not useful or a nightmare - could you point me to one?

Perhaps we're talking past each other - I'm certainly not saying Go should be Haskell (I've never even written a Haskell program!). Go's designers are clearly not stupid, and many people seem quite satisfied with their design choices. But that doesn't mean they "had full awareness of every language feature available in the alternatives", and even if they did, smart people are still susceptible to the blub paradox.

As for use in production, I agree that it can be a fair barometer for "utility", but I strongly disagree that it's a good measure of "quality" (as in, technical design choices). We live in a path-dependent world rife with network effects, so quality per se just doesn't matter all that much, and non-technical factors like "being backed by a major corporation" can matter a lot. I'm sure there's more Visual Basic in the wild than Go, but I'd hardly use that to argue that it's a superior language, or that Go proponents are "abstract language tourists".

What's problematic about .NET's approach[1]?

[1] http://research.microsoft.com/en-us/um/people/akenn/generics...

I think that's perfectly fine, though it's not my cup of tea (and I doubt that empirical evidence would show that Go's particular set of features maximizes "big project" maintainability, though such an experiment is sadly impossible to arrange). And I think that the point, "Critics focus on missing features, but Go's philosophy is to be minimal" is definitely valid. But, "Critics focus on how Go is missing shiny new features (that may not even be fully implemented)" is definitely not true (of most critics). Most people aren't complaining that Go doesn't support dependent types, or row polymorphism, or cutting edge technologies. They're complaining that Go doesn't even reflect the state-of-the-art of 30 years ago.

It seems like Go is reasonably well designed given its creators' goals, and many people like it, which is great. But I think you're being unfair to (some) critics. It's not that Go is missing "shiny new" features - Go is missing features that have been established for a very long time; generics and sum types have been around for decades and have been proven to work.

And to your last sentence, use in production is not a good measure of language quality (except in a tautological sense), because many non-technical factors strongly affect popularity.

It's very nice to be able to check annotations in a build step. I'm just saying that adding language-external checks makes it fairly meaningless to say that "C#" supports it; would it be fair to say that C# supports all of Haskell's features if I require annotating C# constructs with Haskell code and then use a modified Haskell compiler in a post-build step to verify that the pieces are composed in a valid way? None of this is to say that the C# code you linked to is not useful - it's just not possible to use "vanilla" C# to achieve what "vanilla" F# can do.

To your later question, while F# and OCaml share a common core, there's lots of F# code that won't compile as OCaml and vice versa, and units of measure are one such example. The syntax for measure-annotated types is not valid OCaml syntax.

No, not at all. It is true that units are erased at runtime, but the compile time behavior is quite sophisticated, going well beyond anything that's possible in C# or OCaml. (Your link is quite interesting, but I think that using a custom build step is "cheating" to some degree in that you can add arbitrary features by adding language-external post build processing).

By being built into the language, units of measure in F# work naturally with type inference (and definitions can be measure-generic), so:

    let weirdOperation (x:float<_>) (y:float<_>) = x * x + y * y * y

will be inferred to have type

    x:float<'u ^ 3> -> y:float<'u ^ 2> -> float<'u ^ 6>

While F# was definitely strongly influenced by OCaml, their features have diverged significantly. For example, F# has type providers, active patterns, and units of measure (though you're also right that OCaml has lots of features that F# doesn't, like first class modules).

Note also that this blog post is about accepting contributions to the Visual Studio IDE components for F#, not for the language itself (which has been open source for many years, and has already been accepting contributions from the community for a little while).

No, you have to look at the margin. The other 99 people are already there, and you have to choose whether or not to drive; you slow down everyone after you, but you don't slow yourself down.

It's an exciting time to be an F# programmer. The community really seems to be stepping up and getting ready to make important contributions.

I'm curious why this is being downvoted. Isn't congestion a textbook externality?

it's actually matter -> it actually matters

expanse -> expense

Is a building a blueprint?

Look no further than Fiddler for an excellent Telerik product (albeit one that was acquired).

This is an execution-centric view; I think that types really are everywhere when it comes to how typical programmers think about their code (even in dynamically typed languages).

Depends on the industry; there are plenty of places where trade secrets aren't viable (e.g. medicinal chemistry, where it's trivial to reverse engineer a drug).

MSR's LIQUi|> [1] looks like an interesting approach to this problem (although I'm not sure there's a publicly available way to use it).

[1] http://research.microsoft.com/apps/video/default.aspx?id=194...

While C# isn't my favorite language, I always enjoy reading Eric Lippert's measured take on language design. He also has a particularly good sense for how to step back from a question and reframe it in an insightful way, which makes him a good interviewee.

If you look at the Roslyn source, I'm not sure this would have worked too well. It looks like a lot of the C# is somewhat unidiomatic as it is (presumably to meet extremely aggressive performance targets), so it's not clear that F# would have provided much benefit. If you're building a compiler that doesn't need to scale to million line codebases, then F#'s a clear winner, but here I'm not so sure.

Are you curious about using them or implementing them? What level of detail are you looking for?

What makes it easier?

That's a bit different; this is about user-controlled SIMD instructions, not whether .NET can use SIMD instructions as part of its routine JIT code generation (see http://blogs.msdn.com/b/davidnotario/archive/2005/08/15/4518... for some very old commentary on where .NET took advantage of SSE instructions in its code gen).

Thanks for the definitive reply!

This is great to see. While Mono already had a method for using SIMD intrinsics, this tweet[1] indicates that this approach is better. Can anyone elaborate?

[1] https://twitter.com/migueldeicaza/status/452099923157065728