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.
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.
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()
Sorry for the formatting, the reply box on Android is malfunctioning.
> 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 fun…
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 pu…
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.
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.
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 de…
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.
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 fo…
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…