ASP.NET 5 is dead – Introducing ASP.NET Core 1.0 and .NET Core 1.0(hanselman.com)
hanselman.com
ASP.NET 5 is dead – Introducing ASP.NET Core 1.0 and .NET Core 1.0
http://www.hanselman.com/blog/ASPNET5IsDeadIntroducingASPNETCore10AndNETCore10.aspx
58 comments
There's a lot more of those, isn't there. I still remember the time I got on HN and couldn't tell the tech announcements from the news articles. Can't remember any exact titles, but stuff along the lines of "Coffee.net now ships Espresso". Is that a site that sells elixir of life or some kind of javascript and .NET amalgamation shipping a new library?
Go, Python, Lisp, C, C#, Java, all these words getting double booked to make them memorable. If I want to find a place to fix my lisp, do I go on stack-overflow or to a speech therapist? Book on Go patterns? "Java island book"?
But luckily nowadays we can abuse word connections to get google to spit out the right things. "Python generators" may refer to a machine to generate snakes, but short of living in an xkcd comic, it'll probably return the right results. It just gets a little muddled when developers find just the right collocation to name their pet python [project?]. But then we just heap on more specifiers. Unless you decide to call your library "THE" in a fit of genius.
Like Tabasco in your eyes, it just adds spice to your search experience, doesn't it.
Go, Python, Lisp, C, C#, Java, all these words getting double booked to make them memorable. If I want to find a place to fix my lisp, do I go on stack-overflow or to a speech therapist? Book on Go patterns? "Java island book"?
But luckily nowadays we can abuse word connections to get google to spit out the right things. "Python generators" may refer to a machine to generate snakes, but short of living in an xkcd comic, it'll probably return the right results. It just gets a little muddled when developers find just the right collocation to name their pet python [project?]. But then we just heap on more specifiers. Unless you decide to call your library "THE" in a fit of genius.
Like Tabasco in your eyes, it just adds spice to your search experience, doesn't it.
... off to start the THE project...
Shoot for something absolutely essential, destined to be widely used, and if you feel that sadistic streak shining through, start using a word frequency list[0] to name project parts. "of", "and", "in", "to", "in", "I" and "that" will make for marvellous library names, especially if you find a way to hack around the reserved words of your language of choice. Java and C seem like appropriate choices of language, assuming key parts are actually written in Whitespace and/or Brainf*ck. Make it open source, and nest the layers of WTF so it seems like something you could dive into easily.
Maybe if you make all the bad development choices deliberately, you'll actually end up with a beautiful project, because the reverse seems to happen quite frequently.
[0]https://en.wiktionary.org/wiki/Wiktionary:Frequency_lists
Maybe if you make all the bad development choices deliberately, you'll actually end up with a beautiful project, because the reverse seems to happen quite frequently.
[0]https://en.wiktionary.org/wiki/Wiktionary:Frequency_lists
That is not the reason I decided against using Groovy on a project (JVM level was), but it would have made life somewhat harder.
Most names of programming languages are based on nouns (e.g. Ruby, Python, Lisp, Java) or noun-like (C, C#, PHP), whereas very few are based on adjectives (only know of Basic and Groovy) or verbs (only know of Go).
I've been developing on the .net platform for >10 years. Increasingly I get the feeling that I no longer fully understand its extent, how it all fits together, and what is and is not "legacy". Can anyone recommend a comprehensive and up-to-date survey on the platform for someone in my position?
This is what i think.
.Net ( normal) is Windows only, there's mono which is based on .Net itselve and supports Mac. .Net Core is a extensions on the origin of Mono. Making .Net available on every platform. But Microsoft underestimated the effort it would take. So they are going the .Net Core way for better cross platform support (i'm not saying Mono is bad, fyi!)
.Net core is a fork of .Net framework, with support for all platforms ( Windows, Linux and Mac). It tries to support as many things as possible, the hard part is graphics. Which causes problems for WPF and Image processing.
Asp.Net MVC 4 - 5 - ... is based on .Net frameworks.
Asp.Net 5 is a refactoring of asp.net MVC which supports .Net core and .Net. Which causes difficulty for cross platform support ( some dll's are in a different location using the .Net Core). Also, .Net Core doesn't support SignalR and image processing ( as mentioned in https://github.com/imazen/Graphics-vNext )
They are now renaming .Net Core to v. 1.0 because there will be some differences between .Net core and .Net and it's more logical, because .Net and .Net core is not the same. But they are looking into it to minimize the differences.
Just to be sure, SignalR and Image Processing and graphics problem are going to be solved. Just not yet.
Asp.Net Core runs on both .Net framework and .Net core.
.Net Core will be used for cross platform development, while .Net framework will be used for Windows Only development ( probably WPF, because it isn't released as opensource yet)
Nothing is legacy, Windows has always supported older versions of the .Net framework. I can even run .Net 1.0 on Windows Server 2008... That means a lot.
The difficulty for .Net developers is, that .Net core will be using a lot of opensource tools, that they don't have any experience with.
You can stick to your old pattern if you want, but i'd advice to learn the new tools, that other frameworks are using ( grunt, gulp, ...) . You would come in contact with them outside of the .Net framework :-)
.Net ( normal) is Windows only, there's mono which is based on .Net itselve and supports Mac. .Net Core is a extensions on the origin of Mono. Making .Net available on every platform. But Microsoft underestimated the effort it would take. So they are going the .Net Core way for better cross platform support (i'm not saying Mono is bad, fyi!)
.Net core is a fork of .Net framework, with support for all platforms ( Windows, Linux and Mac). It tries to support as many things as possible, the hard part is graphics. Which causes problems for WPF and Image processing.
Asp.Net MVC 4 - 5 - ... is based on .Net frameworks.
Asp.Net 5 is a refactoring of asp.net MVC which supports .Net core and .Net. Which causes difficulty for cross platform support ( some dll's are in a different location using the .Net Core). Also, .Net Core doesn't support SignalR and image processing ( as mentioned in https://github.com/imazen/Graphics-vNext )
They are now renaming .Net Core to v. 1.0 because there will be some differences between .Net core and .Net and it's more logical, because .Net and .Net core is not the same. But they are looking into it to minimize the differences.
Just to be sure, SignalR and Image Processing and graphics problem are going to be solved. Just not yet.
Asp.Net Core runs on both .Net framework and .Net core.
.Net Core will be used for cross platform development, while .Net framework will be used for Windows Only development ( probably WPF, because it isn't released as opensource yet)
Nothing is legacy, Windows has always supported older versions of the .Net framework. I can even run .Net 1.0 on Windows Server 2008... That means a lot.
The difficulty for .Net developers is, that .Net core will be using a lot of opensource tools, that they don't have any experience with.
You can stick to your old pattern if you want, but i'd advice to learn the new tools, that other frameworks are using ( grunt, gulp, ...) . You would come in contact with them outside of the .Net framework :-)
.NET Core wasn't exactly built for cross-platform, that seems to be a (very welcome) side effect. The big deals for .NET Core (versus .NET Framework) is that it is: A) Open Source (yay!), and B) Componentized (.NET Framework is a giant monolith that roughly followed Windows versions; .NET Core is a set of libraries that each can independently iterate with semver).
The new componentized nature of .NET Core (and the other *Core projects here) is really the big deal here, even without the added benefit that it is Open Source and cross-platform. The benefit for developers to switch to .NET Core (or to support both for the time being) is that you are a lot less reliant on/restricted by the version of Windows your users or servers are running. With .NET Core now things like even the System namespaces are now available as semver-versioned NuGet packages that you can upgrade as a developer, rather than wait for your users to upgrade their Windows version (or install a massive .NET Framework upgrade), or your corporate server to upgrade its Windows Server or .NET Framework. This is especially great for ASP.Net developers as it makes it easier to run servers and easier for your applications to run on whatever servers you have available. It's useful to application developers because .NET Core very much is the .NET supported by the Windows 10 "Universal Windows App" platform, and things like .NET Native are made possible thanks to the componentization efforts of .NET Core.
The new componentized nature of .NET Core (and the other *Core projects here) is really the big deal here, even without the added benefit that it is Open Source and cross-platform. The benefit for developers to switch to .NET Core (or to support both for the time being) is that you are a lot less reliant on/restricted by the version of Windows your users or servers are running. With .NET Core now things like even the System namespaces are now available as semver-versioned NuGet packages that you can upgrade as a developer, rather than wait for your users to upgrade their Windows version (or install a massive .NET Framework upgrade), or your corporate server to upgrade its Windows Server or .NET Framework. This is especially great for ASP.Net developers as it makes it easier to run servers and easier for your applications to run on whatever servers you have available. It's useful to application developers because .NET Core very much is the .NET supported by the Windows 10 "Universal Windows App" platform, and things like .NET Native are made possible thanks to the componentization efforts of .NET Core.
I believe your explanation is going to create more confusion.
What I don't understand is that why all these stupid people have become programmers and developers (Obviously they are not any good at what they do) when they don't even understand these simple naming changes. Urrgggggggg.....
What I don't understand is that why all these stupid people have become programmers and developers (Obviously they are not any good at what they do) when they don't even understand these simple naming changes. Urrgggggggg.....
Yes I share your confusion and I wish there was a guide to all of this, but don't forget DNX/DNU/CoreCLR/CoreFX/new platform targets for NuGet and all that hasn't hit RTM yet. So I am keeping an eye on it, but I will await the release date(s) before committing to learning too much about one thing or the other.
The other thing is the move toward command lines, away from GUI. I think it's great to make everything scriptable. But a command line is also many order of magnitudes less discoverable than a GUI. I am not sure how much Microsoft realises that a great part of the success of C# is about making it easy and intuitive, and that involves visual feedbacks. Unless the idea is to make it more of an "elite language".
> Unless the idea is to make it more of an "elite language".
When I think of VB, and how being easy and discoverable produced enormous amount of crap in software world, I almost support this idea.
When I think of VB, and how being easy and discoverable produced enormous amount of crap in software world, I almost support this idea.
I can think of two type of crap you are referring to:
1. VB written in the 90s (VB6 and before), which has mostly do to with VB having been around for so long. To be fair, if you look at code written in the 90s in any mainstream language through today's best practice lens, everything will look shit. Today's VB is a superb language that can be very elegant, and actually quite modern too, relying less on special characters and more on an expressive, english syntax.
2. VB written by non programmers (essentially VBA). You can argue that non programmers shouldn't be allowed to code, but from a business user point of view, there is much to say about the lack of productivity of IT departments in large organisations. Enabling users to automate many of their tasks has a massive productivity impact. A user can automate the production of a report in a couple of hours, instead of having to discuss specs, prioritisations, budgets, tests, etc for months with the IT dept. I think it's absurd to hold the quality of the code produced against the language.
1. VB written in the 90s (VB6 and before), which has mostly do to with VB having been around for so long. To be fair, if you look at code written in the 90s in any mainstream language through today's best practice lens, everything will look shit. Today's VB is a superb language that can be very elegant, and actually quite modern too, relying less on special characters and more on an expressive, english syntax.
2. VB written by non programmers (essentially VBA). You can argue that non programmers shouldn't be allowed to code, but from a business user point of view, there is much to say about the lack of productivity of IT departments in large organisations. Enabling users to automate many of their tasks has a massive productivity impact. A user can automate the production of a report in a couple of hours, instead of having to discuss specs, prioritisations, budgets, tests, etc for months with the IT dept. I think it's absurd to hold the quality of the code produced against the language.
Also worth noting that the new web project types in VS 2015 include bower, npm and gulp by default.
I tried the new templates and gulp was a welcome addition. I'm sick of finding nice JavaScript libraries that aren't on NuGet or are outdated. Now I can get the libraries and the updates the same as everyone else.
I'm in the same position, and in fact started a project/blog to try and force myself to learn about the 'newer' features that had passed me by. Like many of my personal projects, I kind of ran out of steam, but maybe I'll try and re-learn everything again one day...
https://twelveyearslate.wordpress.com/2014/06/05/professiona...
https://twelveyearslate.wordpress.com/2014/06/05/professiona...
I've actually been doing that very thing for the last few weeks - a side project that I had started in Python but decided it would be a good idea to pick up the new MVC stack.
Apart from the initial fights with dependencies, which I've now all fixed, it's been very enjoyable - there have been a few glitches but they've been kind of fun to work around.
Apart from the initial fights with dependencies, which I've now all fixed, it's been very enjoyable - there have been a few glitches but they've been kind of fun to work around.
All you need to understand is the *Core stuff are optional .
.NET Core is a tradeoff. You give up lots of nice stuff and you'll be able to run on Linux.
If 'core' stuff is optional, it's not core at all, it's optional. Core material is the core of something. So naming things 'core' is stupid if it's not the core of something.
Here, the .NET core libraries/frameworks are a different direction. They're not core, but they're not to be seen as 'optional'. They're to be seen as 'alternative' to .NET full. Not a great alternative today, as many features are lacking and they're really rushing things towards a pretty stupidly set deadline (when you're adding features to a RC2, you're not doing it right), but perhaps someday.
Here, the .NET core libraries/frameworks are a different direction. They're not core, but they're not to be seen as 'optional'. They're to be seen as 'alternative' to .NET full. Not a great alternative today, as many features are lacking and they're really rushing things towards a pretty stupidly set deadline (when you're adding features to a RC2, you're not doing it right), but perhaps someday.
Asp.net is going to be as "supported" as webforms or winforms are, i.e. they will patch them but let them die. I don't think it's just an optional alternative.
More confusion.
I hope you will soon have a streamlined way of developing .NET Core 1.0 / ASP.NET CORE 5 or whatever.
Currently we have dnx/dnu and dotnet, I prefer dotnet but it is still really really buggy and dnx/dnu is somewhat aweful to use. It's really hard to get started / trying stuff out. Other starting languages were a little bit easier to test, I remeber Go 0.7 it also had a tool to replace 0.7 stuff with 1.0 stuff, however It was a whole new ecosystem so maybe it's harder to actually build something on top of something already there.
I hope you will soon have a streamlined way of developing .NET Core 1.0 / ASP.NET CORE 5 or whatever.
Currently we have dnx/dnu and dotnet, I prefer dotnet but it is still really really buggy and dnx/dnu is somewhat aweful to use. It's really hard to get started / trying stuff out. Other starting languages were a little bit easier to test, I remeber Go 0.7 it also had a tool to replace 0.7 stuff with 1.0 stuff, however It was a whole new ecosystem so maybe it's harder to actually build something on top of something already there.
It has become really confusing to get started with .NET. There's a ton of stuff just from Microsoft, and it's kinda hard to understand how everything fits together.
I recently did a project where we wanted to a small built in webserver. Understanding how all the OWIN stuff fits together and knowing which libraries to use is hard than doing the actual coding. For a compiled language it's confusing that your code will compile, but not work, because you forgot a "using".
Go is younger and therefore doesn't have the baggage of .NET or Java, but it's a good example of how simple a "development environment" can be. It's not alone, Python, Lua and others are also much much easier to get started with, without being bombarded by a ton of acronyms and surrounding infrastructure libraries.
I recently did a project where we wanted to a small built in webserver. Understanding how all the OWIN stuff fits together and knowing which libraries to use is hard than doing the actual coding. For a compiled language it's confusing that your code will compile, but not work, because you forgot a "using".
Go is younger and therefore doesn't have the baggage of .NET or Java, but it's a good example of how simple a "development environment" can be. It's not alone, Python, Lua and others are also much much easier to get started with, without being bombarded by a ton of acronyms and surrounding infrastructure libraries.
"A small built in webserver" is exactly what ASP Core now gives you. ASP.NET was never previously about providing that, and it wasn't a thing until fairly recently.
Now with Kestrel you only need a handful of lines of code to spin up a web server.
The whole point of Core is that MS have rewritten .Net and ASP to learn the lessons of more modern languages. ASP.NET 4.6 is standing on 19 years of cruft which is why it has so many weird and complicated parts.
Now with Kestrel you only need a handful of lines of code to spin up a web server.
The whole point of Core is that MS have rewritten .Net and ASP to learn the lessons of more modern languages. ASP.NET 4.6 is standing on 19 years of cruft which is why it has so many weird and complicated parts.
> The whole point of Core is that MS have rewritten .Net and ASP to learn the lessons of more modern languages. ASP.NET 4.6 is standing on 19 years of cruft which is why it has so many weird and complicated parts.
MS hasn't rewritten .NET, most code is simply ported from .NET full. ASP.NET has been rewritten, but only a part of it (the rest is simply not implemented (yet)). '19' years of cruft? .NET 1.0 was released in 2002, not sure where your 19 years come from. Besides, it's better to use a framework that actually works and does whatever you throw at it, than some hip new thing that can only do a few tricks today and perhaps learns a few more tomorrow. You know, clients and all, they want to use the stuff you write and not have to stare at things that break down / crash.
MS hasn't rewritten .NET, most code is simply ported from .NET full. ASP.NET has been rewritten, but only a part of it (the rest is simply not implemented (yet)). '19' years of cruft? .NET 1.0 was released in 2002, not sure where your 19 years come from. Besides, it's better to use a framework that actually works and does whatever you throw at it, than some hip new thing that can only do a few tricks today and perhaps learns a few more tomorrow. You know, clients and all, they want to use the stuff you write and not have to stare at things that break down / crash.
ASP (i.e. ASP Classic) is 90s though, and plenty of its legacy lives on for instance in the ASP.NET Request object.
ASP Core isn't going to be able to do "a few tricks" when it's released, it's going to be production ready for a wide range of standard tasks with significant benefits for newer architectures like micro services. "Clients and all" might like having scalability options that don't involve waiting 20 minutes for an AWS Windows VM to spin up for instance...
ASP Core isn't going to be able to do "a few tricks" when it's released, it's going to be production ready for a wide range of standard tasks with significant benefits for newer architectures like micro services. "Clients and all" might like having scalability options that don't involve waiting 20 minutes for an AWS Windows VM to spin up for instance...
>Now with Kestrel you only need a handful of lines of code to spin up a web server.
OWIN is also just a handful of lines, it's just very confusing. Based on the Kestrel examples I've seen I wouldn't say they've improved much.
I would argue that Microsoft hasn't learnt anything from "modern language" (.NET/C# is still a modern language in it self). In some areas Microsoft seems to hit a spot right in between "convention over configuration" and total flexibility via configuration and it's extremely confusing.
OWIN is also just a handful of lines, it's just very confusing. Based on the Kestrel examples I've seen I wouldn't say they've improved much.
I would argue that Microsoft hasn't learnt anything from "modern language" (.NET/C# is still a modern language in it self). In some areas Microsoft seems to hit a spot right in between "convention over configuration" and total flexibility via configuration and it's extremely confusing.
Exlir, also super easy to get started with, and provides testing out of the box. With a sample test included. `mix new foobar` then you can immediately `mix test` and it'll compile and run.
I can't see myself going back to .NET ever again (it's been 6 years now) because it's so fragmented and hard to find immediately useful information. Microsoft needs to invest on that front.
I can't see myself going back to .NET ever again (it's been 6 years now) because it's so fragmented and hard to find immediately useful information. Microsoft needs to invest on that front.
I needed to read this stuff right here. I have been developing happily on a custom-built CSLA-esque .NET platform for almost two years now, and I cannot begin to explain to my OSS buddies what they should do to spin up a .NET project of their own.
1) It's not my job description or my problem domain at work. I'm paid to code the app, not spin up fresh instances of our app framework from scratch. We have maybe a dozen apps in various stages of progress, so it isn't like we need the whole team to know how to outfit a new instance of our app framework on a regular basis, but...
2) ...it's also amazing how difficult it is to even define what .NET is. It's hard to explain to colleagues what's going on behind the scenes when you can't always quite figure it out yourself. And I don't think of myself as simple-minded. I know that this stuff is a corollary to the inherent power/complexity factor that such a stack brings to the table, but MicroSoft could absolutely do a better job of providing clear and human-readable docs for people who are not already wizards.
1) It's not my job description or my problem domain at work. I'm paid to code the app, not spin up fresh instances of our app framework from scratch. We have maybe a dozen apps in various stages of progress, so it isn't like we need the whole team to know how to outfit a new instance of our app framework on a regular basis, but...
2) ...it's also amazing how difficult it is to even define what .NET is. It's hard to explain to colleagues what's going on behind the scenes when you can't always quite figure it out yourself. And I don't think of myself as simple-minded. I know that this stuff is a corollary to the inherent power/complexity factor that such a stack brings to the table, but MicroSoft could absolutely do a better job of providing clear and human-readable docs for people who are not already wizards.
Things are getting more confusing today briefly on the road to getting better.
The new `dotnet` CLI is on its way to becoming much like the `go` CLI as a one-stop-shop for a lot of your IDE needs, cross-platform and easily accessible from your favorite command line and/or code editor.
It should be the case soon that you can `yo` up a new web project (or use some other generator tool if you don't like Yeoman) and then `dotnet web` straight into a simple web server.
Also, at its face OWIN is a lot simpler than it seems. It's simply the name of the "middleware protocol" in modern .NET web applications, similar to the Connect versus Express confusion in NodeJS land in that Express uses/provides "Connect-compatible" middleware, ASP.NET uses/provides "OWIN-compatible" middleware. Maybe that helps a little.
The new `dotnet` CLI is on its way to becoming much like the `go` CLI as a one-stop-shop for a lot of your IDE needs, cross-platform and easily accessible from your favorite command line and/or code editor.
It should be the case soon that you can `yo` up a new web project (or use some other generator tool if you don't like Yeoman) and then `dotnet web` straight into a simple web server.
Also, at its face OWIN is a lot simpler than it seems. It's simply the name of the "middleware protocol" in modern .NET web applications, similar to the Connect versus Express confusion in NodeJS land in that Express uses/provides "Connect-compatible" middleware, ASP.NET uses/provides "OWIN-compatible" middleware. Maybe that helps a little.
Indeed, way too confusing.
".NET Core 5 is now .NET Core 1.0. " Really? What happens when .NET Core v 2.0 comes out?
.NET is drowning in a confusion of its own making.
".NET Core 5 is now .NET Core 1.0. " Really? What happens when .NET Core v 2.0 comes out?
.NET is drowning in a confusion of its own making.
> ".NET Core 5 is now .NET Core 1.0. " Really? What happens when .NET Core v 2.0 comes out?
Is your point that v2 ... v3 ... v4 will eventually overlap with .NET Core 5? Because .NET Core 5 hasn't actually been released yet.
Is your point that v2 ... v3 ... v4 will eventually overlap with .NET Core 5? Because .NET Core 5 hasn't actually been released yet.
I think it's worse. When you will be googling a question for .Net core 2.0, you will find responses for .Net 2.0. But .Net core is not backward compatible, they removed lots of stuff. We would have been better off if they had called it "Monkey 1.0" instead of ".Net Core 1.0".
Even if it had shipped, what's stopping them from skipping 5 and "turn it up to 6"? ;)
dotnet is replacing dnx/dnu - the dnx concept impressed and so has been more widely adopted within the .Net chain.
Having had a play with the RC2 CI build it is considerably more streamlined than ASP 4.X development. I'm really looking forward to starting to use it in anger over the next few months.
Having had a play with the RC2 CI build it is considerably more streamlined than ASP 4.X development. I'm really looking forward to starting to use it in anger over the next few months.
Looking at the post RTM plan, and I really hope they will de-prioritize VB work and push F# more! It has so big potential to attract wider community and bring back some good OSS devs. Except few big companies that needs to maintain legacy apps, nobody really cares about VB any more, specially in some brand new dev stack like asp.net core. Waste of time and resources IMHO.
I was a VB dev, and it really made sense 20y ago. Now, I haven't heard somebody is using VB (excluding some bank maybe - but they're mostly stuck in .net 2 or 3).
Couple of really nice things about F#:
- It's multi-paradigm. If you just gotta have classes? Go make some. But if you want to learn and take your game to the next level, you'll soon ditch a lot of them. F# means you can move from OO to (mostly) pure FP without having to change languages or stacks.
- You can plug in stuff made in all the other .NET languages. There's a ton of stuff out there that you can just pick up and use.
I like F# because the more I use it, the better I get. I know I don't want classes, for loops, mutable state, and the rest -- but sometimes I just can't see how to get around them. So I throw them in there, get the code to work. Then I go back and figure out where I went wrong. Those "going back" moments are like miniature programming lessons tailored just for the things I don't understand well. Very cool.
- It's multi-paradigm. If you just gotta have classes? Go make some. But if you want to learn and take your game to the next level, you'll soon ditch a lot of them. F# means you can move from OO to (mostly) pure FP without having to change languages or stacks.
- You can plug in stuff made in all the other .NET languages. There's a ton of stuff out there that you can just pick up and use.
I like F# because the more I use it, the better I get. I know I don't want classes, for loops, mutable state, and the rest -- but sometimes I just can't see how to get around them. So I throw them in there, get the code to work. Then I go back and figure out where I went wrong. Those "going back" moments are like miniature programming lessons tailored just for the things I don't understand well. Very cool.
> But if you want to learn and take your game to the next level, you'll soon ditch a lot of them.
"Next level"? Sorry, I don't believe it. All I see is more programming style, and that is no more significant for something better than some new Paris designer dress style.
Functional programming style? Not interested. Showing that P = NP? Sure, interested!
"Next level"? Sorry, I don't believe it. All I see is more programming style, and that is no more significant for something better than some new Paris designer dress style.
Functional programming style? Not interested. Showing that P = NP? Sure, interested!
Perhaps I didn't state that well. I'll try again.
I know what good OO looks like. I can apply SOLID and a lot of other techniques to make my class graph "correct". When I'm done, I have a well-decomposed mostly-isomorphic view of the problem domain (usually along with a lot of "helper" stuff thrown in.)
If you know how good OO looks, and you look at your classes and they don't look that way? You can learn a lot by continuing to clean them up.
Same goes for FP. But currying, partial application, and composition allows for a huge amount of code reduction (and corresponding better problem understanding) than OO. So as you "clean up" your functional code, you're learning much better refactoring skills than you ever would with OO.
It's not surprising. OO is mainly concerned with where things go. Learn you some OO and you know where to put stuff. FP is mainly concerned with what things do. Learn you some FP and you'll learn how to make the computer do more with less code. Less code generally means less bugs and easier maintenance, but we can save that for another day. The point of my original post is that F# can let you learn both ways -- and move from OO to FP in an incremental, self-directed fashion. That's pretty cool.
I know what good OO looks like. I can apply SOLID and a lot of other techniques to make my class graph "correct". When I'm done, I have a well-decomposed mostly-isomorphic view of the problem domain (usually along with a lot of "helper" stuff thrown in.)
If you know how good OO looks, and you look at your classes and they don't look that way? You can learn a lot by continuing to clean them up.
Same goes for FP. But currying, partial application, and composition allows for a huge amount of code reduction (and corresponding better problem understanding) than OO. So as you "clean up" your functional code, you're learning much better refactoring skills than you ever would with OO.
It's not surprising. OO is mainly concerned with where things go. Learn you some OO and you know where to put stuff. FP is mainly concerned with what things do. Learn you some FP and you'll learn how to make the computer do more with less code. Less code generally means less bugs and easier maintenance, but we can save that for another day. The point of my original post is that F# can let you learn both ways -- and move from OO to FP in an incremental, self-directed fashion. That's pretty cool.
I'm not seeing your point. Your posts I have read thus far are arguing for a specific programming style....but you dismiss all other programming styles. Your style is just another 'paris designer dress'.
Objectively, certain styles have distinct advantages over others. Your argument comes across as "Broadband? Why would I need broadband? I have a perfectly fine dial-up modem!".
I'm trying to say this as nice as possible: You come across as a person who is against learning any new concepts. As if you learned one thing many years ago and refuse to change.
Objectively, certain styles have distinct advantages over others. Your argument comes across as "Broadband? Why would I need broadband? I have a perfectly fine dial-up modem!".
I'm trying to say this as nice as possible: You come across as a person who is against learning any new concepts. As if you learned one thing many years ago and refuse to change.
[deleted](1)
I learn new stuff right along. Just now I'm trying to get my startup live so am cutting back on learning new stuff, but I have several lifetimes of new stuff I'm eager to learn.
I've learned lots of new stuff in computing and in programming languages. But, by now, in programming languages, mostly I give up -- structured programming, object oriented programming, logic programming, rule based programming, functional programming, programming based on actors, threaded, stack based programming, frame based programming, strongly typed programming, programming based on communicating sequential processes, literate programming -- because the tools are, net, not better.
For some progress, it would be good to be able to have some proofs of correctness. I looked at that field, and it's hopeless: First problem, the proofs are too long and hard to do, e.g., have some astounding collection of induction arguments. Second, with programming language side effects, etc., have to assume away a lot of possibilities for errors. Third, a proof needs some hypotheses and conclusions, that is, givens and results, and for realistic software those two are too difficult to have in precise terms. E.g., for realistic software, it's just too tough to describe in principle, as needed for a solid proof, all the possible inputs and what should be done for all the cases. So, attention to proofs of correctness mostly went away.
Net, in my programming, for progress in having the software simple, efficient, easy to understand, easy to write, debug, and change, my approach is just good conceptual design, documentation, and use of the basic tools in VB .NET. I'm no longer looking for such progress via programming language syntax, semantics, constructs, or features.
I've learned lots of new stuff in computing and in programming languages. But, by now, in programming languages, mostly I give up -- structured programming, object oriented programming, logic programming, rule based programming, functional programming, programming based on actors, threaded, stack based programming, frame based programming, strongly typed programming, programming based on communicating sequential processes, literate programming -- because the tools are, net, not better.
For some progress, it would be good to be able to have some proofs of correctness. I looked at that field, and it's hopeless: First problem, the proofs are too long and hard to do, e.g., have some astounding collection of induction arguments. Second, with programming language side effects, etc., have to assume away a lot of possibilities for errors. Third, a proof needs some hypotheses and conclusions, that is, givens and results, and for realistic software those two are too difficult to have in precise terms. E.g., for realistic software, it's just too tough to describe in principle, as needed for a solid proof, all the possible inputs and what should be done for all the cases. So, attention to proofs of correctness mostly went away.
Net, in my programming, for progress in having the software simple, efficient, easy to understand, easy to write, debug, and change, my approach is just good conceptual design, documentation, and use of the basic tools in VB .NET. I'm no longer looking for such progress via programming language syntax, semantics, constructs, or features.
> Except few big companies that needs to maintain legacy apps, nobody really cares about VB any more, specially in some brand new dev stack like asp.net core. Waste of time and resources IMHO. I was a VB dev, and it really made sense 20y ago. Now, I haven't heard somebody is using VB (excluding some bank maybe - but they're mostly stuck in .net 2 or 3).
Nope. Not even close. My startup is based on Visual Basic .NET and the .NET Framework 4.0 with ASP.NET and ADO.NET, and IIS. My startup has all new code -- I wrote it all. Currently the code has 18,000 programming language statements in 80,000 lines of typing -- right, lots of comments.
No, my startup is not a bank. Instead, my work is for a new Web site where the crucial, core secret sauce is from some original work I did in applied math with some advanced prerequisites in pure/applied math.
I really like VB .NET, a lot. I've used a lot of programming languages, and VB .NET is my favorite, by a nice margin. Microsoft did well.
C#? No thanks. It borrows some of the syntax from C, and it was designed to be sparse, for the old 8 KB main memory DEC PDP-8, with a deliberately idiosyncratic syntax that is tricky, difficult to read, write, or understand and error prone. It's just too darned sparse.
AFAIK, VB .NET and C# are really essentially the same except just for syntactic sugar. IIRC there is a translator from one of these two to the other. Maybe there are some differences, but they have to be for tricky things I likely don't need and don't want to use. So, since VB .NET is much easier to read, write, teach, learn, debug and is less error prone, it's VB .NET instead of C# for my startup.
If Microsoft drops, VB .NET, I will scream bloody murder.
For functional programming, no thanks. I explained my programming style in
https://news.ycombinator.com/item?id=10937342
Really, I have no interest in more revolutions in programming style. Instead, I want good tools, and IMHO VB .NET is the best there is. Then I want just to use the good tools.
For a tool better than VB .NET, that would be a long shot for a long time.
Microsoft: For VB .NET, the .NET Framework, etc. don't mess them up, grow them no more than slowly, keep strict upward compatibility -- don't force me to rewrite or even retest my existing production code.
If some users like C# or F#, fine with me -- I won't be using either of them, or A#, B, C, C#, D, D#, ... or G# either except on my piano.
Nope. Not even close. My startup is based on Visual Basic .NET and the .NET Framework 4.0 with ASP.NET and ADO.NET, and IIS. My startup has all new code -- I wrote it all. Currently the code has 18,000 programming language statements in 80,000 lines of typing -- right, lots of comments.
No, my startup is not a bank. Instead, my work is for a new Web site where the crucial, core secret sauce is from some original work I did in applied math with some advanced prerequisites in pure/applied math.
I really like VB .NET, a lot. I've used a lot of programming languages, and VB .NET is my favorite, by a nice margin. Microsoft did well.
C#? No thanks. It borrows some of the syntax from C, and it was designed to be sparse, for the old 8 KB main memory DEC PDP-8, with a deliberately idiosyncratic syntax that is tricky, difficult to read, write, or understand and error prone. It's just too darned sparse.
AFAIK, VB .NET and C# are really essentially the same except just for syntactic sugar. IIRC there is a translator from one of these two to the other. Maybe there are some differences, but they have to be for tricky things I likely don't need and don't want to use. So, since VB .NET is much easier to read, write, teach, learn, debug and is less error prone, it's VB .NET instead of C# for my startup.
If Microsoft drops, VB .NET, I will scream bloody murder.
For functional programming, no thanks. I explained my programming style in
https://news.ycombinator.com/item?id=10937342
Really, I have no interest in more revolutions in programming style. Instead, I want good tools, and IMHO VB .NET is the best there is. Then I want just to use the good tools.
For a tool better than VB .NET, that would be a long shot for a long time.
Microsoft: For VB .NET, the .NET Framework, etc. don't mess them up, grow them no more than slowly, keep strict upward compatibility -- don't force me to rewrite or even retest my existing production code.
If some users like C# or F#, fine with me -- I won't be using either of them, or A#, B, C, C#, D, D#, ... or G# either except on my piano.
it's possible (really) to help with F# support, no need to wait ms.
That said, vb is same as F#, every language it's ok in some context.
The whole dotnetcli/coreclr/aspnet is a new bootstrap, so it's ok only one language it's supported at the beginning.
Discussing now of other languages help make it language agnostic.
The dotnet cli and aspnet team are really friendly if someone want to help.
That said, vb is same as F#, every language it's ok in some context.
The whole dotnetcli/coreclr/aspnet is a new bootstrap, so it's ok only one language it's supported at the beginning.
Discussing now of other languages help make it language agnostic.
The dotnet cli and aspnet team are really friendly if someone want to help.
Definitely this! I can't remember talking to anyone using VB in last 5 years. And I'm LOB / enterprise app dev.
As a .NET developer turned rails developer, looking back at .NET core 5 (on osx) I like what they're trying. I feel really at home because i love the rails workflow, but i love C#. It's not quite ready for primetime yet (in my opinion), but I could see myself going back in the future.
That said, I feel like my rails experience is helping me understand the new .NET works a lot better than my previous .NET experience. So I think the name change is appropriate. It's different enough.
That said, I feel like my rails experience is helping me understand the new .NET works a lot better than my previous .NET experience. So I think the name change is appropriate. It's different enough.
I think that .NET Core takes a lot of inspiration from node.js as well. Probably why it feels a bit different from Rails.
Sure this makes sense if you've read the explanation behind it, but this type of change is bad for new users - very confusing.
The intention seems to be that when the dust settles, it will be easier and simpler for new users to get started. As others have mentioned, the "install and start coding" experience has to compare well to ruby, python, node.js etc. Like this: https://dotnet.github.io/getting-started/
Indeed - I think this is a welcome change. Might make it confusing for a year - but makes way more sense for the next 14 years.
As though they're not going to do more name changing during that time :)
Although I think it's great that Microsoft is moving to oss and cross platform dev, I can't help but still believe that moving from the .net ecosystem to others like go and ruby was the best move I could have made for my sanity and overall developer happiness.
I love C# as a language, but the development story is still extremely disappointing. I want Microsoft to stop trying to hold my hand -resulting in cookie cutter applications- and give me the freedom that I experience writing applications in a language like Go. If Microsoft wants a larger set of the developer mind share they need to stop playing catchup (integrating bower and gulp? Who really cares.) and start creating more great tooling I can run from the command line.
I love C# as a language, but the development story is still extremely disappointing. I want Microsoft to stop trying to hold my hand -resulting in cookie cutter applications- and give me the freedom that I experience writing applications in a language like Go. If Microsoft wants a larger set of the developer mind share they need to stop playing catchup (integrating bower and gulp? Who really cares.) and start creating more great tooling I can run from the command line.
When .net launched, it introduced vb.net, that gave Visual Basic support. Not a smooth transition, but it gave some developers a bridge to stand on. I wonder why Microsoft didn't just skip the .Net name to signal a new change in both technology and philosophy instead of getting heads blown up by old developers not understanding the switch.