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.

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!

There is no substitute for lambdas :)

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

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

I prefer Clojure.

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

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.

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.

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...

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.

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'm glad to see someone still uses it:)

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

- 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).

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?

  > 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!) :)

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.

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

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?

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!

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.

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

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.

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.

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.

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

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.

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.

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.

    var firstNumber = numbers.FirstOrDefault();

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];
    }

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 :)

> 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 :)

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

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.

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

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.

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

- 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.

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.

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

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...

- 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.

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

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();

    Person george = new Person();

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.

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.

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);
  }

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.

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.

And yet, working with C# is joyful.

- 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...

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

-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

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#.

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.

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.

I take the part on Scala back.

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

This will work.

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

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

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.

+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!

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. :)

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

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.

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.

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 don't use membership so it doesn't infect my db.

(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.)

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.

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.

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.

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

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

    IQueryable iq = null; iq.

(edit: formatting)

"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?

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.

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.

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.

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.

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.

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

  ConnectToDatabase()
  CheckUserName()
  CountPosts()

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

  Con()ENTERChec()ENTERCou()ENTER

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.

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.

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.

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).

() => { DoSomething(); }

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.

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

  Func<int,int> fib = null;
  fib = n => n > 1 ? fib(n - 1) + fib(n - 2) : n;

  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);
  }

  Func<int,int> fib = Y<int,int>(f => n => n > 1 ? f(n - 1) + f(n - 2) : n);

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.

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 use tmux (with tmuxinator), with windows for my editor, shell, debugger, source control, logs. I'm able to, effortlessly, change any part of it.

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

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

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.

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

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

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 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.

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.

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.

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.

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.

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

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)

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.

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.

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.

  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