Hacker News new | past | comments | ask | show | jobs | submit login
Poll: What's Your Favorite Programming Language?
2423 points by GreekOphion on March 23, 2012 | hide | past | favorite | 570 comments
What's your favortie programming langauge?

Below are the most popular languages. If your favorite isn't below select other and comment what it is below.

Note: By voting for a language you are not up voting this poll. Please up vote this poll to keep it alive.

Python
3240 points
Ruby
1805 points
JavaScript
1492 points
C
1032 points
C#
886 points
PHP
711 points
Java
590 points
C++
570 points
Haskell
567 points
Clojure
476 points
CoffeeScript
375 points
Lisp
341 points
Objective C
335 points
Perl
335 points
Scala
253 points
Scheme
199 points
Other
193 points
Erlang
169 points
Lua
150 points
Smalltalk
128 points
Assembly
110 points
SQL
110 points
Actionscript
106 points
OCaml
88 points
Groovy (Added Two Hours Late Due To Requests)
80 points
D
78 points
Shell
75 points
ColdFusion
50 points
Visual Basic
46 points
Delphi
45 points
Forth
41 points
Tcl
34 points
Ada
28 points
Pascal
28 points
Fortran
25 points
Rexx
13 points
Cobol
11 points



C# really feels like the most mature language that I've ever dealt with. Writing it feels clear, if something is wrong the debugger is very clear. The number of features that are there is incredible (especially post C# 2.0 when they added generics). Properties are delightful.

How do you convert to a string? Convert.ToString(). How about an integer? Knowing only that one, it's what you'd expect!

I also picked JavaScript because I am in a love affair with this weird little language. I also think it is one of the easiest languages to teach basic programming with (videos forthcoming).

The amount of time it takes to whip up a five-cent program with javascript without even leaving my browser, heck without even leaving this tab is just astounding to me even after all these years.

One thing I noticed though while writing this comment is that more than the language itself, the tools that I use while building things in the language are what really make them a pleasure to use. If I wasn't using Google Chrome's web developer tools I'd probably consider JavaScript to be a nightmarish corpse of a language that punishes the slightest of typos with a silent malicious grin, as code execution carries on as if A.blah = 5 and A.blsh = 5 were both equally worthy of existing to the JS compiler/interpreter. Only by the grace of tools is JS tame at all.


I've spent most of my time in the open source world, and I would have to agree that C# on .NET feels like the most mature high-level software development tool I've ever used. C#'s biggest strength isn't the language. While the language is nice, there isn't a lot you can do with it in terms of productive development that you can't at least approximate in Java, especially with a good IDE to generate your boiler plate for you.

Where C# and .NET really shines is in its native integration and low level facilities. How many other tools in the world let you debug a mixed application containing both native and managed code, all in the same IDE and in the same session, with the ability to set breakpoints in either area, view values, do memory watch points, and so on?

It also feels so incredibly easy to call native code in C#. There's even a whole web site dedicated to making it easier, pinvoke.net!

Lastly, C# itself contains several performance-sensitive features that have no JVM equivalent, including value types, unsigned integrals, and unsafe code with raw pointers. The .NET platform even has an implementation of tail recursion , now, though the C# compile will not generate IL that uses it, which makes it inaccessible for most people.

When it comes to language design, C# is a little sloppy but it more than gets the job done. In terms of tools and low-level facilities for building a real-world application, C# on the Windows .NET platform feels absolutely world-class.

For my favorite language, I of course, voted for Scala!


> While the language is nice, there isn't a lot you can do with it in terms of productive development that you can't at least approximate in Java

There is no substitute for lambdas :)


Luckily C# supports them:

http://msdn.microsoft.com/en-us/library/bb397687.aspx


your parent is suggesting that java does not have a substitute for lambdas.


Which isn't true anyway, since anonymous inner classes are just very verbose and awkward lambdas. (I'm a Java hater but I'm also a horrible pedant)


True. Then again, what's the practical point of lambdas that aren't concisely expressed?


There are plenty of practical uses: http://code.google.com/p/guava-libraries/wiki/FunctionalExpl...

Note that the Guava lib specifically points out how ugly this is.

I prefer Clojure.


What's the decision procedure for whether a certain expression is "concise?"


Horrible as in "no good" pedant?

Because, no "anonymous inner classes" are no lambdas. They are, well, classes kludgily used to mimic a lambda proper.


What it is to be 'a lambda' isn't particularly well-defined. If we define it to mean an anonymous closure then Java certainly has them — so long as its free variables are final (it closes over references). On the other hand, if we define it as the operator which creates anonymous closures, then Java doesn't, because you have to actually build the closure by hand.

Since the former have a proper name (closures) and the latter doesn't, I'd be inclined to call only the operator a 'lambda'. But since you can at least 'approximate' closures in Java (with anonymous inner classes), I think it's fair to say that they are "very verbose and awkward lambdas", to some definition of lambda.


lordlicorice (the ggp of my post) suggested that there is "no substitute for lambdas" and I was intending to correct that. Anonymous inner classes are definitely a substitute.


> It also feels so incredibly easy to call native code in C#. There's even a whole web site dedicated to making it easier, pinvoke.net!

I'm with you that C# is really nice to use, but interfacing with native code is a nightmare. The reason why a whole bunch of websites exist on pinvoke is because of its poor documentation and incoherent behavior.

As far as low level goes, I'm happy with C++ (if I were an embedded engineer I would say C but it is very nice to be allowed to use the C++ niceties). I think that everyone needs to have a language that can generate native code. On higher levels, python is fine for me. I simply do not have the use for an intermediate language like C# or Java, however nice they are.


> The .NET platform even has an implementation of tail recursion , now, though the C# compile will not generate IL that uses it, which makes it inaccessible for most people.

Sort of. It just so happens that the tail call optimization does get used on x64 platforms because of an implementation detail of the 64-bit JIT.

Source: http://blogs.msdn.com/b/davbr/archive/2007/06/20/tail-call-j...


How is this C#+.NET integration on mono? Are the relevant low-level facilities translated well into linux or osx?


I like Mono, and I respect the work that they've accomplished. It is incredibly difficult to build a runtime like .NET, especially as it was never designed to be cross-platform.

That said, the Mono experience on Linux is inferior to that on Windows. MonoDevelop is nowhere near Visual Studio, so that I just develop on Windows and deploy on Linux. Unfortunately, that doesn't help the fact that both the soft and hard debuggers for Linux are nowhere near Microsoft's debuggers. It also doesn't help the fact that the runtime itself is less stable (i.e., more prone to crash) and there are APIs that only work well on Windows. I would also imagine that the Microsoft runtime exhibits much better overall performance.

My understanding is that Mono mainly excels at MonoTouch, and that is where Xamarin is making most of its money, but I am not knowledgeable in that area.


It is incredibly difficult to build a runtime like .NET, especially as it was never designed to be cross-platform.

Just a historical note: The Shared Source Common Language Infrastructure [1] aka "Rotor" is an alternative version of the .net 2.0 platform developed by Microsoft for research/education use. It can be compiled for FreeBSD and Mac OS X 10. Its rather out of date, but maybe shows that MS did make some kind of effort to make it cross-platform.

[1] http://en.wikipedia.org/wiki/Shared_Source_Common_Language_I...


I remember working on Rotor when I was at Corel.

I'm glad to see someone still uses it:)


Even outside of .NET, it's got a tool built-in to make L"strings" 16-bit on all platforms, which is cool for portability (and an implementation of nmake for unix, which can also come in handy)


Do you know how it relates to Silverlight for Mac?


The FFI is still far better than most of the other FFIs for other Linux-targeting languages. Yeah, and MonoDevelop is not equal to Visual Studio, but it's a damn sight better than almost any other OSS IDE.


How does it compare to QtCreator, do you know?


In my opinion, I'd say Visual Studio > Qt Creator > MonoDevelop. Qt Creator isn't bad, but the debugging is not nearly as great as Visual Studio. For instance, adding a variable to a watch doesn't always work (as in, variables aren't always evaluated when you'd like them to be) and I can't just type a variable name or expression into the watch window, I can't always view the memory at an object's address, and sometimes I get incorrect values (which could be something with my configuration).


Don't know, but QTCreator is a C++ IDE (I think?) which makes it a non-starter for me.


You also can develop just in QML, which is really nice.


I use MonoDevelop every day with Unity. I sometimes hear other devs complaining about it, and saying how Visual Studio is so much better. I think back to the days I used to spend struggling with multi-project solutions in Visual Studio with all its warts and crashes and weird compilation bugs, and thank heavens I'm working with a light-weight IDE.

C# is my new favourite language, and MonoDevelop is a pretty decent IDE for what it is :)


In my experience, these are the problems with developing in MonoDevelop for Unity:

- The debugger is flaky. Sometimes it will miss a breakpoint completely. Sometimes trying to inspect local variables will crash MonoDevelop. Sometimes it will refuse to continue no matter how many times you tell it to.

- If your problem starts in Unity's native code, forget about trying to debug it. The messages are cryptic and the debugger is useless. This happens for some things you can diagnose (like running out of memory, either on the machine or the card)--although good luck figuring out what your memory hog was--and for other things that leave you completely stumped (shotgun debugging becomes your only recourse).

- Don't even attempt to use text search over multiple files (other searches, like reference searches, work fine). MonoDevelop will get stuck in an unproductive loop that never displays any results and never completes.

- Forget about profiling. Unity technically has a profiler, but it's per-frame, not cumulative. It also omits a lot of detail, especially about memory usage.

- There are also a number of minor issues, too, but they aren't deal breakers so much as annoyances.

That having been said, our particular project is rather good about pushing Unity to (and beyond) its limits, and you may never encounter any of these limitations. Still, it's worth knowing that they exist.

Footnote: These comments may be limited to the version of MonoDevelop that ships with Unity 3.3 (there are non-technical reasons why it's not worth our time to go through the effort to upgrade).


Most of those issues are with Unity not MonoDevelop, aren't they?

I hear you though - debugging Unity projects is a real toolchain weakness. I'm lucky if I can even get the debugger to connect.

Text search works fine for me though! I've never had a problem with it.

My worst problem with it actually is just stability, but I've never lost work with it and it restarts pretty quickly.

What are you working on, out of interest? (If you're allowed to say!) :) 


  > Most of those issues are with Unity not MonoDevelop, aren't they?
True, but I consider them as one platform (Unity and its customized MonoDevelop, specifically).

  > Text search works fine for me though! I've never had a problem with it.
It's a weird bug that was probably unique to the 3.3 version.

  > My worst problem with it actually is just stability, but I've never
  > lost work with it and it restarts pretty quickly.
I get a lot of freezes and crashes too, but to its credit MonoDevelop definitely has a very robust autosave.

  > What are you working on, out of interest? (If you're allowed to say!) :)
3-d mapping (à la Google Earth, but with different goals).


The biggest improvements that VS2008 and VS2010 made over the previous versions is that it became much more light-weight, they did a lot of work to remove cruft. If you haven't looked at VS in a long while you might be surprised.


I think the last one I used was 2008. I'll have to have a look at 2010 sometime. Very happy to hear they've spent some time reducing the cruft :)


And no self-respecting developer would ever use Mono on nix anyway because the nix tools run circles around anything .NET/Mono.


mono works fine on nix systems (little bit of tweaking with grsec), a friend has developed a few programs that he has deployed to nix systems without any issues. Initially I was quite anti it, but what the heck, if it works it works.


I knew this would be downvoted by the predominantly Windows users here but, if they knew anything about *nix, they wouldn't do that.


You were downvoted because you made an argument without supporting it, and you were downvoted again because you complained about being downvoted and still didn't provide support for your argument.

From what I gather, HN isn't so much about being part of an "in-crowd" where you "just know" the way things are. You need to be willing to explain your arguments, otherwise you're just a snob.


I once worked on a virtual usb device project on linux with Mono, at least ioctl and pointers work well for me. Use Java for this? No...

Moreover, for maximum performance, mono provides facilities for users to embed native code into the runtime, much faster than Pinvoke.


Unity3d ships with Mono/C# and MonoDevelop as one of the programming language options for its game engine. I haven't used it as much, since I prefer the Javascript version, but most (if not all) high-end game developers opt for scripting in C#.


I'd be curious to hear, why.

I will be working on a Unity3D project and the team wants me to use C# with VS. As a Mac user and Open Source fan, I didn't jump at the idea. Glad to hear, that a lot of people think C# is a good choice. I'm excited to learn it!

Any suggestions for a good book or website? I've been programming in C and C++ quite a bit, but its been a few years. I've only been doing functional programming since then and would probably need a refresher on object oriented programming.

Can someone comment on the best development environment for Unity/C# when using a 2011 Mac Air with 4GB Ram? Should I install bootcamp, use Parallels Desktop or Unity+Mono under Mac OS?


The thing to realize is that the Javascript isn't Javascript. It just looks like it. Writing good Unityscript/Javascript is going to be only syntactically different from writing C# anyway. Unityscript/Javascript is well made, but there's a few edge cases that you'll only encounter once you've already written most of the project. And mixing the two languages is messy and limited.

For C# dev, it depends how hardcore you're going to be getting. Ultimately, you normally going to be scripting, not programming. getting familiar with the Unity3D API is of more use than learning high level features of C#. For instance, while C# is object oriented, >90% of the things you write will inherit from MonoBehaviour, and most of the rest are just fancy structs.

And I code on an iMac -- I use Unity natively, and the version of MonoDevelop it ships with. It works nicely!


I know nothing about developing Unity/C#, however, I know VS runs quite well under VMWare Fusion on a MacBook Air (with 4GB of ram).


Definitely agree with you on C#. It feels like this is what a standard, mature, widespread language should be. There are other languages that are better for specific tasks, but for the general programming language, C# really hits the sweet spot in terms of features, expressability, readability, and environment. This is the language that Java should have been--could have been.

Also, I dread getting asked on my next interview "whats the one thing you don't like about your favorite language". I honestly can't think of anything off the top of my head. Granted, I've come across things that were frustrating at various times, but they never stick in my mind. I think that's a testament to how well the language has evolved.


whats the one thing you don't like about your favorite language

That's easy. So many hacker types dismiss you as some sort of weirdo for favoring anything that came from Microsoft.


Or, less glibly, it's a mostly single-platform language with support for other operating systems offered only through third-party tools.


I don't dismiss C# developers, I'm just glad I'm not one anymore.


Do you mind if I ask why? Not being defensive, just curious.


Well, I'm not the gp, but I am a former C# guy who's happy to be out of that world.

1) I dislike C#'s types; they're neither as strong and intelligent as a ML/Haskell language nor as convenient as a Python/Ruby family language.

2) I much prefer the sense of design displayed by Python and Ruby open source projects over C#. (Not that there aren't issues there!)

3) I hate Visual Studio. Nice debugger, crappy interface for writing code. Horrific user interface design for the most part. (At least back when I was writing C# back in 2009!)

4) I hate Windows. Linux and Mac are far more developer friendly. I hated dealing with Cygwin to get some sort of reasonable (crappy but tolerable) command line environment.

5) I love git. Until fairly recently, git was not available and stable on Windows. For it and for many other bits of software, windows is a second class citizen.

Shall I go on? Because I could. But I'll leave it at 5 for now.


As someone who's more than happy with C#, I'm wondering if there's a world out there I'm missing but I can't really connect with what you're saying.

1. "Strong and intelligent"? "Convenient"?

2. "Sense of design"? My current side project includes a web scraper which uses the following open source projects: AutoMapper, CsvHelper, HtmlAgilityPack, Twitter Bootstrap, jQuery, Modernizer, Moq, NLog, MongoDB C# driver, PetaPoco database driver, Rx extensions, knockoutjs and structuremap. 8 of those are .NET specific. Because of their excellent design, I have probably no more than about 30 lines of code hooking up to them (where I use interfaces) and maybe no more than 100 lines of code total utilizing them directly. Yet they conceal YEARS worth of work I would have to do myself.

3. Have you ever used Resharper? I've never heard of anything equivalent on any platform for any IDE (except for IntelliJ, developed by the same company, Jetbrains).

4. I'm fine with Windows. I find both Linux and Mac less developer friendly. I'm fine hosting my services on Linux and interfacing with them from C#, though, because it's a great server operating system. I've been using computers for 20 years and I'm happy to be away from the command line 99% of the time. What do you like about it?

5. Git Extensions + Git Source Control Provider are a completely integrated and free Git experience on Windows.


1. In Haskell and ML, I don't feel like I spend my life Listing<List<T>, X<T>>, and I have type classes. In Python and Ruby, I don't have to specify types. This lets me do all kinds of convenient things.

I don't think it's far out to suggest these sorts of advantages, and I am 100% not interested in rehashing a flame war that's been had a thousand times over. Please allow that these are my judgements, and I hope you don't need to share them to see that many people feel that way.

2. That's nice? I found C# projects to have a poor sense of design. I'm not sure how you expect me to defend an aesthetic decision.

3. I'm glad you like Resharper? I didn't. I'm a vim guy.

4. I'm glad you like Windows? I don't. I see what you mean, as long as you stay in the MS womb, it's a cozy development environment. I tend to like open source software, and it lags behind very seriously in that department.

5. As I said, I last developed C# in 2009, and I thankfully haven't had to touch Windows since. I'm sure git is nice now, but I suspect that Windows is still a second class citizen for many software projects. Git is just the one that annoyed me most back then.

It seems to me that we simply have different aesthetic criteria.


as long as you stay in the MS womb

You don't need to debase an otherwise great conversation with incendiary language like that.


I certainly didn't write it to be incendiary, and I don't read it that way?

I'm not going to go back and edit it, but I'll ask you to give me the benefit of the doubt that I meant it to be as as far from incendiary as possible.


The perhaps unfortunate metaphor the womb implies is that developing in MS tools is like being a defenseless premature baby who needs to be protected from the big bad world until they come to full term and leave the MS environment behind.


To me, this metaphor could be extended to [whatever environment you first really liked]


I am delighted to give you the benefit of the doubt. Thanks for the explanation.


We do and that was my original impression. Yet you listed a number of items even though they all boiled down to the same thing as far as I could tell. Nothing wrong with having different tastes, I just wanted to see if I was missing something deeper in each point.


I stopped at the part where you compared ReSharper to VIM

I'm guessing you like to debug using print and the command prompt as well?

For most the world keeps on spinning, for some it stops in their youth. Sad.


Hell yeah vim rocks!

So too does the command line! high five


> 1. "Strong and intelligent"? "Convenient"?

Not a C# user, but few languages of the strength and intelligence of types in ML. Covariant arrays (which C# presumably adopted for the sake of Java programmers) moves an easy, and obvious, compile time type check to runtime. The type inferencing in C# is very weak relative to ML/Haskell. The type syntax is generally more lighweight in ML/Haskell as well. For example a function that takes a list of some type ('a) and returns the head of the list if it exists or None if it doesn't looks like:

val hd : 'a list -> 'a option

Of course, all if this works in unison with other type functionality that is far more lightweight in ML than C#. The function above is only really so succinct because I have powerful variant types and pattern matching on them. I think they go hand in hand because using an option-type is somewhat useless if I don't have something like pattern matching to access its state.


C# includes the static LINQ method "FirstOrDefault()" for any types implementing IEnumerable, e.g.:

    var firstNumber = numbers.FirstOrDefault();
(This isn't strictly the same as what you described if "None" is different from "null".) Once such a method exists, does it matter how many lines of code it is written in? I posit that every language feature in a reasonably intelligently designed language serves a valuable purpose, and that everybody has different needs, and the verbosity in C# serves certain needs.

Here's an implementation in C# that is a function on types T implementing the IList interface (rather than IEnumerable like LINQ does):

    public static T Head<T>(this IList<T> list) {
      return (list == null || list.Count == 0) ? null : list[0];
    }
It is used in the same way as the FirstOrDefault() example above. Much more verbose, I'll agree! But the real question for this thread is is it less convenient, and if so why? All the verbosity stems from just a few logical places:

1. the 'option' function you have in your example. In reality, your 'option' is doing all the work I did above, which means that comparing the verbosity of your sample code to the C# equivalent of FirstOrDefault() is perfectly valid in my opinion :)

2. the explicit return type. This serves a valuable purpose in my opinion.

With your code, it's easy to break the hd function by changing the implementation to return a different type. You might not even notice the bug if the different type's implementation is close enough to the right one. I once had a bug like this in VB6 years ago: I changed a method to use an integer instead of a string, and VB's automatic type casting happily allowed the rest of my code to function... until in the middle of a demo I ran a function I hadn't tested and default value of 0 broke something expecting an empty string! My lesson: type inference can be dangerous.

It also makes refactoring a large project much more difficult in my opinion because there is no way to distinguish between specification and implementation. Consequently, changing your implementation runs the risk of breaking your specification without being informed.

There is a school of thought that says your unit tests should cover this aspect of the specification... but then all I'm doing is implementing explicit types in a roundabout way - let the compiler do that I say! That being said I don't know if ML/Haskell have 'interface specification' types to ward against this, where you need it (and everywhere else you get to save on verbosity)? That would be a nice improvement to C#: private methods can use extended type inference, anything public (including implementing an interface) need to be more explicit.

3. syntax: visibility (public), static modifier and return statement. This is a matter of personal preference. With Resharper in Visual Studio each of these words costs me 2 or 3 keystrokes, and if I like I can use templated code snippets to reduce that for any situation, so I'm not too bothered :)


I think you're underestimating how much work the type system is doing here: `option` isn't a function. It's part of the return type definition. The whole point of having a type system as strict as ML's or Haskell's is to avoid the sort of problem you had in VB6. Automatic typecasting is a very, very different beast to type inference: in Haskell, your problematic code likely wouldn't have got past the compiler. You're precisely wrong when you say that it's easy to break the hd function by changing the implementation to return a different type. If you do that, your program won't build.


ML's and C# have their strengths and weaknesses, but from a type theory perspective, ML's type system is simply much more powerful when it comes to ensuring correct code than C#'s. Take, for example, your implementation of Head, what if you messed up and wrote:

> return (list.Count == 0) ? null : list[0];

Would the C# compiler catch it or would you not find out until runtime? An ML compiler would tell you that function is wrong.

What about using Head? If you have a list of integers, will the compiler let you do:

> Head(integer_list) + 2

An ML compiler won't, because it's not safe.

> This isn't strictly the same as what you described if "None" is different from "null".

It is, but the important thing to note is I had to specify that the function, 'hd', can return 'null', by wrapping it in the option type. 'null' is only a valid value for option types. If I write:

> val hd : 'a list -> 'a

I could not return 'null'/None, it simply isn't valid. And the compiler wouldn't let me.

> the 'option' function you have in your example

'option' is a type, not a function (I suppose you can make some high level argument that all types are functions over values or something, but not relevant here). And 'option' itself isn't really even a type, it requires a type variable, so "'a option" is a type where "'a" is replaced by a concrete type at some point. It's not doing the work you described above, it's actually defining a contract between me and users of hd and the compiler.

> With your code, it's easy to break the hd function by changing the implementation to return a different type. You might not even notice the bug if the different type's implementation is close enough to the right one.

No, it isn't actually. If I change the return type the compiler will not compile my code.

> I changed a method to use an integer instead of a string

This cannot happen in ML, the compiler won't compile it because an integer isn't a string. What you described is not type inference, it's dynamic typing. The only danger of type inferencing in ML is annoying type errors during compilation. I'm not sure you actually grok what type inferencing is.

> It also makes refactoring a large project much more difficult in my opinion because there is no way to distinguish between specification and implementation. Consequently, changing your implementation runs the risk of breaking your specification without being informed.

Actually, refactoring code in ML tends to be pretty easy. If you change the type of something the compiler won't compile your code, so you know instantly where you messed up and can fix it. You can construct code to make this not work, but in general that isn't the case. See https://ocaml.janestreet.com/?q=node/101

> let the compiler do that I say!

Exactly, and an ML compiler definitely does more of this than the C# compiler. At a cost, of course.

Your post has several statements which suggest you are ignorant of ML and type theory. If you're interested in learning more, check out Benjamin Pierce's book "Types and Programming Languages". Or just spend a weekend with Ocaml or Haskell and prepare for the compiler to frustrate you with it's strictness :)


As far as #4 is concerned, windows is not configurable and the "command line" is an absolute joke, which renders the idea that it has a better developer experience absolute rubbish :) The command line is super powerful and highly convenient in a developers hands.


The lack of configurability is a bug or a feature, depending on your purpose and your disposition. I personally can't stand configuration nightmares. I want things to just work as much as possible, and in my experience linux has a real problem with that. I'm a programmer, not a configuration engineer. I expect the systems I use to understand that.


PowerShell is no joke. Even if you never intend to use Windows again, it's worth taking a look at, there are some interesting ideas in there.

(Overall though, I agree that Linux and Mac give a better developer experience.)


Seeing as how I've been developing for the last 15 years on Windows and haven't found the lack of a *nixy command line to be an issue I'd love to know what you're doing that I'm not :)


Well, the command line basically means you have the power of a full programmming language at your fingertips for administrating your system, your projects, your build system, etc.

Also, the homogeneity of the unix interface (pipes and utilities that uses them) means that you also have very powerful primitives to work with.

Proving the utility of the command line could benefit from a few full featured examples, but this would need a longer post that i'm in the mood of writing right now :)

With that said, you have a powerful administration programming language on windows called powershell. It's much better than bash by a lot of metrics. The way it's integrated into the system is not very good though. For example, the terminal client sucks, and the security system is way too complicated for casual use.


I Spend a lot time in the command line on Windows. Powershell, GnuUtils, and the Windows server resource kit make it much less of a joke than it used to be.


The only way to know if there is a world out there that you're missing is to go explore it. The biggest problem with the .NET world is that the vast majority of .NET developers have spent the vast majority of their time in it.


Same boat, but still wrestling with windows at work. I've got a workable configuration with Cygwin, and mingw32. Hey Visual Studio's IDE (2008) may be full of cruft but the debugger isn't too bad. Vs2010 feels broken, I gave up creating projects in VS, and now use a simple combination of ruby and cmake for creating solutions/projects.

http://www.victusspiritus.com/2011/10/30/an-elegant-ruby-scr...


Thanks for the thoughtful reply. I've absolutely felt your pain. Some of those things have maybe improved (I use git every day, I love my PowerShell, and Visual Studio + ReSharper is glorious once you tell some of the cruft to stay out of your way) but it's still a long way from perfect.


It's amazing how many people either dismiss PowerShell out of hand because it's different, or don't even think about it when talking about Windows commandline support. Getting .NET objects returned, rather than piping text around is awesome. So is having an IDE specifically for writing PowerShell scripts. I'm still learning PowerShell, and love bash, but as powerful as bash is, in some ways it feels very primitive in comparison. If PowerShell 15 years old when bash was released, would anyone consider it better than PowerShell?


Powershell did not exist when I was a C# programmer. Not saying it would have made a difference either way, just that I couldn't have mentioned it.

Anyway, I don't think bash/zsh is so great, rather the tools that have grown around them for the last 20 years make them the best available option. Powershell may be nice, but it's got a long road to hoe.


True.

It has a steep learning curve, as one needs to learn a new set of commands, but once you start getting it, it is great.

I just have two complaints with it: - the stupid ps1 extension; - commands are verbose when comparing with other shells


Agreed that PowerShell really does make command line work on Windows much more pleasant than the old DOS prompt. I just discovered a PowerShell module for working with Git (https://github.com/dahlbyk/posh-git). It shows status info right in your prompt line and does tab completion of git commands and branches.


Crazy. I could have (honestly) written this exact same post, timeline and all.


4) Powershell! Sweet mother of Scripting Gods, Powershell! As a language it's what Bash should have been. Bash is better in some usability senses like tab completion, but Powershell operates with pipelines of .NET objects instead of pipelines of text.


C# programmer for a couple years, and I think C# is OK (it's definitely way ahead of Java or C++) but I've definitely got a big list of things I don't like about it. The top of it reads:

- Events and properties aren't first-class, which is lame. I can't even easily get the "get" or "set" method of a property without either using reflection or making a wrapper lambda.

- No syntax sugar for tuples.

- No syntax sugar for destructuring anything. Come on now.

- The type system has big holes. For example, I still can't specify class Something<T> where T : new(T) (i.e. where a copy constructor exists on T.) And I can't specify class Something<T> where T : /* is a numeric type */.

- It would be nice if there were type inference on more things, like property and field types.

- All reference types are nullable which sucks.


This is a good list. The lack of decent sugar for tuples makes them very annoying to work with and situations demanding two or more dependent return values are the one place where my code looks nasty and is difficult to follow (unless I create a class specifically for the return type, which I usually end up doing).

By numeric type do you mean a type implementing numeric operations? I agree, it's weird they haven't just whacked an interface on that.

And when are we getting an "unless"? It's way more readable than "if (!(some complex condition))".

Oh and null coalescing with member support. "y = x != null ? x.prop : value" is way too verbose.


> The lack of decent sugar for tuples makes them very annoying to work with and situations demanding two or more dependent return values are the one place where my code looks nasty and is difficult to follow (unless I create a class specifically for the return type, which I usually end up doing).

At least you have the option of out params. I have to use Java every day and the only real option is return classes.


I don't know if I misunderstanding you, but you can indeed specify class Something<T> where T : new Check this out: http://msdn.microsoft.com/en-us/library/d5x73970.aspx

And about numerical types, I agree that would be great to have a base class "Number" for double, int, etc. But meanwhile you can use this trick: http://stackoverflow.com/questions/3329576/generic-constrain...


Right now you can only specify that a type must have a paramerterless public constructor. He or she wants to be a le to specify (presumably) arbitrary constructors (or at least a copy constructor).


Most of your issues are addressed by the Base Class Library (BCL), which is provided by the runtime itself. You cannot use C# without the BCL, so why evaluate it without the BCL? How do the following sit with you?

- Events, i.e. the observer pattern, are indeed supported first class by way of the `event` keyword and BCL `Delegate` type. And the whole point of properties is to be syntactic sugar to hide implementation details by surfacing state accessors with field-like mechanics. If you need a quick and easy way to reference a "getter method", you're breaking the abstraction and shouldn't use properties. That's the trade off.

- The BCL provides multiple generic, high-performance `Tuple` types.

- Destructing. Memory management is handled by the GC, so what would destructing even mean? The `using` keyword along with BCL type `IDisposable` provides a very usable mechanism for releasing non-memory/unmanaged/OS resources.

- This is mostly valid. That said, `ICloneable` can get you most of the way w.r.t. the copy ctor. As far as the numeric generic, one is required to make do with type-specificity and method overrides, since the numeric types were written without generics in mind. Or you can implement your own numeric type system. Do that once and you can write numeric generics to your heart's desire.

- How could this work with auto-properties?

- Trivial to implement a `NonNull<T> where T : class`. But because of other language constructs (`??` operator) idiomatically `null` references are not considered the end of the world. Design by contract support in the BCL `Contract` type alleviates this as well.

edit: expanded property method explanation.


He said destructuring, not destructing. Like so:

   int a, b;
   (a, b) = function_returning_array();


Regarding events: It's a common pattern to pass a function into a method as a callback to do an inversion-of-control kind of thing, like "on error, call this." It would be natural to pass an event with the semantics "on error, fire this event." But there is no way to pass an event. You can imagine similar situations with properties.


Your list basically boils down to "C# isn't <insert favorite language>". Which is fair of course, but most of your list wouldn't really make sense in C#.


That's just not true.

All the suggestions on the list make sense, and many like them have been added over teh past few years. To me it seems that all of them except the 'reference types that are not nullable' one could be easily added without breaking backward compatibility.

In fact, I wouldn't be amazed if a C# 6 has sugar for tuples and destructuring assignments and the likes. It matches the language well (already got a type-inferencing compiler, already on the road to incorporating increasingly many functional programming ideas).

And, well, in code you can already say

    var george = new Person();
But in property and field definitions, you still have to say

    Person george = new Person();
How is allowing "var" there a turning "C# into a different language"? Nearly the entire list the GP mentions are fixes on this level of complexity.

The only reason I see for not doing things like this is to avoid becoming the next C++, in which there's just too many features and things to understand.


What you suggest could work, but I'm not sure how useful that would be in the end when you still have to declare the type for fields initialized in the constructor. The var keyword inside methods covers most cases of using variables. A "var" keyword on the field level would cover less than half of the cases. Plus, you'd have to add a new keyword to do it as "variable" doesn't quite fit the meaning. Just not sure how useful that is.

sugared tuples and destructuring doesn't really fit. You'd have to make special case syntax for it and it would just feel bolted on to the language. Plus, tuples lose their usefulness if you have to declare its type to pass it between methods.

Though his first point about getters and setters does make sense, I didn't quite comprehend it the first time around.


You'd have to make special case syntax for it and it would just feel bolted on to the language. Plus, tuples lose their usefulness if you have to declare its type to pass it between methods.

I think it could be OK even without return type inference on methods. Imagine you could type this:

  (int, bool) TryParse(string str) {
     // do stuff
     return (num, success);
  }
That would be clean enough.


I think you might be right about that one. That does look rather elegant. I was initially skeptical about creating a totally new language construct to create inline tuples, as (num, success) looks like it needs a new in front of it, which ruins the pattern of assignment for destructuring.

But once you get over that mental hump of seeing a new in front, it really starts to make a lot of sense. A tuple could be considered a value type and treated similarly to int or string literals. Very cool.


How would you access the return value object? Given obj is (int, bool), obj.Key and obj.Value? Or obj[0] and obj[1]?


Why would sugared destructuring not make sense in C#? Or first class events and delegates?


Destructuring just doesn't fit with the current language syntax. There are no copy constructors in C#, so something like [a, [b, c]] = [1, [2, 3]] makes no sense syntactically. In languages where declaring objects don't require a new, this syntax follows naturally.

For the simple case of say, destructuring a tuple, that could work well: a, b = ReturnsATuple(). But anything more general would just seem tacked onto the language.

But then again, tuples don't really fit well in C# either! Tuples are only useful if you don't have to declare their types, ever. Without full type inference, nothing is saved by using tuples over, say, an inline object.

I don't understand the significance of first class events, so I can't really comment on that. And as far as I know, delegates are first class now with the inclusion of lambdas.


A good list, which can be extended. Just recently, for example, I came across the unpleasant fact that interfaces in C# cannot be nested (in fact, a C# interface is not allowed to define any nested types). Inconvenient, breaks encapsulation, and does not seem to have a good technical reason for it.

And yet, working with C# is joyful.


Did you have a look at Scala?

- There are only properties, no fields or other stuff. This means you can replace a method with a constant easily, or add your own setter to a mutable property later without breaking source or binary compatibility.

- Tuples: (1, "Foo", 42.0)

- val (a,b) = (1,2). Also works with regexes, case classes, ... basically everything which has an `unapply` method.

- class Something[T : Numeric]

- Type inference everywhere, with the exception of method parameters (and recursive methods).

It also has one of the most powerful type systems, traits, everything-is-an-object, higher-order functions, higher-kinded types.

Caveat: Runs on the JVM. The .Net port hasn't been officially released, but is planned for the next release.

There is an introduction for C# developers, if you are interested: http://docs.scala-lang.org/tutorials/scala-for-csharp-progra...


That is easy -- non nullable objects. What I mean by that is that you can already specify that some numbers may be nullable. I would love to be able to specify that some objects cannot be null and have the type-checker verify it.

Even better I would have an option type so that you never need to use null, ever.


They don't really work at the type system level, but Code Contracts (http://msdn.microsoft.com/en-us/devlabs/dd491992), though quite verbose, may be used to achieve that to a certain degree. The integration with Visual Studio is decent and the documentation is great, but they are designed to provide a whole design-by-contract framework which may be an overkill.


That's a good one, I'll keep that in mind. (I'm not just cribbing, I ran into a real world situation that just screamed non-nullable objects).


I remember Anders saying that that was one of his regrets for not implementing this from the beginning. According to him adding this now would break quite a few things, but he hasn't yet given up on the idea.


I agree in large, but there are some rough edges.

-It's wordy. The var keyword was a step in the right direction, but there's still a lot of redundant type information, even compared to other statically typed languages like Go or F#.

-Legacy code. A lot of things that are concise and easy in C# 3.5+ were possible but hideous in older versions. Sadly, that code must still be maintained.

-Null handling. Like another commenter, I wish the language would help more with null values. I'd love an operator to do monadic null coalescing: var foo = thing1.thing2.thing3.bar; Sometimes I want foo to be null if any of the chained objects are null.

It's a pretty good language, though. I'm looking forward to the Roslyn API to the compiler: http://msdn.microsoft.com/en-us/hh500769


Legacy code is a problem in every language. Whether the language evolves, or just the common insights of how to use it best.

In fact, C# deals excellently with legacy code. While, unlike the JVM, .NET is not binary backward compatible (allowing some excellent language improvements that Java still has not managed to pull off), it is nearly (but not entirely) source code backward compatible. Sure, this allows to old code using old constructs to stay alive, but it works. That alone is pretty unique, especially if you see that nearly any other language either does not manage to move its community to the next version with breaking changes (Python 3, PHP 6) or has tons of compatibility issues every time something changes (Ruby, Scala), or simply is at a standstill (Java).

Having to deal with a DictionaryBase child class which was made before generics were added is way less of a deal than not being able to upgrade your software to the newest version of the language at all. Which is what would've happened if this was done like Scala. Or, if it was done like Java, we'd still be hacking DictionaryBase child classes.

I'd maintain that no language/platform deals with legacy code better than C#.


Good point. Having to deal with portions of old code is better than not being able to use new features at all. I've revised my opinion.


FYI, Python has an automated script for migrating code from Python 2.x to Python 3.x


You should tell Django guys they should be thrilled to hear it.


Django already has a branch with support for Python 3.x. The only reason why they're holding off on deprecating older versions is so that users get enough time to upgrade their systems.

A lot of hosting environments like Google AppEngine still do not support Python 3. The "there's going to be no 2.8" PEP might help that, though. We can only hope.


I found it half funny that Python 3.3 reintroduced the unicode string literal for Django. The only way support will come is if user push their providers to get up to speed. It is such a pain that Python has become forked for all practical purposes.


Here's an interesting blog from the Django developers about their plans for python 3: https://www.djangoproject.com/weblog/2012/mar/13/py3k/ The short of it is that they are planning to move for sure and with each release of Django they drop support for one of the 2.x releases of python. Django 1.5 (the next major version) will experimentally support python 3.


I was being facetious - my point is 2to3 has been around since py3 was released and Django was python 2.x only for years, along with many other libraries, implying that porting is a bit more involved than applying a script :)


I don't understand the points about Scala here. Scala has pretty much the same strategy as C#.

In fact, the "big breakage" in Scala everyone loves to cite was the addition of better collections. Just like C# did in 2.0 and now finally drops the old non-generic ones with WinRT/Metro.

The reason it gets so much flack is that Java developers want _binary compatibility_, because that's what they are accustomed to and Scala gets often used by Java developers. Java developers would target the same criticism towards C# if it would run on the JVM.


Hm, hm. I guess you're right. Or, at least, I can't find any proof that you're not, so you get my benefit of the doubt :-)

I take the part on Scala back.


No problem. :-) If you have any questions, just ask.


Null handling

You can do a fair amount of relatively frictionless null handling with extension methods. If that helps.


var foo = thing1 ?? thing2 ?? thing3 ?? bar;

This will work.


"thing1 ?? thing2 ?? thing3 ?? bar" will return the value of the first non-null variable in the list. zmj wants something like Ruby's andand [1] instead.

andand negates the need for an explicit null check on each property in a property lookup chain, which would normally be required to avoid a potential NoMethodError or NullReferenceException.

You can create something similar [2] to andand in C# if you are willing to do property lookups using lambda expressions.

[1] http://andand.rubyforge.org/

[2] http://stackoverflow.com/a/4958550


Yep. To me C# feels like the standout all-round language. It's not super-elegant, but it's modern and brings together a lot of useful features without messing up much. I especially like the stuff that was added in v3.0.

On design alone, I would probably vote Clojure. The features and their rationale are very compelling.


<i>I honestly can't think of anything off the top of my head.</i>

Limited support in the open source ecosystem? Open source projects are reluctant to build on something that might infringe on an MS patent. That's what keeps me away from the language. To be fair, this is more an indictment of the patent system than C# itself.


I was thinking more along the lines of the language itself. Complaints about the (lack of) open source ecosystem are more than valid. That's something I dearly miss in the .Net world.


If I wasn't using Google Chrome's web developer tools I'd probably consider JavaScript to be a nightmarish corpse of a language that punishes the slightest of typos with a silent malicious grin... Only by the grace of tools is JS tame at all

+100000. We can thank the Webkit Tools team (including folks from both Apple and Google) for making the web platform environment as pleasant as it is. Kudos!


> We can thank the Webkit Tools team (including folks from both Apple and Google)

webkit originally comes from the KDE project and was known as KHTML (with its KJS companion).. they basically showed the world that a decent HTML renderer can be written in nice-API-C++-code (Qt-style-nice-API) and with limited resources.

how long did Mozilla take to make Netscapes ancient codebase usable? it took forever!

and chrome+safari+android+iOS >= 40% of the browser market. wow.

anyway, lets also thank the KDE project that booted it. :)


Have you worked with Firebug before? Webkit tools is a carbon copy. It is smoother of course, in the same way Chrome is more polished han Firefox.


You're talking to Yehuda Katz here. Yes, he has worked with Firebug.


How these two compare to Dragonfly[1] (Opera). I never worked in depth with any of them so they look pretty same to me. Only difference I know is probably remote debugging which Opera had for years but there was no need for it in firebug/chrome dev so I wouldn't count it as an extra feature.

1. http://www.opera.com/dragonfly/features/ / https://bitbucket.org/scope/dragonfly-stp-1


Writing C# code in Visual Studio feels almost like telepathy. Intellisense is so good that, it nearly writes 30-40% of total code.


I couldn't agree more. In fact, that is my single biggest problem with being a C# developer. Sounds counter-intuitive, right?

Each time I dive into another language, I feel handcuffed because I don't have the features and options that I get from Visual Studio. Once the "new language smell" has worn off, I find myself wishing for faster ways to develop sections of code. I miss instant code compilation and validation. The ability to hop around sections of code, immediately find all references, or catch compile errors at a glance are all things I take for granted until they aren't there. And don't even get me started on ReSharper. Those guys at JetBrains are glorified drug dealers and I am one very hooked addict.

All that said, it makes it very difficult for other languages to gain traction with me. At times, the software adventurer in me gets frustrated about this, but the pragmatic side of my personality (the one that likes food and a house) prevents me from giving up all those benefits.


Amen, I almost totally jumped ship when MVC was a 'new' thing, if they hadn't brought out ASP.Net MVC when they did I would have left.

The only thing I hate about C# is the 'magic' they keep trying introducing to the frameworks. ASP.Net was bloody awful but if you haven't checked out MVC 4, this is truly WTF were you thinking MS:

http://www.asp.net/web-api/overview/getting-started-with-asp...

GetAllProducts magically maps to api/products/

GetProductById magically maps to api/products/{id].

Fucking retards, just give me the tools, not the magic. It's so focused on incompetent idiots. It's even worse than the stupid and almost but not quite utterly useless user membership crap they infect your code and database with. That's what's pushing me away from C# more than anything else, the random magic that will suddenly kill your application.


I'm guessing you're being downvoted because you're calling people retards because of what you perceive to be a poor design, when in reality they've done exactly what you've said, you just don't realise it. Which makes your "incompetent idiots" remark rather ironic and gave me a good chuckle. For the competent, or consciously incompetent:

1. ASP.NET MVC implements customizable routing, like pretty much every other modern web MVC framework these days. The routing library can actually be used in old school ASP.NET Web Forms applications or your own raw ASP.NET application, if you like; it is not ASP.NET MVC specific.

2. The default route in the code generated as part of the "ASP.NET MVC Web Application" template project in Visual Studio maps routes as follows: /{controller}/{action method}/{id parameter}. There's nothing stopping you from (a) changing this in the generated source code (Global.asax.cs) or (b) generating an EMPTY default web application without the code at all and zero routes pre-defined.


I found the magic just got in my way when I first got into ASP.NET MVC. I needed to use Firebird with Entity Framework but I didn't want to use that horrible feature which connects to the database and maps it automatically for you using a GUI. Mapping my model to the database is just something I'd rather do manually, and eventually I figured out how to do it and it's awesome.

I don't use membership so it doesn't infect my db.


YES. THANK YOU.


Sorry, wait - how is this different than the RoR magic. Where you can do stuff like MyObject.findByArbitraryProperty and it just works? That's PFM if you ask me. Django, RoR, and Node all have lots of magic bits. You don't have to use any of the magic, which also goes for MVC.

(I do agree with you though - just because other frameworks have magic bits doesn't mean I like it in MVC. I would also prefer it not be there. I just don't think you can really pick on MS in this case.)


It doesn't fit the language and the environment.

ASP.NET MVC is way too much of a RoR clone than is good for them. C# programmers aren't used to magic: they're used to compilers telling them about typos. Convention over configuration is nice, but it's essentially the concept of dynamic typing translated to frameworks. It fits badly in a statically typed language.

I'd have much preferred ASP.NET MVC to have less magic and, for instance, decent, controllable, IDE-supported and compiler-guarded routing.

Example: in an action method, parameter names are mapped to URL parameters. This is horrible, I should be able to change the parameter name in any method without calling code being affected. Or, when this is not the case (e.g. when C# 4's named arguments feature is used in calling code), I want a compiler error saying that calling code can't find the parameter anymore.

In ASP.NET MVC, I get neither of those things. I might have as well gone Ruby all the way, then.

In short, it's brittle.

Compiled languages have pros and cons, but if you're compiling anyway, please use all the pros to the max. APS.NET MVC doesn't, and that's a shame.

It's still a nice enough framework, but it screams "missed opportunity", much like all those Java libraries that were ported over to C# back when .NET was new.


Binding between a request and a controller method is entirely customisable. The framework uses a completely customisable number of parameter sources (query string parameters, POST parameters, session variables, you can customise this to e.g. query LDAP if you want) and binds those to the parameters of your method in a completely customisable way. See, for example http://odetocode.com/blogs/scott/archive/2009/04/27/6-tips-f... .

That being said there is definitely a deficiency in strong typing in ASP.NET MVC as-is. That's why I use T4MVC (http://mvccontrib.codeplex.com/wikipage?title=T4MVC_doc&...). I'm not too sure how the MVC team have done things much differently, though, without overcomplicating the framework... you'll note the T4MVC approach is based on code generation that inspects your source tree.


Wow, cool stuff!

I think code generation from inspecting source trees really is the future for compiled languages.

I used to think that the only reason to generate code (instead of using reflection or interpreting some DSL) was speed. I missed how code generation gives you excellent additional features, such as more compile-time safety and, most importantly, excellent IDE support. Once my code is generated, I can talk to it from other code like it was a hand-written library including all the IDE goodness (API discovery through autocompletion, etc) that it comes with.

I really hope they'll keep making T4 even more awesome than it already is. Combined with Roslyn, I think we'll get some pretty cool tools ahead that we can't even fathom now.


.NET magic is generally limiting things down so that happy path works and edge cases are expensive. Other platforms do a much better job of this because they start on an edge and make that run through happy path by convention. I can't speak to it being language limitations or just the way Microsoft works, but they almost always seem to get this part wrong.

See ASP.NET MVC Routing as a example (kinda related to the above).


If code can be written by auto completion, it's by definition redundant and IMHO shouldn't be necessary in the first place.


No, it's more like the IDE is augmenting your brain and fingers. The code comes out readable, but you only have to type a fraction of the characters. It's a code-writing assistant robot.

Also, it makes APIs incredibly discoverable. Not sure what a `IQueryable` provides?

    IQueryable iq = null; iq.
and scroll through the popup. Instant one-line descriptions are available in the tooltips, and you can get full documentation with F1. you've ever experienced this, it's REALLY hard to go back to Emacs. It's incredibly well done.

(edit: formatting)


Agree on the discovery part, this is the biggest reason why I stay away from vim.


http://www.vim.org/scripts/script.php?script_id=1520


That doesn't sound all that good to me. My steps to finding what IQueryable provides:

* Cmd+Tab to Chrome

* Cmd+L for location focus

* \IQueryable searches DuckDuckGo for IQueryable and takes me to first result

I get to use the editor I want (hint, not visual studio), and I know a lot more about IQueryable anyway and can continue poking around in the docs to learn more about the 'nearby' bits of the API.

I don't really want my editor to write code for me after only a fraction of the characters. I like writing code. I agree with Inufu, I feel like completion of more than, say, IQu[tab] is starting to show redundancy I'd prefer not to have in the first place.


"Here's how to instantly find documentation on something."

"That doesn't sound all that good to me. Here's how I do it in multiple steps, in a different window!"

Do you see the problem here?


Yea, I really don't. What's wrong with different windows? I prefer to read documentation in a tool that is good for reading documentation (don't understand the IQueryable crap? Just jump over to StackOverflow in a couple keystrokes).

The description I was replying to had you hovering over little thingies for tooltips. The whole time you're writing code little popups and widgets are flying all over the place. That is distracting. Give me an environment that edits text please.


Stockholm syndrome.

Try Visual Studio for a month. At first you'll be like "get out of my way stupid intellisense popup" and then you'll be like "holy crap that just saved me 60 seconds... for the 60th time today." And then you go home early and use that free time to have sex with your wife.

Point being, it'll change your life for the better.


I was forced to use Visual Studio in school, I hated it throughout and took every chance I could get to use Python or Ruby or something else with a unix-y stack.

Trying it again now would be pretty far out of my way just to reaffirm what I already know, since of course I've long since left Windows entirely.


Visual studio has changed a lot since 2008. VS2010 is actually surprisingly good. Personally I prefer it over any other IDE I've ever used, such as eclipse.

As you said, since you don't use windows, there's no point in you using it. But let me just say that it certainly sucked at one point, but it is now one of Microsoft's best products, IMO. They've definitely done a LOT of work to improve it.


Most of the time you don't even need the documentation, as methods are named well enough that they describe their behavior. This is simply much faster than opening another window and doing a google search. The times you do need the docs, a hotkey will open a full window for it.

I'm with you on the crap flying around on every other keypress though. Feels like I'm programming with an extreme case of ADD.


No, I don't. He's using different tools for different jobs, which is the way it should be. Not an integrated mess of a thousand and one things that should be stand-alone programs with intercommunication ability.

Those who don't understand UNIX are forever doomed to re-implement it - poorly. Which is the story of every IDE ever.


As if the goal or intention were to approach UNIX's philosophy. UNIX is practically by definition decoupled. Integrated Development Environments are by definition integrated.

I spent years hating Java and embracing vim, but as I tried to shape my environment more, I grew increasingly frustrated. Finally, I was forced by necessity to use Eclipse and Maven with Java, and the lightbulb turned on for me.

Any language that takes 30-40% less code to do something for you is taking away some freedom. They're making convention easy but can make escaping it to be hard, or may slow down because of more dynamic-ness, or some other tradeoff. And there are many good tradeoffs to be had when creating programming languages, of course.

The deal with Java is that it is the pedant of languages. Half-answers and hand-waving to how objects interact (i.e. duck-typing) aren't good enough for it. This makes libraries or APIs very, very easy to reason about, because if it doesn't access to that information then that means that the library or API is broken or intentionally hiding those details from you. But on the other hand, it enforces a kind of light, but still present, agreement between classes on their relationships to each other.

The point at which your thoughts on IDE come into this is that because Java has a very rigid structure, it can make sweeping code changes at massive scale. This is something that, with shallower insight into the language, or without insight into the flow of code through a method (i.e. checking for dead code or invalid assignments), and so on, would take a massive number of man-hours to duplicate, or make use of the exact same code the IDEs themselves have written for the purpose (i.e. emacs and vim are capable of delegating certain functions to eclipse). Decoupling it in the UNIX way doesn't really make a whole lot of sense when everything is very interrelated in nature.

As well as generate, but given that some people think that if code can be generated, it should be done at runtime by the language instead, I don't want to argue this too hard in this reply. They're not wrong but they sure aren't right.


That is not true. Autocompletion is a decision with user override enabled. It is, at the very least, a visible decision. That does not imply that it is totally automatable.


What about sensible defaults? If the libraries you use are designed with reasonable defaults that have already anticipated your needs there should not be any need for anything but the most basic syntactic autocomplete functionality (closing brackets for example) because any code at that point is customization for your specific project which is not easily generalized (otherwise it would be a default in the library).


Just hide the default behaviour and make the overrides optional.


If you haven't already, you owe it to yourself to try ReSharper. The automated refactoring and static analysis tools are best described as "pair programming with a genius robot".


I felt like I was more of a configuration engineer than software developer when I was working in VS. If I got stuck I would just start typing and then hit ctrl+space and scroll through intellisense to get the options that seemed to fit.


I get that feeling with all modern software engineering. Intellisense and similar environments at least try to make it bearable.

How I long for the day of starting your project with only a blank document.


I guess that's why I gravitate towards JavaScript, still kinda the Wild West where we can still write things from scratch.


if your IDE writes 30-40% of code for you it just means your language needs at least 30-40% more code than it should to cleanly describe the algorihtm. (not dissing C# here, just all IDE-aised languages)


If my IDE writes 40% of my code it means i can call my functions ConnectToDatabaseCheckUserNameAndCountPosts() instead of ConDBusrCnt() just to save a few taps on the keyboard.


Though arguably that should be three different functions:

  ConnectToDatabase()
  CheckUserName()
  CountPosts()


Obviously that's not taken from any real code but just the most obscure function name that still makes sense that i could make up in my head while writing the reply.

...But even after splitting it into three functions you would still save 60% of your keystrokes by using auto completion ;)

  Con()ENTERChec()ENTERCou()ENTER


Which doesn't mean that you can get GetCellLocatuonById into Get CellLocation ById


Sorry for the formatting, the reply box on Android is malfunctioning.


Vim doesn't write any code for me yet I can still have long function names because of the cutting edge magic of auto-completion.


Autocompletion is writing code for you. That's what we're talking about here, in large part.


Touche.


ConnectToDatabaseCheckUserNameAndCountPosts() should be 3 functions, not one.


not entirely true. some languages are very-IDE-aidable but verbose (java and c# come to mind), some are not very IDE-aidable but less verbose (ruby and python come to mind, various LISP variants also fit here I guess).

but that is not hard rule as, for instance, haskell is potentially-very-IDE-aidable AND less verbose.

now only the haskell IDEs need to mature :) but this is a mater of time.


Yes, but with Ruby or Python 60% of that code wouldn't even need to be written.


I almost never log into HN (read it daily), but I felt compelled to put up a vote for C# because it makes me feel like I have super powers. As a solo developer, I get a lot of firepower from the MS stack, and C# is like the icing on the cake. There, I said it.


I hate to hijack this comment, but this topic really highlights an issue with the HN comments. It is now virtually impossible to have any broader discussion since this thread filled the page. A topic that is massively more broad than discussion about C#.


I've only been here a few years, but how and why is this new?

If you're implying that it has to do with the lack of visible scores, I'd point out that I think that the comments are still ordered by score, even if they aren't necessarily displayed.

If it's just because of the sheer number of comments attached to the C# specific parent, I can't remember a time when a really popular comment didn't take up a larger share of space as more comments logically take up more space.

I mean, there was the pre-pagination era, where you could just keep scrolling down, but that was also the era of HN crashing all too frequently.


With "now", polshaw is referring to "this moment in the life of this thread", not "this moment in the life of HN" - so it's not about how HN has gotten worse, just that big threads like the C# one can push other meaningful parts of the discussion way down. It's not because it's always been that way that it's ideal.


Fair point, I suppose. I guess I was just thinking to myself, as I read that, that this is easily the least of HN's problems.

I suppose it IS a fair point though, especially considering that C# is (by my quick once over) only the fourth most popular language, and easily represents the most popular discussion on the topic.

Also, looking through the additional pages, it seems as though there aren't many other comments that even have children, much less anywhere close to the same discussion space.


Eh, C# is good for the environment it lives in, but it's not without it's cruft.

C#'s answer for all of its missing features seems to be a generic class. Don't have tuples? We'll give you Tuple<T>. Don't have inline functions? We'll give you Func<T>. It feels very tacked on (especially Func).


Func<T> is just the type signature they use for lambdas. The syntax allows fully inline functions now:

() => { DoSomething(); }

No return value needed (compiles down to an Action<T> I think)


> No return value needed (compiles down to an Action<T> I think)

Which is an other crufty thing in C#: because Void/() is not a type (inherited from Java), it needs to have both `Func<Tn..., T>` and `Action<Tn...>` in order to handle functions-with-a-return-value and functions-without-a-return-value.


This is true, but its mostly transparent unless you're doing something particularly ugly.


Like trying to take one of these as parameter or return it?


This is a statically typed language mind you. If you're passing something around as values, you're gonna need to declare what its type is (of course there's type inference, but that just turns it into a totally different language)


> If you're passing something around as values, you're gonna need to declare what its type is

I fail to see the relation this has with my issue.


You should need to know whether you require the lambda you're accepting to return some value or not, and its type.


You completely missed the point I was making. Try reading these comments again.


Can't recursively call a lambda function, no thanks.


There are two ways of recursively calling lambda functions, neither perfect, but both usable.

  Func<int,int> fib = null;
  fib = n => n > 1 ? fib(n - 1) + fib(n - 2) : n;
Or write yourself a Y fixed-point combinator, described in http://blogs.msdn.com/b/wesdyer/archive/2007/02/02/anonymous...

  delegate Func<A,R> Recursive<A,R>(Recursive<A,R> r);
  static Func<A, R> Y<A, R>(Func<Func<A, R>, Func<A, R>> f) {
    Recursive<A, R> rec = r => a => f(r(r))(a);
    return rec(rec);
  }
used like this:

  Func<int,int> fib = Y<int,int>(f => n => n > 1 ? f(n - 1) + f(n - 2) : n);
(I'm not advocating writing a fib function this way, but it's a useful example!)


https://blogs.msdn.com/b/wesdyer/archive/2007/02/02/anonymou...


I also feel like "Funcs" are a work around. What I like the most about C# is the fact that it keeps evolving and incorporating new paradigms (closures, lambdas, LINQ, etc)


Try F# then, tuples, records, pattern matching, etc. It's essentially OCaml.net


Have used F# quite a bit. It's nice, the nicest ML I've used, but it has some cruft as well. It feels like 2 languages, really, the nice functional ML language, and then the C#-with-F#-syntax object oriented side. I wish they wouldn't have bothered with the latter.


Actually the OO side is quite similar to OO in OCaml, so I miss your C# remark there.

For a language to be first class in .NET it needs to be able to do OO with the same semantics that the CLR has, otherwise you will have leaky abstractions all over the place.


Yeah, C# tuples are a pretty glaring hack in an otherwise great, evolving language.


Like other C# features and behaviors, I expect that, down the line, the language will pick up syntactic sugar to make the creation and usage of those tuples more straightforward (see delegates -> anonymous functions -> lambdas).


Yeah and F# is the breeding ground for C# features


Func<T> are part of expression trees.

They are intended to manipulate the abstract syntax tree of lambda expressions. A bit like macros.

You should only need to know about them if doing AST manipulations.


I have to agree with this. If only ruby or python had such a powerful development environment (sigh). There's simply nothing in the open source community that rivals the beautiful, simple power of that IDE and language combination. Tools matter when you're trying to ship code.


The beauty of Ruby and Python is that you aren't restricted to an IDE in order to use them; I wouldn't enjoy using them if I was. I like to choose my own tools. This isn't quite so easy when using an all-encompassing (and platform specific) IDE like Visual Studio.

I use tmux (with tmuxinator), with windows for my editor, shell, debugger, source control, logs. I'm able to, effortlessly, change any part of it.


I'm not sure what this means. Are you saying it is impossible to write C# code without the IDE? If so, my .vimrc would like to have a few words with you.


You can write code in vim, yes. Do you debug it there too? Didn't think so. You use a separate debugging tool (or clewn, if you're a masochist). And a separate source control client (possibly wrapped in a vim plugin like fugitive). And a shell.

Effectively you (like me) have probably put together your own set of tools that perform the functions of a IDE.


I used the Vim/Ruby combo for a long time but RubyMine pushed me from Vim to an IDE again (they aren't always bad).


To be fair, having just had a good look at RubyMine, it looks very good.


Pycharm is as powerful as Visual Studio IMHO. I love both of these IDE's.


Agreed, a good IDE goes a long way to make up for the sins of the language.


The new await/async in C# 5 is beautiful. Just try/catch around an await and suddenly async is easy to read and handle errors.


Closure compiler is also very useful for making JS a bit more safe and fast

https://developers.google.com/closure/compiler/


Is it still a good choice if you don't intend to deploy to Windows?


Probably not, eventhough there is Mono.


> How do you convert to a string? Convert.ToString().

Actually, I think this is a bad example because oop is inadequate in this particular case. Converting something to something else perfectly fit the functional paradigm (take an argument, returns something, don't store anything). Why do you need a Convert object? How would you explain this to someone not familiar with C#.

I think Console.WriteLine("hello"); is a better example.


This makes me so happy to read. Honestly i love writing in c#. I spend a lot of my life now using php, but honestly the times when i followed best practices the best (unit tests all over the place, often test first approach) was when i was coding in c#. I think the language just lends itself, and the IDE...to doing things right.


I just wish Microsoft would improve AOT compilation with NGen, or even better, provide native compilation as they do in Singularity with Bartok.


I don't think anyone will be pulling out C# marketing videos from their archives any time soon. Like AT&T archives' the unix operating system http://news.ycombinator.com/item?id=3749496

It will be interesting to see what happens with C# if Microsoft succeeds with Windows 8 on the desktop, tablet, and phone.


If only C# has Maven (that supports both Mono and .NET) and a solid cross-platform libraries, I'd leave everything behind.


What about Npanday(1)? Don't use it myself but the devs at work use it.

1. http://incubator.apache.org/npanday/


NuGet seems to help a bit, but granted it is not Maven.


It's funny. Every time I use a new language, or go back to an old favourite, it becomes my favorite language for a time. Static typing? Wonderful error messages! Dynamic typing? It does what I want! Functional programming? This is the future of programming! Object-oriented programming? I can describe the world! Low level? My code is fast. High level? My code is *expressive.

Is this normal or is it just me? Don't you come to like, or love, a new language? Every time I do something different I realize how good things could be. But this is just a case of "the grass is greener on the other side" I guess.

I ended up voting for Perl as it feels the most fun language. But ask me again in a month and you might get a different answer.


I feel likewise (except for the Perl part. I have the most fun working with PLT-Racket tools).

I believe this happens because language design involves a lot of trade-offs, so every language incorporates these trade-offs.

When one is comfortable in many kinds of languages, one is in a special position to see the trade-offs in the design of the language one is currently programming it.

The way I see it is slightly different then the way you describe. Say I'm programming in Prolog, for instance. In the beginning, I'll be like "Wow, such expressiveness". But inevitably I'll do something that is outside the scope of Prolog and it will be as slow as hell. That's when I think to myself: "if I could just fix this little part... I miss C". So when I'm back programming in C I'll think "now my code is fast", but then inevitably: "if I could just find a way to do this without so much repetition".

In the end, it comes down as a "right tool for the job" thing. One possible ideal would be do the things Prolog is good at in Prolog, the things C is good at in C (and also throw in some Python, Erlang, Lisp, etc). Except most of the time this is infeasible. Working with FFIs suck. Sometimes there are no FFIs, sometimes there are many incompatible ones, and the dream of calling any language from any language is just further and further apart. And don't get me started on the pain that it is to have multiple runtimes with slightly different semantics...

Even if it were possible, a developer would have to learn all these little languages enough to be working on them comfortably, and we all know this is not going to happen. So hardly anybody does this, as hiring someone for a polyglot project is a complete nightmare.


Tradeoffs are a sign of a false dilemma; rather than choosing one solution or another, use them all where they work best. This is where Unix got it right all those years ago; Unix isn't just a slightly more stable platform for running today's bloated and monolithic software, rather, it's an elegant system for connecting maintainably-small utilities. The shell glues said utilities together into programs. Such an approach combines the best of high and low level programming, reuse and specificity, tradition and novelty, etc.

I know shell isn't going to with this popularity contest, but a return to it is what's badly needed in CS today. Instead of attempting to recreate the shell in C# or Java's supplied libraries and subsequently becoming frustrated when interaction with the "outside world" is clumsily accomplished through an FFI pinhole, just use the shell as it was intended: as a lingua franca between utilities.

Write what requires prolog in prolog, what requires c in c, what requires awk in awk, etc. Use flat file databases such as starbase or /rdb and avoid data prisons such as MSSQL, Oracle, MySQL, etc. Make all of these utilities return sane return values and spit out JSON formatted output. Finally, tie it all together with shell. If you need a UI, code it as a thin layer in TCL/TK, python/pytk, ansi c/gtk, or, consider pdcurses, etc. Profile your program and find any weak links in the chain. Recode in a lower level language only when needed.

Programming doesn't have to be hard. As in speech, the more one says, the less one means.


In some ways, I think REST interfaces exchanging JSON are the modern equivalent. Doesn't matter what the underlying programming languages are, everything can talk to everything else through a simple (well, not as simple as pipes), broadly understood, and widely implemented interface.

The Web, of course, has been recognized as the cause of the recent proliferation of and resurgence of programming languages. As long as you speak HTTP, it doesn't matter that you're a dog.


You make a very good point.

And I think it is no coincidence that the creator of Unix is one of the designers of Go, a language that shares Unix's conceptual and implementation simplicity, makes very conscious tradeoffs and where channels work somewhat akin to pipes.

Of course interfacing with the rest of the world has become much harder thanks to XML, SOAP, XMPP and every other such monster, but as somebody else pointed out, the modern equivalent seems to be REST+JSON, I would have preferred something like 9P, but oh well, one has to pick their battles.


That's the right attitude. Each popular language has its strengths and shortcomings. As long as you enjoy it and get the job done, it's a good language. What I can't stand are people dissing other languages to make their language look good. It's like they have to justify their insecure choice of their language by bringing down the others.

As for Perl, I used to hate Perl for its many arcane ways of doing the same thing, but I then forced myself to do some Perl scripts at a job and it's not too bad. It got the jobs done. Since then I've used Perl for many quick scripts.


It's exactly the same that happens with me, and i guess with most of the people. Besides, whenever i am programming in a new language, it happens that I gradually come to know more tricks, hacks and lower level details about the language which makes me like it even more. And, then it becomes my favorite language. And, then I can argue with someone over it. And then one day, I start writing hello_world in a new language, or one of the languages which i had not touched for many years and it becomes my favorite language. And then, i think how foolish it was of me! Btw, i voted for C because nothing is more beautiful than it IMHO; you can do whatever you want so elegantly that it mesmerizes me.


I'm the same way, though I feel like this flies in the face of reason. Switching to a less familiar language usually implies more headaches and less productivity, but the novelty makes it more enjoyable. Another example of how programming is oddly emotional.


Nothing odd about it, IMHO. One of the things I think tech-oriented people consistently ignore is the role of emotion and the subconscious in decision making, even in what are nominally objective disciplines. Our conclusions may be based on reason, but then where do our hypotheses and inspirations come from?


Totally agree. More accurate phrasing would have been "another reminder of how..."

Book recommendation: Thinking Fast and Slow by Dan Kahneman. Great overview of how those factors affect decision making.


Nice, I'm going to check that out :)


... oh... that's just magic. i will intellectually dine on that for a week!


Writing good Perl is definitely a blast. Make sure to read Modern Perl.


No, I think you hit the nail head on. I almost often do quick little things in Perl out of laziness (even though Ruby would be so much prettier), but I also like Pascal/Delphi for static typing and relative speed. C is about as close to assembler as I'd care to come.

But this "Java" thing keeps paying the bills for most of the last decade. I guess it doesn't do everything wrong. (as much as I'd like closures & function pointers, tuples or even working destructors sometimes, I get by with Java)


I agree with this sentiment, and I voted for D because of what it is meant to be. They want it to support any paradigm, with any abstraction layer, and be useful in almost any context. I like that kind of freedom. Especially in a native compiled language.

No, it is not there yet. The hope it that it one day will be. Because that would be amazing. It is already about as easy to write as Java, and usually beats it in performance.


I feel the same way, my problem is it usually starts while I'm learning a new language, so I might drop the current to pick up another, which I of course drop again etc. pp... I'm learning Haskell atm which seems to be the first language that captures my interest even after months. (the announcement of Julia made me think of dropping it, though)


This voting scheme is known as "single-vote-plurality". And it's a giant suckfest. Beyond two candidates, it completely falls apart, and tends to suggest very different results than the actual preferences of the voters.

Hypothetical example. Let's say that 1/4 of HN likes C, then Lisp, then Python, then Java. 1/4 of HN likes Python, then Lisp, then C, then Java. 1/5 likes Lisp, then C, then Python, then Java. And 3/10 like Java, then Lisp, then Python, then C.

So we have:

1. Java has the highest number of votes, even though 7/10 of HN thinks it's the worst language. Java wins!

2. Lisp has the fewest number of votes, even though it's the only language to appear in the top two preferences of 100% of the voters. Lisp loses!

In other words, the results from your voting scheme suggested the opposite of what people really liked (and disliked). This is a known, and very common, pathology of single-vote-plurality and becomes more and more of a problem the more candidates enter the race (and you have a gazillion of them).

Since you can't have people easily express their rank ordered preferences on HN (eliminating Condorcet, IRV, and the like), the next best thing would be to do approval voting. To do approval voting, you'd change the wording in your posting to:

"What languages do you like? Vote for as many as you want."

Then the winner is then the language with the most votes.


I agree with the flawed voting scheme. What I don't understand is why the number one voted comment thread is on how great C# is when I can't last remember an article on HN talking about C#. This whole thread seems so contradictory to my perceptions of the HN community. Either there's a whole host of C# lovers that finally decided to participate in todays discussion (a silent majority), or microsoft evangelists are taking over HN! I'm so confused.


I don't think anything sneaky is going on. I don't code in C# because the MS stack doesn't really make sense for what I'm doing, but it's a good language with a fantastic IDE.

Put another way, there are a fair number of HN articles about PHP but I don't think that's because it's an inherently great language.


Um, what? Maybe I haven't been paying attention, but I haven't noticed any PHP articles around here on any kind of regular basis.


Spot on. Though I’m not sure that instant-runoff voting would be as infeasible as you suggest.


Here are the languages ranked by likes/dislikes ratio (I compared the above poll with the "dislike" poll: http://news.ycombinator.com/item?id=3748961). For example, for each person who downvoted Clojure, there were 28.8 who upvoted it. This ranking is fairer to languages that are well liked by those who use them, but not as well known:

  Clojure        28.8
  Python         26.5
  Haskell        19.7
  C              17.3
  Lua            16.4
  Lisp           11.5
  Erlang          9.9
  Ruby            8.4
  Scheme          8.1
  C#              7.9
  OCaml           7.3
  Smalltalk       7.1
  Scala           6.4
  D               4.4
  CoffeeScript    3.6
  JavaScript      3.5
  Forth           3.2
  Groovy          2.9
  Assembly        2.5
  Ada             1.7
  Objective C     1.6
  Perl            1.6
  SQL             1.4
  Pascal          1.3
  Rexx            1.3
  Delphi          1.2
  C++             1.0
  Tcl             0.9
  Fortran         0.7
  PHP             0.7
  Shell           0.7
  Java            0.6
  Actionscript    0.6
  ColdFusion      0.4
  Cobol           0.1
  Visual Basic    0.1


Not everybody can downvote. That adds significant noise to this data.


I used the term "downvote" figuratively -- I don't mean literal downvotes on this poll (I don't think anyone can downvote a poll option anyway, and even if you could I wouldn't be able to isolate upvotes from downvotes since we just see the combined number); I mean votes for "least favorite language" in the other poll.


I really like go. It's very succinct, clean and orthogonal, yet is enormously powerful. The amazing compilation speed and concurrency primitives are the icing on the cake.

I especially like the lack of a type hierarchy. I have come to think that type hierarchical structures are somewhat brittle - you create these initially correct representations, however when something changes or isn't quite right suddenly you either have to rewrite your hierarchy which is potentially a lot of work, or hack it up whereby it ends up not only incorrect but also misleading.

In go, you get implicit, dynamic interfaces whereby you define an interface and get duck typing against it without having to explicitly indicate that types implement it. The capabilities of a type determine its abstraction, nothing more.


I find it difficult to divorce 'favourite language' from 'favourite stack'.

I use C# a lot, and I love it. But it's tied into MS's heavy stack for web stuff (ASP.NET, etc.) so recently I've switched to using node.js and CoffeeScript in my projects. It's fantastic. So right now my favourite language is JavaScript/CoffeeScript, but just because of the things I can do with it.


I agree.

I'm not especially fond of the Haxe language, but it's Good Enough that I'm happy using it day to day.

However, its ability to export to so many different targets (C++, Javascript [+ Node.js], Java in beta I believe, Flash SWF, AS3, Tamarin, PHP etc) is a real killer feature.

Would that count towards this poll or not?


Which targets are you using?

Wouldn't be awkward to use Haxe for a project that employed language specific APIs? It seems like the sweet spot would be using it to write basic libraries that had no external dependencies.


C++, Flash, and Tamarin and Neko experimentally.

Platform specific APIs are awkward, which is why it's mainly used for writing games. NekoNME abstracts most of that away. I'm not so sure how easily it does node.js.

But the standard runtime for Haxe has been ported to the other languages in a fairly bulletproof way.


So the end result is being able to make games that run in the browser and on the desktop from the same source code?

Any other reason why someone might want to use it?


I love the Python ecosystem but I prefer Coffeescript as a language. Guess I'll upvote both.


> just because of the things I can do with it

I am hard pressed to find a better reason to like a language or stack.


Well, I was thinking that it's possible to like a language in a very pure, abstract way- C# is a great example of that. Lambdas, LINQ, anonymous functions... it's a slick, slick language. If I'm looking at language alone, it's probably my favourite.

But I can't do anywhere near as much with it.


I love Haskells purity -- simply because it is so audacious and so different from everything else. I love Lisps and how it made meta programming first class even though I will never be in a position to use it in my day to day work.


But it's tied into MS's heavy stack for web stuff (ASP.NET, etc.)

For what it's worth, ASP.NET MVC is much, much less heavy than the original ASP.NET (if that's what you're referring to). This is especially the case if you use the Razor syntax for your views.


Being a little offtopic, but I have a personal pet peeve with ASP.NET MVC ... since they bothered to release it as open-source, why are they keeping Razor as a binary blob? Shit, why are they keeping ASP.NET itself as closed source?

This is something that always bothered me about Microsoft-related stuff. Right now I'm using Python and Django for web development. I'm also using Ruby on Rails for a side project. Having access to the source code is vital for me as I've become accustomed to reading a lot of source code. And reading source-code for lack of better documentation is sweet, but then I went further and for instance I also copy/pasted a lot of snippets straight from Django's source code, or worked-around bugs by patching components.

That's why I consider open-source to be superior, regardless of all the polish that Microsoft is able to apply to their products. I'm a software developer, not your average user. Just as a sports-car racer would find unacceptable the lack of access to the internals of her own car, I find unacceptable the lack of source-code that I can read, modify and distribute.


While Microsoft could be more open source friendly, in the enterprise world I work on, I would consider Microsoft one of the good guys when compared with some of the other companies.


That hasn't been a problem for me personally, but I see where you're coming from.

For pure debugging purposes, have you tried using a decompiler? For reasonably well-written (and not obfuscated, naturally) code, the decompiler output is remarkably clear.


> For what it's worth, ASP.NET MVC is much, much less heavy than the original ASP.NET

And thats if you even use that... I use 2 open source libraries to build web apps - Nancy & Simple.Data - and they are both f'in amazing. This is about as "light" as you can be. I have a prezi presentation on my blog about using these libraries to build web apps for a few talks I gave at code conf's. (thinkdevcode.com)


Love seeing shout-outs to Simple.Data- I know the author. Great guy, awesome library.


Cool. Thanks for sharing. I'll absolutely check those out.


Oh, I know, and it is much better. But the whole stack is still heavy- compare setting up an ASP.NET MVC site and IIS to node.js's "http.createServer()". There's no comparison.


You should try NancyFx (https://github.com/NancyFx/Nancy) some time. Its a light weight web framework. Simple and beautiful.


NancyFx is pretty cool. I'm not thrilled with Mono's performance as a server app, however (and I wouldn't bother with a Windows server). I should note, though, that the GC seems a little questionable, though 2.11.0 apparently has made SGen production-ready so I need to look at that again.


What the fuck is a stack?


Applications are open for YC Winter 2024

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: