Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Ars Technica Tours Mono 465

Kevin Francis writes "Over the coming weeks, Ars Technica will be taking a look at Mono, including a basic introduction to Mono, MonoDevelop, and C#, and then branching out to GTK#, database access, ASP.NET, advanced C# topics, and conclude with a discussion of the future of Mono, and the C# standard. All the examples will work on Windows and Linux, with OSX support coming shortly. Part 1 of the series is online now."
This discussion has been archived. No new comments can be posted.

Ars Technica Tours Mono

Comments Filter:
  • by urbieta ( 212354 ) on Thursday July 15, 2004 @02:04PM (#9709419) Homepage Journal
    Time for coders to take a closer look!

    What are the methods currently used by GIMP, OpenOffice, Mozilla among others that already support multiple OS's?

    Maybe Ill start learning coding with this and kill more birds with the same shot :)
  • by Random Web Developer ( 776291 ) on Thursday July 15, 2004 @02:06PM (#9709436) Homepage
    I am writing an app for mono that is supposed to run on linux mac and windows in the end. From what I see it's nowhere near just starting a .NET app on linux using mono.

    The app clearly has to be written with crossplatform execution in mind. (I know this goes for c and java too, but some people seem to think they will run office on mono in the future.).
    You need to steer clear of anything that depends on a platform.
    - if you define a path, make sure you use path.combine or path.directoryseparatorchar instead of a / of \.
    - don't depend on environment variables
    - pay attention to casing, don't say "file.ext" when it's "File.ext"

    I know it should be ovbious to any cross platform dev out there, but I just thought I'd bust some bubbles with some of the less informed.
  • Re:Libraries (Score:5, Informative)

    by ajp ( 192328 ) on Thursday July 15, 2004 @02:08PM (#9709474)
    Uninformed slashdotters with tin foil hats should click this link.
    ECMA-335 Common Language Infrastructure [ecma-international.org] (of which .NET, Rotor and Mono are implementations.)
  • Re:RAD tools (Score:5, Informative)

    by Lussarn ( 105276 ) on Thursday July 15, 2004 @02:14PM (#9709545)
    Glade [gnome.org] is language independant. As long as there is libglade for mono it should work very well.
  • Re:RAD tools (Score:2, Informative)

    by Random Web Developer ( 776291 ) on Thursday July 15, 2004 @02:16PM (#9709571) Homepage
    It does pretty much everything except for the gui designer (and a debugger or help system if it's not built correctly).
  • Re:blech! (Score:4, Informative)

    by turgid ( 580780 ) on Thursday July 15, 2004 @02:31PM (#9709708) Journal
    Since when does imposing Windows conventions everywhere by force equal "cross platform compatability?"

    We have Open Standards and Open Source for that sort of thing already.

    We also have Java for the write-once-run-anywhere thing. I fail to believe that .NET/Mono/.GNU will be better or solve any new problems that have not already been solved.

    There's even an official Windows port ofn Java, so I'm told...

  • Re:Bull (Score:5, Informative)

    by cbiffle ( 211614 ) on Thursday July 15, 2004 @02:40PM (#9709787)
    And, of course, there's the fact that his latter two complaints are kind of sort of fixed in 1.5.

    So... :-)

    Personally, I think the C# folks make too much of a big deal about the mandatory exception handling in Java. Heard a fellow from Microsoft say "Frequently, Java folks just put an empty catch() block to catch the exception they know won't happen, so why make it mandatory?"

    I've got bad news for you. I find situations like that about once a week when auditing my programmers' code, and it's almost always a situation that -can- happen, but the programmer couldn't see it.

    Don't trust the programmer. I know, I am one. :-)
  • by FooBarWidget ( 556006 ) on Thursday July 15, 2004 @02:42PM (#9709803)
    I don't know about OpenOffice and Mozilla but your claims are definitely not true for Gimp.

    First of all, Gimp is not C++, it's written in C. And Gimp contains very little to no platform-specific code. Gimp uses Gtk and Glib as portability layers. The Gimp maintainer strives to have as little platform-specific code as possible. He even wants to eventually get rid of all of the remaining little #ifdefs.

    Gtk and Glib are also not littered with #ifdefs. Gtk uses Gdk as portability layer. Gdk has several implementations: X, Win32 GDI, DirectFB, etc. An implementation is automatically chosen by the configure script (or something like that, not really sure about this one), but there are very little #ifdefs.
    I don't know about Glib.

    "The theory is that with .NET you won't need ANY platform specfic code. If that turns out true, I will be completely amazed."

    My theory is that it will end up with something like Java or all the other portability frameworks for C/C++. The simple things are portable but when you want to do some more complex things, you suddenly face the limitations. And you also have limited ways to really integrate with the platform's desktop.
  • by De ( 39631 ) on Thursday July 15, 2004 @02:57PM (#9709990)
    You're of course welcome to use wxNet (wx's C# bindings) instead of GTK#. Mono doesn't force you to use a toolkit, they just make it easy to use GTK#.
  • Re:RAD tools (Score:2, Informative)

    by Oxy the moron ( 770724 ) on Thursday July 15, 2004 @02:59PM (#9710019)
    It is important to remember, though, that if you use GLADE you should have it set to Gtk+/Gtk/Gtk#. If you have it set to GLADE, I don't believe it will work in Windows (yet) due to lack of library support.
  • by moonbender ( 547943 ) <moonbender@gmaEE ... inus threevowels> on Thursday July 15, 2004 @02:59PM (#9710022)
    How is this different from Java? In my opinion Java makes things harder than it needs to be. For starters, enforced exception handling can't auto-box/unbox primitive types and doesn't support arbitrary length parameter lists String.Format() style.

    Right. Of course that's all about to change - from the Java 1.5 ("5") new features site [sun.com]:
    Autoboxing/Unboxing

    This facility eliminates the drudgery of manual conversion between primitive types (such as int) and wrapper types (such as Integer). Refer to JSR 201.
    Varargs

    This facility eliminates the need for manually boxing up argument lists into an array when invoking methods that accept variable-length argument lists. Refer to JSR 201.
    You still need to deal with exceptions - that's a bad thing?
  • by Graelin ( 309958 ) on Thursday July 15, 2004 @03:17PM (#9710186)
    I mean, take Python! (my favorite high level cross-platform programming languate)

    No, Python is a SCRIPTING languate [sic]. It is already being used in places where it makes sense to embed a scripting language. Website programming, app automation and some Linux distros use Python to build a lot of their tools. For the latter, I don't think Python is a good choice but that's another thread entirely.

    Java is a programming language. The differences between it and Python (as seen here [ferg.org]) are largely semantic/structural. I would also add that the Java SDK supplies developers with FAR more common libraries than Python does which tends to cut development time. Semantically, Java is a pure-OO language. Python is not.

    Furthermore, a lot of the verboseness and non-compactness of Java provides a lot of flexability. Opening a file in Python is a one liner. In Java you need 2 or more objects and 3+ lines of code. But you have much greater control over how the descripter is read.

    What I don't understand is that when people are talking about "cross platform" programming, it almost always is about Java or .NET/Mono.

    Maybe because nobody has a mainstream cross platform app that is written in a scripting language? Where as Java already has lots of exposure in that area thanks to Applets and other applications.

    I don't think you can think of .NET as cross platform yet. Mono is a huge step in the right direction but there are several large pieces of .NET that are not ported to Linux or OSX yet. Winforms, to name one and RDBMS access is another. I'm not sure how RDBMS works under Mono but I imagine it's different from Win32.NET. Can someone prove me wrong here? Please?

  • it's not either/or (Score:3, Informative)

    by dekeji ( 784080 ) on Thursday July 15, 2004 @03:29PM (#9710323)
    Mono isn't all about cross-platform development, it's about giving you a more modern general purpose programming language than C/C++ and providing lots of useful bindings for it. Some of those bindings happen to be cross-platform, others don't. You really just get a choice.

    As languages, C# and Python are simply different. Both have their uses, and neither is better. C#, for example, lets you do pointer manipulation and its implementations are efficient enough even for writing low-level loops. Also, people find C#'s static type checking useful for long-lived, multi-programmer projects. If all your needs are met by Python, consider yourself lucky; other people's needs are not that simple.

    In terms of libraries, you can have Python/Gtk+, Python/wxWindows, C#/Gtk+, and C#/wxWindows, and all four exist (C#/wxWindows isn't all that far along yet, but people are working on it). So, your choice of toolkit and your choice of language are orthogonal.
  • by Cereal Box ( 4286 ) on Thursday July 15, 2004 @03:30PM (#9710327)
    Python and Java are both languages and run-time thingies.

    Not necessarily. People have targetted other languages for the Java runtime, including Python (Jython) and Scheme (Kawa). Basically, as long as you can spit out Java bytecode it doesn't matter language what you compiled to get it. Same basic idea with .NET.
  • by Anonymous Coward on Thursday July 15, 2004 @04:13PM (#9710745)
    While C# and Java are very similar looking, the difference between .NET and Java is huge.

    A couple of key differences....

    - .NET's garbage collection is not based on reference counting, but is actually a rooted reference map and is absolutely gorgeous to behold - heap allocations are identical in process time to stack allocations (unless the heap allocation triggers a GC) providing an incredible speed increase.

    - Everything in .NET is derived from the base class object. In Java, native types (int, float, etc) are not. Although Java 1.5 syntactically supports calling of methods on native types, behind the scenes a method call on type int boxes that type up to a type Integer, silently incurring an allocation, copy and deallocation cost. In .NET, method calls are permitted on value types and those types only need to be boxed when explictly casted to type "object".

    - .NET supports value-types, or types derived from
    object which can be stack allocated. In Java, native types can be allocated on the stack, but the user cannot define new native types, and there are no methods assigned to the existing native types. All custom objects must be heap allocated.

    - In Java, every method is virtual by default. In .NET, a method is only virtual if explicitly marked as virtual. This is a boon to .NET, since a JIT compiler can smartly inline non-virtual methods much easier than it can inline virtual methods (and it can only inline the virtual method in somewhat rare circumstances), producing much faster execution times.

    - .NET supports delegates, which are effective "safe" function pointers. The .NET Framework libaries use these as the mechanism for event-driven programming models as opposed to Java which requires listeners interfaces. Although its debateable, I personally find this produces much more elegant code, although there are others who disagree with me - the point is, listener interfaces can be implemented in .NET too. In Java, you don't have a choice.

    - .NET allows developers to embed type metadata into their objects, and have very powerful tools for reflection. Take a look at how easy it is to make a webservice in .NET as opposed to Java, or how easy it is to mark an object as serializeable. Admittedly, Java 1.5 supports metadata as well, and I don't know enough about its inner workings to compare it to .NET.

    - .NET supports inlining of "unsafe" or unmanaged code into an assembly. When an assembly is marked as unsafe, .NET treats it with the same permissions it would treat any other native executable, but it allows one to write below the .NET layer and add .NET stubs to their native objects without having to write a wrapper layer ala JNI. There are already Windows device drivers written as .NET assemblies that run just as fast as any other native driver, only that developers have to use a safe, managed interface to interact with them. The very existence of C++ with Managed Extensions and the "unsafe" keyword in C# make interoperability with low-level elements significantly more easy to work with and develop than it is to do the same in Java.
  • by ncaHammer ( 518236 ) on Thursday July 15, 2004 @04:19PM (#9710811)
    There is nothing special in general about .NET that doesn't apply equally to Java


    Except those
    A. Polymorphic instruction set
    In JVM most instructions have the types of their arguments hardcoded (faster interpretation but harder to create a compiler to emit the correct one)
    In CLR has polymorphic instruction set, only the result type is hardcoded (compilers have much easier job but JITer has more work to do)

    B. Extensible convention for emitted members using attributes
    C. Assembly packaging vs JAR (zip file) packaging (can also contain native code or preJITed code)
    D. In JVM you are unable to encode
    1) enumerations (all)
    2) structures (records in Delphi, struct in C)
    3) unions (C and Delphi)
    4) variant records (only C)
    5) overflow sensitive arithmetic on integer data types (all)
    6) reference parameters (var in Delphi)
    7) function pointers (all)
    8) extern functions with calling convention (all)
    9) variable length arguments (array of in Delphi, C ...)
    10) tail calls (only Scheme IIRC)
    11) Unsafe code (eg C, Delphi pointer/memory manipulation)

    so the compiler writer that targets JVM must emulate all the above (using Java actually) resulting functional crippling or degraded efficiency

    E. JVM has an 64K limit in branching, making compiler writing more difficult than CLR

  • by StarfishOne ( 756076 ) on Thursday July 15, 2004 @04:20PM (#9710816)

    I've been playing around with (wx)Python as well lately and it rocks!

    Especiall combined with:

    Boa Constructor:
    'A cross platform Python IDE and wxPython GUI Builder. It offers visual frame creation and manipulation, an object inspector, many views on the source like object browsers, inheritance hierarchies, doc string generated html documentation, an advanced debugger and integrated help.'

    http://boa-constructor.sourceforge.net/

    And the Twisted framework for network programming. http://www.twistedmatrix.com/

    "Twisted Matrix Laboratories is a distributed group of open-source developers working on Twisted, an event-driven networking framework written in Python and licensed under the LGPL. Twisted supports TCP, UDP, SSL/TLS, multicast, Unix sockets, a large number of protocols (including HTTP, NNTP, IMAP, SSH, IRC, FTP, and others), and much more."

    I've now got a fully asynchronous and very fast custom server running.. in less then a day from a clean start with the Python language!

    I really recommend checking this out!! ^_^

  • by dekeji ( 784080 ) on Thursday July 15, 2004 @04:26PM (#9710861)
    Strangely that assumption is quite widespread. I think I've tracked down the source [mono-project.com] though.

    Yes, you have correctly tracked down the source of that misconception. It's an easy misconception to have, given what the Mono project writes about itself.

    Now, dig down a little deeper and go to the downloads [ximian.com]. What do you see? A "Mono Stack" on the left, consisting of OSS libraries and APIs, and a .NET stack on the right, consisting of .NET libraries and APIs. You can pick one or the other, or both. Neat, huh? Now, also note the relative sizes of the Mono and .NET stacks.

    Now, turn to the FAQ:

    Question 132: Is Mono only an implementation of the .NET Framework?


    Mono implements both the .NET Framework, as well as plenty of class libraries that are either UNIX specific, Gnome specific, or that are not part of the .NET Framework but people find useful.


    Question 50: Can mono run the WebMatrix?


    No. That requires System.Windows.Forms support which is not currently implemented.


    Question 40: Do you fear that Microsoft will change the spec and render Mono useless?


    No. Microsoft proved with the CLI and the C# language that it was possible to create a powerful foundation for many languages to inter-operate. We will always have that.

    Even if changes happened in the platform which were undocumented, the existing platform would a value on its own.


    What does that tell you?

    • A lot of Mono software (most, in fact) already is completely incompatible with Microsoft .NET, since Mono doesn't even implement important parts of .NET, but does provide extensive non-.NET libraries that are being used by Mono applications. So, .NET compatibilty just doesn't matter to most Mono developers.
    • People know that Microsoft could change .NET, and it generally doesn't matter to them.


    Why is the Mono project seemingly saying one thing and delivering another? Well, in part, it's because the term ".NET" is really ambiguous. In part, it's because where their money comes from and where their commercial interests are (they aren't doing this out of religion, they are in it for commercial purposes).

    So, your confusion is understandable. I wish the Mono project were clearer on their front page, too, but I suspect they have reasons for what they are doing. Either way, you should really dig a little deeper.
  • by koali ( 175176 ) on Thursday July 15, 2004 @05:16PM (#9711397)
    Errrrr... no, it's not.

    In fact, there's a new method in 1.5 to get all the env vars...

    http://java.sun.com/j2se/1.5.0/docs/api/java/lan g/ System.html#getenv(java.lang.String)
    http://java. sun.com/j2se/1.5.0/docs/api/java/lang/ System.html#getenv()
  • by Arkaein ( 264614 ) on Thursday July 15, 2004 @05:33PM (#9711560) Homepage
    This is pure ignorance. The differences between programming languages and scripting languages are completely in the eyes of the developer. Python has excellent tools for developing solid applications which perform well and make use of libraries normally associate with C/C++ applications:

    • A large standard library [python.org] that rivals "programming" languages like Java
    • Hooks into popular [riverbankcomputing.co.uk] interface [pygtk.org] libraries [wxpython.org]
    • for developing GUI applications
    • A JIT optimizing compiler [sourceforge.net] for speeding up interpreted bytecode to near-directly compiled code speeds
    • Great support for regression/unit testing by allowing "main" functions to be used in every script/class file in large projects

    In short, Python can do pretty much anything Java or Mono is likely able to do. In addition, it's faster and easier to code in than most "programming" languages, largely due to dynamic variable typing.

    For developer friendliness Mono and Java are a step up from C/C++, but languages like Python (and probably Ruby, though I haven't used it) have potential to be even more.

  • by Merk ( 25521 ) on Thursday July 15, 2004 @05:39PM (#9711593) Homepage

    Java compiles to bytecode, Python compiles to bytecode. If being a "scripting language" means that you're not *forced* to compile to bytecode to run a program, then aren't scripting languages simply a superior form of "programming languages"?

    Verbosity in Java doesn't translate to flexibility. It may occasionally translate to more control, but that's rare. Most of the time, it's just due to the inflexibility of the language. Conversely, just because Python provides an easy way of dealing with files doesn't mean that it lacks flexibility. What kind of low-level things can you do with Java that you can't do with fileno and fcntl in python?

    fileno()


    Return the integer ``file descriptor'' that is used by the underlying implementation to request I/O operations from the operating system. This can be useful for other, lower level interfaces that use file descriptors, such as the fcntl module or os.read() and friends. Note: File-like objects which do not have a real file descriptor should not provide this method!

    Commercial applications use Python and Java. Both are extensively used on servers (like Google uses Python for example). Java may have more desktop GUI use, but Python is used as a scripting engine in many applications, including games.

    As for Java being pure-OO and Python not being pure OO? Mwhahahahahaha.

    % python
    >>> (1).__add__(3)
    4

    Although the syntax may be somewhat ugly, even integers in Python are objects. Try that in Java. Java has Integer objects and 'int' types. That's not even slightly OO, let alone "pure" OO.

    Having said all that, I don't even like Python. I happen to be a big fan of Ruby, and am not at all used to defending Python. I think Python's syntax is ugly. I think significant whitespace for indentation of loops and conditionals is a huge mistake, making the code really inflexible when it comes to copying and pasting. I think it's requirement to pass around self when defining methods within a class is simply stupid. And the few remnants of non-ooness bug me, like len(str) instead of str.len() On the other hand, there's even more I dislike about Java. Java is way too verbose, and incredibly inflexible in a lot of areas. By making things like 'int' types rather than classes, it defeats a lot of the purposes of object orientation. At the same time, it makes things more difficult for programmers by lacking a simple printf/sprintf function. Of languages with a C-like syntax, I guess Java is the best option in most cases, but it's lack of true OOness, and its static typing really annoy me. Misinformed people who think that there is something inherently superior about languages which you have to compile to use just make it worse.

  • by VP ( 32928 ) on Thursday July 15, 2004 @08:47PM (#9712812)
    Windows.Forms really needs to be *the* standard implementation.

    Bullshit. Mono supports Windows.Forms via Wine. There is no way this can be "*the* standard". Windows.Forms is tied to the Win32 API, which even MS considers outdated. That is why they are replacing it in Longhorn. From this already discussed article [joelonsoftware.com]:
    And if you're developing a Windows GUI app today using Microsoft's "official" latest-and-greatest Windows programming environment, WinForms, you're going to have to start over again in two years to support Longhorn and Avalon.

  • by Nailer ( 69468 ) on Thursday July 15, 2004 @09:43PM (#9713090)
    White is the hyperlink color. Clicking the big white link named after the article takes me to the same page.

    The phrase we've got other stuff lined up inside would imply the link goes to the other stuff. The url for it seems like it'd show an index of all their linux content. But the word 'inside' actually shows the article.
  • by Anonymous Coward on Thursday July 15, 2004 @10:38PM (#9713332)
    For GUIs did you look at wxPython? PyQt? PyGTK? I've used wxPython which is very complete and native on Windows and Mac (think it uses GTK on Linux which is a shame but there ya go). I have touched PyQt briefly a few times and it seems nice and high quality too.

    As for IDEs, eric3 is good. Very good. You talk about time savers - eric3 will kick your ass!! It is written using PyQt though so not sure whether it runs on Windows. Personally I still use a text editor tho.
  • by Anonymous Coward on Thursday July 15, 2004 @11:44PM (#9713630)
    You need the mono runtime and libraries installed. Then you can either do a "mono v27e2.exe" to execute the .exe like java does or if you have bin_fmt support in your kernel you can do modify some files to have bash execute it directly. $./v27e2.exe

    Debian does modify the bin_fmt configuration so you can execute it directly, but I'm not sure about other distros.
  • Re:Java (Score:3, Informative)

    by turgid ( 580780 ) on Friday July 16, 2004 @03:23AM (#9714323) Journal
    Yeah, and Java really took off now, didn't it?

    It did actually, despite what Microsoft, the Slashbots and the Linux (and Windows) press would have you believe. There are millions of Java developers across the world, there are billions of devices from phones to high-end servers running Java. The number is growing despite what the Redmond Marketting Machine tells you. Even IBM likes Java.

  • by StrawberryFrog ( 67065 ) on Friday July 16, 2004 @04:37AM (#9714479) Homepage Journal
    .Net was and imho still is - to a large extent - a joke. What MS did was rename the .obj files from all their developement stuff to .net

    You don't know the first thing about it, do you? Go read [everything2.com].

    NET langages compile to plaform-independant bytecode. Shure it's ripping off Java, but it shows good taste in plagarism.

  • by ultrabot ( 200914 ) on Friday July 16, 2004 @04:50PM (#9721371)
    There's no true data hiding, for example.

    What's the relevance of data hiding in OOP?

    There's some inconsistencies that look bad (why str(foo) and not foo.str()?)

    Well, there is __str__ which is "magic", and every objects implements one.

    Not to even mention that deep down many types aren't really objects at all, even though they may be used as though they were.

    Of course they are objects, they just weren't subclassable in older Pythons. They were still normal referenceable objects.

    and one of Python's strengths is that you don't need to use OO in your own design, but you can if your design needs it.

    Even if you don't use it, it's still there (and that's the way it must be). Everything you see are objects and names bound to objects. That's what I consider pure OO, not the B&D imposed by Java that enforces the use of *classes* for everything.

To program is to be.

Working...