I'm mainly working with MS Visual Studio, and C#/Entity Framework/SQL-server at the moment.
The .NET environment encourages the development of other languages, and the reuse of "binary" (semi bianary by MSIL Vitual Machine like the Byte code in Java).
This makes it possible to seamlessly building components in any .NET Compliant (CLR, Common Language Runtime) language. The code is compiled to a DLL and is very easy to use in another lagnuage.
This has the effect that I, in my favorite language C#, can use components written in Visual Basic.NET, Visual Cobol.NET, Visual Ruby.NET, Visual PHP.NET, Visual X.NET-language .....
The CLR/MSIL/.NET aproach has made this possible, and a software company that develops a completely new language actually don't need to rewrite any of the .NET libraries that already exists. But it is still possible for the developer to use the new languages syntax to use the components. This is a really good thing!!! Ver good reuse of existing codebase, indeed!!!!
I definitly think new languages will arise in the future as well as they do today.
The learning curve will be less steep and the reuse of already written and tested code in the form of DLL components will increase amensly.
We have already seen this happen when the mono-project in Linux now is pretty good at implementing the CLR and .NET environment.
It is very easy to build my entire software with EXE-files and DLLs in an Windows 10 envisonment and Visual Studio and the just copy the files over to a mono-installation in most Linux distributions like Ubuntu, Debian and hardware like Raspberry Pi. It's not perfect yet, but most of it works pretty well.
The future problems will not be the languages but the 3rd-party or custom components, that has to be consistently documentet and maintained.
The .NET environment encourages the development of other languages, and the reuse of "binary"
Yes, having a common runtime is very handy. It allows to share knowledge and pick your own favorite language. I think it's one of the reasons that allowed .NET to remain relevant all these years.
I guess it's more or less the same with the JVM.
It is certainly a way to settle on a common implementation of the main building blocks and focus on productivity or proposing new approaches for such building blocks.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm mainly working with MS Visual Studio, and C#/Entity Framework/SQL-server at the moment.
The .NET environment encourages the development of other languages, and the reuse of "binary" (semi bianary by MSIL Vitual Machine like the Byte code in Java).
This makes it possible to seamlessly building components in any .NET Compliant (CLR, Common Language Runtime) language. The code is compiled to a DLL and is very easy to use in another lagnuage.
This has the effect that I, in my favorite language C#, can use components written in Visual Basic.NET, Visual Cobol.NET, Visual Ruby.NET, Visual PHP.NET, Visual X.NET-language .....
The CLR/MSIL/.NET aproach has made this possible, and a software company that develops a completely new language actually don't need to rewrite any of the .NET libraries that already exists. But it is still possible for the developer to use the new languages syntax to use the components. This is a really good thing!!! Ver good reuse of existing codebase, indeed!!!!
I definitly think new languages will arise in the future as well as they do today.
The learning curve will be less steep and the reuse of already written and tested code in the form of DLL components will increase amensly.
We have already seen this happen when the mono-project in Linux now is pretty good at implementing the CLR and .NET environment.
It is very easy to build my entire software with EXE-files and DLLs in an Windows 10 envisonment and Visual Studio and the just copy the files over to a mono-installation in most Linux distributions like Ubuntu, Debian and hardware like Raspberry Pi. It's not perfect yet, but most of it works pretty well.
The future problems will not be the languages but the 3rd-party or custom components, that has to be consistently documentet and maintained.
Yes, having a common runtime is very handy. It allows to share knowledge and pick your own favorite language. I think it's one of the reasons that allowed .NET to remain relevant all these years.
I guess it's more or less the same with the JVM.
It is certainly a way to settle on a common implementation of the main building blocks and focus on productivity or proposing new approaches for such building blocks.