Well, what's the alternative? The length at least is descriptive, there's no question about what it does. Double negatives are unfortunate, but that all depends on what the default value previously was (in the event that there actually was no flag like this, it definitely makes sense to make the default false, and then the language follows).
But sure, maybe PreventApply... would've been better. Then again, PreventApply... sounds weird, and should probably be PreventApplying..., but, ehh, naming is hard.
WPF actually is, but apparently not everything in code is measured in WPF's quasi-pixels, apparently, so a few spots may look off. That said, none of the things they fixed looked especially horrible before. I've seen much worse in other toolkits.
I am really curious at how is the scene for .NET developers, with the rise of things like nw.js(node-webkit) and electron(github's atom shell).
I do know that the framework is stronger and more test proven but the traction this type of tools are earning is important.
Will the .net framework will conquer the heart of developers with the release of some of their projects as open source, and will create the best cross platform desktop development kit?
Or is it doomed to be a Windows only beutiful thing.
In terms of desktop development, it's important to keep in mind that Windows is still what's running on ~90% of desktops and laptops outside a few bubbles. I doubt your average desktop .NET developer has spent much time thinking about those sort of cross-platform approaches, compared to how much the web has eroded the market for rich client apps.
If you can live with the Windows only target, developing desktop apps in .NET/WPF using Visual Studio is incredibly pain free in a way that I've never found developing HTML websites. Maybe those frameworks take some of the pain away, but I can't imagine that ease of development is anywhere near that of WPF. It helps that C# is a very nice language with a really great standard library.
I do understand that .net is far more powerfull, far more everything, but the best tool not always is the one that conquers the world. I would truthfully love to see Microsoft bring WPF to other platforms.
Yeah. The sad thing is so many web devs have never written a desktop app of any kind, so have no idea how painful the web really is. I loved Delphi in the 90's. That said, modern tools have far surpassed it.
If you want a C#+WPF type experience that's also open source and cross platform, check out Kotlin and JavaFX. JFX is the new third gen (post-Swing) GUI toolkit in Java and it's quite impressive. It's scene graph structured like WPF, has data binding, but also pays close attention to visuals: you can style it with a dialect of CSS, everything is 3D accelerated via D3D or OpenGL, you can do shader based effects on any part of the UI, etc. It has all the usual layout management and business components but also can do things like embedded h264 videos, 3D objects, and there's a tightly integrated embedded WebKit too if you need it.
Finally there's a tool that takes your app and spits out bundled/native packages for each platform, so the user doesn't ever have to know that the app was written in Java. No JRE or awful toolbars to install.
I've written a few apps this way and it's much more fun than writing a web app.
I tried JavaFX circa 2009 and it was scary; pure black magic in terms of what the same code would on a given day. I guess Oracle put some effort into it over the years, but never, ever again will I touch that language.
It's not a custom language anymore. It's just a regular widget toolkit API like Swing. There is a thing called FXML which is a run of the mill XML based layout language, with a GUI designer called Scene Builder.
Alternatively writing web apps using Knockout seems so much nicer than WinForms and INotifyPropertyChanged hell. Maybe WPF solves this, but I wouldn't want to go back.
I was interviewing student devs recently and was flabbergasted how many of the kids doing greenfield personal projects were still using WinForms. It's frustrating how Visual Studio pushes them to work with this bone-headed warty out-of-date technology. These weren't old hands using somethign familiar just to get an MVP for a personal project, these were kids who didn't know any existing GUI frameworks and started using WinForms because it's the default in VS.
Meanwhile I am doing a greenfield project in WinForms, because it needs to be integrated into an existing eco-system of applications and components built around WinForms.
Knockout is a data binding framework for DOM/HTML based apps.
WPF and JavaFX both have a mature reactive data binding framework so altering your model causes updates to the UI and vice-versa. JavaFX has an entire functional reactive framework in it so you can build lazy functional transforms over observable collections and the like. The fact that it's an API rather than a DSL makes it kind of ugly, I believe LINQ is a little similar but much more nicely integrated for the .NET world. But it's all there.
javapackager. It comes with JDK8+. It can make signed DMGs on MacOS, EXE/MSI packages on Windows, DEBs/RPMs/tarballs on Linux etc. They don't have any Java branding. Here's an example of how to use it:
The catch is you need the platform to make packages for the platform. It can't make Mac DMGs from Windows, for instance. I have a Mac laptop with Parallels so I can make packages for all three major platforms.
To stay on the .NET topic, this is the closest the JVM world currently has to something like .NET Native, I guess, although of course, there is no native code involved .... it just looks that way to the end user. I guess when .NET matures as a cross platform solution they will need a similar tool, as other platforms don't have the runtime installed by default.
I love C# enough to do side projects in it, and I never thought I would say that about a msft product, especially with so many powerful scripting languages out there now. But it really is a good language, and the development environment beats any web framework toolset I have used.
I worked with .NET for years and never made a desktop app. C# is a great language to work in when making backend services for websites, IMO (even though there's a whole load of crap that comes along with the framework).
These days I've moved on, but .NET is far from a desktop-only thing. Particularly when you can make iOS apps with Xamarin, etc.
>C# is a great language to work in when making backend services for websites, IMO (even though there's a whole load of crap that comes along with the framework).
Exactly how I feel. I've been working professionally with C# professionally for over a year now doing a lot of backend stuff for websites and it's great. .NET shares a similar philosophy with Python in that it's a "batteries-included" language. Need a REST endpoint? I can have one up and running from scratch in under 5 minutes with WebApi. Inter-process communication? Let me create an MSMQ instance - done! The only downside is what you mentioned - whole loads of crap that come with the framework. I hate IIS for this reason (but love how easy it is to deploy web services). We're currently working on an HTML5 replacement for our current Silverlight stack (lol) and wanted to go with Node.js instead of IIS, but we really want C# on the backend and don't want to hack it. From our point of view, JavaScript is great for the front end but completely idiotic for the amount of work we do on the backend. Type safety and static compilation is essential for us.
You don't need to use IIS for hosting anymore, look up Owin self hosting. You'll have to build some of the stuff IIS gives you yourself, but the speed is better
Others have mentioned this but they've really migrated away from an IIS-only approach. .NET 2015 has really tried to emphasize that you don't need IIS. Take a look at some of the .NET core documentation. They're officially supporting Linux and OSX when it's released (tentatively Q1 2016...so far away) but it will "just work" out of the box.
Honestly I've found getting up and running with Mono and Kestrel really simple with the latest beta. I ran from Visual Studio without really doing anything and then switched to OSX and it worked perfectly. You still need to rely on some mono classes as of now for things that haven't been open sourced (Xml streams....) but even the mono implementations worked just fine.
I would disagree with that statement. Nuget packages make it incredibly easy to use other people's code in C#. You add the package, and it's ready to be referenced. Automatically pulls it in on builds, too.
Sure, I can agree with that, but that doesn't exactly impact the ease of using other people's code. The availability of said code? Definitely. The ease in which you can use it? I'd give that to C# just because of not having to download the libraries and keep them up to date yourself.
Switching to RyuJIT is great. Also, the SIMD support being a first-class citizen in the runtime and BCL seems huge for gaming and number-crunching related applications.
> I think it sorta means "use case" and comes from Agile development
That's one use, but the use of "story" upthread is a different common sense that is actually more like "solution" (and much more of a marketing term) than the requirements sense of "story" used in some development methodologies.
I remember reading a report that found that the use of buzzwords was a benefit when done among management. But telling developers to leverage their synergies is probably not going to help you at all unless you are joking.
Consider, though, that with all of the new stuff being developed in the open, and huge parts of it being open sourced outright, that this could provide the Mono team with the ability to fast track feature parity.
> New in C# 6! Enables a concise syntax for calling static methods without type qualification.
Essentially you still have to put your functions in a class, but you're allowed to call them without the class (if desired). Kind of like "free functions" in C.
I like C#, but it looks like the team is running out of ideas. Or, perhaps, they realized that the "everything must go in a class" mantra was a bad idea.
I think you're underestimating the power of static includes. A benefit is being able to add a dialect of sorts to your codebase to give it some functional flair. One person took this to the extreme[0].
I don't think it's that they've run out of ideas, it's that they're being picky with what they implement as C# is fairly modern but also fairly mature. This isn't like the C++ revolution of the past few years where they've been adding new, interesting, (and sometimes dramatically different) features to a decades old language.
Regardless, this change is very handy. Even if "everything must go in a class" is a bad idea (I think it's fine), the end result of this change, from the library consumer's standpoint, is the same as having functions defined outside a class but within a namespace. It's a great pragmatic change that doesn't rock the boat much.
In line with that are the other mostly minor but time saving changes like simplified null coalescing.
public static string Truncate(string value, int length)
{
return value?.Substring(0, Math.Min(value.Length, length));
}
In previous versions this looks like:
public static string Truncate(string value, int length)
{
return value != null ? value.Substring(0, Math.Min(value.Length, length)) : null;
}
I recognize that this particular change is meant as a convenience. But I'm not the person who put the exclamation mark in the part that I quoted from the article. And it makes me laugh that one feature they specifically call out is the ability to do what programming languages could do in, say, 1958 ( https://en.wikipedia.org/wiki/ALGOL_58 ).
It really does put a big fat grin on my face to see C#/.Net get love here. I've been using it for years and love what it has evolved to. But the msft bashing on hn (thus, by default, all ms products, with maybe the exception of F#) was really hard on the proverbial soul for the longest time.
I hope to one day be able to natively do C# on linux under a vs parity ide (the tools are really great).
MS has definitely made strides the last few years.
Still, they haven't given up on their product-key nonsense and their unfortunate cozy relationship with govt-surveillance types which are incongruous with open platforms. There's progress left to be made before I will consider their products again.
C# gets more love than not on HN. Even my suggestion of VB as an advanced-yet-approachable language ended up being voted to the top of a recent thread[1].
70 comments
[ 27.0 ms ] story [ 2354 ms ] threadBut sure, maybe PreventApply... would've been better. Then again, PreventApply... sounds weird, and should probably be PreventApplying..., but, ehh, naming is hard.
HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor
http://grepcode.com/file/repository.springsource.com/org.asp...
I'm unsure if I should laugh or cry.
Just speculating, but this might be a fail safe since bool's default to false in .NET.
Its about time.
I do know that the framework is stronger and more test proven but the traction this type of tools are earning is important.
Will the .net framework will conquer the heart of developers with the release of some of their projects as open source, and will create the best cross platform desktop development kit?
Or is it doomed to be a Windows only beutiful thing.
If you want a C#+WPF type experience that's also open source and cross platform, check out Kotlin and JavaFX. JFX is the new third gen (post-Swing) GUI toolkit in Java and it's quite impressive. It's scene graph structured like WPF, has data binding, but also pays close attention to visuals: you can style it with a dialect of CSS, everything is 3D accelerated via D3D or OpenGL, you can do shader based effects on any part of the UI, etc. It has all the usual layout management and business components but also can do things like embedded h264 videos, 3D objects, and there's a tightly integrated embedded WebKit too if you need it.
Finally there's a tool that takes your app and spits out bundled/native packages for each platform, so the user doesn't ever have to know that the app was written in Java. No JRE or awful toolbars to install.
I've written a few apps this way and it's much more fun than writing a web app.
Agree fully. there are concepts that are fully mature in desktop applications, that the web has yet to come close.
WPF and JavaFX both have a mature reactive data binding framework so altering your model causes updates to the UI and vice-versa. JavaFX has an entire functional reactive framework in it so you can build lazy functional transforms over observable collections and the like. The fact that it's an API rather than a DSL makes it kind of ugly, I believe LINQ is a little similar but much more nicely integrated for the .NET world. But it's all there.
https://github.com/vinumeris/lighthouse/blob/lighthouse/mac-...
The catch is you need the platform to make packages for the platform. It can't make Mac DMGs from Windows, for instance. I have a Mac laptop with Parallels so I can make packages for all three major platforms.
To stay on the .NET topic, this is the closest the JVM world currently has to something like .NET Native, I guess, although of course, there is no native code involved .... it just looks that way to the end user. I guess when .NET matures as a cross platform solution they will need a similar tool, as other platforms don't have the runtime installed by default.
These days I've moved on, but .NET is far from a desktop-only thing. Particularly when you can make iOS apps with Xamarin, etc.
Exactly how I feel. I've been working professionally with C# professionally for over a year now doing a lot of backend stuff for websites and it's great. .NET shares a similar philosophy with Python in that it's a "batteries-included" language. Need a REST endpoint? I can have one up and running from scratch in under 5 minutes with WebApi. Inter-process communication? Let me create an MSMQ instance - done! The only downside is what you mentioned - whole loads of crap that come with the framework. I hate IIS for this reason (but love how easy it is to deploy web services). We're currently working on an HTML5 replacement for our current Silverlight stack (lol) and wanted to go with Node.js instead of IIS, but we really want C# on the backend and don't want to hack it. From our point of view, JavaScript is great for the front end but completely idiotic for the amount of work we do on the backend. Type safety and static compilation is essential for us.
In addition to Owin self-host, you might want to check out Edge.js, which lets you host .NET under Node: http://tjanczuk.github.io/edge/
http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducin...
Honestly I've found getting up and running with Mono and Kestrel really simple with the latest beta. I ran from Visual Studio without really doing anything and then switched to OSX and it worked perfectly. You still need to rely on some mono classes as of now for things that haven't been open sourced (Xml streams....) but even the mono implementations worked just fine.
Not really, as they have no story for Mono not to mention ARM NEON support.
Complaining about "hip substitute buzzwords" is very hip, though. Thumbs up.
That's one use, but the use of "story" upthread is a different common sense that is actually more like "solution" (and much more of a marketing term) than the requirements sense of "story" used in some development methodologies.
b) Why would Microsoft have a story for Mono? Mono isn't a Microsoft thing.
Essentially you still have to put your functions in a class, but you're allowed to call them without the class (if desired). Kind of like "free functions" in C.
I like C#, but it looks like the team is running out of ideas. Or, perhaps, they realized that the "everything must go in a class" mantra was a bad idea.
[0] https://github.com/louthy/language-ext
Regardless, this change is very handy. Even if "everything must go in a class" is a bad idea (I think it's fine), the end result of this change, from the library consumer's standpoint, is the same as having functions defined outside a class but within a namespace. It's a great pragmatic change that doesn't rock the boat much.
In line with that are the other mostly minor but time saving changes like simplified null coalescing.
In previous versions this looks like: Not a huge change, but a very handy one to have.At least in Java-land, it's considered bad style to use this for anything other than constants.
I hope to one day be able to natively do C# on linux under a vs parity ide (the tools are really great).
Still, they haven't given up on their product-key nonsense and their unfortunate cozy relationship with govt-surveillance types which are incongruous with open platforms. There's progress left to be made before I will consider their products again.
[1] https://news.ycombinator.com/item?id=9908446