There was no discussion of async/await in here which is one of the best things C# has going for it.
When I meet other devs and tell them I work in lots of languages and platforms but prefer c# they usually look at me like I have 3 heads.
I like to show them LINQ and Async as some things I really like about C#, then I get into how rich the BCL itself is.
Devs are also pretty shocked when I tell them I can write truly 100% native iOS and Android apps in C# (thank you Xamarin) and that one of the most popular mobile game engines (Unity) uses C# and a version of the .NET Framework under the hood.
It's funny when you tell hipsters about .NET. They get really shocked at just how good it is. A lot of people dismiss .NET because it's backed by Microsoft. It really sucks that these people can't just look at the technology for what it is rather than dismiss it based upon who created it.
As an aside... whilst C# takes a lot of the public .NET praise, F# is the real hero in the making. When I show F# to some hipsters they get very unsettled very quickly as suddenly they realise all that shitty Ruby and JavaScript they've been writing for years is probably not going to be anywhere near as employable in another 10 years, maybe, hopefully.
Interesting times indeed. And yes, Xamarin is awesome and Microsoft seriously needs to bring that great firm under their wing. Writing your mobile apps per platform is a major violation of DRY principles and is utterly ridiculous.
> A lot of people dismiss .NET because it's backed by Microsoft. It really sucks that these people can't just look at the technology for what it is rather than dismiss it based upon who created it.
Since .NET isn't open-source, it doesn't come with the same guarantees as something like Java, C++, OCaml, Haskell, etc... Microsoft could discontinue it, make the terms of use more restrictive, etc...
Further, .NET applications only run (officially) on MS platforms, Mono isn't the same, and due to legalities many people are hesitant to base their business on Mono.
As far as hipsters and Javascript or Ruby, MS has fully embraced Javascript. It's a first class language on VS, Windows 8 'modern' interface, etc... Ruby is great within its domain, and even has a .NET implementation (though I don't know how well supported IronRuby is anymore).
And funny you praise F#, because it's just a MS implementation of OCaml, with a few small differences. Speaking of which, OCaml is pretty awesome, it compiles down to pretty much anything, and is fast as hell...
F# isn't "just a[n] MS implementation of OCaml, with a few small differences". F# did start out as an OCaml port for .NET, but the language has grown organically from there, especially since the first public, supported release (v2.0, in VS2010).
The foremost difference is the ability to easily and closely interoperate with existing .NET code; this sounds very simple, but it's very tricky to get it right, and in fact this is widely considered to be a major strength of F#.
F# also has computation expressions (like monads in Haskell), sequence/list/array comprehensions, type providers (for strongly-typed data access), and built-in async support. Not to mention, since F# runs on the CLR, it has a well-tuned, high-quality, multicore garbage collector at it's disposal.
I know some of the folks from OCaml Labs, and I have nothing against OCaml. I just want to dispel the notion that there are no differences between OCaml and F#.
".NET applications only run (officially)" -- what's that even mean? I can rephrase it: "Mono applications only run (unofficially) on Microsoft's CLR".
The actual runtime is an ECMA spec (which has been unchanged since v2, as all MS has added since are implementation changes and more libraries). C# and the core parts of the runtime are under Microsoft's Community promise[1]. But you're right that MS could try to assert copyright over parts of the extended APIs, and some companies might be worried about that. OTOH the Oracle versus Google thing should alleviate a lot of concerns.
As far as F#, it's quite a bit more than a few small changes.
> ".NET applications only run (officially)" -- what's that even mean?
If MS feels threatened by Mono, it changes its runtime and kills interoperability. From that point on, Mono is playing catch-up and who knows what happens to the users caught in the middle.
That's one of the least-plausible Microsoft trickery ideas I've heard of. Anything that makes Mono play catch-up also hurts every existing .NET program.
Even if they had some magical changes that kills interop (like, what, I don't know), Mono still works with all current apps at that point, and only developers adopting the new, not-compatible system (and thus discarding all their old libraries) would be affected.
Microsoft sorta has done this, with Silverlight and WinRT. They required different stdlibs and a bit of runtime tweaking, as I understand. Silverlight was handled by Mono, and WinRT - not sure if anyone is interested, as it's really for Windows Metro applications.
What kind of change could Microsoft make to their runtime to "kill interoperability" with Mono without affecting backwards compatibility for everyone else using .NET?
There are enough people (especially enterprises, their most important customers) using .NET now that Microsoft has to be very careful about any changes they do make to avoid breaking existing applications and upsetting their paying customers.
There's a lot more to F# than its OCaml origins. It's obviously heavily based on OCaml, but the directions have diverged.
One of the most powerful features I've found is part of the LINQ framework - the expression tree output. You can specify parts of code to be 'half-compiled', it leaves an AST fragment in the output in addition to the regular code.
This means you can do runtime transformations, for example to JavaScript or HTML.
The pattern matching extensions also make these transformations easier than you'd expect.
Don't knock the practical value of seamless interop with the .NET ecosystem.
A few years ago I tried to introduce OCaml to a company I was working at, an Oracle shop, and immediately hit a snag - the Oracle bindings hadn't been maintained in years and wouldn't compile with the current GCC or OCCI. ISTR there were also 32/64 bit issues. Anyway, I actually went ahead and wrote my own, styled to look a bit more like the classic OraTcl to make adoption easier. I say this not to blow my own trumpet but to illustrate that there is more to a language then the language. And not to knock the OCaml guys, just that their research priorities are different than my corporate data processing priorities.
Anyway, the OCaml world is playing much more nicely with others now, the book Real World OCaml is almost out, OCamlPro are doing some good work. But in F#, you can "hit the ground running".
> Microsoft could discontinue it, make the terms of use more restrictive, etc...
> .NET applications only run (officially) on MS platforms,
Not only that - non-Microsoft platforms have a huge choice of languages, platforms, runtimes and other tools Windows can't match. With all that going on, it would be surprising if someone decided for .NET to run on non-Windows boxes.
The only reason to target .NET is to build Windows-compatible software. It's an important requirement, sure, but there is a lot more happening these days on spaces Windows simply can't reach.
Also, Microsoft have patents not just on .NET itself, but also on fairly broad ways of using particular .NET functionality. Needless to say, patent infringement by your code isn't covered by any of their patent promises or licenses. I'm pretty sure at least Gtk# infringes on at least one such patent I found some time ago; since essentially every graphical C# application uses either that or WinForms which is also covered by multiple patents, running any C# GUI app anywhere other than Windows is legally risky.
Microsoft, Oracle, HP, IBM, and others also hold a variety of patents related to garbage collection algorithms. The legal risk isn't limited to C# on non-Windows platforms; I'd guess that any garbage-collected language is potentially open to litigation: C#, Java, Python, Ruby, Haskell, OCaml, etc.
> And yes, Xamarin is awesome and Microsoft seriously needs to bring that great firm under their wing.
I'm a Microsoft fanboy, but a thousand times no. So they can do what with it exactly, pull another Skype? Xamarin caters to areas MS rarely do and bringing them in would push people out of the windows ecosystem, not inward. MS's catering to ios and android is to push people to windows phones and that isn't likely to change anytime soon.
I'm definitely glad Xamarin exists, especially after Novell kicked them to the curb. They could've kept their ball too but they decided to play fair and let Mono live on. I would never in a million years think MS could be that generous, and again I love MS for better or worse. Could they be? Sure but in spite of Bill Gates charitable contributions to humanity, those notions rarely took root in the company that enabled him to become that person in the first place.
I really wish F# was as approachable as Scala is. Every time I consider it I see no strong selling point. Loosing ReSharper + a steep learning curve make it too much for me.
If you know C# and you want to learn F#, consider reading Real-World Functional Programming: With Examples in C# and F# (http://www.amazon.com/Real-World-Functional-Programming-With...). It's been well-received by C# developers, IMO because it does a great job of explaining the purpose of certain F# features, and how they can be used to simplify some common C# coding patterns.
As an active contributor to the F# open-source community, I can tell you that there is a lot of effort -- both from Microsoft and the wider community of developers -- to build out the F# ecosystem of tools and libraries. For example, Deedle (https://github.com/BlueMountainCapital/Deedle), a data frame library for F# and C# was released a few days ago; this gives you the kind of data-manipulation functionality as you'd get with Pandas or R. JetBrains even started an open-source project to bring F# support to ReSharper: https://github.com/jetbrains/fsharper
I hate to be a negative guy. I have actually read some chapters of that book - thanks for links, I do appreciate. Maybe the problem is that my job is DB + GUI + simple business logic type of projects. Which is probably similar to most other jobs these days. I would love to work for Blue Mountain Capital but I don't. I am the only one in the team who thinks F# could be useful and had to defend using Maybe monad in C#! The only strong use case I have found so far for F# is building DSLs. Even then I would personally prefer an external DSL built with ANTLR or other proper language work-bench.
PS: that F# ReSharper project is actually dead, last update was months ago. I don't understand why Microsoft won't pay JetBrains to add support. I don't understand why Microsoft won't make a Roslyn for F#. No, instead poor F# team guys have to talk to community to build some basic OOS IDE.
On the contrary: Even for these boring apps, using F# means you'll have a lot less code. C# only really wins if you're using the GUI designers.
I converted a C# application to F# manually, preserving the C# style. I needed 1/20th the number of type annotations. I've done ASP.NET MVC apps using F# and find it far lighter-weight to write controllers.
And the neat thing is that while using F#, even as a lightweight C#, you'll start using better abstractions because they're so easy.
If you can, write some projects in F#. I've found the best way to convert people is just to enjoy how little code's required to get things done, which makes them jealous and they'll switch.
Do you use WPF for your GUI programming? GUI isn't one of F#'s strengths -- it doesn't have all of the fancy codegen tools C# does -- but Dmitry Morozov has built some excellent tools for working with WPF in F#: https://github.com/dmitry-a-morozov/fsharp-wpf-mvc-series/wi...
Database-oriented programming in F# is pretty good from F# 3.0 onwards, thanks to a few minor language improvements and the major addition of Type Providers. F# 3.0 ships with a type provider which interops with the standard classes in System.Data.SqlClient and another which interops with Entity Framework. See: http://msdn.microsoft.com/en-us/library/vstudio/hh361035.asp...
Dmitry (whose WPF framework I mentioned) has also written another type provider which provides strongly-typed access to all kinds of stuff (e.g., stored procedures) if you happen to use SQL Server as your database: https://github.com/dmitry-a-morozov/FSharp.Data.SqlCommandTy...
C# and it's related tools are very solid and have much momentum and marketing muscle behind them, so it's understandable that some developers (e.g., your co-workers) might feel uncomfortable learning something new. I've found the best way to convince people is to start writing little bits and pieces of your work, like small tools or minor libraries, in F#; when it turns out they have few, if any, bugs that usually does a good job of convincing people F# is worth taking another look at.
I actually like how meaningful white-space forces formatting. I want more inference in C#. What I don't like is that language "feels" too "big" for me to approach. Things like "The DefaultValue attribute is required on explicit fields in class types that have a primary constructor" make me think WTF, why use OCaml with "patches" instead of starting from scratch? Don't get me wrong, I will learn F# the day it will be paid properly by the market (London). But today it doesn't give me enough to abandon C#. PS: Microsoft says F# is not meant to replace C# and I don't do scientific calculations or big data.
I'd be surprised if F#, all-in-all, has more complexity than C#. For instance, C# has crazy duck-typing rules, but they only apply when using certain keywords (like new Whatever{} or foreach). Or all of C#'s type-coercion stuff, like C. Floats, integers, even strings - let's implicitly convert them galore!
F# has a fairly coherent model, which makes most of the design principles deducible. For instance, that quote about DefaultValue. You're using a keyword to introduce a field without initialization. Since F# avoids uninitialized fields, so you don't end up with nulls, it forces you to be explicit here, noting that you're requesting the compiler to allow an uninitialized field, which is not something you often want.
Microsoft's marketing is shit as far as F# goes. They've invested a lot in C#, and it's embarrassing for some people to admit that MSR came up with a far superior language. So instead they mumble about how F# is great... if you're like a rocket scientist or quant or like, really super-duper smart. The implication being that C#/VB are the only practical languages for normal get-stuff-done programmers. In truth, the only real advantage C# has is the tooling. There are drag-n-drop designers, and codegen tools that F# doesn't have. Some libraries make implicit assumptions about C# compiler implementation details. But that's hardly a language problem, and something MS could fix if they cared to put resources on it.
As a side note, the F# team has some of the same people responsible for actually designing and getting proper generics into the CLR. Without that team, the CLR wouldn't have proper generics, but probably eventually would have gotten a lame model like Java's.
The biggest problem F# faces(or faced) is it looks very foreign to a journeyman c#/java/c++ developer. Significant whitespace and lack of curly braces does not look quite odd now, with the proliferation of Python, Ruby etc. Prior to 2005 or thereabouts, it was a huge challenge.
Part of it is a community problem as well - the leading lights of the Alt .NET community pretty much cold-shouldered F#. Don Syme & team waged a lonely battle to bring mindshare. Till f# 2.0 shipped, I can't remember more than 2 or 3 significant developers who were actively developing F#. Things are looking up now though.
@profquail: First of all those links are meaningless given the scarcity of F# positions. You just can't compare them statistically. Second of all if you look closely at actual positions then it turns out they are not F#-centric at all, more like "Scala, F#, Erlang, Haskell knowledge is a plus". I mean people who use F# were hired not because they knew F# well but for other skills - e.g. deep knowledge of finance, distributed computing etc. Why not focus on learning that instead? Nobody pays 100k for F# alone. I might be wrong but I just don't see it as a skill that sets you apart that much. People are more interested in HTML5 :(.
With languages like C#, Java, Python, C++, etc., job postings often ask for experience with that specific language. Sometimes you'll see postings which allow developers to jump back and forth between C# and Java, but that's about it.
With functional languages, the specific language is much less important, because the languages share many features, and the real key is that you understand how to design and structure functional programs. Along with the fact that functional languages -- even the popular ones -- have much smaller developer bases than your mainstream imperative languages, many job postings for functional programmers list multiple languages just as you described.
And you're right, no one's going to pay you 100k just for knowing F#. That's true for any language at any salary point though. What companies are looking for are those other skills; F# developers generally command higher salaries because they're often highly skilled senior developers, not because of their language preferences.
Many F# developers work in the financial sector (myself included). Working in the financial sector isn't some magic ticket to a higher salary though, i.e., given an engineer who makes $X in some other industry, they're not automatically going to make 2 * $X just because they switch to finance. The reason salaries are higher in finance is because it's really worth the investment for financial companies to spend extra money to hire the most highly-skilled engineers (and other staff) they can find. Some other industries (e.g., aerospace) have similar requirements, so salaries are higher than normal there as well.
I have an ongoing bet with a few friends on when and who will buy Xamarin. In April my bet was 18 months they would be bought by Microsoft or Amazon. I still lean Amazon.
I hold out hope that the next Microsoft CEO won't be as blind as Ballmer was and that the first thing on his hit list will be to buy Xamarin or at least "secure" it to prevent anyone else buying it; a suitably large investment could do that.
Xamarin would provide the perfect solution to getting a major foothold on mobile app developers, which is what Microsoft so desperately needs for their Windows Phone aspirations. Once you have developer mindshare, you have cracked half the problem.
Microsoft should buy Xamarin, but they'll also need to open-source all of .NET. That would improve Mono on non-Windows platforms. That would be the best thing they can do to really get a foothold in the mobile space and also win back some part of the startup community.
P/Invoke and stuff like that is unopensourcable. The run time is way too deeply embedded in COM and the registry for its own good.
This move could have outright killed java in 2006 when the .NET 2.0 was way ahead of java in everything. Right now - I am not so sure it will be such a big thing.
(Disclaimer - haven't touched serious project in 4-5 years in .NET but I loved C# and the libraries)
Funny, but P/Invoke seems to work great on Linux with Mono... it's probably the single biggest reason I started out with it, as JNI by comparison is an ugly beast.
I love a lot of what C# and .Net have to offer, even though half of my server-side dev time is in node.js for the past couple years, I still like a lot of .Net ... It will be really interesting to see where things go in the next couple of years. I think unchaining VS and Office from Windows would be the best move MS could make right now. Web Matrix (with an extension) is imho second best dev environment for node.js out there, and that they haven't integrated this into VS really surprises me.
MS put a lot of effort into libuv, so not sure why they wouldn't get the runtime system that uses it up to speed better.
The BCL in .Net are second to none in terms of breadth and comprehensiveness. I feel that if MS really opened up most of .Net in MS-PL or something similar, it could really gain ground outside of windows... Again, this would mean getting VS and Office away from the windows anchor.
Unfortunately, the .Net Framework source is available under a 'reference license'.. You are allowed to look at the source, but not modify or redistribute it. Mono specifically has to be very careful about these problems, so if you have ever looked at Microsoft's 'shared source' code you are not eligible to contribute to Mono.
I think that keeping Xamarin out of MS's hands is actually better for the ecosystem. It is very healthy that there are multiple independent but compatible implementations of the CLR and other tools so that everything is not tied to Microsoft.
> In summer of 1997, he [Miguel de Icaza] was interviewed by Microsoft for a job in the Internet Explorer Unix team (to work on a SPARC port), but lacked the university degree required to obtain a work H-1B visa. He declared in an interview that he tried to persuade his interviewers to free the IE code even before Netscape did so with their own browser.
Yeah, I am really curious why someone would hate the ecosystem. Very strong word for something like that, surely you have some reason beyond something as superficial as style or your personal experience with a person or project...? Do tell.
Excuse the rant nature of this but I'll give you some reasons as a software/devops guy who does 50/50 UNIX/Windows and has written more C# than I care to remember, daily for 12 years...
The ecosystem is horrible. Why?
1. It's full of little cargo cults powered by Greg Young, Udi Dahan and Oren Eini in particular. Each of these sells snake oil that costs you piles of cash and screws up your architecture or heavily couples it into a product which has a recurring cost.
2. Rip off merchants such as Telerik producing buggy components that rarely work.
3. Abandonware galore. There is no inertia. Everything tails off and dies after a bit. You can't drag something off NuGet without the inevitable result of it dying miserably after a year or so. At least we have NuGet now so ancient versions don't just disappear. We have to maintain our own forks of various things now.
4. Framework circle-jerking. Microsoft literally suck up to every framework that appears that gets traction resulting in much friction for those who adopted other frameworks before the circle-jerk began because it's not the one true framework (MVC validation I'm looking at you).
5. Everyone you get off the street is rubbish, at least in the UK. I mean really rubbish. So rubbish even though we offer a damn high salary, we have a 1 in 20 hit rate for staff. Perhaps 1 in 50 people actually give a crap past getting a pay cheque. It seriously attracts the wrong people.
6. Blindness. Not a single person I know has even managed to take a look at other platforms past perhaps owning an iOS or Android phone. There is literally no variation of knowledge or alternative viewpoint to pit the status quo against.
It's just a career programming market if you ask me and to be honest it's the only reason I do it. It pays better and I can work locally.
Fortunately I have a number of UNIX boxes I can dissolve into (much like some people drink after work).
I've been doing C# development for a few years now, and did 100% Solaris/Linux for the decade prior to that.
1. Never heard of them. They certainly haven't impacted anything I've done.
2. I've been ignoring Telerik for twice as long as I've been working in C#, because of their HTML/JS stuff. I'm not surprised their C# stuff is equally bad.
3. You could say the same about OSS projects on SourceForge, GitHub, or other repositories. Whenever you choose a third-party library (vendor-supplied or not) you have to consider how widely deployed it is, how big and active the community around it is, and what it's longevity will be. If you're not doing that (or doing it poorly) and getting burned by abandoned libraries, then you need to learn to judge better.
4. See #3. It's true though, Microsoft does tend to try to include everything; I suspect that comes from trying to develop general libraries/frameworks for use by Enterprise developers. Each Enterprise needs something specific, and most of them need different specific things, so a general-purpose all-inclusive framework winds up trying to have everything.
5. I think that's Enterprise thing again, and it's probably just as true for Java developers. When the vast majority of developers familiar with a technology are doing internal IT development for companies where software development is a cost center rather than an investment, the hiring pool is going to be full of mediocre developers. The best developers will be working for software companies and companies whose business advantage is based on their software, and that's true regardless of the platform they use.
6. See #5. This certainly applies to lots of Java devs too, and also most less experienced devs who started learning the trade in college rather than on their own.
Rant excused. While some of your points are more or less correct, would you care to elucidate on a few of the others?
1. You mentioned Oren Eini, who is the author of Rhino Mocks and contributed heavily to Castle and NHibernate. Apart from the usual TDD zealotry, how exactly do any of these screw up architecture? Or cost anything? -- they're free. Are you referring to RavenDB? Also, can you seriously name a platform that doesn't have celebrity developers slinging trash ware to line their wallets? Is this strictly a Windows/Dot Net phenomena?
5. & 6. While I agree that there are tons of clueless/mediocre Dot Net devs, I've met many that are exceptionally sharp and just as capable as any hardcore, passionate Java/Python/whatever developer. Passion outside of the Microsoft ecosphere? Are you at all familiar with the entire Alt.Net "movement"? Is your sampling based on the type of "talent" your company attracts? Or maybe the UK?
1. Oren is the least bad of the three mentioned, but his "Ayende" blog at times is a little vicious when it comes to slating other people's work [1] especially when the sheer number of bugs we've tripped over in NH, Castle dynamic proxy and NH profiler is as high as it is. I'm not a TDD zealot (I write tests for critical sections only, usually after the code writing event) but from an architectural point of view, unlike J2EE etc, there are no standard abstractions so once you've integrated something, you're stuck with it unless you fancy rewriting everything. This is hard work when your codebase is around the 2 million lines of C# and 150,000 lines of NH mapping XML (yes it's that big). Cost isn't just for the product - it's an ongoing concern. We've got to the point where we are becoming "that conservative enterprise" that someone else mentioned above.
Platform that doesn't have celebrity developers: C/POSIX. Even C++11 possibly now (I haven't evaluated it fully yet). Why? It's a set of standards, not a product. You're free to move around in it. I'd argue J2EE is fairly close to that but to be honest it's a pain to work with unless you're using Java EE 6. Go is pretty celebrity-free i.e. the authors with their heritage don't do it for the fame (which in itself sounds ridiculous).
5/6. Yes we've met them as well but to be honest they want lots of money (£100k+) or are contractors. I'm quite happy to take 3 people on that basis in myself and lose 6 members of our team as there would be a net gain but unfortunately employment law in the UK doesn't allow it and PHBs think more bums on seats is a good metric for measuring productivity. This is unfortunately a universal FAIL in the UK which concentrates on unemployment figures only - it's almost programmed into the minds of all business folk.
I'm not saying the last point is specific to .Net as for example the Perl developer community in the UK is even worse (I worked for an outfit where use strict was laughed at) but it's a hell of a lot easier to get a decent C expert than it is to get a C# expert just from the sheer amount of noise from low quality developers expecting miracle salaries. Recruitment agents are a joke as well (although they're easy to get a free lunch out of ;-) but that's another story.
> I'd argue J2EE is fairly close to that but to be honest it's a pain to work with unless you're using Java EE 6
The thing with Java is that the community is freaking huge. Actually, with Java you're not talking about one community, but of several huge communities.
If you don't like J2EE, that's OK, as there are plenty of well-supported and awesome alternatives. Alternatives like Dropwizard and Play Framework. If you don't like Java, the language, that's OK too, as there are awesome alternatives, like Scala, Clojure, Groovy or JRuby, all of them widely supported with big communities behind them.
Also, people should really acquire better taste in what technologies to pick. (N)Hibernate sucks so badly that I've always been amazed of its popularity.
Agree with your point about hibernate and its derivatives. Unfortunately with .Net you're stuck with that or EF which is even worse or something off the shelf and even crappier. TBH I've actually used raw ADO.Net with provider abstraction and dapper.net recently as replacements.
Despite its inefficiency, the old CQRS pattern with commands that INSERT/UPDATE and queries as typed DataTables are actually the most scalable solution I've found (over several years, not just on small projects).
7. Most .NET shops are so technologically conservative they mandate their developers write "C# 2.5" because those C# 3, 4, 5 features are too scary and unproven. Which is part of what causes #5.
Also, low quality commercial .NET libraries are an epidemic.
There's no such thing as C# 2.5. You must be referring to 2.0. Anyhow this may be true of financial institutions, but to say that it's a norm... is not my experience at all. > 15 years of experience.
Sorry, 2.5 was me being sarcastic, so I put it in quotes. It basically means you code mostly in C# 2 with a few C# 3 features cherry-picked (Like null coalesce, maybe implicit typing with var) but avoid anything LINQ-related.
Most of the problems arise from people not understanding that linq queries return iterators, not collections and therefore writing O(n²) loops. But that's not too hard to learn.
Alas, if you are talking about Linq2Sql or Entity Framework, then of course you have to deal with all the typical ORM problems; but this has nothing to do with Linq.
I think the common sentiment is that we'd all hope to hell that we never have to work on a project so crappy that team members can't understand programming language basics.
Hate is as strong as Love. I don't see people complaining when other people use Love to describe their feelings.
(0) I don't care how great .NET/C# is on top of Windows, because Windows does not exist for me.
(1) Visual Studio does not run on my Ubuntu Linux workstation. It does not run on OS X either. In contrast with IntelliJ IDEA or other IDEs.
(2) Mono sucks for building and deploying web services on Linux. Last time I tried it, I had to restart the process constantly as it was leaking memory. Performance sucked too. Things should be better now, with that new generational garbage collector, but building web services was always an afterthought.
(3) Mono is always behind (while also being ahead in some areas). Async landed in Mono and it's finally usable. People did have to wait a lot of time to try it out. People that think Mono is some sort of .NET for Linux/OS X/iOS are wrong. Mono can be treated as a different platform.
Also, Xamarin has been treating Debian/Ubuntu as a second class citizen. The latest version is 3.2.3, but the version I have on my Ubuntu is 2.10.8, as packaging is done by the community. I understand that they have other priorities, but they are also the only company that packages software for Linux and that ignores Ubuntu/Debian.
(4) The ecosystem has no real open-source culture. Most third-party tools and frameworks worth bothering with are proprietary/commercial. Most open-source libraries and tools worth considering are either part of the (small) Mono community or are clones of projects running on top of the JVM. The whole ecosystem is actually very Microsoft-centric and Microsoft couldn't even be bothered to ensure that NuGet works on Linux.
(5) As a corollary to the above, almost everything you need is proprietary and costs a lot of money. Given that my job does not involve .NET/C#, it means I can only use C# in my personal projects (that's how people start). I don't like building projects on top of freeware and again, as example, for $299 per year, Xamarin doesn't even provide email support. And I could rant all day about how BizSpark / WebSpark suc
Yeah, if he had simply stated that he didn't use Windows, you would have saved yourself some time by immediately disregarding everything he had to say, such as his informative summary of the .NET's OSS ecosystem, which you simplemindedly equated to "don't like".
"People are always waiting for Microsoft to develop new software/tools/IDEs and it results in a delay and in a dependency when talking about adopting new technologies like SASS, LESS and CoffeeScript, even when a non-Microsoft tool is developed, people tend to wait until a Microsoft solution is released to start to use these new technologies.
When good non-Microsoft tools are released (Resharper, CodeRush, RedGate Tools, NCrunch and others), they are usually paid, looks like the community culture is, if people pay for new software, people will sell new software. IMHO, it breaks a little bit the concept of community, that is everybody helping each other to build better and better tools."
Mono kind of sucks full stop, which wouldn't matter so much if Miguel de Icaza didn't try and oversell it for tasks for which it was totally unsuitable. For example, for the longest time the Mono garbage collector was non-generational and certain kinds of objects couldn't even be garbage collected full stop. This meant that OpenSim, a long-running server app that ran fine under .NET proper, ran out of RAM and crashed within hours under Mono.
Miguel de Icaza's response was to run the server under both Mono and .NET without actually connecting to it so that it was totally idle, and use the results to claim that in fact Mono was more memory efficient and the developers of OpenSim were just spreading FUD. I am sadly not joking: http://opensimulator.org/wiki/Mono
The Mono GC has improved dramatically in the past year. It's still not as fast as the CLR's or the HotSpot JVM's, but it's miles better than the old GC.
F# ran okay under the old GC (Mono 2.x), but tended to be a little crashy because it put a lot of stress on the GC (as functional languages tend to do). I haven't had any problems with the new "sgen" GC though (it's now the default in Mono 3.2.x).
But look at C# - since after they shipped version 3, they practically stopped doing anything neat with it. They haven't cleaned up any of the v3 features introduced (like type inference or expression trees) - it's just sitting there. In fact, from some of the statements I've read, it sounds like MS has purposely stagnated C# to avoid alienating their enterprise customers.
They mismarket F#, preferring to say it's for scientists and financial programmers. Instead of marketing it as what it is, a much more capable language all-around, unless you need certain GUI/tooling support.
These kinda things don't help .NET's reputation. If a non-MS affiliated company marketed a language as lean as F#, with as good a runtime and editor/debugger, they'd be a huge amount of "hipster" cred and praise.
C# 4 added serious dynamic typing, so that you can make ruby/pthon/js-style dynamic objects;
// properties not declared anywhere; runtime property definitions
dynamic myObject = new JavaScriptStyleObject();
myObject.firstProperty = "hello";
myObject.secondProperty = 1;
C#5 added async/await, which I think is one of the most 'integrated' ways I've seen of doing async programming. Think node.js with a lot less syntactic cruft around the callback functions; in C#5 you could write, say;
// evented I/O using the 'await' keyword;
var fileContent = await ReadFile(@"c:\foo.txt");
Console.WriteLine(fileContent);
rather than;
fs.readFile('c:\\foo.txt', 'utf8', function (err,data) {
console.log(data);
});
This eliminates the need to write lambdas while retaining the evented I/O style.
Both of which have been in F# for years, and C# re-implemented them later, poorly. F#'s dynamic is extensible (and around since 2007? 2008? earlier?)). If you wanted to implement a "dynamo" object, go ahead. If you want loosely typed CSV-reader access, go ahead. (You get the ? and ?<- operators to define as you'd like.)
C#'s async comes from F#'s async (available since Oct 2007), which in F# is just a library. That's because F# supports workflows aka computation expressions aka warm fuzzy things. What F# does as a library feature, C# requires baking into the compiler.
So for 5 years now, MS has added these two features. They've still yet to deliver a REPL, or finish implementing type inference, or any such stuff. It looks like Anders Hejlsberg, the main C# designer, seems more interested in adding some basic features to JavaScript, lately. C# seems fairly abandoned, language-wise, to me. They seem to be content to have put Java in its place, and leave it at that.
P.S. C#'s a great language, and I'm not trying to insult the people that have done great work on it. As a popular language, it's one of the nicest ones out there IMO.
I would dearly love for the C# type system to get a bit stronger and less verbose. It's also confused, I think, because you have explicit classes, anonymous types, and dynamic, and they aren't always very well put together. I actually also like what Anders did in TypeScript around structural types, and wouldn't mind some of that mojo in C#.
I take your point about pace, though. I wonder how it compares over the same timeframe vs other languages? In the 5 years for C# to cover that distance, what have other languages achieved? The biggies are particularly interesting (JavaScript, Python, Ruby, Java, C++, etc) because users probably demand more in terms of support and compatibility. (For others contributing, I'm thinking language-specific, so not libraries, frameworks, or runtimes, just pure syntax.)
It's also worth throwing uptake into the mix here; it's not much use if there's a version of the language defined in a spec but everyone's using the compiler from 1999 (JavaScript, I'm looking at you) I'm not a pythonista but I understand Python 3 has struggled with uptake, too. Not too sure of the details; happy to be corrected.
> C# 4 added serious dynamic typing, so that you can make ruby/pthon/js-style dynamic objects;
So you can match the so-so performance of dynamic languages (which is debatable, BTW) with C#'s horrid (when compared to Python or Ruby, at least) syntax.
I fail to see the advantages here. If I'm doing something that demands dynamic types, I do it in Python. If I need static-types, I do it in C, C++, Objective-C, Go, Java- whatever better fits the problem.
The purpose of dynamic is not to turn C# into a dynamic language. It was added to make it easier to interface with certain other parties. Sometimes you just don't have the type information (practical example is handling JSON data) and dynamic can make the code cleaner in these cases.
Dynamic typing support helps in a pinch in C#, as you can avoid a lot of code in some cases where performance isn't paramount. I've personally used that in a few cases in the past.
Static typing helps generating very concise and fast native code. I'd go with C or C++ when speed and or very precise control are absolute requirements. It also doesn't hurt you when you have a clearly defined problem that will never change - when you know you'll never receive a float instead of a 64-bit integer.
But there are other reasons to pick static typing. Using Java is natural for writing Android apps, Go has a very natural syntax for expressing concurrency and C# is the best choice when you want to write a Windows app. A programmer should always pick the language that better fits the problem it has to solve.
C#5 added async/await, which I think is one of the most 'integrated' ways I've seen of doing async programming.
What's with the C# developers ans async/await? Almost every time I read their exhortations it feels like they're blissfully unaware that other languages have already had their own mechanisms for doing concurrency.
We're talking languages here; the way a grammar construct helps the programmer.
The C# async language effectively writes a whole batch of code that you'd need to write yourself in other languages; try/catch blocks, callback functions, thread synchronization code, code to wait for results, etc. In effect, it makes into a language feature something that has previously been considered a design pattern.
So something like this in C# 5;
01 var foo = await LongProcess1();
02 var bar = await LongProcess2(foo);
03 var baz = await LongProcess(bar);
does a significant amount of work. If I were to code it without the language support, I'd be writing a great deal of crufty code to handle errors, to make sure one thread completes before using the result in another thread (see foo set on line 01 and used on line 02 for an example) and it avoids the callback hell problem of languages like JavaScript, which become apparent in Node.js programming, for instance.
I'd be interested to know what other mainstream languages have as complete a solution for asynchronous programming -- afaik, JS, Python, Ruby, Java, and C++ don't have this. I'm guessing erlang probably has it built right in, but I'm not sure. Anyone care to share?
We're talking languages here; the way a grammar construct helps the programmer.
So do I. We've had CSP, Occam, Newsqueak, Alef, Limbo; now we have Erlang and Go. I'm just puzzled by the walled garden phenomenon present in such communities as that of the .NET programmers. The very fact that you're comparing C# to Node.js (!), of all things, just confirms it. It isn't very difficult to beat Node.js in terms of the language quality. Hardly seems like a fair fight to me.
It's hard for me to see how I'm living in a walled garden here. If there is a Microsoft walled garden, Hacker News is very much outside the wall, isn't it? I'm here, not on MSDN, trying to have a reasoned conversation with intelligent people from different backgrounds, showing code samples, and asking openly for information about other languages. What else should I be doing?
> The very fact that you're comparing C# to Node.js (!), of all things, just confirms it.
The node.js comparison is fair, I believe. We're talking about language support for asynchronous programming, particularly the evented I/O programming idiom. That's exemplified by C#/await, and the Node standard libraries, and python/twisted, and I'm sure a lot of others.
Node is a very popular, visible platform which takes evented I/O as a core concept, so it's reasonable to compare the implementation of the idiom in C# to the current poster child. Is there a better comparison I missed?
> We've had CSP, Occam, Newsqueak, Alef, Limbo; now we have Erlang and Go.
Agreed. That's fine, and I specifically called out Erlang and asked for more info. However, the others you list suffer from not being mainstream development languages -- TIOBE[1] doesn't list any of them in the top 50 languages. Occam may well do it better, but since I can't pay the bills writing Occam, I'm more interested in the languages I mentioned -- JavaScript, Python, Ruby, Java, and C++. Feel free to throw in C, PHP, Perl or Objective-C. Do any of these languages have better language or core library support for async programming? Do they result in shorter, more readable, or more reliable code for parallel and async operations?
Your original reply -- "Almost every time I read their exhortations it feels like they're blissfully unaware that other languages have already had their own mechanisms for doing concurrency." -- suggests I'm unaware of something. Can you please start telling me what it is.
They've admitted that progress has slowed but have also explained why and it's got nothing to do with enterprise customers.
The reason is that they're rewriting the C# compiler using, er, C#. It's as part of an initiative called "Roslyn" that aims to make the compiler a pluggable component with a public API for the compilation AST.
They did a blog post recently explaining that whilst this work is ongoing they are trying not to change the C# language too much to aid them with testing and verification. But that once Roslyn is released they will start a fresh wave of language enhancements for C#. I think we all have some ideas on what those will be to start off with... proper tuples support, and probably some form of pattern matching.
What?? Visual Studio 2013 just shipped a week ago. They have released 5 versions of the MVC framework in the last 3 years or so. The new async/await stuff is fantastic. EF6 is new. SignalR is new. We get new Windows Azure SDKs every 3 months or so. They are constantly improving everything.
None of that, except async, is a C# feature. And that was taken from a 6-year-old F# feature of the same name, except in F#, it was implemented as a library, not baked into the compiler.
MS is moving .NET ahead as a platform, but C# doesn't seem to be doing much. As another comment said, they're rewriting the compiler and then are supposed to make it take off again. Still, 5 years with minimal additions seems "stagnant" to me.
> it was implemented as a library, not baked into the compiler.
You keep saying this as if its a bad thing. Personally I consider it the exact opposite. I have no experience with F# but my experience with features that are baked into the language vs in a library is that having a feature be a first class citizen gives all sorts of benefits in terms of usability, consistency, tooling support, not to mention being able to justify introducing the fancy new feature into your project.
Nothing about having it be a library means there's anything less in terms of usability, consistency, or tool support. It's not like people avoid System.Text.RegularExpressions because it doesn't have a compiler-intrinsic ~= match operator.
The exception I see is if a certain pattern requires a drastically different compilation method, even if only as an implementation detail. That would perhaps break debugging support. But that's not much of an argument, because nothing stops you from special-casing your tooling support (which you'd presumably do anyways).
It just seems incredibly inelegant to have to special-case things in a language when the general case could be implemented.
case /\(.+)!(.+)@(.+)/
nick, user, host = $1, $2, $3
...
vs
if( (match=new Regex("(.+)!(.+)@(.+)").Match(caseInput)).Success )
{
var nick = match.Groups[1].Value;
var user = match.Groups[2].Value;
var host = match.Groups[3].Value;
...
}
If I'm using a ton of regexps, having domain specific language support can certainly help keep things simpler and clearer, aiding usability by aiding readability. This is important enough people can and will resort to implementing their own domain specific languages. While I'm all for erring on the side of general purpose language features for a general purpose language, if only to reduce the possible explosion of corner cases for language design mistakes, discounting language level support as "inelegant" and having no benefits is, to me, tantamount to discounting DSLs in general for the same.
And perhaps you do so, but the argument doesn't resonate with me.
F# active patterns allow you to do exactly this kind of thing, in a general and extensive way, without building support for regex into the compiler. That's what I'm talking about.
And it takes all of 4 lines to add the support:
let (|Regex|_|) pattern input =
let m = Regex.Match(input, pattern)
if m.Success then Some(List.tail [ for g in m.Groups -> g.Value ])
else None
Boom, done. I'd call that a far more elegant approach than hardcoding regex into the language. Edit: And nothing is stopping the core developers from including such patterns in the standard library. So you get the best of both worlds, a common well-known manner, and a useful general purpose feature that people can extend and use if they need so.
Usage looks like:
match phone with
| Regex @"\(([0-9]{3})\)[-. ]?([0-9]{3})[-. ]?([0-9]{4})" [ area; prefix; suffix ] -> ...
If you look at how much has been added to say, python or ruby or java in the same time frame it seems comparable. .NET 4 (released in 2010, so really only 3 years ago) added a ton of new features (dynamic, better generics, better expression trees, optional paramters, etc.).
NET 4.5 was comparatively a more quiet, but I think that's just a consequence of the language maturing.
C# 4 did bring forward the covariance/contravariance feature that's been in the CLR since v2, yes. And they did add dynamic, which was the big major feature of v4.
Better expression trees, as I understand, aren't accessible from C#. That is, the C# compiler doesn't allow you to write arbitrary code as an expression. What shipped was the DLR-based expression trees, which are more flexible, but require a cumbersome API. So that's not really a feature. (Correct me if I'm wrong; I haven't used C# extensively since 3.0 as I moved to F# for .NET tasks.)
Optional parameters were a mistake to leave out of the original spec. MS insisted that providing a ton of method overloads was a more elegant approach, for some insane reason. And at any rate, the C# implementation C# is the same, lame, VB/C-style callsite embedded optional parameters, which hampers their usefulness (but it's still much better than overloads!).
Perhaps I have unrealistic expectations from C#, as I certainly don't appreciate the effort required to design a language for such widespread use.
> If a non-MS affiliated company marketed a language as lean as F#, with as good a runtime and editor/debugger, they'd be a huge amount of "hipster" cred and praise.
OCaml? Which is what F# is based on, compiles to anything (including fast native code), and is open-source?
Are OCaml's main libraries even threadsafe yet? Is there a smooth editor/debugger like Visual Studio? Just a quick look says the Windows version of OCaml doesn't even have a debugger. OCaml is neat, and more advanced than F# in some aspects, but I'm not sure the dev experience is nearly as slick.
Another thing not mentioned: libraries. Anything half-well designed on JVM or .NET has access to a massive amount of libraries (and both stdlibs are pretty complete). Depending on the project, that's not a trivial consideration.
You can get a fairly complete stdlib on OCaml too, as long as you are willing to commit yourself to using Jane Street Core rather than the one that comes with the language.
Perhaps because you're being pedantic about .NET versus the CLI? The CLI spec is a standard and open source. Microsoft's own version isn't open source (well, they did release an "open" source version, Rotor). But Mono's is.
F# has a very strong following on Mono though. In fact, I suspect a higher percentage of F# developers develop and/or deploy on Mono than any other language does.
You may not know this, but F# ships with the Mono distribution for OS X, and it may well ship with the Linux packages before long.
BTW, I maintain the F# port for FreeBSD, and the combination of F#, Mono 3.2.x, FreeBSD 10, and emacs is extremely fast and stable. http://fsharp.org/use/freebsd
That's true. Mono is generally slower than the CLR, though it has been improving ever since Xamarin took over. There's also an option now to use LLVM as the JIT compilation engine in Mono; for server-based applications (where steady-state performance matters more than start-up time), this can greatly improve the performance thanks to LLVM's optimizer.
With the improvements in the latest 3.2.x branch, I think Mono's performance is at least "good enough" for many use cases.
FWIW, I do a bit of F# + Mono development on FreeBSD 9 (and now FreeBSD 10) and have found the performance to be quite good. I wrote an installation guide (http://fsharp.org/use/freebsd) if you want to give it a try, e.g., in a VirtualBox VM.
Whilst no, the Microsoft CLR is not open source. It doesn't need to be. Because the CLI is a ECMA standard and known-good third party implementations (Mono) already exist.
The only thing to be gained from open sourcing the Microsoft CLR would be to benefit Mono. As Mono is the defacto official cross-platform port of the CLR. Since the Microsoft CLR almost certainly contains IP and trade secrets that they wouldn't want their commercial rivals to see, it would be more beneficial if Microsoft merely gave a fairly open code sharing and IP license to the Mono / Xamarin team so that they could benefit in the exact same way as though it were OSS MIT.
I can make the same comment about C#/F# guys when I show them Scala. Scala is a better, more powerful language. I quite like C# and do it for my main contract I have, but I am always missing features that Scala has, while I never have the inverse.
It's nice that F# has better type inference, but I feel like it really isn't that different than C#. If C# got rid of boilerplate, made brackets optional, and fixed type inference, what does F# buy you?
Workflows. Tuples. Immutable types. Inline functions. First-class functions. Definable operators. Pattern matching. Active patterns. Type providers (although full hygienic macros would be even better). Everything-as-an-expression. Lack of nulls. Nested functions. Discriminated unions. Quotations (expression trees are a weak hack just for LINQ-to-SQL). Object expressions. Concise function definition and application syntax (which naturally creates the illusion called partial application).
I make the inverse argument: At a minimum, you can use F# as C# but with better syntax. So what does C# buy you, if you're not using some of the VS designers?
Without workflows, you can't achieve e.g. async without building it into the compiler. You can abuse the LINQ syntax to simulate part of it, but you don't get proper exception handling, and it reads terrible as well.
Versus Scala, F# seems far more concise. Scala seems to be very Java/OO oriented, and comparatively verbose. I understand the type system is more advanced in Scala. But I've not written anything in Scala so this is sorta speculation. I'd be surprised to find that the tooling for Scala surpasses F#'s though.
You mean apart from discriminated unions, pattern matching, computation expressions, units of measure, partial function application, immutability by default and general lack of null reference exceptions?
I'll throw in my 2 cents about Xamarin: I'm amazed at how well it really works. I'm involved in a project right now developing a mobile app for Android that uses a USB-connected sensor to do color analysis. It's all been done in C#, and it's so nice to know that when we want an iOS version of this, we just have to do the storyboarding. Once that part's done, the app will already be fully-tested and ready to go.
Xamarin now also supports writing iOS and Android apps in F#; it's only a "preview" at the moment, but some of the Mono developers have been getting more involved in the F# open-source community and Xamarin recently hired a well-known, very skilled F# contractor to help improve their support for the language.
There is also the "dynamic" part of C# and the DLR. Here is a library I worked on to mainly showcase the dynamic features - https://github.com/manojlds/cmd
Clojure has some awesome libraries, but unless you can show some use cases where futures/promises and core.async make it possible (or even just easier) to implement functionality compared to async/await (or F# async) I'm not inclined to take your word for it.
CSP gives you everything async/await gives you, plus more. Channels can act as throw away promises, or as continual streams of events. Add to that the power of alt! (http://clojure.github.io/core.async/#clojure.core.async/alt!) and you got some very powerful primitives. There's nothing about async/await that's really new. You can implement these on top of yield (C#/Python), or with any language that supports the pausing and resuming of execution.
In Clojure CSP is implemented as a library (core.async), no changes to the compiler needed. Now that's power.
I agree, async is much more flexible and powerful when it's a library feature (as it is in F#) as opposed to being a built-in language feature (as it is in C# 5).
core.async looks very well-rounded, congratulations on a fine job.
Replying to myself, since I can't edit my post anymore --
Futures and promises aren't unique to Clojure. For example, AliceML had them ages ago.
After thinking it over, I'm going try implementing them for my ExtCore library for F# (https://github.com/jack-pappas/ExtCore). Thanks to the GP for the idea.
The biggest problem with C# and .Net is the Windows platform; very little on Windows can be automated. There is no sane shell. Everything assumes that there's a user clicking the mouse. And since that's the direction MS took, 3rd party devs followed suit. For anyone who has worked with another OS, Windows is fundamentally broken.
Think about it. Setup, Administration or Programming can't use any of the thousands of programs already written for the OS.
Most Microsoft-only developers don't get it. They usually say, "Oh, you should try Powershell". Powershell is, to put it mildly, 'utter crap'. They might have as well asked people to use a C# REPL with the .Net BCL.
I think your opening sentence is simply false; nearly everything on Windows can be automated these days, and usually without much pain. The real problem right now is that the WMI/WSH stacks, and the PowerShell stacks, overlap, but not completely; the right way to automate something requires knowing a lot about the old Windows automation stacks, and the new ones.
Let's take your example. The only reason it's shorter on Unix is that most Unix systems have programs called "zip" and "unzip". That's legitimate, but if we looked at e.g. modifying DNS, tweaking folder permissions, and a lot of other things, the PowerShell and bash/sh ways would be much closer. I'm not going to argue that PowerShell is a great language; I've been pretty public about hating it. But this isn't about whether Windows can be automated.
The real issue is that, for any given task, there's an easy way to do it in either the old COM-based WMI/WSH system, or in the PowerShell system, but not always both. Since we're on the topic of zipfiles anyway: the way I'd actually make a zipfile from a script would be to bust out the ol' "Scripting.FileSystemObject" COM object, which lets you pretend a zipfile is simply a folder, and which is merely a "$fso = New-Object -ComObject Script.FileSystemObject" away in PowerShell. One that bit us at work last week in a more real-world situation is that, while nearly all of Hyper-V is controlled via PowerShell, the network connection sharing settings are only available via COM interfaces, so allowing your Hyper-V machines to talk to the world still requires a trip back to the Windows 2000 administration handbook.
This stinks, and it needs to be fixed. I'll even grant that the situation might be worse than on many Unixes. But it's also totally automatable, and I'm not convinced that it's dramatically worse than other systems I've had to administer.
Until you have to cope with the fact that you have: Powershell cmdlets with their own specific behavior - mostly standardized; COM components loaded from Win32 - major pain in the neck - you basically need a huge brain to really understand all those rules and quirks; AND old school external commands - where all hell breaks loose since on Windows they couldn't standardize even the freaking exit codes (!0 is bad, fools, as Mr. T would say :) ). Yes, Powershell is usable, but it's really hard to write secure, reliable, maintenable scripts with it...
Your zip example actually demonstrates why Powershell is significantly more powerful than Bash (or any other Unix shell). I presume that if asked "How do you zip a file in Bash?" you would reply with something like this:
zip archive.zip folder
The equivalent Powershell code would look like this:
7zip a archive.zip folder
Pretty much exactly the same, since in both cases the shell isn't doing anything other than invoking a standalone executable. So this doesn't really tell us anything at all about the relative merits of Bash and Powershell. A better comparison would be this: how do you zip a folder in Python? Again via Stackoverflow (http://stackoverflow.com/questions/1855095/how-to-create-a-z...):
import os
import zipfile
def zipdir(path, zip):
for root, dirs, files in os.walk(path):
for file in files:
zip.write(os.path.join(root, file))
if __name__ == '__main__':
zip = zipfile.ZipFile('Python.zip', 'w')
zipdir('tmp/', zip)
zip.close()
Compare that to your Powershell example, and I think you'll agree that the .NET API is nicer to use (heh, don't say that very often). But to return to the subject, how do you zip a folder in Bash? YOU CAN'T. Bash can't zip folders. It can't call libraries that can zip folders. It can only invoke programs that can zip folders. And any shell, even the wretched cmd.exe, can do that.
I have plenty of problems with Powershell but it is by far the best effort at a shell that the world has yet seen. I come from a Linux background and when asked what I like about working on Windows, I reply with "well, it's got a nice shell." Usually gets me a weird stare, but if we're really comparing shells to shells (and not shells to a wide variety of standalone utilities) then Powershell blows everything else out of the water.
I actually don't like PowerShell, I don't like the verbosity of it all.. it's easy enough to get most unix tools in Windows (minw) variants... put these into a folder added to your path, and most stuff just works the same, or very similar. I tend to use the command line tools, and piping, or I'll use node.js scripts, which work pretty much the same everywhere I need them...
The only differences are nssm for windows services, and init.d for linux ... haven't had to setup any background/startup services on my mac yet, so not sure what it uses.
I don't get why people hate windows so much as a rule, I really like the Win7 UI (not a fan of 8, but can see how some would be)... Also, warming up to Unity (more than win8)
Agree about PowerShell. It's not just that the scripting language sucks, which as you show it does. But nearly everything about PowerShell is bad. For example:
1) It takes a good 4 or 5 seconds to boot PowerShell. This is unacceptable, a terminal emulator should boot near instantaneously.
2) Cmdlets are really freaking hard to write or use. It's hard for users to enable them, it's hard for users to install them, and it's especially hard for programmers to create them. Unix shells are much easier for all parties involved.
1: Just a note, PS is a shell, not a terminal emulator. And yes, Windows could really use a decent terminal program - the standard console is terrible.
2: The hard-to-enable is a result of Microsoft's pro-security standing. They got a bad rep for allowing scripts to run freely in the past, so they tried to lock it down.
As far as developing and using them, I dunno, it seems vastly better than bash. Sane quoting that helps avoid injection mistakes. Auto-complete built-in throughout the system. Actual types, instead of just passing strings everywhere. And they ship a nice little editor/debugger with it, if you'd like that kind of thing.
No, cmdlets are hard to develop. You have to follow a hard-to-understand API that doesn't ship with the operating system. With bash it is stdin and stdout... that's all you really need to know to write any shell script. With PowerShell you have to write a very particular type of script that compiles to .NET (and again DOES NOT SHIP WITH THE OS); your language choices are limited to about 3. Interoperability is important to something as fundamental as shell scripting and PowerShell is not interoperable.
I lost you on your "Does not ship with the OS" point. What are you referring to?
PowerShell has shipped with the OS since WS 2008 and Vista. We have ALSO made it available to prior versions of the OSes (e.g. down to XP.
I also missed your point about interoperability of shell scripting and PowerShell.
PowerShell can launch any process, pipe data to it and read/parse the data that it generates.
PowerShell can be launched by any process and read/write text.
So when you say "interoperate" that is what I'm thinking of so I think they interoperate well. Are you referring to something else or are you experiencing a problem?
Thanks!
Jeffrey Snover [MSFT]
Distinguished Engineer and Lead Architect for Windows Server and System Center
> I lost you on your "Does not ship with the OS" point. What are you referring to?
The SDK for developing cmdlets. This would be equivalent if on unix you needed an extra download to write to stdout/stderr.
> So when you say "interoperate" that is what I'm thinking of so I think they interoperate well. Are you referring to something else or are you experiencing a problem?
Cmdlets can only be developed by languages created by Microsoft. You cannot write a cmdlet in Python, Perl, or even C.
The app tends to boot fast but you have to wait for .NET to warm up before you can use it. I'm talking about usability time. It's also much faster after you've initially opened the app.
1) What version are you running?
We had a problem with earlier versions that didn't NGEN and had startup delays.
With V2 we made it so you can write cmdlets in PowerShell itself which is pretty simple.
With V3 we added auto-loading of Modules which allowed Xcopy deployments and simplified discovery.
We just released V4 so you might want to give a more recent version a try.
2) What don't you like about the language? Is it just personal preference or are there things you can't do or are too hard to do?
Thanks!
Jeffrey Snover [MSFT]
Distinguished Engineer and Lead Architect for Windows Server and System Center
That is an absolutely fair rock to throw. What we find is that if PowerShell has a cmdlet for what you want to do, it is pretty simple to work with (modulo personal syntax preferences). If there isn't a cmdlet, then you can usually get the job done but you need to roll up your sleeves and do some coding (or searching/downloading).
This is not that different than Unix BUT because so much of Unix is done using ASCII text files, the coding is really manipulating text files which can be done easily by admins. Windows is an API-oriented OS (vs a document-oriented one) which means that the coding looks much more like programming than in Unix.
The solution is to have the cmdlets you need. We are making great progress on that front but the reality is that Unix has about a 30 year head start so it will take us a while. In V2 we had ~240 cmdlets and in V3 we had ~2,400 cmdlets. (Sadly, ZIP/UNZIP are not among them). We added more in V4 and are extending our focus (from IT pros) to devops with features like Desired State Configuration. That is very much of a minimal viable product but I think we got it basically right and there is a lot of energy around this.
I appreciate the criticisms and encourage you do continue making them and don't hold back - we really do read these and use them to make the product better. Politeness is optional but we would really appreciate specificity (like you provided here).
Please let us know other things that we should be adding, doing differently or stop doing.
Thanks!
Jeffrey Snover [MSFT]
Distinguished Engineer and Lead Architect for Windows Server and System Center
That has nothing to do with Windows as an Operating System -- thats just part of the tooling that is included. Feel free to install additional tools into the PATH on Windows and get the same capabilities.
A lack of understanding of how to do something on a very different OS != you can't do it.
I very much dislike PowerShell personally but its incredibly capable in modern versions of windows. We use it with Chef to automate our server configuration/setup.
> as an Operating System -- thats just part of the tooling that is included
An operating system includes the tooling that comes with it. This is what distinguishes Debian from other linux distributions: what tooling comes with it? It matters because it directly determines what you as a user can get done quickly, without needing to go through the trouble of installing additional functionality. (Or, as a developer, what you can do without needing to distribute or include additional functionality.)
Windows is particularly bare in what it comes with: many tasks that I need to accomplish require additional tools. I often field questions of "how to do X on Windows?" that cause me to think, "well, this is a built-in command in Linux… in Windows, you could download X or Y, but they're not scriptable to what you want to do…"
This is what drove me to Linux: The batteries are included. And they're scriptable.
Does it require you to open a browser and download the software?
Does it require you to FTP to a server to grab the file?
Does it require the server to fetch it via network file system and launch the installer UI?
Do you have to add the tool to "PATH" on windows? (unless the installer does it for you... which is variably on Windows platform).
The culture of Windows platform unfortunately dictates you how to use Windows as an OS.
Now let's go to Development Code type of dependencies (we're talking about libraries and stuffs here).
NuGet has reached the "accepted" level of dependency management _recently_ (for a while in the past, it couldn't download the Source Code as well. Maven, RubyGems, and others can) while other platforms have dependency management for years _and_ integrated to developer daily workflow.
What about scripting the build for .NET type of development? I don't know the exact number but I still see people not using MSBuild (or even know what it is) or NAnt.
Most Java IDEs would generate build.xml for your project and would provide you hints that you should be using that instead of "Build Project" (or perhaps the "Build Project" is tied to Ant, by default).
Besides, both MSBuild and NAnt are painful compare to Maven, lots of boilerplate stuff to setup.
What about Continuous Integration and Deployment? Microsoft didn't build one for a while (not sure if they've built one and baked it into TFS) and y'all have to rely on CruiseControl or TeamCity or Bamboo or something else.
I recently interviewed a senior .NET developer who said to me that he deploy his ASP.NET project from VS.NET IDE (like y'know... hitting F5 or something) to the Production server!
Let's take it a little bit further: Docker and Vagrant are useful tools for automation testing. Docker doesn't exist in Windows. Preparing Vagrant for Windows require you to have licenses and probably you have to figure out how to script software installation (you could cheat a little bit by preparing a Windows OS + a base software installed). Compare that to Ubuntu on Vagrant: breezy.
I think the pattern is rather quite obvious: Microsoft/.NET community has always been behind everybody else.
At the end of the day: you cannot automate the process of calling a Sales person in order to get the software, which, in the F/OSS world, such workflow doesn't exist.
You've move the goalposts a bit here, but for the sake of discussion...
On windows we have Chocolatey available to help with application-level package management, granted you need to install it first but I would argue thats not much different than needing to add a PPA or new apt source before apt can install the right app/version you're looking for..
It isn't perfect but its getting better. No UIs launched, all done via console. Handles adding items to the path, handles portable executables, etc.
NuGet is great, apart from a few issues and has been in that state for quite some time. Not sure why we require things to be good for a decade before we're ready to talk kindly about them without the air quotes.
There are a ton of tools for scripting .NET builds but the real trick is that most people don't need to do anything 'special'.
msbuild Solution.sln or msbuild Project.csproj
Your project files can include any number of pre/post build targets to handle any scenario you can imagine. Again, not perfect but manageable. If this isn't to your liking you can use all the build tools for other languages if you like.. Many people like Rake as a general purpose tool and others have done the work of providing msbuild integration there for you.
Your .csproj file is built for you by Visual Studio (or by hand if you wish) and from there you can add much of what you need for your builds. I have worked on several very very large codebases for enterprise projects and there has never been any serious amount of 'boilerplate' to setup for builds.
What about Continuous Integration and Deployment? Microsoft didn't build one for a while (not sure if they've built one and baked it into TFS) and y'all have to rely on CruiseControl or TeamCity or Bamboo or something else.
For CI, you can use TFS if you wish (really, really easy to do but somewhat limited in its ease of customization), or Jenkins, TeamCity, CC, Bamboo, whatever.. Its the same for any language. Pick a CI tool, install it, use it. Hardly a weakness of one platform over another.
As far as deployment, that depends on the type of application you're building. Could be as easy as a git push that deploys to Azure/AppHarbor or it could by a PowerShell script or possibly a ClickOnce deployment. Any one of these can be triggered from the VS IDE.
I recently interviewed a senior .NET developer who said to me that he deploy his ASP.NET project from VS.NET IDE (like y'know... hitting F5 or something) to the Production server!
Certainly this must be the norm then. Capability to deploy from the IDE is great for testing but the same things are available for scripting to put in a real deployment process.
Let's take it a little bit further: Docker and Vagrant are useful tools for automation testing. Docker doesn't exist in Windows. Preparing Vagrant for Windows require you to have licenses and probably you have to figure out how to script software installation (you could cheat a little bit by preparing a Windows OS + a base software installed). Compare that to Ubuntu on Vagrant: breezy.
Yes, containers are great. Windows doesn't have them in the sense that Linux does with LXC. Vagrant can and does work well on Windows. The licensing situation isn't as you think though for most .NET devs - they are likely working with MSDN provided software which provides licenses. As for scripting installs, again - chocolatey. Vagrant + chef is a win on any platform. I do wish it worked with Hyper-V client services properly though.
At the end of the day: you cannot automate the process of calling a Sales person in order to get the software, which, in the F/OSS world, such workflow doesn't exist.
At the end of the day: people believe what they want to believe. Windows as a platform is incredibly capable. Its not perfect and it can't compete on every level but it is getting better constantly.
I work with Windows daily - using .NET, Node.js, Ruby, Python and more. I also work with Linux daily doing the same things. The biggest issues I encounter have more to do with package developers using non-portable code than anything.
I definitely agree with you that Microsoft is listening on the server side. The biggest change that really made me realize this was with the release of Windows Server core.
Also, the release of PowerShell as the glue for automation has really made so many things possible. PowerShell is not perfect but it is definitely making a difference in the Windows ecosystem.
Sometimes it seems that people that are criticizing Windows are still stuck in the Windows 2003 world and pre-Powershell days.
One can basically automate Exchange, SQL Server, IIS etc. using Powershell. Granted, there may be still edge cases, but for the most part it's all there.
This is empirical but I also feel that over the last 5-6 years Microsoft has really started to take the best of linux and open source and start to incorporate it into its ecosystem. There are still scenarios where this is not the case but I do notice the trend.
I echo the other reply, thanks for writing long detailed response. MS does try to improve albeit slow and ugly (but that is for another discussion altogether).
Having said that they are always behind (that seems to be the trend).
IMO the problem with bash piping is that it's just text streams. Which means you end up having to do all sorts of text manipulation tasks if something outputs a complex object. Compare to, say, PowerShell, which pipes objects along. You can treat them as a text representation, or operate on their properties without having to embed a little parser.
I'm not sure what about F#'s piping syntax (it's just reversed function application) blows bash away, though.
FWIW:
F# ships a standard definition for the operator |> as "let (|>) x f = f x".
Hence you can do e.g. "123 |> write" instead of "write 123". In practise this leads to normal chaining of map/reduce and other list manipulations. In F#, this operator also gains attention as F#'s inference is left-to-right, so suppose you have a list of strings "xs". Without piping, you might write:
Again, you are piping functions, not programs. Piping programs is important to shell scripting. This is actually very hard in PowerShell. I've written a few cmdlets; it is hard. And even harder for the user.
Can you provide an example of some task which is easy in a shell script (sh) and difficult in PowerShell? Perhaps something related to piping?
I've written a few .sh scripts here and there and I use PowerShell occasionally; I'm nowhere near an expert in either though, so a concrete example would make it easier to understand your point about PowerShell being more difficult.
Both of those links require a browser plugin that I'm not going to install. From the url's I'm guessing this is about piping functions? I'm not asking about that, I'm asking about piping commands (programs), something any shell scripting language needs to be able to do.
Mono works just well enough to convince people that C#/.NET is an acceptable cross platform solution. By the time they realise it's so buggy and unreliable compared to .NET that they'll have to shell out for Windows licenses, they're stuck with it.
See, for instance, keithwarren's comments in this discussion: he hypes up Mono-based cross-platform support in what's currently the top comment on this submission[1], but when someone who's actually tried Mono replies and talks about the problems they've had with it, he makes it clear that they should shut up, forget about Mono and use Windows[2].
The first time I used Mono in a production environment (part of a payment connector running on a Linux system) was around a decade ago.
Since then I've had daemons running 24/7 doing telecom processing (either routing decisions or call record management), written in F#, running on Mono. We build, debug, etc. on Windows, then deploy the binaries to Linux. It works surprisingly well. These aren't massive systems, and I tend to deplore the handful of core systems (i.e. website) on Windows but all the actual call handling goes on Windows.
The real problem with Mono was the naive GC which for some applications had very degenerate and broken behaviour. AFAIK, the sgen GC has cleared that all up.
Your characterization of the comments are very misleading.
There is also jscript, it's been there for a long time and can be very powerful! It's available also on machines that don't have powershell installed (like windows xp).
I agree. I'm very proficient on any version of Windows but when I started learning web development I was stunned by how hard everything was in Windows. In fact, my immense displeasure with Windows as a development platform is what drove me to consider Linux and Mac. And one I discovered that both of those platforms offer significantly saner development workflows, I've never looked back. Now I use Windows exclusively for Excel and Access. Everything else is done in Linux or Mac.
Of course, there are limitations but there are fantastic projects out there that have been made with all free Microsoft development tools. Visual Studio 2013 Express is really an amazing, free development environment. Combine it with SQL Server 2012 Express which is the free version of SQL Server that works on databases up to 10 GB and you can see you can do a lot with free Microsoft software.
Don't think you're being unbiased here. Using C# inevitably means you will be shelling out for various tools along the way that you would never have paid for if you went with something like Python. Granted, if your business is making any money these costs are not going to have any real impact, but passing it off as 'no costs' is silly.
Funny you mention python as, until last month when PyCharm community edition was released, there was no decent and free IDE for python. :)
I can't think of any tools for .net that are really must-haves and that cost money. Maybe resharper but you can survive without it. There are free profilers, decompilers, analysis tools, SCMs, you name it. The only thing you don't get with express is integration with plugins in the IDE. Using .NET with free tools is also easy, connecting to MySQL is just as easy as to MS SQL Server to give an example.
Meanwhile, Python Tools for Visual Studio is a great IDE for Python, IMHO. Of course, being a free plugin for VS, you need a paid license of VS to use it.
No you can just download the free isolated/integrated Visual Studio shells - PTVS works just fine. And, imho, it's the best Python IDE I've worked with (I mostly use pandas/numpy/scipy)
How am I biased? I don't work for Microsoft. If using a technology stack makes one biased and thereby (as you imply) invalidates their opinion, then let's just shut down Hacker News right now because nobody is capable of expressing an unbiased opinion in your opinion.
The reality is that Microsoft has free development tools that millions of people use - for free.
Just to throw in another point here - while the development tools may be free, licencing SQL Server(s) for production use can be very expensive & convoluted.
licencing SQL Server(s) for production use can be very expensive & convoluted.
It's not convoluted at all.
Want a free on-premises database? Simple. Use SQL Server Express. That will handle a database up to 10 GB.
Want to have Microsoft host your SQL Database for you? Simple. Use Windows Azure SQL Database. $10 per month for 1GB and then $3.96 per GB per month after that up to 10 GB and then cheaper from there.
Have you ever even looked into using Microsoft software or did you just immediately dismiss it without looking at it?
Ok, but you will lose the plugins support and will also have to change the Visual Studio Express with you want to work in another project type (web, mobile and so on).
<sarcasm>what's with all the Microsoft shills on HN lately?</sarcasm>
I love C#. I have a project right now built in it. Everybody talks async/await--which is certainly great--but there is a lot to love in C# and .NET that have been there for a long time. Real generics. The reflection libraries are outstanding and extent easy to use. Dynamic assembly loading is just downright awesome and also easy to implement. I could go on, but there is a beer in front ooh me getting warm.
Reflection showing erased types. Slow collections because internal arrays are object[]. Various caveats with bridge methods/ClassCastExceptions. The list goes on and on. Erasure isn't a pragmatic design decision, it's an utterly and fundamentally broken design. Reified generics are both simpler to implement AND more performant AND more powerful in terms of metaprogramming. I fail to see the argument for erasure apart from backwards compatibility (which isn't really an argument).
To be fair, very few languages have type systems as powerful as Haskell's ;)
You're right though -- the .NET CLR type system (specified in ECMA-335) basically supports only a simple form of parametric polymorphism with subtyping constraints, along with co- and contra-variance. The idea is to allow some limited forms of generic programming while keeping the type system simple enough that it doesn't impose significant overhead during JIT compilation. Another advantage, is that it allows the JIT compiler to generate type-specialized code, which offers a significant performance advantage for unboxed value types.
The F# type system is a little more powerful, though anything it offers beyond what the CLR officially supports gets erased when the program is compiled (e.g., unit-of-measure types). See: http://msdn.microsoft.com/en-us/library/vstudio/dd548046.asp...
One interesting thing I've realized recently is that F# could potentially support GADTs in the future, just like Haskell and OCaml. The hard part -- the GADT type inference -- would take place at compile time, so there shouldn't be any problems encoding the result (the inferred type) in the CLR's type system.
If you're interested in type systems (and as a Haskeller, I imagine you are), there's also F* -- it's a dependently-typed variant of F# which is being used for verification research at MSR: https://research.microsoft.com/en-us/projects/fstar/
If you're interested in type systems (and as a Haskeller, I imagine you are)
Bah! Interested, definitely yes, but I share Alan Kay's point of view that "I like type systems but I don't know any that doesn't suck", so in this particular area, I'm a bit of a Luddite. (I'm much more of a lisper in heart.)
BizSpark is great for technology startups - free software and $150 per month worth of Azure hosting for 3 years. That's enough to get a medium-sized VM or a ton of SQL Server databases or a whole host of other hosting resources.
"Unlike Visual Studio, MonoDevelop is free and open source."
Probably many are aware, but there is a free Express version of Visual Studio. I stopped paying for Visual Studio a couple releases ago and have been getting by quite nicely with the free version.
MonoDevelop is free, but if you have a large code base, it's very slow. As in "wait 30 minutes for MonoDevelop to start and analyze the entire project" slow. And then the crashes...
Xamarin fixes all of these problems. But then, the free version is limited and the paid version is very expensive. When it comes to IDEs, you really do get what you pay for.
In my opinion a developer should always pursuit the better setup to be able to use all the features that a platform offers. Visual Studio Express lacks important things that the Ultimate Version has.
There seems to be a lot of attention on cost of the tools and almost nothing on developer productivity.
Assume I have to buy the expensive $10K Visual Studio license then pay $3K/year after that. Put developer cost at $100K per year. You need only a 10% productivity gain to break even in year one.
My thoughts are that I'd get 10% just from the awesome Intellisense code completion and navigation support or from the Entity framework.
...
My only reservation about C#/.Net is that all of my peers are in the Unix side of the world. I feel like Microsoft has been losing mindshare among the top tier of engineers. Oh, and it is really nice to be able to spin up 1000 VMs without having to pay an OS tariff.
This is my reservation too. As a .NET developer you can often feel alienated because of the platform you build on.
About a year ago, I picked up Python because I wanted to build a site using Django. I decided to fire up my Ubuntu VM, and work my way through the official tutorial. The language was easy enough to pick up and within a day I finished the tool I was building. However, I would have finished it in half the time if I was working on Windows. As much as I love the Terminal, my main time-sink was getting used to working in Linux again. After two hours I ended up downloading PyCharm because Eclipse was as awful as I remember it from my Java days (I downloaded Eclipse because using a text-editor was so slow!). I know some fantastic C# developers, but if they wanted to work in Ruby, Python, or any other language outside of the .NET framework I bet that most of them would struggle; not with the language, but with the tooling and Linux.
I absolutely love .NET and C#, and I'm very happy working with them, but I don't like the idea of being restricted. If I lost my job and a great opportunity came up in a Python shop I'd like to be confident in my ability to move to a different platform. That jump seems 10x worse if you're also jumping OS.
Working without plugins support is not a option for me. We have to always try use the most productive environment and if we can't do it due licenses cost, it's time to analyze the platform.
Ah... that is a really good point. It is so easy to get blinded by being in the US.
Thank you for the clarification.
However, at those salaries, I could hire you and 2 of your friends, pay for the tools, and still come out at $100K.
I've got a tremendous amount of respect for technical talent in the rest of the world (i.e. -- most of the smart people in the world don't live in SF) but the problem I have is that I have no clue about how to find, hire, and manage really good people outside of the US. Hell, it is hard enough with a common language and culture.
I've always thought that Microsoft tools are priced accordingly to the region, I assume that it's adjusted depending on the purchasing power of the consumers?
e.g. Visual Studio costs $500 in the US, but it's at least twice that here in Australia.
I've actually found it to be incredibly strong, but they've centralized around StackOverflow rather than Microsoft's forums. There's not a ton of activity on Github, but it's by no means a small community; and as far as I've seen most of the projects are quite collegial.
An analysis of C#/dotnet should be much deeper than this to provide an accurate picture. And, because of that fact, one can draw inferences about the platform -- namely, that it's a rather sizable one.
Whether you love it, hate it, or simply have to live with it, the dotnet platform is pretty robust -- you can create a LOT of different things with it. Web, desktop, service, mobile -- it may not be the best in any or all of those scenarios, but it's all very do-able with their toolset.
As with any technical platform, it's really best evaluated for depth in specific scenarios.
" // use .Not(), for me, is more elegant than use the '!' operator "
That's like doing "#define BEGIN {" in C.
I'd also make a note that if you're considering .NET, F# is a better language than C# in nearly every aspect. C#'s development is practically stagnated, at least from an outsider's point of view.
As a comparison, the F# code of his example is just:
type Student = { Age: int; Name: string }
let student = { Age = 17; Name = "Paulo Ortins" }
let PrintAdultStudent student = if student.Age > 18 then printfn "%s" student.Name
That's 176 significant chars versus 267, and as normally formatted, 3 lines versus ~9. Once you start using F#, going back to C# is just painful due to the incredible verbosity and lack of critical things like pattern matching (active patterns are amazing) and good type inference.
Because in 5 years of development now, C# has only shipped two major features: dynamic and async. Both of which F# has had since 2007 (maybe dynamic was 2008). Both of which F# implemented better (as libraries, so you don't need intrinsic compiler support). Async's design comes from F#'s design.
But without comparing it to F#, Microsoft has not polished the C# 3.0 design. Expression trees are still half implemented (no way to call one exptree from another). MS created anonymous types, but neglected to add simple types like tuples (let alone anything more advanced). Type inference is still ridiculously limited in scope:
- Neither parameters nor members can be type inferred.
- Local function vars can't be type inferred (because they chose identical syntax for expression trees).
- Generic constraints can't be type inferred.
- Generic parameters have limited inference. If one parameter can't be inferred, you _must_ specify all of them.
On one of the developer blogs, they noted that the reason fields couldn't be inferred was really due to internal compiler codebase complexity. Yet 5 years later, that's still not taken care of. Basically, they aimed for the LINQ outcome, and implemented the required feature set only within the context of LINQ, not for the language as a whole. Which is fine for V3. But then they just left it at that.
I love F#, and greatly prefer it to C# for most tasks, but I think you're overreaching a bit. C#'s dynamic feature is also extensible (via IDynamicMetaObjectProvider) and much more complete than F#'s (e.g. F# probably ought to have (?[]) and (?[]<-) operators for dynamic indexed properties). Likewise, there are several real benefits to having built-in support for async/await, such as the improved performance of a state-machine-based approach and a far better debugging story (e.g. call stacks that are async-aware).
C# is truly a great language; it was just created by people who have different priorities than you (or I) do.
You're right, you can implement interfaces for C# dynamic extension, but that won't help against existing objects. But I'm out of my league here, because every time I see an API that shows off dynamic, it boils down to saving a handful of quotes. I get the feeling F# added it just to say "yeah, what's your point?"
The benefits of built-in features you mention can be accomplished by special-casing as an optimization. Zero downside language wise, only requires some level of more resources for the compiler writers. For debugging, seems like the same amount of work; either way it has to reconstruct the "async stack". Best of both worlds, no downside.
C# is a great language, probably the best of the mainstream ones I'd say. But I still find it severely lacking in some areas, with no justification other than lack of desire/resources (type inference being the #1 case).
C# has tuples[1], but I'll agree they are not built into the language. Being able to have multiple return values from a function would be really nice rather than having to go
return Tuple.Create(valueA, valueB);
Likewise being able to declare functions as returning multiple values in a natural fashion would be really cool.
But both of those changes are very much sugar, neither of them would make the language more powerful.
By that definition, any language that has user-defined types has tuples. Proper tuples are represented as a kind of type, not just a Tuple class.
As far as sugar - if the language is Turing complete, then every feature is syntactic sugar. You need a perverse definition of power to suggest that being able to properly handle tuples via deconstruction doesn't increase the power of the language.
> As far as sugar - if the language is Turing complete, then every feature is syntactic sugar. You need a perverse definition of power to suggest that being able to properly handle tuples via deconstruction doesn't increase the power of the language.
The difference in this case is just a couple of lines of code.
Compare that to C, where it would be a great deal more work!
(Of course a good deal of this difference is in C# using and abusing the heap so much.)
> As far as sugar - if the language is Turing complete, then every feature is syntactic sugar. You need a perverse definition of power to suggest that being able to properly handle tuples via deconstruction doesn't increase the power of the language.
Well yes, but there is the matter of how much mental effort the transformation from idealized software engineering concept to actual implementation takes the programmer.
Tuples in C# don't require that much mental effort, sure it'd be great if they were a native part of the language, but they aren't unreasonably unwieldy.
That said there are certainly times I wish multivalued returns were a natural part of C#!
Of course the problem with returning multiple unnamed values is that you can easily lose semantic information. (obviously I am ignoring comments above a function) It is not too hard to indicate the meaning of a single return value from a function, but beyond that it can get a bit harder.
(Yeah I know the scripting language people don't care, but with every passing day I am more firmly in the static typing side of things, I like my fields with both names and types!)
All that said, I can only imagine how much more productive the 80s 90s would have been if C had supported multiple return values from a function. In the very least Windows programming and HRESULTs would have been a fair bit saner!
(I do find it funny that seemingly no compiler vendor ever extended C to add multiple return values into it!)
Since then, F# has a full LINQ-to-SQL generator (via the Type Providers mechanism), so you don't need that part of the interop.
Also, this is more of a Visual Studio/web framework issue. The VS people chose to ignore F# with their project type specifications. And the MVC people are very C# oriented, depending on C#-compiler implementation details for many of their methods.
Frameworks like WebSharper, for example, allow you to use full F# across the stack.
On the other hand, using MVC with F# controllers is very smooth, and you can use C# on the rendering engine, as there's rarely much code at all going into the actual view part.
About the only thing I know of that you can't do with F# right now (in terms of web development) is write inline code in ASP.NET MVC Razor views. That's not too big a deal though, since you can still write the guts of the application (e.g., your controllers) in F#.
Maybe the lack of a strong community is because of Microsoft trying to build it around itself, while always trying to push the new thing. WPF as an example.
That's the risk of the .NET ecosystem -- depending on any particular technology within the stack is fraught with peril, simply because MSFT has proven it's willing to kill support for any product, service or technology at any time. I personally love C#, and I'm faster and more fluent with it than Java or Scala, but the technical risk plus the much higher TCO relative to a *nix+JVM stack makes it hard for me to justify it for solutions that don't already have MSFT enterprise licensing in place.
I use it all the time, but it's not exclusive. Love msdn too. But like all communities built around large entities, there will be some product pushing that's not very organic, and gets adopted regardless of merits.
WP may not pass iOS's market share in the US market by 2015, but it is growing by leaps and bounds in many of the other major markets (e.g., Europe, Russia). A large part of this success is thanks to the lower-end Nokia Lumia models like the 521, which are competitive with lower-end Android phones on price while being generally higher in quality.
I have a running bet with a friend that it will be. I made the bet several years ago before its actually starting to do in other markets already.
When I made the bet my friend (who works in the cell phone division for an large multinational) was adamant that Android would take over. In the past year the company has decided to removed all Android devices due to support cost/issues and moved to iOS. (I don't know the specifics as to what the android problems where, so don't bother asking, but he said management was very unhappy with them).
I don't see iOS being more useful to a business in the long than windows phone. I'd say in two years time when they review purchasing again that iOS isn't the favored choice, and my bet finally come to fruition.
Wow, that was strangely lacking in hyperbole for Hacker News.
I've used C#/.NET for years now, and it's been quite good - no real complaints and a lot of enjoyment. Also, you don't have to worry about expense when you're company buys the tools, and I believe there are some good discounts if you have Microsoft Certified type people on your staff.
What would it take for MS to make C# fully open source with no threat whatsoever of patent or copyright litigation? Is it really a strong selling point keeping companies using Windows? Now that MS is the underdog in the mobile wars, wouldn't it benefit them if developers of other platforms adopted C#?
They already gave F# away to the community. I don't see why they can't do the same thing with C# and hopefully all of .NET. Maybe the post-Ballmer MS will do it.
This will be interesting to watch. The guy to keep tabs on is Scott Guthrie -- if C# (dotnet, rather) is going to go anywhere off the Win platform, it will be because Scott pushed it there.
It's a tough sell, though -- even with the underdog situation. Java took the approach of running everywhere, and Sun really didn't manage it well. I'm not sure MS is ready or able to participate in a world where the platform isn't the central ideology.
Any promise they make not to sue would be worthless - since they can always just create a shell company (to which such promises would "not apply"[1]) and sue anyway.
Ballmer and Microsoft has always threatened Linux with patents; and worse, they have refused to name which ones. There really is no reason to risk such contamination. So even if they made a patent grant, you wouldn't really see a lot of adoption.
Actually, they have already given a patent grant for C# and .Net. Nobody cared, except the Ximian guys (now Xamarin, which has always been an awesome team).
Not sure what you are looking for or mean by 'fully open source'. The .NET Framework libraries are open source, ASP.NET is open source, the C# compiler itself is closed is closed but it is an ECMA standard and there are open source implementations of it.
They're only open source in the sense you can view them, but you definitely cannot do anything with them, edit them, compile them, etc (from what i can determine). Its purely for reference, not use.
Agree with all.
In fact features of C# are very close to what Scala offers.
.NET performance improvement in last couple years is impressive enough for me to stop recommending any interpreted language based frameworks to my clients.
For me, C# still lacks a bootstrap project like Rails to boost the team productivity. I always have the feeling that the ruby/python teams are more productive cause they have Rails/Django.
Isn't those called ASP.NET MVC or WebApi or Nancy or ServiceStack or ...? I think you have a lot of options - in fact you might have 1 or two too many in the .NET world.
I've worked with the C#/.NET platform for a number of years. As OP points out it has a lot of cool features. But this can also be part of the problem. When you have a big team working on an Enterprise project (which is probably this stacks main audience) you always seem to end up with people who love certain parts of the language and hate others and as a result it makes it difficult for people to work on each others code because theres so many features and not everyone wants to take the time to learn everything when they already have their core set of features that work for them.
It is great that it improved upon what Java was lacking, but I think the C# team is starting to go too far adding too much.
What exactly seems too much? C#'s feature set doesn't seem that expansive. I'd be upset to be forced to deal with a least-common-denominator subset because someone doesn't understand, say, closures.
But I've not worked on an "Enterprise" project, and I assume the main goal there is making sure you can hire anyone and make sure they can understand how to add a new rule for e.g. Alaska sales tax.
Sounds like an issue with process. Is there no code review or coding standards document or collaboration in planning "what is the best way to do this"?
While referring to a xamarin app there is a screenshot of a sample app with a caption
"The same application with native controls and sharing almost 75% of the code base."
Is this xamarin code base shared somewhere?
Also, if there is a significant growth in the share of Windows phone ? Would you use still use Xamarin to develop for Windows phone or would you use Visual Studio?
AFAIK Xamarin doesn't support Windows Phone right now, but I'd imagine they'll do so in the future as WP's market share grows; given that Windows Phone already supports .NET, that's a huge chunk of work they'll be able to skip if/when they do decide to add WP support to their products.
They don't need to support Windows Phone because it already runs .NET CLR code. MvvmCross enables you to target iOS, Android, Windows Phone, Windows 8 Metro/Modern, WPF, OSX Mac from a single code base.
Xamarin only needs to fill in the gaps, which are iOS, Mac and Android.
I think the analysis leaves out the most important aspects for non-C#/.NET developers. My analysis:
C#, the language:
Pros:
* The most elegant of this family of languages (statically typed curly bracket imperative).
* If you are coming from C++: C# is Feature rich but still not too large to make it "choose your own sublanguage" like C++ (yet). You can actually learn this
language from the inside out. There are few undefined implementation details and quite few quirks.
* The tooling is fantastic if you can agree to using windows and shell out some money.
Cons:
* It was designed to rival C++ and Java with a nice learning curve for C++/Java devs. If it was designed today, I think it would have a lot more modern/functional features built in such as tuple deconstruction, algebraic data types/pattern matching (instead of Null) and so on. Now when you use F#, C# feels old with its only half-decent type inference, null keyword and so on.
* Performance (This is actually more .NET than C#): While it can be quite performant, idiomatic C# is still often quite slow. Especially in the hands of non experienced developers. There are often hidden allocations and boxing calls that are hidden behind syntax sugar, that end up taxing the garbage collector (example: A simple foreach call often allocates an object which later gets eligible for GC). So writing high performance code is possible in C# but still very hard. You'll find yourself either making the code look like C (for example: arrays of structs rather than lists of objects which was the idiomatic solution), or simply calling to C/C++ for performance sensitive bits. In comparison to C++ for high performance code, I'd say C# offers free reliability/conciseness etc., and you have to struggle with perf. With C++ you'd get a lot of perf for free because idiomatic C++ is fast (array of structs may well be an idiomatic solution!), but instead you may struggle with leaks, overruns, token salad... Bottom line: C# can often be as fast as C++ but when it is, it's no easier than just using C++ because you have to make allocation free code basically (which is HARD, especially as an afterthougt).
.NET, the platform:
Pros:
* It feels like they looked at java and just corrected a lot of the problems. Sane dependency/versioning is just one example.
* The community is very much alive. Stackoverflow has become the center of it in later years.
* Frameworks evolve at a stunning pace. If you blink you missed two versions of ASP.NET MVC.
Cons:
* Same as above. Hard to keep up with things if you aren't working full time on it. The webpage you did last week is now two frameworks away from the latest
version. You spend a lot of time upgrading code to newer frameworks.
* The GAC is a horrible implementation of a good idea. The fact that you can't really use signing in a useful way without it also feels like a mistake.
* The free versions of everything (compiler, IDE, servers..) feel like second class citizens. You can't code up a prototype webpage in the latest framework and
expect it to run on an OSS server under linux. It's hard to know what subset of language/tools/frameworks actually work under e.g. Apache+Mono. A clear disadvantage compared to Node/Python etc.
* It feels like Microsoft has a bit of a weird relationship with .NET, or rather, it feels like the OS division of microsoft never really accepted .NET while it has stayed the pet of DevDiv. The worse examples has been the slow death of Silverlight (I can see how it should die, but the silence from microsoft has been remarkable). Now it also seems that MS don't really have a plan for how .NET should be a first class citizen for both desktop and "modern" application development under Win8, instead pushing C++. That to me is extremely worrying.
There's one fatal problem with .NET platform: it only (usefully) available for Windows. Who can afford to ignore other platforms these days? Windows, especially on the server side is on the decline. In mobile it never took off. The rest is not really relevant.
I agree with you about windows, but I've been doing C# development on mac and linux for the past year. I don't even call myself a .NET developer anymore, I just say Mono or C#.
I find .NET confusing when comes to packaging - Assemblies, netmodules, gacs, etc. Something written in the same way might be a package, or object. Also tons of methods, for which you have to rely on IDE that guides you all the time. I consider this a bit of bad thing - all it means is that I can really only think of what could be done in front of the IDE - by discovering functions by their names that sound like the task I want to accomplish.
Then moving from 2.0 or other version to newer, comes with surpires - the guy that previously coded something left his assemblies that he downloaded from whoknows where, and these are no longer supported, or there is no x64 version, and they were somehow 32 bit only.
I'm not sure what language you're used to, but the .NET package system isn't that hard to work with.
Assemblies: think JAR files, Python eggs, Ruby gems. They're collection of classes, which can be grouped into modules.
Modules: a collection of classes. 99% of the time, there is one module in an assembly. Modules are effectively invisible for developers in all contexts; they really come up when you combine a pile of existing assemblies into one big master assembly for distribution, in which case that master assembly will have multiple modules, but as a developer, the main way that this would show up is that the things that were previously their own assemblies still act as if they're all in separate assemblies.
The GAC: This is what it sounds like: the global assembly cache. It allows multiple programs to safely use the same DLL, so that you only need to have one copy on your machine.
I've not actually heard of people getting totally lost in the .NET 2 to 4 transition, but I'm sure it's happened. That said, that's also happened in the Go world (especially due to their lack of versioning), in the Python world (especially as 2 to 3 starts actually happening), in the Java world (where someone didn't specify full versions for what JARs they were using, and the new ones conflict), and a bunch of other environments. I don't consider that .NET-specific.
It's funny how you managed to make a powerful feature sound like a flaw. Just forget "tons of methods" exist and code your implementations then. In a Notepad.
Yeah and the costs are more like $1000 a year vs 10, 000 so it only takes a 1 percent improvement. I don't know the exact numbers. But I know your example is an order of magnitude off.
C# and Java are similar enough, I wonder if it would be good to show a few comparisons between syntax of those two languages, if most of his peers in fact knew Java well.
There was no substance behind that. It was just a poorly managed PR disaster. One of many during that year that Windows 8 was launched.
Silverlight deserved to die. But somewhere along the line the Windows division got the wrong end of the stick and thought that meant all of .NET too.
They've stopped the rot now between the DevDiv and Windows divisions. Heads were banged together over that one. Sinofsky was blatantly behind it, that's why he got sacked. It wasn't about Windows 8 not being a good product (it was). It was because he was running the show like Steve Jobs did in the 80s; actively fostering mistrust between teams and undermining intra-division communication and respect.
I don't think the Windows division will ever fully respect .NET for what it is until some of the old guard have moved on. Which is a real shame. It is a first class programming stack that is practically unrivalled.
No, that was just a big scare. Microsoft dropped Silverlight (browser plugin to run sandboxed .NET apps in the browser) in favor of HTML5+JS, but I think that was an eventuality anyway as Silverlight never really seemed to gain enough momentum to stand on it's own merits.
I think the point is that there are now multiple officially sanctioned ways to develop apps for Windows Phone and Win8 tablets: .NET (C#/F#/VB.NET/etc.), WinRT (C++/CX, which is an offshoot of C++/CLI), and HTML5+JS. Each way has it's own strengths and weaknesses, but the idea is that you can use whatever's best for your specific application.
When I meet other devs and tell them I work in lots of languages and platforms but prefer c# they usually look at me like I have 3 heads.
I like to show them LINQ and Async as some things I really like about C#, then I get into how rich the BCL itself is.
Devs are also pretty shocked when I tell them I can write truly 100% native iOS and Android apps in C# (thank you Xamarin) and that one of the most popular mobile game engines (Unity) uses C# and a version of the .NET Framework under the hood.