Slashdot Mirror

Nah, C# is a no-go. It's only useful as long as you don't care about any platforms beyond Microsoft Windows.

Oh really?

Linux runs programs written in Visual Basic 6 through two userspace frameworks: X.Org X11 and Wine. For Visual Basic .NET, it uses X.Org X11 and Mono. What support from the kernel would make VB programs more efficient?

WPF has been depreciated. If you want you can use GTK# for c# for gui development.I believe their was an editor or search index utility for GNome 2 written with Mono's implementation of C#.

.Net is fairly close; but lacks actual solid cross-platform implementations for desktop applications.

Now we're getting somewhere constructive. What is Gtk# missing in solidity?

You can take your C# skills straight to Linux or OSX using Mono.

The problem is not WinForms, but WPF. An increasing amount of applications use WPF because WinForms is considered 'deprecated' by Microsoft and people are encouraged to use WPF instead, which is the new 'hot stuff'.

It looks like Mono has support for WinForms. I've never used it though, and usually used GTK# for GUI development on Linux.

"...VB is MS only." No it's not.

http://www.mono-project.com/do...

Sure you want to get sued by Microsoft over the use of some of the keywords and their related patent filings.

Even the agreement that MS signed with Novell didn't cover VB, only C# and what they published to EMCA and ISO. Everything else was still open for lawsuit. Of course, even that agreement has now expired, and Miguel's new company doesn't have a new agreement either.

So good luck there.

Your vbnc was last updated in 2010, and targets Visual Basic .NET 8, which was released with Visual Studio 2005. The VBNC compiler has not had any significant updates since 2011.

Visual Basic .NET is now on version 12. vbnc is horribly behind, and it does not appear to be actively supported. If your instructor were to use any newer language features, such as lambdas, iterators or asynchronous programming, you would not be able to use VBNC to compile that code and would probably have to resort to using Windows somehow.

On the flipside, Python now comes standard with most Linux distributions, and is standard with Mac OS X. It's very simple to install on Windows and even comes with a bare-bones IDE for editing code. In every respect, it is easier to get started using Python than to start using VB .NET, especially on non-Windows platforms.

"...VB is MS only."
No it's not.

http://www.mono-project.com/do...

Mono supports nearly everything important. http://www.mono-project.com/do...

.NET places no requirements on MSSQL. Me personally, I store my data in a mix of MSSQL. Postgres, SQLite, Cassandra, Lucene (the Java version), and yes, even Firebird (and I absolutely do NOT recommend Firebird).

If you want to host ASP.NET code on Linux, there are various ways to host Mono's version, using Apache, Nginx, and other servers: http://www.mono-project.com/do...

Once .NET Core actually exists, we'll see what the hosting story looks like. I imagine it'll look a lot like Mono's.

So this github project is "lock-in" in your biased POV
http://www.mono-project.com/do...
OR https://roslyn.codeplex.com/
But not Java?

Yes, it is:

Mono
ASP.NET
Entity Framework

I believe they also used to use custom chips with extended instruction sets designed to interop well with their custom JVM. Not sure if they still do that.

I could've sworn I'd read that they'd stopped with their hardware work, but I think I was wrong: Appendix A of this page gives the impression (though I can't see it explicitly stated) that they're still doing custom hardware, but their software will work on ordinary Intel/AMD chips as well.

GC doesn't have to suck.

Indeed. It's Sturgeon's Law, but I think the '90%' part might be too low in this case. Major interpreters/'VMs' - even the ones with optimised native-code compilation - have awful GCs. Up until quite recently, Mono was using the Boehm GC. The GCs in OCaml and D show no signs of improving any time soon.

(disclaimer: I have interned at Microsoft for the past three summers; I do not speak for them)

I think your criticism against lock-in is fair, and this is clearly one of Microsoft's strategies, and I suspect that it will continue to be to some degree. But on the language front, you are wrong. Not only are Microsoft's newest languages open-source (F#, TypeScript), but they are also cross-platform and collaboratively developed with open source groups. And, of course, you can run all .NET languages on the Mac, Linux, FreeBSD, etc. with mono.

While it is theoretically possible that all of this is a deadly Microsoft-bait-and-switch just waiting to happen, having worked at Microsoft, I can say that doing so would fly in the face of a lot of hard work by many, many people there. I was as critical about Microsoft as you were (dig into my /. history and you'll see) until I worked there. Not only is it a great place to work, but the company really is committed to changing its culture. Use of open-source tools at Microsoft used to be strictly-prohibited. Now they have a fast-track process for working with them. Open-sourcing of Microsoft software was also a complete non-starter. Now putting Microsoft code up on the web is increasingly routine, and they even have their own open-source hosting ala GitHub that has git bindings.

Microsoft is a big company (the Redmond campus is mind-bogglingly huge to me) and they have a lot of corporate momentum. Despite this, in my opinion, I've seen my daily interactions with people do a complete 180 in the last couple of years. Microsoft knows that the era of selling boxed copies of proprietary software is coming to an end. So you're simply wrong about Microsoft not being able to change.

Until it's there by default, It's simply unacceptable for consumer software.

Just bundle Mono and be done. Problem solved.

• On Linux, package-managers solve the dependencies (and Mono is hardly an obscure dependency)
• On Windows, one can generally depend on .Net being installed. If you don't like this idea, you can always bundle Mono with your program
• On Mac, you can just bundle Mono with your program, right inside the .app

In my opinion, the 'culture' of not bundling virtual machine software is a real problem. If your Windows program uses Java, why not just bundle it? You avoid version compatibility issues, and you avoid installing an enabled-by-default blight on web security (Java applets). Everyone wins. (Some programs do this today, but not many. The indie game Blocks That Matter is one such.)

And the implementation is 100%? Nope. With Java, though, I get everything Java has to offer, anywhere Java is available. Maybe platform consistency isn't important to you, but it matters to some people.

From a purely logical standpoint, Java wins if you don't want to have to double-check whether each of the APIs you're about to use is actually implemented on all of your target platforms. From an idealistic standpoint, yes, I can see why someone would avoid Java (and, in fact, I have managed to do so for the entirety of my career, thus far), which is why the Mono projects exists, and why it is important. However, it's just not there yet, from a logical perspective.

1) Become a sponsor of the Moonlight project
2) Become despised by both open and closed source communities alike.
3) ???
4) Go out of business.

1) Set up a web page with the address http://netflix.com/linux/ which helps customers to watch the flicks under Linux
2) Become a sponsor of the Moonlight project
3) ???
4) Profit!

Believe it or not, CIL (or MSIL in Microsoft-speak), the bytecode for .NET, is an ECMA standard, and implementations of both .NET JIT'ers and standard libraries exist for practically all modern platforms, thanks to Mono. So I'd say: "competition for portable applications". Really! Just take a look at Gtk#. As a result, there are numerous applications for Linux written in .NET languages (e.g., Banshee). Having written huge amounts of code in both JVM languages (Java, Scala, JRuby, and Clojure) and .NET languages (F# and C#), I would take .NET over the JVM for a new project any day.

Also, to pre-emptively swat down this counter-argument: while the Mono people and Microsoft may have had some animosity in the past, it is most definitely not the case any more. Most of the Mono people I have spoken to (yes, in person) say that their relationship with Microsoft is pretty good.

Build systems and dependency management for the JVM are their own mini-nightmare. .NET's approach isn't perfect but compared to [shudder] Ant, Maven, Buildr, SBT, and on and on and on... it largely just works.

Another argument frequently used is portability; you just port the browser and all the web apps run, at least somewhat. Your examples, however, aren't all that convincing in that direction. While C# works somewhat with Mono on Linux and OS X (though the (Free)BSD port isn't actually officially part of Mono) when using WinForms, WPF is not supported and Mono has no plans to support it. C++ with Qt and/or Boost is reasonable, though there are some pitfalls here and there to watch out for. As for Delphi, I'm not sure how mature Kylix is and if it runs on the BSDs.

Generally, if you say portability is more than just x86 with Windows/OS X/Linux, you'll hit a brick wall really fast, and browsers are surprisingly frequently ported.

Another argument frequently used is portability; you just port the browser and all the web apps run, at least somewhat. Your examples, however, aren't all that convincing in that direction. While C# works somewhat with Mono on Linux and OS X (though the (Free)BSD port isn't actually officially part of Mono) when using WinForms, WPF is not supported and Mono has no plans to support it. C++ with Qt and/or Boost is reasonable, though there are some pitfalls here and there to watch out for. As for Delphi, I'm not sure how mature Kylix is and if it runs on the BSDs.

Generally, if you say portability is more than just x86 with Windows/OS X/Linux, you'll hit a brick wall really fast, and browsers are surprisingly frequently ported.

You definitely know a lot about D.

You're too generous - I've just read a bit about it and played about with it a little; I'm certainly no D master :P

Regarding frameworks/libraries/maturity/practical power, I think you might underestimate what Mono is capable of - I'm no expert, but I don't think you'll have any trouble doing web-dev work with it.

For D, I believe there are libraries out there for doing web-dev work. This one might do, but looks a bit on the low-level side. For serious production code I'd certainly recommend C# over D (ASP.NET is already out there in the 'real world'), but I'm sure it could be done with D.

Hm, should check how D is in the area of multi threading.

I don't know much about this, but I do know that D2 has some thread-safety features built into the language itself: 'global' variables are now by default actually merely 'thread-global'. You have to use a special keyword if you want real process-wide globals. I can see where they're coming from, but I'm not sure I like it.

But bottom line I don't like many of the design decisions in D

There are certainly seem to be some warts - I get the impression the const system is a bit broken.

like having no true MI

I've never been bitten by not having MI, but maybe that's because I learnt Java before I learnt C++. The arguments for not having MI are fairly persuasive imo: simpler for the compiler, generally less error-prone for the user, and MI is rarely the right solution anyway.

I never quite got my head around Scala's solution (it looked a lot like MI to me), but people seem to like it.

(with language versus platform I mean the broad spectrum of libraries that are focused on special purposes in Java, like JPA or the Java Rest and Soap support via annotations etc. the huge amount of third party frameworks like spring or Aspect/J or hibernate)

Ah, the advantages of bytecode and reflection. Sounds almost like Aspect Oriented Programming is what you're really getting at here. There's not much in the way of AOP for D, from what Google tells me.

You don't have to with C# either...

Then again, I'm becoming a bit of a NodeJS fan for server-side dev.

Visual studio could be updated to output binaries as rpms, apks, or what ever the hell else the compiler developers want. The CLR could also be ported if M$ really wanted (See Mono) The point of .NET is to build MISL (Microsoft Intermediary Language) instead of direct code. As long as the OS can run the CLR a .NET program should work just fine. The only reason that M$ doesn't port VS to other OS's because they don't have to sell it and they really would rather you develop applications for their OS's on their OS's.

I write my C# apps in VS. I later run them in mono. Typically I don't have an issue.

Oh, I see, I don't agree with you and my experiences differ from yours, therefore I'm wrong. Got it.

Sad thing is, my experiences with C#/.NET is that they manage the design intent of Java, better than Java, even without that being the design intent. In part because MS actually freely contributes to the Mono project at times.

Fortunately, the research if fairly simple...
http://www.mono-project.com/Compatibility

Outside of WPF, you tend to have to be working with stuff that is either fairly niche (code contracts / server side OData), or unlikely to be used in a non-windows platform (ASP, windows specific stuff from .NET 1.1) to run into problems, or be at the very cutting edge.

So, yeah, not perfect, but at least, unlike java, where it fails will be fairly well documented, rather than running into some random garbage issue, then googling it only to find some poor SOB like yourself ran into it years before and it's just never been documented.

Good job handwaving away Mono. I can see how you'd be forced to, since it undermines your entire argument. Mono supports most of the BCL, all the way up to .NET 4.5. Again, please take the time to understand what you're talking about. http://www.mono-project.com/Compatibility

FUD. .NET is NOT windows only. There is an open source cross platform implementation that works quite well. Actually, in my experience, so long as it is on a supported platform, and the developers consider the Mono documentation, it is better than Java using the Sun (now Oracle) java implementation in terms of compatibility/reliability between platforms - though it does tend to be slightly slower on many platforms.

Objective-C is mostly MacOS/iOS, I don't know of an Objective-C compiler for Android - it's typically Java or a translator from another language into java into the Dalvik bytecode (other languages such as C# and C, but maybe Objective-C is in that list).

Where are you getting 90%? C#, which is much more popular than the second most popular .NET language (VB.NET) never got up to 9% according to TIOBE, let alone 90%...

modmono

Actually, it really is a shame that you can't reliably host .Net applications out of Apache on Linux. I know mod_mono made some headway into this, but it'd be huge if this were possible in a real, production ready way.

http://www.mono-project.com/ASP.NET

Mono can generate a normal, runs-without-Mono, Windows .exe executable from your C#, but I get the impression that generation of a (native) .dll can't be done, even with Mono.

Mono can generate a normal, runs-without-Mono, Windows .exe executable from your C#, but I get the impression that generation of a (native) .dll can't be done, even with Mono.

You write the C# -> native compiler first ;)

And how do you think C# code is executed?

The "Native Image Generator" is

the Ahead-of-time compilation service of the .NET Framework. It allows a .NET assembly to be pre-compiled instead of letting the Common Language Runtime do a Just-in-time compilation at runtime

Not an ordinary .exe, granted, but the native code is there even in normal C# use. Ordinary native binaries can be generated from C# if necessary though - this is how Mono targets platforms like the Wii. The reason you can't write (normal) Windows drivers in C# is because Windows isn't written in C#.

That said, bindings exist for libusb, so that's a start.

(There seem to be a number of similar bindings for Java, and a standard API spec that no-one's implemented.)

Google tells me two operating systems have been written in C#: Cosmos and Singularity.

This isn't to say C# is more suited than C to OS/driver work, but it can be done.

...and it works well with nginx http://www.mono-project.com/FastCGI_Nginx

PHP is fine, but if you want to learn about a better, enterprise-ready languages I would suggest using ASP.NET. It integrates perfectly with .NET apps and libraries and comes with a comprehensive library (as it uses .NET). The great thing about ASP.NET is that you can use C# to develop for it. ASP.NET also comes with various functions to make state management easier - an important feature that is completely missing in other languages. It also has built-in cache management.

ASP.NET originally lacked templating engine, but Microsoft introduced it in 2.0 version. You can have master templates that have placeholders for the dynamic content, as well as all the HTML and JavaScript that is shared between all pages.

It is basically more than your off-the-shelf PHP/Python/Ruby. ASP.NET provides much larger library to use, has templating engine, error handling, controls and events (and hence is more familiar to Windows developers), caching, object-oriented design and session control which can even be saved in SQL Server. It's not just a language, it's the complete package.

One of the great things about ASP.NET is also that you can use your favorite language to develop for it, as long as it supports .NET. This means you can use VB.NET, C#, J#, Delphi.NET etc. And because you compile the code to bytecode, it runs significantly faster. On top of that Visual Studio is a great free (and commercial) development environment.

Oh, and if you want to run ASP.NET under Linux servers, it's easy too. Apache has mod_mono module or you can use it via FastCGI.

The Linux console COULD be written to pass objects between standard OS programs, but it was not. Linux has the UNIX paradigm of piping arbitrary ASCII streams between programs. And the presence of Python and Perl (as on every OS) doesn't change that.

You don't need to write everything yourself. Proper objects simply doesn't need to be part of the OS. In Windows, they do everything for you, so object passing is (in a sense) part of the OS.

In Linux, you just have a kernel and you can install Windows-like object passing on top of it. If you don't want to use pipes and Python serialization then use some other shared libraries that provide that functionality. Install Gtk+ or Qt, which provide Windows-like object passing. You can even use Mono which an attempt at an open source version of .NET. Then just use shared memory to pass objects between programs, and use Python bindings to these libraries do shell scripting.

So sharing objects between applications is not integrated into the Linux OS, but that means you have a choice of how to do it. However, the trade-off is a less consistent universe of application software.

The result is, in Windows, you are stuck with the Windows graphical interface, but in Linux, you can change freely between KDE, Gnome, Xfce, or anything, without even restarting. That is a triumph of modularity, if not consistency.

You can't get a reasonable BASIC for your average GNU/Linux distro? http://www.mono-project.com/VisualBasic.NET_support

Yeah, I kind of understand the hate, but a person can do almost everything in Visual Basic that they can do in C#, but for some reason, VB is a red headed step child. If it is just MS hating, there are a lot of people that like C#, and both C# and VB compile to the exact same byte-code.

"To be honest, Java needs to die already. Everyone will be better off."

Except those that run a platform that lacks support (either no support or some outdated version).

I'm programming in this right now:
http://www.mono-project.com/Start

And the IDE is absolutely terrific:
http://monodevelop.com/

Sounds pretty familiar. Oh, yeah, Mono does this already.

Yes, if only something like that existed, and could even target the Apple, Android AND Windows phone platform, as well as many desktop and 'big box' server platforms.

There is no Silverlight for Linux because Microsoft hates Linux and if they cannot control it (which they clearly cannot any time soon) then they want it to die. It's not emotionally-based, but it's true nonetheless.

There is a Sliverlight implementation for Linux--Moonlight. It can't play encrypted content, though Microsoft did release a media pack for licensed codecs.

, what does sound interesting is the whole 'bypass the .NET CLR and everything that makes .NET work and compile C# code to native". A lot of people were interested in that kind of thing a while back, I wonder if they still are.

It's not really new - e.g. Mono folks have done it last year so as to target iOS in MonoTouch. Some obvious limitations there, like some corner cases with generics (that require a VM), or anything in the standard libraries that does IL generation.

What would be more interesting is a CIL to LLVM translator, for the sake of portability.

Cool! Can I use this C# language to create desktop apps that run without modification on Linux, Mac OS X and Windows?

yes: http://www.mono-project.com/Main_Page.

You have a choice between Windows Forms or GTK as the widget toolkit. Both are supported on X11, Win32, and OSX.

Is there a cross platform IDE for this C# language that allows me to develop in the same IDE on Linux as my colleagues do in Windows or OS X?

yes: http://monodevelop.com/

The .NET languages are probably the best for native integration (certainly better than Perl, shudder). Sure, there are warts (just look at this Mono description of the problem: http://www.mono-project.com/Interop_with_Native_Libraries), but a lot of the problems are on the part of the platform developers, not the end developers. If you are calling C functions from C#, it's really quite trivial. You write your C function like usual and then you put a "public static extern void foo(int x);" declaration in some C# class with a DllImport attribute and you are pretty much done. You can call it in C# like a normal C# function and in C it acts like a normal C function. It's only weird if you want to be able to use managed types in C, in which case you have to jump through some hoops.

For OOP though, the terchniques are the same for C++, Java and C# so unless you want them to learn the C#/.NET specific parts (eg WPF, WCF, all the wizard generated bumpf) then or learn how to use Visual Studio, you might as well show them Java instead. The tooling should be better for your platform and I'm sure you can find better example code.

Well, if "MS doesn't make .NET for (his) platform", Visual Studio is totally out of the question. He's most likely on a *nix; so, he'd most likely go with something like MonoDevelop (GTK#) for an IDE and one of these may be chosen for a GUI toolkit (when he eventually gets to that): http://www.mono-project.com/Gui_Toolkits

If he wants to stick with Pascal, he could also consider Oxygene which also runs on top of the CLR/Mono. This has the advantage of using all the classes already available in Mono, but with a similar syntax.

"Mono can't run .NET apps."

Wow, that's funny. I must be on acid, because I thought I just compiled a .NET app in Visual Studio, copied it to Linux, and literally ran the Portable Executable file (.EXE) with Mono.

"Probably you would have to code in a subset of Mono, this coupled with the fact that Mono will always play catch up to .NET means that developing cross-platform apps in Mono will always place severe restrictions on you."

Let's see how true this is:

http://mono-project.com/Compatibility

So here's what's missing:

CodeContracts - API complete, partial tooling
EntityFrameworks - Not available.
Server-side OData - Depends on Entity Framework.
WCF - silverlight 2.0 subset completed
WPF - no plans to implement
WF - Will implement WF 4 instead on future versions of Mono.
System.Management - does not map to Linux
System.EnterpriseServices - deprecated

So other than the above Microsoft specific technology plus Entity Framework (use NHibernate instead), the entire C# 4.0, .NET 4.0, and ASP.NET 4.0 platforms are supported. Oh, and what really matters is ISO/IEC 23271:2006 and ISO/IEC 23270:2006... you know the ISO standards that Mono implements.

So basically, your entire point against Mono as a multi-platform solution for ISO standards based .NET development is bullshit. The few libraries that are limited on Mono aren't that critical for applications, web, or backend development. WinForms is supported, ASP.NET is supported, and services (as console apps) are supported.

". Compared to a Silverlight solution, the JS player is 3.5 times larger (535kb vs 154kb), uses about 3.6 times as much CPU power (25% vs 7%), and has to have significant modifications to work in multiple browsers."

Can you please tell me what modifications are necessary to use the silverlight plugin on my Solaris SPARC system? You say it works in multiple browsers so I would like to test your assertion.

No modification needed, just install it: http://www.mono-project.com/Moonlight. If Silverlight isn't your thing, Flash or Java would also be better solutions. The point wasn't that Silverlight is great; it was that JS is terrible.

if you wanna get freaky you can install http://www.mono-project.com/Moonlight it's pretty crappy but it is better than flash on linux

...Moonlight and Mono, their open source right? :p