Will help the progamming community to grow larger…
More likely than not, it’d just encourage naff ports of poor Windows and Linux applications. <sarcasm>Of course, its not like we don’t have enough of them </sarcasm>
No new Haiku applications would be written using it, and really, when you change OS and continue using the same applications - it defeats the purpose - e.g. using Linux and WINE.
jfd wrote:
Will help the progamming community to grow larger...
See thread here:
http://www.haiku-os.org/forums/viewtopic.php?t=132
I support your opinion - .NET doesn’t specifically bring any type of software, but it does bring another “standard” development platform and language (C#) which helps developers migrate to Haiku.
While Haiku is “application-poor” - it needs all the cross-platform support it can get.
I would think that this is approximately as important as bringing Java to Haiku…
It would also benefit Haiku if an effort to create Haiku/BeOS bindings for the .NET environment so that “native” apps could be written using .NET on Haiku.
[quote=“umccullough”
It would also benefit Haiku if an effort to create Haiku/BeOS bindings for the .NET environment so that “native” apps could be written using .NET on Haiku.
The developer time writing bindings would use up (how many hours would be needed to get the intricities of some of the more obscure functions replicated?) would outweigh the benifits - that developer time could be used to write BeOS native applications that aren’t interpreted that do the same job as the ones that could be ported over to a BeOS .NET enviroment.
MYOB wrote:
The developer time writing bindings would use up (how many hours would be needed to get the intricities of some of the more obscure functions replicated?) would outweigh the benifits - that developer time could be used to write BeOS native applications that *aren't interpreted* that do the same job as the ones that could be ported over to a BeOS .NET enviroment.
I disagree. Although it would take a lot to get something working, once it is, no more work need be done. In the long term there would be a benifit, and the long term is the one that counts. Thus there is no “wasted” time.
Another benifit of a project like this is it gives, for those of us that aren’t skilled at system programming and want something to do, something to do.
Of course I say this from the point of view of someone this project wouldn’t aid (I don’t know anything .NET and I plan to keep it that way). But, with the sheer number of windows developers out there, something like this would help the Haiku project greatly.
SigmaNunki wrote:
MYOB wrote:The developer time writing bindings would use up (how many hours would be needed to get the intricities of some of the more obscure functions replicated?) would outweigh the benifits - that developer time could be used to write BeOS native applications that *aren't interpreted* that do the same job as the ones that could be ported over to a BeOS .NET enviroment.I disagree. Although it would take a lot to get something working, once it is, no more work need be done. In the long term there would be a benifit, and the long term is the one that counts. Thus there is no “wasted” time.
Another benifit of a project like this is it gives, for those of us that aren’t skilled at system programming and want something to do, something to do.
Of course I say this from the point of view of someone this project wouldn’t aid (I don’t know anything .NET and I plan to keep it that way). But, with the sheer number of windows developers out there, something like this would help the Haiku project greatly.
I would also like to point out that the only real “Windows-like” development that is done in .NET is with Microsoft’s Winforms, but there is certainly no requirement that developers use it - just as there’s no requirement that developers use the GTK# bindings either… Microsoft has very much abandoned their highly criticized Win32 API in .NET, you pretty much never have to touch it as a .NET developer… I’m pointing this out because very soon, there is a very good chance that .NET developers will not be windows-only developers at all…
umccullough wrote:
I would also like to point out that the only real "Windows-like" development that is done in .NET is with Microsoft's Winforms, but there is certainly no requirement that developers use it - just as there's no requirement that developers use the GTK# bindings either... Microsoft has very much abandoned their highly criticized Win32 API in .NET, you pretty much never have to touch it as a .NET developer... I'm pointing this out because very soon, there is a very good chance that .NET developers will not be windows-only developers at all...
As a curiosity, how fast is .NET? ie C is grease lightning, python/perl/any scripting language is not.
SigmaNunki wrote:
umccullough wrote:I would also like to point out that the only real "Windows-like" development that is done in .NET is with Microsoft's Winforms, but there is certainly no requirement that developers use it - just as there's no requirement that developers use the GTK# bindings either... Microsoft has very much abandoned their highly criticized Win32 API in .NET, you pretty much never have to touch it as a .NET developer... I'm pointing this out because very soon, there is a very good chance that .NET developers will not be windows-only developers at all...As a curiosity, how fast is .NET? ie C is grease lightning, python/perl/any scripting language is not.
It runs about as quick on my 2GHz development machine at work as BeOS apps run on my old P100.
OK, not quite. It’s not quick though, and applications are very memory-hungry (I tested a simple single blank window and it took about 13MB of ram when running). You do get some nice language features though, and crashes are much easier to track down than in C++ programming.
I think it would be good to have mono, but it shouldn’t be down to the Haiku team themselves to do it. An interested 3rd party can port it when we have an OS to run it on.
Simon
tb100 wrote:
SigmaNunki wrote:As a curiosity, how fast is .NET? ie C is grease lightning, python/perl/any scripting language is not.It runs about as quick on my 2GHz development machine at work as BeOS apps run on my old P100.
OK, not quite. It’s not quick though, and applications are very memory-hungry (I tested a simple single blank window and it took about 13MB of ram when running). You do get some nice language features though, and crashes are much easier to track down than in C++ programming.
I think it would be good to have mono, but it shouldn’t be down to the Haiku team themselves to do it. An interested 3rd party can port it when we have an OS to run it on.
Simon
<sarcasm>On windows? Slow? Memory hungry? Never.</sarcasm>
Seriously, if someone was to optomize it, then it’d be worthwhile. That’s just too much.
13 Meg? Really? …
Quote:
It runs about as quick on my 2GHz development machine at work as BeOS apps run on my old P100.OK, not quite. It’s not quick though, and applications are very memory-hungry (I tested a simple single blank window and it took about 13MB of ram when running). You do get some nice language features though, and crashes are much easier to track down than in C++ programming.
I think it would be good to have mono, but it shouldn’t be down to the Haiku team themselves to do it. An interested 3rd party can port it when we have an OS to run it on.
Simon
Yes, I will definitely agree that it’s slow (compared to native C/C++), and memory hungry, especially Winforms.
Part of the problem is that in order to run ANY app, the CLR has to be loaded to provide the base classes and runtime functionality (similar to Java’s JVM)…
Running managed code requires constant type/bounds checking and exception handling - but blocks of code can be marked as “unsafe” to increase performance.
Advantages of course are managed code, garbage collection (for those that enjoy that feature), cross-platform binaries, etc.
I also agree that the Haiku developers need not worry themselves with this project any time soon - but it would still be nice if it existed for Haiku/BeOS 
If it means I can write apps using a half decent RAD IDE in either windows or linux, I can’t see any downside.
euan wrote:
If it means I can write apps using a half decent RAD IDE in either windows or linux, I can't see any downside.
While I haven’t used GTK#-based MonoDevelop, I have used it’s Winforms based cousin SharpDevelop (open-source .NET IDE that is very feature rich and compares nicely to Microsoft’s own Visual Studio .NET) - and it’s pretty slick, although it’s a bit heavier than visual studio, as it’s all built on .NET using C#.
All-in-all, I find the .NET development environment pretty friendly, although it will be much better in the upcoming versions as the C# compiler will be modified to allow better debugging hooks, and allegedly the ability to modify and debug code while its running without restarting your app - that’s a feature I always loved about VB6.
umccullough wrote:
euan wrote:If it means I can write apps using a half decent RAD IDE in either windows or linux, I can't see any downside.While I haven’t used GTK#-based MonoDevelop, I have used it’s Winforms based cousin SharpDevelop (open-source .NET IDE that is very feature rich and compares nicely to Microsoft’s own Visual Studio .NET) - and it’s pretty slick, although it’s a bit heavier than visual studio, as it’s all built on .NET using C#.
All-in-all, I find the .NET development environment pretty friendly, although it will be much better in the upcoming versions as the C# compiler will be modified to allow better debugging hooks, and allegedly the ability to modify and debug code while its running without restarting your app - that’s a feature I always loved about VB6.
urg don’t get me started on VB.net. 
euan wrote:
urg don't get me started on VB.net. :cry:
Who said anything about VB.NET? - as far as I’m concerned, VB.NET is useless…
Quote:
The developer time writing bindings would use up (how many hours would be needed to get the intricities of some of the more obscure functions replicated?) would outweigh the benifits - that developer time could be used to write BeOS native applications that *aren't interpreted* that do the same job as the ones that could be ported over to a BeOS .NET enviroment.
As far as supporting obscure functions that should be left up to groups like mono or DotGNU where possible. Making it possible for these platforms to run on Haiku would probably take porting some of the underlying linuxy stuff. After the ECMA stuff of .NET is supported on Haiku simple bindings could be created to allow native Haiku apps be be created using C# or any langauge that has been compiled to IL and run on Haiku.NET.
.NET applications aren’t interpreted either any more than C or C++ applications are. Code is compiled on first occurence allowing for more flexibility with just a slight performance hit. Other performance related side effects are introduced from type safety, bounds checking, garbange collection and the use of the VM but in my oppinion these performance hits are worth the extremely readable, rapidly implementable, highly portable, and reliable code and applications. In my oppinion the performance difference of .NET applications compared to native C apps has been a neglegable.
MYOB wrote:
No new Haiku applications would be written using it, and really, when you change OS and continue using the same applications - it defeats the purpose - e.g. using Linux and WINE.
One question I never actually asked as a result of this post was: What purpose are you referring to?
I can only assume you believe that the “purpose” is to have something completely new and different (i.e. all Haiku-only native apps) vs. something usable and “available” (once ported).
I don’t see any huge problem using WINE to run Windows apps on Linux - mostly what I see is a cross-platform compatibility layer that allows owners of existing Windows applications to run their investments (both time and money) on a new operating system… what purpose is that defeating?
umccullough wrote:
MYOB wrote:No new Haiku applications would be written using it, and really, when you change OS and continue using the same applications - it defeats the purpose - e.g. using Linux and WINE.One question I never actually asked as a result of this post was: What purpose are you referring to?
I can only assume you believe that the “purpose” is to have something completely new and different (i.e. all Haiku-only native apps) vs. something usable and “available” (once ported).
I don’t see any huge problem using WINE to run Windows apps on Linux - mostly what I see is a cross-platform compatibility layer that allows owners of existing Windows applications to run their investments (both time and money) on a new operating system… what purpose is that defeating?
The purpose of changing OS. Nothing annoys me more than new BeOS users wanting XYZ ported - usually WINE, Blender, OpenOffice, etc.
BeOS is too different a system for ports to work well - look at how unstable AbiWord is, or the troubles the BeZilla team have to go to get BeZilla as good as it is now.
We need native apps, preferably good ones, but at all costs we need native apps. .GNU will just be a bad port that provides yet more bad ports.
MYOB wrote:
The purpose of changing OS. Nothing annoys me more than new BeOS users wanting XYZ ported - usually WINE, Blender, OpenOffice, etc.BeOS is too different a system for ports to work well - look at how unstable AbiWord is, or the troubles the BeZilla team have to go to get BeZilla as good as it is now.
We need native apps, preferably good ones, but at all costs we need native apps. .GNU will just be a bad port that provides yet more bad ports.
I won’t disagree that BeOS/Haiku needs new native apps, but you’re referring to the classic chicken/egg issue.
Why bother supporting POSIX? - why bother supporting ANY other standards - why not just re-invent everything from the bottom up to be “perfect”…? - I can understand the complaint that WINE is not a standard (although the Win32 API has inherently become a standard by existing as long has it has) - but most of .NET IS an ECMA standard.
I will assume you are just as evenly against Java for BeOS in this particular case.
Why are you of the opinion that BeOS developers should NOT have a development environment like .NET? Why must EVERYTHING be C/C++ in order to meet your approval?
Do you use bash? Do you use GCC? It could be argued that ANYONE using a commandline is using a “ported” application, after all, most commandlines mimic other OSes.
You may be tired of people asking about apps XYZ, but if apps XYZ were designed to run on any platform in the first place, then why should it be a problem?
Some envision a future where compatibility layers and emulation may eventually allow “ANY software to run on ANY platform”… there’s really nothing wrong with that in general.
I think what you’re trying to say is that you disagree with people who become frustrated when some app they wanna run is not currently available for the platform, and no decent replacement yet exists for it. They have no right to “demand” that it be ported, or complain about the lack of said application because it’s ultimately their choice to change OSes in the first place. I believe, on the other hand, that this very same problem must be alleviated to some extent before new users will magically leave their existing platform - that is unless Haiku is only destined to be a hobby OS that “geeks” use.
I agree that .NET would be good for Haiku. If Mono or something .NET is ported so that I can write C# applications for Haiku I will definitely use Haiku and contribute to the community as much as possible. If I can’t develop apps in a langauge like C# I will give it a quick try probably find a lot of things I would like to implement or change and just say “well I guess I’ll have to wait a few years until somebody implements what I want for me” because I don’t want to waste my time programming in something like C or C++.
kainhart wrote:
I agree that .NET would be good for Haiku. If Mono or something .NET is ported so that I can write C# applications for Haiku I will definitely use Haiku and contribute to the community as much as possible. If I can't develop apps in a langauge like C# I will give it a quick try probably find a lot of things I would like to implement or change and just say "well I guess I'll have to wait a few years until somebody implements what I want for me" because I don't want to waste my time programming in something like C or C++.
BeOS already has Portable .NET, or .GNU, or whatever its called. Just no GTK so no GTK# bindings. C# SDL apps even work.