Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews Technology

Mono: A Developer's Handbook 301

Posted by timothy from the one-at-a-time dept.
vertigo writes "I am reasonably proficient in C and C++ as well as the more common scripting languages, but i always felt the lack of a sweet spot between the hard and fast low-level programming languages and the loosely typed scripting languages. Lately, my interest in the Mono project has been growing. The C# language appears to offer just that sweet spot between power and productivity I've been looking for, and its class libraries like Gtk# seem to provide the programmer with a very clean and intuitive API." Read on for vertigo's review of Mono: A Developer's Handbook from O'Reilly.
Mono: A Developer's Handbook
author Edd Dumbill and Niel M. Bornstein
pages 278
publisher O'Reilly Media, Inc.
rating 8
reviewer vertigo
ISBN 0596007922
summary An introduction to programming with Mono

When learning a new language such as C#, or working with a new development environment such as Mono, it usually takes some time before you get up to speed in developing programs. Wading through the reference documentation and reading other people's source code often provides much-needed information on how to do certain things. Both, however, are very time consuming and tedious.

Enter Mono: A Developer's Notebook. This book provides a series of task-driven chapters which are thin on theory, but rich on practical content and example code. The featured code snippets are, in contrast to ones in books that teach theory and concepts, not solely designed to illustrate a specific theoretical aspect of programming. Each one is designed to perform a useful task that is essential in day-to-day application programming. What sets this book apart from the multitude of .NET books already available on the market? In order to answer this question it is neccesary to provide a short introduction on Mono.

Mono is essentially an open source cross-platform implementation of Microsoft's .NET development framework and implements the API's which are standardized by ECMA. It is, however, not an exact clone. Besides providing a (partially implemented) stack that provides compatibility with Microsoft's .NET API's, Mono adds a whole new API-stack of its own, consisting of open source technologies such as the Gtk+ toolkit and the Gecko HTML rendering engine. This makes it possible to develop cross-platform applications based on open source technology while (mostly) compiling from a single code-base. In contrast to most .NET books available on the market, which focus primarily on Microsoft's API's in the context of Visual Studio.NET, this book concentrates on the basic ECMA API's and Mono's own open source stack. A complete coverage of .NET and the Mono architecture is outside of this review's scope, so for more information you are advised to check the Mono Project's website.

Before we dive deeper into the content of the book, a short introduction on the Developer's Notebook series by O'Reilly may be useful. The books in this series are styled to resemble the kind of notebooks college students carry around during their classes in which to take notes or, more commonly, draw caricatures of their teachers. The 'notebook' theme persists throughout the look-and-feel of the book. The 278-page thick paperback has a glossy blue cover, complete with faux post-it note and coffee-stains. Inside, the pages are not clean white but lined like the pages found in math notebooks. In the margin, useful comments are scribbled in a font that resembles handwriting. At first I suspected that the 'busy' look would distract from the content, but in practice this was no problem, thanks to the thick black typewriter font in which the bulk of the text is printed.

The chapters in this book are referred to as labs. Each of them focuses on a specific set of tasks and/or features and is divided into several paragraphs. Most paragraphs consist of a number of standard sections following a rigid formula that help you understand a certain aspect of working with Mono. The most common sections are:

  • How do I do that?: Often using a liberal amount of practical code, this section shows how to accomplish the task at hand, for example working with files.
  • How it works: In this section, the code and concepts involved in the previous section are explained more in depth, step by step.
  • What about...: Offers a short focus on more advanced topics or pitfalls.
  • Where to learn more: If you are craving more information after reading the previous sections, you are often offered a helping hand on where to find more information, providing url's to relevant documentation such as MSDN and other websites.

The first chapter, Getting Mono Running, describes how to get Mono up and running on Linux, Windows or Mac OS X, and how to compile from source on other platforms. The installation instructions for Windows only describe how to install Mono and Gtk#. Integration of Gtk# only in an existing Visual Studio.Net installation falls outside of the scope of the book, but a recent blog entry offers some hints on how to accomplish this. Besides installation, the first chapter offers a short description of the individual tools that make up the mono development. After installation, you will want some kind of editor or IDE to work with. Both the MonoDevelop IDE and several other ways of integrating Mono into your existing environment as a Java or Windows developer are covered. Finally, the community is an important aspect of every open source project. Ways of interacting with the community as well as a guide on how to submit bugs and links to some working Mono/C# applications are part of this chapter.

The C# introduction in the second chapter, Getting Started with C#, is tailored towards people who have at least some proficiency in using an object-oriented language such as C++ or Java. Some differences between C#, Java and C++ are discussed, as well as the differences between value- and reference types, the basics of error handling, working with assemblies and more. Concepts such as classes, methods, inheritance and namespaces are assumed to be known territory. If you have no previous programming experience, Mono: A Developer's Notebook is only useful in combination with a book that teaches programming with C# such as The C# Programming Language by Anders Hejlsberg.

An important part of any modern language is its class libraries. The third chapter, Core .NET, provides an introduction to the standard Framework Library Classes, which describes essential everyday tasks that are part of every program, such as working with files, strings, searching for text patterns and handling collections of data. Besides those basic functions, the chapter also dives deeper into the internals of a compiled assembly, the handling of processes and easy multitasking using threads. Finally, the last paragraph explains how to use a .NET version of the JUnit Java Unit testing framework, Nunit, to test your code.

Developing Gtk-applications with Mono and C# is remarkably easy. Chapter 4, Gtk#, describes the basics of writing Gtk# applications. First, it's neccesary to remark that Gtk# might be a bit of a misnomer. Besides the raw Gtk+ toolkit functionality, Gtk# also includes most of the Gnome libraries like gconf, the gnome canvas, libglade and more. Chapter 4 describes functionality available in the Gtk namespace, the basic Gtk+ toolkit. Gtk+ is a constraints-based toolkit, which means that widgets are not positioned using absolute pixel coordinates but rather on basis of their logical relation to each other. This can be a bit confusing for novices, but this chapter provides a good introduction to the basic principles of writing layouts using Gtk#. The authors provide descriptions of essential operations that almost every application needs, such as creating menus and drawing pixmaps (or more advanced things like using the treeview widget and drag-and-drop), assisted by easy-to-read code snippets.

While chapter 4 introduces basic Gtk# functionality, chapter 5, Advanced Gtk#, delves deeper into more advanced features of the Gtk# library which also include functionality outside of the basic Gtk-namespace, such as the Gnome libraries. Working with Gnome button toolbars, the Glade user interface designer, storing your application settings in Gconf, setting up some preferences through the use of a wizard/druid, asynchronous operations and threading to increase responsiveness of your application while performing background tasks, rendering HTML in your application using the Gecko rendering engine and internationalisation and translation of applications are all described in this chapter.

The use of XML is tightly integrated throughout the Mono framework. It is, for example, the underlying format of the messages that web services use to communicate using the SOAP and XML-RPC protocols. The 6th chapter, Processing XML, describes the XML functionality available in Mono. It starts off by simple operations, reading and writing to an XML-file using relevant examples such as RSS and Dashboard clue-packets. It then proceeds to describe how to modify XML in memory, how to navigate and transform XML using Xpath and XSLT, how to constrain XML in several ways and how to serialize and deserialize objects into and from their XML representation. As in previous chapters, the information density is very high so it might take several reads to grok everything explained. The code examples and accompanying text however are very clear and concise.

The 7th chapter called Networking, Remoting, and Web Services describes the networking functionality available in Mono. The chapter starts off with ASP.NET. Mono's stand-alone XSP webserver and Apache integration with mod_mono are discussed, as well as the basics of writing a web application using ASP.NET's code-behind functionality which enables web applications to completely seperate presentation from the underlying code. Communication using plain tcp/ip, remoting using binary serialized objects and invoking remote procedures using XML-RPC as an alternative to SOAP are also described in this chapter. You might want to encrypt the data you send over the network, so a basic description of the Mono cryptographic API is provided. Finally, a short introduction to database handling using ADO.NET concludes chapter 7.

The 8th and last chapter titled Cutting Edge Mono starts off with an introduction on how to use the GNU Automake, Autoconf and the pkg-config tools to create an easy to build source package of your project. It then proceeds to describe various pitfalls and considerations in case you want to write cross-platform applications using Mono, such as filesystem layout, configuration storage and the calling of native code using p/invoke. A particularly cool project is IKVM, which translates Java bytecode into the Common Intermediate Language bytecode Mono uses. This enables Mono to run Java applications and allows Java and Mono code to inter-operate. A short introduction on the use of IKVM is provided, as well as some code examples on how to call Mono assemblies from Java and use the Java class libraries from within Mono applications. The chapter ends with some other cutting-edge functionality, like how to run a development version of Mono, a preview of the Generics (templates in c++) implementation available as featured in C# 2.0 and how to write Mono programs in Basic.

What is missing? The book doesn't contain a reference section on any of the described API's. If you need detailed information on the C# language specification or an API reference you will need to consult external resources such as the documentation provided with Mono, MSDN, or a separate book covering the topic to make optimal use of the information contained in this book. Fortunately, the book kindly provides pointers on where to find those. The information-density is much higher than you would expect from a book this size. This means the information contained in it is terse. Many topics are treated in a only a couple of pages and the book doesn't take time to explain a lot of programming concepts. The information gets you 'on the road' quickly however, which is exactly what this book is supposed to do.

The strength of this book is that it fills the gap between the earlier-mentioned reference documentation and the need to go out and try to read sourcecode to find out how a particular thing is done. The writing style is clear, concise and neutral. Some topics are clarified by the use of screenshots, which is especially useful in the chapters dealing with Gtk# widgets. All in all, if you are a developer with previous experience in object-oriented programming, Mono: A Developer's Notebook will provide you with an excellent introduction into many of the aspects of working with Mono, its associated libraries and programs.

More information and a sample chapter can be found at the book's homepage.

You can purchase Mono: A Developer's Handbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Mono: A Developer's Handbook More

Mono: A Developer's Handbook

Comments Filter:

  • No animal on the cover? (Score:5, Funny)

    by Neil Blender ( 555885 ) <neilblender@gmail.com> on Wednesday September 29, 2004 @03:19PM (#10386600)
    It was only a matter of time before O'Reilly used them all up.

  • Summary of the next 100 posts (Score:5, Funny)

    by Swamii ( 594522 ) on Wednesday September 29, 2004 @03:19PM (#10386602) Homepage
    1. Why not use Java? 2. Does it run on Linux? 3. Imagine a beowulf cluster of these! 4. Keep up the good work Miguel! 5. Miguel you are a tool! 6. Why not use Java!
    • Yeah, but why not use Java? And who is Miguel?

    • Why not use Java? Probably didn't feel like it.

      Does it run Linux? Yes, where else would you expect GTK# to run?

      I will ignore a few here...

    • I can't imagine why anyone would use Mono when it can be ripped out from under you by Microsoft's patent attorneys at any moment, and the alternatives are so superior. For example, gcj, or
      Ruby's GTK and Gnome or QT and KDE bindings.

      While C# and dotnet get enormous amounts of PR hype, they really don't amount to much in the real world, where the platform lock-in and enormous bloat that dotnet entails spell doom.

      • Re:Summary of the next 100 posts (Score:5, Insightful)

        by Bastian ( 66383 ) on Wednesday September 29, 2004 @04:10PM (#10387254)
        The big advantage to .NET/Mono is not platform-independent development. It's kind of asinine to even make that claim since Microsoft has not released the .NET framework on any platform but Widnows, and doesn't have any plans (that they're talking about) to do so.

        The big advantage to .NET/Mono is the ability to easily use a common set of libraries from any (.NET/Mono compatible) language. This is why the GTK/GNOME people are so interested in Mono - they have always been interested in letting people work with whatever language they want with a minimum of effort.

        As for the patent stuff, I'm not aware of what patents cover .NET. I realize they applied for some patents, but I was also under the impression that the patents they went for covering .NET are so broad they would never hold up in court. Assuming that is true, the only real worry for Mono is that Microsoft would change .NET enough to break what compatibility they have, but the Mono project has already explained why this doesn't worry them.

        • Microsoft has not released the .NET framework on any platform but Widnows, and doesn't have any plans (that they're talking about) to do so.

          That's assuming you don't count Rotor [c-sharpcorner.com], Microsoft's reference implementation of the ECMA-standardize bits of .NET (the C# language, the CLR, etc, but not bits like WinForms), which at least works on various BSD platforms, and is licensed such that you can safely port it to other platforms, or use it as the basis for a reimplimentation (think BSD's network stack, for

        • The big advantage to .NET/Mono is the ability to easily use a common set of libraries from any (.NET/Mono compatible) language.

          It's about time! Everyday when I come into work, I have all these software maintainers waiting for me with a common plea: please code my application with ten different languages! It's nice to know that I can know fulfill their request and provide them with unending job security.

        • Assuming that is true, the only real worry for Mono is that Microsoft would change .NET enough to break what compatibility they have, but the Mono project has already explained why this doesn't worry them.

          I just wanted to clarify this part in case people are wondering why. Basically Microsoft can't break .NET compatibility in old versions of the Framework because it'll break all the programs that use those versions. So versions 1.0 and 1.1 can be considered unchangeable right now (except for fixes probab

      • Why does someone always make this absolutely retarded comment every time a Mono story is posted on Slashdot?

        Let's get a few things straight about Mono:
        1. Microsoft submitted the language spec and virtual machine bytecode format as an ECMA standard. There's no way that Microsoft could possible sue Mono because they have a language that resemebles C# in syntax or produces .NET bytecode. Period.
        2. To that end, there is absolutely nothing stopping someone from producing .NET bytecode that just so happens to be
        • Microsoft submitted the language spec and virtual machine bytecode format as an ECMA standard. There's no way that Microsoft could possible sue Mono because they have a language that resemebles C# in syntax or produces .NET bytecode. Period.

          Wrong. Just because something is standardized does NOT mean it isn't patented or patent pending. The two are orthogonal issues, there are many patented standards out there. With a patented standard, you ned to license the patent to legally use the standard.

          # To th
          • Wrong. Just because something is standardized does NOT mean it isn't patented or patent pending. The two are orthogonal issues, there are many patented standards out there. With a patented standard, you ned to license the patent to legally use the standard.

            Can you name a case where something similar (let's say an API or language spec) was submitted as, let's say, an ECMA spec and later the implementor(s) was sued into oblivion? I find it highly unlikely that Microsoft would legally be able to make public
            • Can you name a case where something similar (let's say an API or language spec) was submitted as, let's say, an ECMA spec and later the implementor(s) was sued into oblivion?

              I can think of several ISO and ANSI specs where this happened. I don't know about EMCA in particular, in fact before MS used them, I'd never heard of EMCA. You can also look back at the W3C proceedings a few years back- they were deciding wether or not to allow patented technology in standard. The no patent groups barely won.

              But t

    • Re:Summary of the next 100 posts (Score:5, Funny)

      by pnatural ( 59329 ) on Wednesday September 29, 2004 @03:30PM (#10386720)
      1. java is teh suck! 2. it does, and with hot grits! 3. imagine them in your pants! 4. karma whore! 5. so is cowboy neal! 6. java is teh suck!
    • You missed the post above yours, "why not use Objective-C?"

      If you want cross-platform and (fairly) strong typing, use Java, if you want loose typing and want Linux or OS X, use Objective-C ( GNUStep/Cocoa respectively for UIs ), if you want M$, use Visual Studio C++ or flavor-of-the-moment C#, or flavor-of-the-last-moment VisualBasic, or ( somebody's favorite Wxyz windows-centric development platform here )...

      But seriously ( for a moment ), without asking why not use Java, why use C# ? What's the benefit

  • Objective-C (Score:4, Interesting)

    by remahl ( 698283 ) on Wednesday September 29, 2004 @03:20PM (#10386603)
    For me, Obj-C combined with Cocoa (*Step), is that same sweet spot. And sometimes Python, when a really high-level language is required. Naturally still together with Cocoa through PyObjC.

    • Re:Objective-C (Score:3, Informative)

      by Swamii ( 594522 )
      As a footnote, I know the Mono guys have done a Cocoa# bindings for the PowerPC.

      Sidenote #2, IronPython, which runs on Mono, has been shown to perform better (on average, 1.7x better) under most performance tests than standard Python v2.3. (this is not a troll or flame-incitation, just a FYI). See IronPython.com [ironpython.com], or this paper from PyCon 2004 [python.org].

    • Re:Objective-C (Score:4, Informative)

      by jeif1k ( 809151 ) on Wednesday September 29, 2004 @03:46PM (#10386923)
      For me, Obj-C combined with Cocoa (*Step), is that same sweet spot.

      To each their own, but I suspect you are in a small minority. Garbage collection, safe modules, type-safe linkage, and runtime code generation are all important modern language features that C# has and Objective C lacks.

    • Perhaps for a lot of apps, but not for me. I had a close look at Objective-C about a year ago. I started reading up on it and found that it missed operator overloading. I tend to do a lot of graphics and physics programming (nothing professional of course) and the thought of doing vector, matrix, and quarternion maths without operator overloading was just unacceptable. But I notice that ARToolkit [artoolkit.org] is written in Obj-C (whenever it's released). Could a seasoned Obj-C coder explain whether there's a way to get

      • Re:Objective-C (Score:2, Informative)

        by myrdred ( 597891 )
        There's such a thing as Objective-C++, which solves just that problem. Go Google for it, Apple uses it for Safari.

      • I had a close look at Objective-C about a year ago. I started reading up on it and found that it missed operator overloading.

        Operatror overloading? OPERATOR OVERLOADING??? One of th momst abused features of C++ and you miss it? You clearly haven't worked in the industry long enough to seen the abortions people produce with misconceived features like these.

  • Mono (Score:4, Funny)

    by NoInfo ( 247461 ) * on Wednesday September 29, 2004 @03:21PM (#10386616) Homepage Journal
    Am I the only one who immediately thinks of debilitating diseases whenever this project is mentioned?

    • I can't imagine being some who works on the software of this project:

      - So what do you do for a living?
      - I develop Mono
      - Er.. Look at the time, I've got to be going now...

  • Mono (Score:2, Funny)

    by Anonymous Coward
    I had Mono in 7th grade, it sucked.

  • Mono vs .NET Framework (Score:3, Interesting)

    by Nick of NSTime ( 597712 ) on Wednesday September 29, 2004 @03:32PM (#10386742)
    One thing I still haven't been able to figure it is how Mono compares to developing .NET applications on Windows with the Microsoft toolset. Does Mono capture the simplicity of the .NET Framework in building Windows (GUI-based) applications?

    • Re:Mono vs .NET Framework (Score:4, Informative)

      by jblake ( 162981 ) on Wednesday September 29, 2004 @03:47PM (#10386931) Homepage
      It's not Mono vs .NET Framework. Mono is an implementation of the .NET Framework and C# compiler on the linux platform. If you're asking about IDEs, then look at the ones the review talked about, and sharpDevelop and such.

      The mono c# compiler allows you to create CIL (common intermediate language) code, which is analygous to java byte-code, except for just-in-time compilation. The mono implementation of the .NET Framework allows you to compile CIL to native linux binary JIT and run it on Linux.

      The whole point about the .NET Framework and CIL is that you could write and compile a program using Mono, then copy it to windows and run it, and vice versa for VS.NET to linux. Right now this probably only works with console programs, and web services and ASP.NET and such. (Of course, with both windows and linux if you include system specific APIs, they won't run on the opposing system. )

      When Mono's Windows.Forms implementation is complete, you should be able to do this same thing with complete GUI applications, however in the mean time that's what GTK# and other linux-based APIs are for.

    • Re:Mono vs .NET Framework (Score:5, Informative)

      by steve_deobald ( 729154 ) on Wednesday September 29, 2004 @03:51PM (#10386974)
      Yes and no. The framework is in place, but the tools are somewhat lacking. Some people would argue that building Gtk# applications in Glade is just as easy as the Visual Studio Forms Designer.

      Personally, I disagree. Visual Studio is still a phenomenal IDE, and its GUI tools are some of the best on the market. But I think as we see Mono stabilize and mature past 1.0, the GUI tools for Gtk#, ASP.net, and the new Managed.Windows.Forms implemenation will be quite impressive.

      (Disclaimer: This isn't a knock at Glade. Glade is good at what it does, but with the advent of Mono it's time for a replacement.)
    • How difficult it is to build applications for .NET depends on the tools you use for building those applications, not the runtime you execute them with. So, you can use VisualStudio or Sharpdevelop or whatever other .NET tools you use for developing Mono applications.

      But, in addition, Mono also offers bindings to the Gtk+/Gnome APIs, and that makes software development a lot easier for Gnome developers. There are some GUI builders you can already use with those Mono bindings, and a new GUI builder will be
    • what about packaging of the finished product?
      I suppose if I develop in Mono for Windows I need to be able to make an .exe that would run on any .NET implementation (MS or Mono) my user happens to have installed.
      I guess I can always use Visual Studio to create nice installer that would include gtk/glade dlls and whatever else I may need. But can I do the same without VS?

  • Sweet Spot? (Score:4, Interesting)

    by Freedom Bug ( 86180 ) on Wednesday September 29, 2004 @03:32PM (#10386743) Homepage
    Sweet spot? I call it uninteresting void. It seems to me that most programming is either:

    1) operating system kernel or core library, embedded or high-performance programming. This niche only finished moving from assembly to C a few years ago. C++ is usually too slow & big & unwieldy for this niche, let alone C# or Java, although we may be ready for it in 5 years or so.

    2) application programming. Here development speed is more important than execution speed. Python and kin provide 'good enough' execution speed when coupled with proper libries (QT, etc) with the fastest development speed.

    What kind of code falls between the 2? Sure there is some, but is it interesting?

    Bryan

    • Re:Sweet Spot? (Score:5, Interesting)

      by tcopeland ( 32225 ) * <tom AT thomasleecopeland DOT com> on Wednesday September 29, 2004 @03:44PM (#10386896) Homepage
      > Here development speed is more important
      > than execution speed. Python and kin

      Right on. And with Ruby/Python/etc you can always dip down into a C library for bits that turn out to be performance-critical. With Ruby, this is usually as simple as something like:
      require 'dl/import'

      module Curl
      extend DL::Importable
      dlload "/usr/local/lib/libcurl.so"
      extern "char *curl_version()"
      end

      puts Curl.curl_version
      Hard to beat...

      • Re:Sweet Spot? (Score:2, Informative)

        by Swamii ( 594522 )
        And with Ruby/Python/etc you can always dip down into a C library for bits that turn out to be performance-critical.

        The same is true for C#, using the platform invoke mechanism, it's even simpler.
        // import the C dll method signature
        [DllImport("myclib.dll")]
        static extern void DoSomething();

        // make a call into the C dll
        DoSomething();

        • The same is true for C#, using the platform invoke mechanism, it's even simpler. // import the C dll method signature
          [DllImport("myclib.dll")]
          static extern void DoSomething(); // make a call into the C dll
          DoSomething();

          The point isn't that lower level languages can call libraries -- I'd *hope* that any non-toy language can do it -- the point is if a higher level scripting language can do it, why *bother* with all the extra bother of low level languages?
      • What about when pointer semantics is less clear?

        How does Ruby know whether or not it has to free() the string returned from Curl.curl_version?

        These things may look nice at first, but trying to automagically use low-level languages as if they were high is doomed to a painful failure :)

        You may be aware of this, but your post is misleading in that it makes the reader think the programmer is freed from dealing with the pesky details of using a low-level language.

    • Re:Sweet Spot? (Score:3, Insightful)

      by j1bb3rj4bb3r ( 808677 )
      So I am an embedded engineer working on a networking device (load balancer). I've been working in the field for about 6 years now. C++ has been in use the entire time. As memory has become cheaper, more and more of the control plane on these embedded devices has been developed a la application software (using OO design principles, etc.). Device drivers are generally written in C, but that's not because of any inherent bloat in C++, but simply because 'driver people' historically know C and are not conce

    • Re:Sweet Spot? (Score:5, Insightful)

      by jeif1k ( 809151 ) on Wednesday September 29, 2004 @04:07PM (#10387215)
      operating system kernel or core library,

      It's a myth that C/C++ is particularly fast or efficient for those applications: in the absence of language-provided features like garbage collection, runtime safety, or dynamic typing, people end up reinventing those features over time, badly and less efficiently.

      Both Gtk and Qt are actually sad examples of this: not only does their functionality suffer from their choice of language (each has invented their own object models), their resource requirements are embarrassingly bad.

      application programming. Here development speed is more important than execution speed. Python and kin provide 'good enough' execution speed when coupled with proper libries (QT, etc) with the fastest development speed.

      Languages like Python have other problems for the development of large systems, like the lack of static type checking. Python is great, however, for prototyping, extensions language uses, and for single programmer projects.

      But, in any case, there is a lot of application software that requires much better performance than languages like Python can deliver: CAD systems, graphics systems, image encoders/decoders/editors, vector graphics renderers, typesetting and layout software (including web browsers and editors), audio encoders/decoders, GIS systems and mapping programs, speech recognition engines, and lots more. No, application developers have neither the time nor the resources to turn all the compute intensive core functionality in C/C++ code and then link that into Python. C# is a good middle ground.

      let alone C# or Java, although we may be ready for it in 5 years or so.

      The performance of Sun's Java implementation is excellent (although Java sucks for other reasons). The performance of C# implementations is quickly catching up with Java implementations.

      • Re:Sweet Spot? (Score:3, Interesting)

        by bushidocoder ( 550265 )
        The performance of C# implementations is quickly catching up with Java implementations.

        That depends. For single processor 32bit x86 environments, I've found .NET to be significantly faster than Java. It helps to be able to inline short non-virtual methods, perform allocations for simple non-native-typed objects on the stack, etc. The gap will probably only widen as the two camps release their very different implementations of generics.

        Java clobbers .NET in the 64 bit world and in the multi-processor

      • Both Gtk and Qt are actually sad examples of this: not only does their functionality suffer from their choice of language (each has invented their own object models), their resource requirements are embarrassingly bad.

        This is a baseless argument. What evidence do you have that GTK (I have no experience with QT) is a poorly designed object framework? In actuality I find it a superbly well-designed framework that translates *very* well into these other object-oriented languages like C#, Java, and C++. Py
        • What evidence do you have that GTK (I have no experience with QT) is a poorly designed object framework?

          Nowhere did I say it was "poorly designed". Gtk+ is probably about as good a toolkit as you can design with C.

          Python and Perl also have bindings that are very comfortable within their own object framework.

          Yes, after a lot of work has been spent on fixing the bindings and the bugs. And even then PyGtk applications written in pure Python still can crash with memory management and pointer errors. And

      • The performance of Sun's Java implementation is excellent

        But not near as good as JRockit(BEA) on Intel.

      • Re:Sweet Spot? (Score:4, Insightful)

        by Peaker ( 72084 ) <gnupeaker @ y a h oo.com> on Wednesday September 29, 2004 @05:41PM (#10388389) Homepage
        No, application developers have neither the time nor the resources to turn all the compute intensive core functionality in C/C++ code and then link that into Python. C# is a good middle ground.

        Huh? I typically find that I don't have the time not to do this. Programming in Python takes me about 5 to 10 less time than programming the same functionality in C, and in the rare cases something is too slow even with Psyco [sourceforge.net], I use Pyrex [canterbury.ac.nz] for the inner loop, typically a single function or class.

        CAD systems: I am not familiar with those, what exactly is too performance-critical for Python in CAD systems?

        graphics systems: Huh?

        image encoders/decoders/editors: Image encoders/decoders are typically very small projects - small enough to write in C or other low-level languages.

        vector graphics renderers: Probably true

        typesetting and layout software (including web browsers and editors): Python is fast enough for these, on non-antique hardware.

        audio encoders/decoders: Similar to image encoders/decoders, these are small and should be implemented in a low-level language.

        GIS systems and mapping programs: What is time-critical about these?

        speech recognition engines: I suspect there's a small algorithm running in an inner loop and a lot of higher-order code. Only the inner loop needs C, and that only if you want Real-Time behavior.

        Ever since I turned to write nearly all my code in Python, my productivity was boosted by hundreds of percents, and I am less surprised with time that Python is fast enough in almost all cases when it is used right.

      • Re:Sweet Spot? (Score:3, Insightful)

        by Junks Jerzey ( 54586 )
        Languages like Python have other problems for the development of large systems, like the lack of static type checking.

        This is a debatable point. On the one hand, yes, it is dynamically typed. On the other hand, having easy access to an interpreter and zero compilation times leads to interactive testing and a more incremental approach to building large applications. In my experience, the latter far outweighs the former (as long as raw performance isn't the issue).

    • Re:Sweet Spot? (Score:2, Interesting)

      by bushidocoder ( 550265 )
      The problem is that alot of people don't think Python/Ruby/Perl fits appropriately into 2) because of the language bindings. One of the advantages of managed frameworks (particularly .NET/Mono) is that once somebody somewhere wrote a .NET library to do something, that library is available immediately for use in any language which compiles to IL or has an IL runtime built into it.

      Projects like IronPython give you all the advantages of working in Python, all the advantages of working on top of the CLR frame

    • What kind of code falls between the 2? Sure there is some, but is it interesting?

      The whole enterprise middle-tier application world. The one where they spend billions of dollars on software, you know? Where hordes of mindless drones whip out custom code that actually has to run reasonably fast and interoperate with a variety of systems.

      In short - everything you want to run in an app server to do business.

  • I thought... (Score:3, Funny)

    by Rorschach1 ( 174480 ) on Wednesday September 29, 2004 @03:36PM (#10386800) Homepage
    I once thought I was developing Mono for an entire year. Turns out I was just really bored.

  • Before anyone starts trolling... (Score:5, Informative)

    by adolfojp ( 730818 ) on Wednesday September 29, 2004 @03:37PM (#10386806)
    Lets look at somne important facts first so we can have an eduated and informed discussion.

    Mono with the .NET, ASP.NET and ADO.NET compatibility layers might run into trouble in the long run because those libraries are patent encumbered.

    Mono with GTK#, Gnome, Mozilla and other libraries doesn't have that problem because the only thing that it uses from Microsoft is the ECMA standard C# language implementation.

    Why Mono and not Java? Mono is 100% open source.

    Why Mono and not Python? Mono uses a virtual machine environment that is faster than an interpreted language. Some people prefer the Java and C++ similarities that C# offers. Mono is cuasi language independent. You can use Python in Mono (See Iron Python).

    "Miguel de Icaza is wasting his time..." Miguel works on Mono because he likes it, he is not employed by you (except if you are Novell) so he spends his time as he sees fit. He owes you nothing.


    Cheers,

    Adolfo

    • Re:Before anyone starts trolling... (Score:3, Informative)

      by Anonymous Coward
      Why Mono and not Java? Mono is 100% open source.

      Well.. if you're going to be "educated and informed", you should at least trouble yourself with considering the fact that there are open-source implementations of Java.

      JBoss, gcj, kaffe...

      And it's also fair to remember that there are indeed two different .NET implementations, Mono and dotGNU..
      • Mono with the .NET, ASP.NET and ADO.NET compatibility layers might run into trouble in the long run because those libraries are patent encumbered.

        Mono with GTK#, Gnome, Mozilla and other libraries doesn't have that problem because the only thing that it uses from Microsoft is the ECMA standard C# language implementation.

      And the beaut think about that is the *potentially encumbered* libraries are in a different part of the build tree, ready to be pulled if a MS (FUD) patent does get served.

  • For the uninitiated (Score:4, Informative)

    by mreed911 ( 794582 ) on Wednesday September 29, 2004 @03:43PM (#10386892)
    If you have questions about Mono, read the project launch statement [mono-project.com] or visit the list of Frequently Asked Questions [mono-project.com].

    There's an RSS feed [mono-project.com] for the newest news, updates, etc. on Mono, too.

  • Developing Mono. (Score:4, Funny)

    by holzp ( 87423 ) on Wednesday September 29, 2004 @03:48PM (#10386943)
    Most slashdotters need instructions on the normal way to develop Mono.

  • Who needs a book? (Score:3, Funny)

    by SensitiveMale ( 155605 ) on Wednesday September 29, 2004 @04:02PM (#10387130)
    I developed mono back in the 7th grade.

  • Argh! (Score:5, Informative)

    by be-fan ( 61476 ) on Wednesday September 29, 2004 @04:03PM (#10387162)
    C/C++ = Weakly statically typed
    Java/C# = Strongly statically typed
    Python/Ruby = Strongly dynamically typed

    "Loose" typing is another way of saying "weak" typing. Meaning the system doesn't enforce type safety. In almost all scripting languages, type safety is strongly enforced.

    • Re:Argh! (Score:3, Informative)

      by ari_j ( 90255 )
      You didn't cite any examples of weak dynamic typing, like Tcl. Don't forget Tcl!

      • Re:Argh! (Score:2)

        by ajs ( 35943 )
        You didn't cite any examples of weak dynamic typing, like Tcl. Don't forget Tcl!

        I keep trying to forget TCL... the drugs are helping... aaahhh!! Vignette!! Tk applications that don't scale!! burning! death!....

        Ok, I'm ok... it's ok... please don't mention that language again.... PLEASE.
    • Bah, I can't believe people stilll shovel this stuff.

      C/C++ = Weakly statically typed
      Java/C# = Strongly statically typed

      Why? Because you can cast to a void *? You can cast to Object in Java and it's not checked until run time. The typing of Java is no stronger than C++.

      At least we have strongly-typed collections in C++. How many times have you pulled the wrong thing out of a Java collection and not found this out until run-time...

      The silly things they print in textbooks...
      • C/C++ has weak typing not because you can cast to void*, but because you can then cast that void* back into a type different from the original type, and then use that pointer. Java will give you an error at runtime in this situation, but C/C++ will happily go and corrupt memory.

      • Re:Argh! (Score:3, Informative)

        by be-fan ( 61476 )
        At least we have strongly-typed collections in C++

        You *don't* have strongly-typed collections in C++. You've got *statically* typed collections in C++. They are, however, still *weakly* typed.

        The difference between weak and strong typing is in that a strongly typed language, the compiler enforces the type system.

        The difference between static and dynamic typing is that in a dynamically typed language, some type information may not be known until runtime.

        Maybe you should read one of those textbooks...
    • While Java is nominally statically typed, typing information is preserved into run-time, not least because using collections (pre 1.5) meant throwing away type information and casting (because the type system was ridiculously primitive, with no parametric polymorphism). It's comparisons against this typing information that allow ClassCastExceptions and IndexOutOfBoundsExceptions to be thrown at run-time (and furthermore that such RuntimeExceptions are built into the execution model that allows 'strong' typ

  • Here is somthing funny (Score:3, Informative)

    by N8F8 ( 4562 ) on Wednesday September 29, 2004 @04:09PM (#10387233)
    You can run ASP.NET on Linux using Mono, but you cant run it on Windows. You would think there would be a big push to get in working under Apache on Windows since this woulod be the perfect bridge to moving your site to Linux.

  • C# without .NET? (Score:3, Interesting)

    by Animats ( 122034 ) on Wednesday September 29, 2004 @04:09PM (#10387235) Homepage
    Can you use C# without .NET or some replacement for it? Is it possible to use it with POSIX alone? Or perhaps with OpenGL?

  • Oh hell, I'll bite (Score:5, Insightful)

    by DrZombie ( 817644 ) on Wednesday September 29, 2004 @04:25PM (#10387449)
    I've been writing in Java for 6 years professionally, and been playing with it since I picked up the beta with one of the original programming books in '96ish time frame. Lately I've been playing with C#, and while I don't particularly care for Microsofts business practices, they put out some pretty good development tools. C# is a damn fine language that seems to have learned from the mistakes others have made while taking away the good stuff. Java has way too many things that bug me. Little things here or there. C# pretty much got rid of them. Off the top of my head, overloading operators is a big one for me. I tend to write a lot of mathematical manipulations, and being able to overload the operators to naturally manipulate custom data structures is a huge benefit from my standpoint. I mean if you want to write a method to do it in Java and then have to make explicit method calls feel free... You're stupid, but feel free. I'd rather just work with it naturally. The Java GUI library is crap, and with rare exceptions (sweet sweet firefox) doesn't produce attractive apps. C++ is still my favorite development language, but I don't want to write tons of boilerplate code, deal with messy structure, or have to deal with custom memory managers everytime I write an app. For those who are putting down Mono as some kind of stupid side project, stop stroking your self. I'm a little tired of sysadmins out there who know a little scripting coming off like they are developers. It's a pretty ambitious undertaking for anyone to work on in their spare time. And just because a Microsoft team developed C# doesn't mean it's going to just be a Microsoft development language. The C# spec has been accepted by ISO and anyone can write a C# compiler at this point.
    • The Java GUI library is crap, and with rare exceptions (sweet sweet firefox) doesn't produce attractive apps.

      Where did you get the idea that Firefox was written in Java? It's derived from Mozilla (which is C++) and makes heavy use of XUL which uses JavaSCRIPT. That has nothing to do with Sun's Java one single bit.

    • I won't. Since when was Firefox written in Java?
  • "but i always felt the lack of a sweet spot between the hard and fast low-level programming languages and the loosely typed scripting languages"

    Every try pascal or Object Pascal (Delphi)?

  • Hehe... (Score:3, Funny)

    by Jugalator ( 259273 ) on Wednesday September 29, 2004 @05:11PM (#10387982) Journal
    Lately, my interest in the Mono project has been growing. The C# language appears to offer just that sweet spot between power and productivity I've been looking for

    Yeah, of course now that there's an open source implementation, C# is a good language...
  • It is an equivalanent system, no matter what are the personal preferences.

    But Java has better support on a bigger variety of systems. And it does not rely on the good will of Microsoft to allow it to run on Linux.

    And when using JRockit JVM on INtel harware - it is fast. Faster then equivalent C# code in my applications (prototyped certain numerical algorithms)

    And it has a better development environment: Eclipse, IntelliJ etc.

    Why C#. Why make it sound that this is some revelation of a language? T

    • Java relies on the good will of Sun, which recently has entangled themselves with Microsoft even more. The 32 bit space & allocation limits of the JVM might limit some applications, and the JVM is still a resource pig.

      • The 32 bit space & allocation limits of the JVM

        I must have been dreaming running JRockit on Itanium. Or, much more likely, you do not know what you are talking about.

        Java beats pants off C# on 64 bit. Java does not depend on the good will of Sun as long as folks like IBM, Oracle, BEA etc are around.

    • Java and C# are quite different in my view. Java is succesfully entrenched on the server side, while C# looks like it will become quite successful on the desktop.

      To date Java has produced exactly two good desktop applications, Eclipse and Azureus. It's an abysmal failure, and the associated stigma won't disappear anytime soon.

      Telling users to go to Windows update and pull down .NET 1.1 or bundling the runtime with the OS is a tremendous benefit and a magnitude easier than getting end users to install Java

  • C# Rocks (Score:3, Interesting)

    by Pedrito ( 94783 ) on Wednesday September 29, 2004 @10:00PM (#10390403)
    I have to say it. C# does rock and I'm so happy about Mono doing so well.

    There are mistakes in how the C# language has been designed that really bug me at times, but I've been developping in C# for about 2 years now and I've never been so productive in my life.

    It has a lot of the advantages of Java, but with a better UI (and by better, I mean better looking AND better performance. The Java ones seem to be one or the other: Fast and Ugly or Slow and Pretty, and maybe even some slow and ugly ones).

    I really hope Mono can keep up with the Longhorn development because I really expect the library design to be better. There are a lot of aspects of the .NET framework that are clearly hacked together just to make it work. Others were clearly designed by developers with very little understanding of object oriented development principles.

    But complaints aside, overall it's excellent and as I said, I've never been so productive! As an independent contractor, that means a lot to me.

Slashdot Top Deals

It is easier to write an incorrect program than understand a correct one.

Close