Please create an account to participate in the Slashdot moderation system


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:This is great news! (Score 2) 173

Amazing, I wonder what advertising platform paid for the Internet before this generation of marketers declared themselves essential to pay for the Internet? I can host a website for $4.99 a month, buy a Linux VM for $20 a month. Plenty of content is made by people not paid by your advertising dollars. Advertisers, we don't need you, don't test us.

Comment Re:All a mistake? No. 90% a mistake? Yes. (Score 1) 688

"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:

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.

Comment Re:I actually like it (Score 1) 688

Are you serious? We abandoned C++ Builder for Visual Studio and C# .NET and every other developer meeting we're praising the flying spaghetti monster that we did. The massive reduction in defects and the massive improvement in productivity were huge for our team. C++ Builder is great for breaking compatibility with every release (we owned literally every version up to XE), the IDE and/or compiler crashing at random intervals or producing broken code that itself crashes at random intervals. Plus you're serious about real code when you're talking about writing software that's based on the VCL?

Oh and by the way, a base class library that requires you to *new* every BCL object but doesn't have garbage collection, simply begs for access violations and memory leaks. Simply idiotic. You couldn't pay us to switch back.

As a bonus, we can compile our .NET binaries to native code with one drop down box selection, rather than code that pushes all of our data through a Delphi interface and back and beats the hell out of a shitty heap implementation. At least they switched to a 3rd party C++ STL implementation rather than their own buggy garbage.

Comment Re:But I said all that years ago (Score 1) 688

Microsoft hasn't abandoned DOS or Win16???? Have you tried running a DOS program or a Windows 3.x program in Windows 7? I think you'll find that your information is more than a little out of date.

And NT was a complete and total abandonment of the Windows 9x codebase. The entire OS was rewritten from scratch in C, an entire NT API exists under the hood that powers that OS, and then the Win32 API/ABI was added as a compatibility layer on top of that OS. As was their POSIX and OS/2 compatibility layer.

I know you probably can't be bothered to validate what you're saying before you say it, but perhaps a little bit of Google is in order before you spout off? Or try running a DOS app. Or something. Or let the grown ups talk.

Comment Re:Of course it was a mistake... (Score 1) 688

I hate having to explain this to non-.NET developers over and over again. Try to follow along.

In Visual Studio, if you select x86 or x64 or Itanium as your target instruction set, CIL (formerly MSIL) is not generated. NATIVE machine language is generated, doing the job that the JIT would normally do. You with me so far? You can target native platforms, and produce native code.

Beyond that, if you do choose to generate an "Any CPU" binary, .NET caches all of its JIT compiles in the GAC. Thus for a particular platform, the CIL is only compiled into native code ONCE. The second time the code is executed, even between shutdowns and reboots, the native code is executed. You can read more about the GAC here:

Your argument is like saying, because you have to run a tarball of source through ./configure && make once on a particular platform, the code is interpreted. That's ridiculous. Interpreted code is read by an interpreter AT runtime. Deferring final compilation to 0.01 seconds before the program entrypoint is executed doesn't mean a program is interpreted. What actually executes at runtime is native x86 or x64 or Itanium assembly language, generated exactly once.

Slashdot Top Deals

Genetics explains why you look like your father, and if you don't, why you should.