Related
I joined a place where they have an application that is written using VS2005 and .NEt 2.0 Desktop application. Reason why they don't want to move is they are not feeling comfortable and they feel it will break a lot. I feel the opposite. There may be lot Security fixes .NET latest version it was not applied to old version. Is there a Security issue here?
I know there are breaking changes but it will take one or two months to sort it out.
Did any one faced same problem. What are the risk here not to upgrade to the latest version.
I understand .NET 4.5 has whole lot of new functionality it will improve programming experience. Since it is a maintenance application is there a benefit of upgrading to the latest version.
NET 2.0 should be secure. The mainstream support for .NET 2.0 has ended on 4/12/2011 as noted here. Right now MS offers only extended support till 4/12/2016, which includes security updates as you can see in the table at: http://support.microsoft.com/lifecycle/default.aspx?LN=en-us&x=12&y=15.
The first thing you can do is change the target platform and test it. I'd be very surprised if it didn't compile right away.
The .NET framework maintains a lot of legacy code to prevent upgrades such as this from breaking, so compilation and run are both unlikely to break, albeit you may get lots of warnings due to Obsolete implementations.
As for the security consideration, consider that one major aspect of the .NET Framework is the reverse compatibility, which means that your application is already running against the newer runtime anyway, depending on the client environment.
As for improvements to the coding environment, note that the newer coding practices require changes to the code, and thus won't simply automatically be taken advantage of, but may offer a way to go back and streamline (both in terms of performance and code readability) older sections of the code. In short, upgrading offers the chance to integrate these newer functionalities, it doesn't include them automatically.
Finally, as mentioned, support for .NET 2.0 has ended, meaning any security flaws discovered won't be patched, making your 2.0 app potentially less secure than a 4.5 one, which gets regular security updates. This is, again, subject to the client runtime, but will prevent a client from running against the possibly insecure 2.0 Runtime.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The company I work for uses C++ Builder 6. We've been developing native code since conception. Our flagship product is written completely in native code.
Enters the .NET Framework with its bells and whistles. I fall, hook, line and sinker. I convince management that .NET should absolutely be our new framework for all new software development and that we should start migrating our existing codeline ASAP. With all the benefits it doesn't take much convincing. They accept my proposal as usual.
At this point I start developing my very first .NET application. It's all going as planned. The project is only one component of our product. And so I get to the point of creating an installer for this new component. As a company we pride ourselves in making things for the user as easy as possible. Even Microsoft with thousands of developers don't create installers like we do. When you install Microsoft CRM for instance, you will only get a list of failures and prerequisites that needs installing before you can continue. Not us. Never. If you need something, we will install it for you.
This makes our installations feel so easy. .NET Framework not installed? No problem! We'll do it for you. Need SQL Native client? Fine!
The issue is this, now that one single component of our solution is written in .NET, it complicates the installation process incredibly. Before I can even get to installing our product, I need to do the following:
Detect whether the prerequisite is installed
Install it if it isn't
Verify that it was installed successfully
Next prerequisite
To install .NET Framework, I need the Windows Installer 4.5 first. But there are different versions for the different OSes, so I add OS detection and launch the correct EXE. Oh, .NET framework is already packaged with 2k8 and the installer exe cannot run on it, you have to run OCSetup.exe with parameters to install it.
And so it carries on. Then SQL Express 2005 needs to be installed. The dependencies increase once again.
I argue with management that even Microsoft don't make it this easy for the user. Their response is that there is no reason for us to not be better than them in this way. I can't argue with that except that I feel that there are very good reasons they've gone with their approach.
Suddenly, our installer is massive. All the prerequisites for .NET, not even talking about 64 bit support which has a whole separate range of EXEs to install. So now it gets to the point where we want users to be able to download a "quick" evaluation. What a joke. You need to download 500MB to get a 30MB application running. The majority of the installation package is prerequisites.
Management feels that we have too many dependencies/prerequisites. I understand completely. They suggest we move away from the .NET framework, back into native land where things were still "easy" in terms of installation. This is where the one part of me wants to stand up for .NET explaining the benefits in the big picture, the improved development experience, easier maintenance and overall code quality. The other part of me agrees with them wholeheartedly! Developing in .NET simply requires you to install too many other prerequisites which complicates the installation.
Yes, some of the .NET advocates will claim that everything should be installed on a patched and updated operating system. This is true, but not all customers have this, and simply saying "I'm sorry, update first" just won't cut it. Remember, we pride ourselves in the overall user experience.
We are now considering writing native code again and I know we're losing in terms of development speed and all the goodies of .NET. But we are gaining in this area, be it small if you look at the big picture or not. As we have native code development skills and .NET is actually new ground for us, it even makes sense to move back.
My question is this: what is your company's view on this issue if it even is an issue at all and what will the business case look like that I propose to management assuming I want to continue migrating all our products to .NET?
This is the reason to why many companies have switched to web installers that download all prerequisites on the fly from your homepage. Since in most of the cases, the OS have 99% of what's needed (if they have been updated using Windows Update).
I would not put everything for x64 and x32 in the same installer. Create two installers, one for each architecture.
Paint.NET wraps the installation of prerequisites up nicely without bundling the .NET framework with it by default. The end result is an unmanaged shim executable that checks for the .NET framework and some other stuff and holds your hand as it gets installed; all downloaded on the fly as they are needed. They then run a WinForms application that pInvokes into MSI to further wrap the installation up in cotton-wool.
Worth a Google.
Also likely is the fact that a lot of client machines will already have some version of the .NET Framework installed as it is part of Microsoft Update - making it more easily consumable in the business world.
Paint.NET blog posts about installing:
http://blog.getpaint.net/2008/08/24/the-paintnet-install-experience-part-1-version-3xx/
http://blog.getpaint.net/2008/08/25/the-paintnet-install-experience-part-2-version-40/ (thanks Rup!)
Reading into the story a little more, presumably management had to go through the pain of deployment with the C++ application at least once, but it is now done and classed as "easy". Put some time against the deployment and present this to management and, hiding the pain, show them how easy it is to install :)
Let's go back to why you wanted to switch from native code to .NET code in the first place: it's more efficient for you, as a programmer. Many things are easier in .NET than they are in C++ (or whatever native language you're using), and so you can develop your applications much more quickly.
Then, how does the time you spend developing the application compare to the time you spend developing the installer? Even if you have to spend a couple weeks nailing down the installer (specifically the framework setup portion), that should be more or less the only time you have to go through that.
For all future applications, you would be using an almost identical installer; you would still do all the prerequisite checks, but instead of copying files to C:\Foo, you're copying some different files to C:\bar.
In my opinion, this is a simple question of economics. Yes, it's more expensive to develop a (good/complete) installer for a .NET application, but if that's the step you need to take once to dramatically improve your development time, it's a no-brainer. Your return on investment would probably be in the order of weeks.
I feel I need to respond to this statement:
Yes, some of the .NET advocates will claim that everything should be installed on a patched and updated operating system. This is true, but not all customers have this, and simply saying "I'm sorry, update first" just won't cut it. Remember, we pride ourselves in the overall user experience.
If your user is insistent on shooting themselves in the foot by operating a system that the vendor has informed them is no longer fit for purpose, then there's nothing much you can do to 'help' them. I'm aware that this makes me look like something of an obnoxious activist, but I look at it in the same way that a manual tradesman might - it is up to the customer to ensure that the environment in which they want me to work is sound and appropriate for the product. If it isn't, I'll accept further renumeration to do that job as well, but it might still cause them extra work because they haven't had the foresight to make sure they understood what they were buying.
I believe software customers have been allowed to remain ignorant for long enough, and that they should now be required to understand what it is they are buying. Operating a corporate IT environment that isn't properly patched is the same as continuing to run a vehicle that has been subject to a manufacturer's recall - a Windows service pack is equivalent to a recall in many respects. You're not legally obliged to submit to a recall, but it's in your best interest as a business and you may be held responsible for damages caused by your shirking of responsibility.
Any Visual C++ app has prerequisites / external dependencies as well: runtime 6.0, 2003, 2005, 2008 or 2010? no SP, SP1 or SP2? x86 or x64? What version of Windows Installer does 2005 SP2 require? And what 2008 SP1? And so on, so on.
Thus that's far-fetched arguments! Like Joel's grumblings about .NET. And look what's now!
I don't see how there are significantly more pre-requisites for .net over C++ Builder. You complain about SQL Server, but you ignore the fact that you have to install some database with C++ builder as well. You complain about x64 vs x32, but .NET doesn't require any change.. the same exe runs on both (and compiles itself optimally for either environment). The same can't be said about C++ Builder. You may need seperate versions of SQL server, but again that would apply to C++ builder (unless you just install x32 on everything).
Yes, there are the new installer version issues, but those components aren't very big. And you really can get the installers to download and install only the aprts that are necessary.
C++ builder is probably easier for you because you've already invested the time in creating a good installer. You need to do the same for .NET, and then you can choose based on real issues.. and not this.
By the way, the reason Microsoft chooses to do things the way they do is that many users, especially corporate users, do not appreciate having things installed for them automatically (perhaps because they have an application that depends on a specific version of a library, and you come along and wipe it out with a new version that they can't easily uninstall).
What you view as "making it easier" for less knowledgable people is actually making things MUCH harder for those that know what they're doing.
Here's a good example. One thing I absolutely despise is when I install an app that needs SQL Server, and it installs its own instance of SQL Server, even though I may already have several instances already that it could use. Easy for the novice, a pain in the ass for me to try and get your app to work with my single instance.
If your app runs under Mono, then shipping your app with the Mono runtime might be less painful.
Migation of a VB6 application to .NET platform is almost like a rewrite, no matter it is VB.NET or C#. Do you think it will require more effort to do it in Java platform, when compared to .NET platform, since it is a rewrite anyway? Please share your thoughts!
No offence, but you are wrong. Porting to .Net is usually far easier than a rewrite.
Here's the official advice from Microsoft UK:
Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.
From a blog post by a Microsoft guy who consulted on rewrites:
Many companies I worked with in the early days of .NET looked first at rewriting driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects ran into difficulty and several were never completed. The problem they were trying to solve was too large
I recommend the following two steps in this order.
Write down the reasons for migration or rewriting. What benefits will it bring? The benefits might be just to keep the development team happy - that might even be a good enough reason, I don't know. Make sure you know, and your managers/users agree.
Check out the Microsoft UK advice with a screencast explaining the 5 basic options for .Net migration. Decide which is best. It may be rewriting, but go into it with your eyes open.
In answer to your actual question: would a complete rewrite be easier in .Net or Java? That mainly depends on which one your team knows best. It also depends a little on whether the application interacts with COM, just like SLaks says.
The effort of rewriting a VB6 app is more than just a question of which language you're targetting. VB apps often rely on COM objects and certain VB-specific library methods which may not have equivalents in Java - but may have some portability in .NET.
Unless you are willing to abandon all of the dependences of the project, you may find .NET an easier target to re-write for, especially if you need to preserve some of the behavior of the existing application which derives from libraries or other dependencies.
Another consideration will be which platform your team is most familiar with - if you have a lot of Java expertise but little or no .NET expertise, then perhaps Java is a good choice for you.
There are tools available that will migrate from VB6 to VB .Net, including the one built into Visual Studio. This tool migrates VB6 to C#. Whatever tool you use, you will still need to do a lot of manual work on the code that the tool outputs, however this is likely to be less work than a complete java rewrite.
Depending on your existing application's architecture, and how well the code is structured, you may decide it is better to completely re-design and rewrite it anyway, in which case there may not be much to choose between .Net and java.
It is important to reduce not just the total effort during migration but also the cost of maintenance after migration. Many factors drive TCO, but all things being equal I think the .NET tools, community, framework, and C# language meet or beat Java in terms of developer productivity, operational managability, and performance -- assuming your are targeting windows OS.
I do not think ease of keeping COM should be the deciding factor either. In fact, I think migrating VB6 to .NET but keeping COM when you do not have to defeats a critical purpose of doing a VB6 migration in the first place: to reduce development costs and risks by moving to a well-supported and viable platform. I will tell you why:
Most of the popular COM libraries and
controls that were used with VB6 have
not evolved in many years; many of
the smaller vendors have disappeared
or if they are still supporting their
wares, they now also offer new and
improved .NET versions.
Living with old COM after migration
means living with additional
complexity in terms of debugging,
builds, and deployment. Also beware that COM
components do not really "speak" .NET
(i.e they do not use .NET types and
conventions) so their use with .NET usually
results in added complexity in the
coding and design.
There still are a few
hold-outs and exceptions to this rule
and a .NET replacement is not the
always best choice, but in general,
migration teams will be able to find
at least one .NET replacement option
for almost every COM component they use.
Taking the time to thoughtfully
evaluate, select and upgrade to one
of those options will pay off after
the migration.
You will not want to interop anything
that is VB6 you plan to migrate. Interoping your own code will lead to a longer,
complex transition and typically
requires back-tracking and
reworking/retesting already migrated
codes. Clearly this is not the most
efficient and understandable upgrade
path.
One more point about having to do "a lot of manual work on the output". The Great Migrations product is a new, programmable migration tool. It is designed to help migration teams incrementally improve the quality of generated code and thus reduce the manual work required to complete the migration project. This includes making the translations more correct, dealing with complex multi-VBP migrations, and also automating the restructuring of VB6/COM code to use .NET components. These features are particularly helpful if the VB6 codebase is very large, changing frequently, and being significantly re-engineered and cleaned up during the migration. This is an agile migration methodology we call the tool-assisted rewrite.
Disclaimer: I work for Great Migrations.
If the application uses COM, it will be far easier to rewrite it in .Net than in Java. Otherwise, it will probably be somewhat easier to port to .Net.
For a more specific answer, please provide more details about your application.
You could also use Jabaco it is a Java Bytecode compiler and it has it's own IDE and syntax very similar to VB6 (nearly the same).
You can find more information at:
http://www.jabaco.org/
http://www.jabaco.org/board/
use a migration tool, like ArtInSoft to just migrate it to .NET.
You can migrate the VB 6 application using the in built VS migration to VB.Net. Try to see if that helps you. If you are looking at migrating VB 6 to C# then I would also recommend what ScaleOvenStove user has recommended.
I have just won 1 Telerik Premium Collection for .NET Developer with subscription (lucky me!) and was wondering whether the OpenAccess ORM is worth learning? Has anyone thrown away their open source variant and are now using the Telerik ORM tools instead?
Are there any benefits from using the Telerik ORM tools instead of an open source variant?
Any thought suggestions?
BTW I can't wait to start using their RadControls for ASP.NET AJAX!!
I'm a happy telerik customer for more than 5 years. I used their ORM only in one solution and never used an open source ORM.
Throw away the existing one?
NO - if you have no problems and the thing does what it should do I wouldn't change.
That has nothing to do with quality or other aspects of telerik ORM.
It's just a matter of fact that using a new product means to learn new things, solve some solved things again in a different way and so on.
BUT - if you have problems (or must make compromises) with your current product it's sure worth to give it a try.
Without knowing other ORMs I have one clear point why I would try telerik ORM.
It's their (telerik's) outstanding support.
None of my other vendors offers / does what telerik does.
Simply take a look at their forums http://www.telerik.com/community/forums.aspx and you'll see what I mean.
You have a problem - they solve it; and that with very fast response times.
And that's a point you should think about when making a decision about ORM (or any other kind of product).
This is an older post, but I thought I would weigh in.
We recently started using Telerik's SiteFinity product for a client website. It is a very good, developer-oriented tool for creating a web content system without the size or expense of SharePoint or something similar.
We also went with a Cloud solution as Telerik's ORM supports Azure, so thus so does SiteFinity - which uses OpenAccess (ORM) to communicate with its database.
I was very impressed with the speed and flexibility of it all, being my first Cloud (Azure) development project. Telerik's customer support and personal attention is beyond reproach. I have been using Telerik products for years and was not surprised how well it worked.
Two days before the site was to go live everything bombed with a very inexplicable .Net error. As it turns out Microsoft announced they were upgrading their Azure SQL servers starting July, 2011: "This upgrade is also significant in that it represents a big first step towards providing a common base and feature set between the cloud SQL Azure service and our upcoming release of SQL Server Code Name 'Denali'."
(http://blogs.msdn.com/b/windowsazure/archive/2011/07/13/announcing-sql-azure-july-2011-service-release.aspx)
By its very nature, Cloud servers are upgraded and moved around behind the scenes so you don't have to mess with it. OpenAccess failed to take this into account however, and when our SQL Azure server group was upgraded OpenAccess failed to recognize its version and bombed.
Telerik, of course, was very quick about releasing a patch - but it still took them a few days. We couldn't wait that long, unfortunately, having already lost quite a bit of time just trying to figure out what was going on. The practical result was that I got to work nonstop for two days with no sleep to move the whole thing into a regular .Net solution with Entity Framework 4 as the ORM.
So to answer the question: Is Telerik ORM worth learning and / or better than an open source solution? I agree with the above statement that if you already have an open source solution, it is working well, has good performance, and is intuitive to develop against - absolutely stick with that.
The value of open source is the community that supports it and your ability to make changes to the underlying system if need be. Had my project been based on an open source ORM, I could have changed the code to default to the most recent version of SQL if it finds it is working with a version higher, and problem solved - sleep had.
The value of a product like OpenAccess ORM is that it is in competition with other products, open source or otherwise, and it has to: Perform Well, be customer oriented, have a manual (very important), and be easier than doing it yourself or learn an open source system that may or may not be very intuitive.
Throw in that Telerik's support is top notch, and I would say you could do worse - as long as you are willing to give up some control and have to wait for upgrades / patches to handle things like I described above.
First off I want you to know that I am not Telerik evangelist...
We did moved away from Telerik's ASP.NET AJAX controls only because we desired greater control over the look and feel of our UI (we still use the controls for quick internal solutions), but I must say their products are excellent given the right conditions. Our web product team started to use the Open Access ORM for our solutions and honestly we never looked back. The first reason that comes to mind to choose a Telerik solution is grade A support which has never failed to provide a resolution to a problem regarding any of their solutions with in 24hrs usually including sample code... Although I can usually dig through blogs for hours to find solutions for most of my issues regarding Microsoft technology I must say it is nice to have support when we need it.
I would certainly recommend using the Telerik Open access ORM. I have used Telerik products (eg telerik Ajax/Silverlight) for a number of years and they are best in class and the technical support is second to none. The company makes money by providing software that works.
Unfortunately this does not apply to open source since by definition anything can changed without proper control. All it needs is one duff developer and an entire suite can be rendered useless.
In order to use the products correctly, swiftly, and efficiently, it is necessary to be a highly competent web developer.
I'm one of those people that won a license at a users group meeting. Thankfully I got to experience how crappy this software is without paying for it.
I never got to test the ORM capabilities because the Visual Studio integration failed. Any click on the Telerik menu in VS threw an exception. And the VS item template that was supposed to be installed was not there, so I couldn't even begin to test the functionality.
Don't be fooled by the pretty designer screenshots, they can't even get the installer to work correctly.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What is the benefit of using Windows Workflow foundation (WF) versus rolling your own workflow framework?
From what I can tell, WF only provides a pretty bare-bones runtime engine, a bunch of classes, and a schema (XAML-based) for defining workflows. All the hard stuff such as persistence, providing a host process for the runtime, and implementing distributed workflows (across processes) is left up to you.
Plus there is a learning curve to using WF... if we created our own workflow framework we would simply leverage skills that all developers already have (C#, XML, SQL, etc).
I saw this blog from an MS evangelist which tries to explain why we should use WF:
Why Workflow?...
IMO it doesn't do a good job of convincing because it just states that it helps "developer productivity", while admitting that developers could roll their own.
Can any of the smart folks here come up with a better reason?
SUMMARY FROM ANSWERS GIVEN BELOW:
I think the most convincing reason is that using a standardized workflow platform such as WF (versus rolling your own) will allow you to leverage current and future tooling such as the Visual Designer, provided by MS and third parties.
Also because it is part of the MS stack of .NET based technologies, it will likely have better integration/migration path with future MS technologies (such as Azure).
Finally, the number of developers with WF experience will increase (as it will benefit them career-wise), turning it into a basic commodity skill such as SQL or HTML, meaning it will become easier to find people who can start working with it with minimal ramp up time.
The choice to use WF takes some evaluation and I'm going to try and provide a fairly comprehensive list here on what the pros and cons are. Keep in mind that if you're going to use WF don't use anything other than WF4+ because it was rewritten and is significantly vetted past its predecessors.
Pros
Cost
Flexibility
Durability
Distributability
Future
Cost
The cost of WF is important to note when comparing it against other paths. Those paths may include BizTalk, an open source code based framework like Objectflow, or even rolling your own. Bear in mind that unless you need something significantly simplistic, rolling your own would be the most expensive approach every time. So, if you need a sizable piece of functionality but also need control over the source code I would recommend an open source framework.
Flexibility
WF is a very flexible framework in contrast with a framework like BizTalk. In WF you can write your own custom activities and do what you need to do outside of the framework - this really gives you the power you need.
Durability
WF includes a very powerful durability framework. It's durable in the sense that the state of a workflow can be persisted, the workflow can be set idle (to preserve resources), and then recalled later. But, that durability goes a lot further because it's already setup for durability across a host farm. In other words a workflow can be started on one host, persisted, and then recalled on another host.
Assumes that the workflows are hosted via a web service (i.e. WorkflowService).
Distributability
WF is already setup to be distributed across a host farm.
Assumes that the workflows are hosted via a web service (i.e. WorkflowService).
Future
WF is the replacement orchestration engine for BizTalk and is in fact developed by the same people that built BizTalk. Therefore WF has a bright future in the Microsoft stack. In fact, right now Microsoft is working on building individual components to replace every feature of BizTalk with components. For example, Windows Server AppFabric (and more specifically the plug-in to IIS) is the replacement for the monitoring services that exist within BizTalk today.
Why is Microsoft doing this? Because BizTalk isn't really well suited for the cloud because it's one massive install, whereas the components they are building could be deployed to a cloud solution.
Cons
Flexibility
Monitoring
Flexibility
WF's flexibility can also be its pitfall because sometimes you don't need the flexibility that it provides and thus spend more time building stuff that you would otherwise want to just be included. Sometimes you need a framework that makes a lot of assumptions and maybe works off of convention instead (e.g. MVC). However, generally speaking I have found that this isn't true when coupling the WF4 framework with the open source extensions provided by Ron Jacobs.
Monitoring
The monitoring for WF is still very young and this is its biggest pitfall. However, this will advance very quickly over time and in the meantime you can build your own monitoring tools with custom tracking mechanisms.
Resources
Your best resource is Ron Jacobs. I have never met somebody that is so willing to help the community of developers that have to use Microsoft's frameworks than him. Believe me, he's provided a vast amount of information surrounding WF via numerous channels, just get on Google and check it out.
The main reasons I can think of to lean towards using WF over another workflow framework are:
Microsoft is supporting it as a core part of the framework, so it can/will be easier to integrate into their other technologies like Sharepoint and Azure "cloud applications"
The tooling is likely to improve and be really slick in another few versions, which should improve developer productivity
I have had to create Workflow activities at my job, and I can't even tell you the answer.
One not very valid reason is that invalid values/inputs can be determined and refused at design time for workflow diagrams, and so compile-time errors basically don't exist (assuming all that boilerplate code you wrote has no compile-time errors).
Short answer: it's free and it gets the job done. If you can roll a better framework for managing workflow and want to spend your time on it, by all means do. But consider that your time is worth money, so how much money are you willing to commit to building a better framework for managing workflow? I could see that getting expensive.
Also, I'm pretty sure that persistence (to disk or SQL) is handled out of the box.
There is some reasonably nice designer support in Visual Studio that I'd rather not have to roll for myself, and it's a framework supported by someone else rather than me, meaning someone fixes the architecture bugs and does the main testing, leaving me to test just my workflow. I mean, I could roll my own versions of GDI+ calls, but I'd rather not. Same goes for my own serialization framework, XML parser, or some other element of the .NET framework.
When it comes down to it, these things are provided as a toolkit. Whether you choose to use a tool or not depends entirely on the problem you're solving, the suitability of the tool, and the time and resources you have available to achieve the goal.
Its a new technology Or you can say its latest with a promise of constantly updating features.
It respects the previous working environment and uses it and add those features which are very helpful with regards to the development of the long running programs(large projects).
It produces all that features directly into the hands of the developer which were previously running at the back lacking the interaction between the inner core concepts and the programmer.
Yeah its a little complex but also it provides more power in the hands of the programmer.
You can expect better frameworks and features in the coming future.
Its the future of the programming so better we start learning it today.