×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Mono: A Developer's Handbook

timothy posted more than 9 years ago | from the one-at-a-time dept.

Programming 301

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.

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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

301 comments

First PSOT! (-1)

Anonymous Coward | more than 9 years ago | (#10386567)

Mono chupa la que cuelga :D

Relevance? (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10386579)

Why is this on Slashdot?

Anyone?

update: (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10386735)

For sale : seven letters [ebay.com] (Warning, use of these letters in the wrong order will get you sued by Microsoft!)

No animal on the cover? (5, Funny)

Neil Blender (555885) | more than 9 years ago | (#10386600)

It was only a matter of time before O'Reilly used them all up.

Re:No animal on the cover? (4, Funny)

lukewarmfusion (726141) | more than 9 years ago | (#10386655)

The "Notebook" series does not have animals.

Unless you count the rare and beautiful stickynote species, of which there are colors, shapes, and sizes. I have a small herd of sticky notes that surround my monitor and desk. My co-worker swears that he has heard me talking to them. I don't understand why this is strange, considering that many people talk to their pets. These are no ordinary pets, however... I was warned by the old Chinese man at Office Depot that I should not feed them after midnight, expose them to bright sunlight or let them touch water. He didn't explain what time after midnight it would OK to feed them, how bright the light can be, or how they are able to survive in moist environments and be made up of so much water but not touch it. Weird.

Beware the stickynote, for it is a mighty foe when angered.

Re:No animal on the cover? (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10386674)

Perhaps they could switch to illustrating their covers with various animals feces, most appropriate given the subject matter of this particular title.

Re:No animal on the cover? (2, Funny)

mopslik (688435) | more than 9 years ago | (#10386686)

No animal on the cover?

Since the book deals with Mono, might I suggest a gourami [thetropicaltank.co.uk]?

Re:No animal on the cover? (1)

Megaslow (694447) | more than 9 years ago | (#10386788)

Miguel de Icaza is Mexican...

In Spanish, Mono means Monkey, and I suspect that the "correct" pronounciation of Mono is "MOH-noh" (like Sonny Bono), not MAH-noh (like monochrome).

Re:No animal on the cover? (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10386716)

I think they rejected this picture [annexathens.com] for some reason, likely due to the fact that it's not the safest one for a work environment.

Re:No animal on the cover? (1)

Iron Monkey (113162) | more than 9 years ago | (#10386758)

Are you kidding? There are six million [bbc.co.uk] or so species of insects alone out there. That's a lot of books.

Now - which language gets the dung beetle?

Re:No animal on the cover? (1)

FuzzyBad-Mofo (184327) | more than 9 years ago | (#10387171)

Now - which language gets the dung beetle?

I nominate BASIC.. it's slow, ugly, and does jobs no self-respecting language wants to perform. Nevertheless, it fills a niche in the ecosystem.

The Mono Mascot (1)

unixbugs (654234) | more than 9 years ago | (#10387147)

How bout Streptomononucleosis? They could write a whole rash (haha) of MS books based on pests, plagues, vermin, stds and other microscopic scum. At this level, O'Reilly will never run out of themes which is good, since MS never seems to run out of crap to spew.

Summary of the next 100 posts (5, Funny)

Swamii (594522) | more than 9 years ago | (#10386602)

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!

Re:Summary of the next 100 posts (0)

Anonymous Coward | more than 9 years ago | (#10386629)

you forgot;
Why not use python?
Rants about mono beeing a patent infected M$ vaporware.
Rants about /. posting advertisment.

Re:Summary of the next 100 posts (1)

lphuberdeau (774176) | more than 9 years ago | (#10386705)

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...

Re:Summary of the next 100 posts (2, Interesting)

aminorex (141494) | more than 9 years ago | (#10386709)

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 (1, Interesting)

iezhy (623955) | more than 9 years ago | (#10386774)

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 it will be ripped out by evil M$ attorneys, as soon as it spreads enough. M$ is only waiting till enogh open-source project migrates to mono.

Re:Summary of the next 100 posts (1)

Swamii (594522) | more than 9 years ago | (#10386837)

They really don't amount to much in the real world, where the platform lock-in and enormous bloat that dotnet entails spell doom.

ACCKKKKKK! I see the writing on the wall!!!! It's spells D-O-O-M!!!! Run for the hills and repent of your sins!

Re:Summary of the next 100 posts (4, Funny)

pnatural (59329) | more than 9 years ago | (#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!

Re:Summary of the next 100 posts (2, Insightful)

javaxman (705658) | more than 9 years ago | (#10386790)

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 over *anything* else, other than Microsoft is pushing it hard ?

What's funny (0, Troll)

rd_syringe (793064) | more than 9 years ago | (#10386820)

What's funny is that Slashdotters criticize Microsoft constantly for not innovating and for ripping others off. Meanwhile, we're discussing C# and a .NET clone, running on a UNIX clone, which runs desktop environments that have Start menus, taskbars, integrated file/net browsers, and more.

The power of all the volunteers in the world, and all we can come up with is a UNIX clone with a Windows clone running on top of it.

Re:What's funny (0)

Anonymous Coward | more than 9 years ago | (#10386955)

What the fuck does that have to do with people criticizing MS for not innovating? All the shit you discribed was NOT invented by MS. FFS even C# is a Java rip off.

Forgot one... (0, Troll)

gillbates (106458) | more than 9 years ago | (#10387228)

Why not use C# and .Net?

Mono is seriously embarassing to the OS community. Why we had to create a cheap knockoff copy Microsoft's .Net (which itself was a bad clone of Java), is beyond me. Perhaps some of the more enlightened ones would be so kind as to instruct me as to which problems Mono solves that C++ didn't.

This is serious re-invention of the wheel. Neither Java, nor .Net, nor Mono have anything new and useful to offer programmers.

  1. They all borrow from the same syntactic conventions.
  2. Their libraries don't offer significantly better features or functions than the existing libraries available in C++.
  3. They impose upon the end user the additional burden of starting up a virtual machine, in addition to the fact that interpreted code almost never runs as fast, let alone faster, than natively compiled code. Granted, you might say Java's hotspot would help this, but what's the point of jumping through hoops to get the same performance you already had?

So let me get this straight: If I wanted to use Mono, I'd have to:

  1. relearn how to do everything I already know how to do in C++...
  2. rewrite all of my personal libraries...
  3. learn a completely new set of bugs in a new API....
All so that my code would do the same thing it's always done, but perhaps a little slower. Why bother?

I know that dissing a language is likely to get me branded a troll, but I honestly don't see the point of jumping on the Java-.Net-Mono bandwagon when I'd have to relearn everything to gain practically nothing. Yes, I'd learn it if a job required it, but why OS authors are bothering to re-implement something that shouldn't have been done in the first place is beyond me.

As much as I hate to say this, I get the impression that the Mono project is little more than a bunch of programmers with something to prove; they stroke their own egos thinking, "Look at me, look at me! Microsoft made .Net, and I made Mono..."

Meanwhile, the rest of us just roll our eyes. Copying Microsoft doesn't make one L33T, just unimaginative. I'd be more impressed if Mono wasn't compatible with .Net, and if it actually offered something better than what C++ did ten years ago.

Objective-C (3, Interesting)

remahl (698283) | more than 9 years ago | (#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.

Q: What is the definition of redundant? (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10386656)

A: I'm a gay Linux user

*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_
g_______________________________________________g_ _
o_/_____\_____________\____________/____\_______o_ _
a|_______|_____________\__________|______|______a_ _
t|_______`._____________|_________|_______:_____t_ _
s`________|_____________|________\|_______|_____s_ _
e_\_______|_/_______/__\\\___--___\\_______:____e_ _
x__\______\/____--~~__________~--__|_\_____|____x_ _
*___\______\_-~____________________~-_\____|____*_ _
g____\______\_________.--------.______\|___|____g_ _
o______\_____\______//_________(_(__>__\___|____o_ _
a_______\___.__C____)_________(_(____>__|__/____a_ _
t_______/\_|___C_____)/LINUX_\_(_____>__|_/_____t_ _
s______/_/\|___C_____)USERS_TAKE(___>___/__\____s_ _
e_____|___(____C___IT_UP_THE_ASS//__/_/_____\___e_ _
x_____|____\__|_____\\_________//_(__/_______|__x_ _
*____|_\____\____)___`----___--'_____________|__*_ _
g____|__\______________\_______/____________/_|_g_ _
o___|______________/____|_____|__\____________|_o_ _
a___|_____________|____/_______\__\___________|_a_ _
t___|__________/_/____|_________|__\___________|t_ _
s___|_________/_/______\__/\___/____|__________|s_ _
e__|_________/_/________|____|_______|_________|e_ _
x__|__________|_________|____|_______|_________|x_ _
*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_


Important Stuff: Please try to keep posts on topic. Try to reply to other people's comments instead of starting new threads. Read other people's messages before posting your own to avoid simply duplicating what has already been said. Use a clear subject that describes what your message is about. Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) If you want replies to your comments sent to you, consider logging in or creating an account.

Important Stuff: Please try to keep posts on topic. Try to reply to other people's comments instead of starting new threads. Read other people's messages before posting your own to avoid simply duplicating what has already been said. Use a clear subject that describes what your message is about. Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) If you want replies to your comments sent to you, consider logging in or creating an account.

Important Stuff: Please try to keep posts on topic. Try to reply to other people's comments instead of starting new threads. Read other people's messages before posting your own to avoid simply duplicating what has already been said. Use a clear subject that describes what your message is about. Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) If you want replies to your comments sent to you, consider logging in or creating an account.

Re:Objective-C (3, Informative)

Swamii (594522) | more than 9 years ago | (#10386668)

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 (0)

Anonymous Coward | more than 9 years ago | (#10386904)

Python will run even faster on parrot, since it was designed for dynamic languages whereas the CLR was not.

Re:Objective-C (5, Informative)

Swamii (594522) | more than 9 years ago | (#10386961)

Python may very well run faster on Parrot. However, your thinking that the CLR is not designed for dynamic languages is incorrect. Take this quote from Jim Hugunin:


It was a little less than a year ago that I first started investigating the Common Language Runtime (CLR). My plan was to do a little work and then write a short pithy article called, "Why .NET is a terrible platform for dynamic languages". My plans changed when I found the CLR to be an excellent target for the highly dynamic Python language. Since then I've spent much of my spare time working on the development of IronPython.

The more time that I spent with the CLR, the more excited I became about its potential. At the same time, I was becoming more frustrated with the slow pace of progress that I was able to make working on this project in my spare time. After exploring many alternatives, I think that I've found the ideal way to continue working to realize the amazing potential of the vision of the CLR. I've decided to join the CLR team at Microsoft beginning on August 2.

At Microsoft I plan to continue the work that I've begun with IronPython to bring the power and simplicity of dynamic/scripting languages to the CLR. My work with Python should continue as a working example of a high-performance production quality implementation of a dynamic language for the CLR. I will also reach out to other languages to help overcome any hurdles that are preventing them from targeting the CLR effectively. I welcome any and all feedback about how to best accomplish this. You can reach me at jim@ironpython.com.


Lesson to be learned, if you think something from MS sucks, only to find out it doesn't, you might just get hired. ;-)

Re:Objective-C (0)

Anonymous Coward | more than 9 years ago | (#10387231)

I read the IronPython paper already, it discusses overcoming the design implimentations of the CLR. The CLR was never designed to host dynamic languages, if it were Microsoft would not have needed to hire him and this is exactly the conclusion I draw from the text you quoted.

Lesson to be learned, I have morals, I would starve to death before working for a company like Microsoft. ;-)

Re:Objective-C (3, Informative)

jeif1k (809151) | more than 9 years ago | (#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.

Re:Objective-C (2)

imroy (755) | more than 9 years ago | (#10386941)

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 around the lack of operator overloading without using explicitly named methods?

Re:Objective-C (0)

Anonymous Coward | more than 9 years ago | (#10386957)

Both you and the submitter seemed to suggest that C and C++ are "low-level languages". Really? What's assembler then? Machine language? C and C++ are quite high-level.

Re:Objective-C (2, Insightful)

ari_j (90255) | more than 9 years ago | (#10387055)

High-level vs. low-level isn't a dichotomy, it's a continuum. At the lowest level you input raw machine code, and you move up through assembly (which was, at one time, very high level), and then to procedural languages like Fortran and C, and then it all branches out but there are languages like Python and Ruby that are higher-level than C, and eventually you get to Lisp which is an extremely high-level language.

Object-orientation is just a language feature, it's not a true indicator of the level at which a language exists, but typically it provides a boost to the level of a language. C, Objective-C, and C++ are each slightly higher-level than the last, but only slightly. It's other standard features (iostream, STL, etc.) that make the language truly higher-level.

The level of a language also depends on what you measure that level relative to. One way to look at it is to ask how far above the machine you are. In assembler, you aren't very far off the hardware. Every instruction is tailored to the hardware. But you can also measure relative to the OS. In C, you are farther from the hardware itself, but low-level to the operating system - you have to tailor your code to the OS it will run on.

What about java? (-1, Troll)

pUNX.h (515817) | more than 9 years ago | (#10386610)

Some body had to say it!

Java can be just as fast as C...
Just look at the Java multimedia projects...
Speech to text.... text to speech... all in java.... all just as fast as C could do it....

Mono = Microsoft.NIX

Re:What about java? (5, Informative)

Swamii (594522) | more than 9 years ago | (#10386738)

Not quite. A better comparison,

Mono is Novell's implementation of this standard [ecma-international.org].

On the other hand, .NET is Microsoft's implementation of this standard [ecma-international.org].

Same standard, 2 different implementations of the standard.

Re:What about java? (0)

Anonymous Coward | more than 9 years ago | (#10387091)

..and the class libraries be damned! Or?

Re:What about java? (3, Informative)

tonyray (215820) | more than 9 years ago | (#10386847)

It takes MUCH longer to code a program in Java than C# (business type programs with lots of screens, error checking and database access). Each language has it's place and C# approaches VB for RAD where Java is more like programming in C++ for speed of application development.

Mono (3, Funny)

NoInfo (247461) | more than 9 years ago | (#10386616)

Am I the only one who immediately thinks of debilitating diseases whenever this project is mentioned?

Re:Mono (0)

Anonymous Coward | more than 9 years ago | (#10386632)

No, I personally thought that all you had to do to get mono is make out with someone who had it, and was confused as to why people would need a whole book to explain this.

Re:Mono (2, Funny)

xtort17 (757334) | more than 9 years ago | (#10386700)

No, I personally thought that all you had to do to get mono is make out with someone who had it, and was confused as to why people would need a whole book to explain this.

There are always books explaining how to accomplish difficult tasks. Most people here would be hard pressed to contract mono the way you described.

Re:Mono (0, Offtopic)

32bitwonder (684603) | more than 9 years ago | (#10386749)

Agreed! This project should be renamed if for nothing else than to help bolster more pleasant mental imagry for those unaware of this project.

Re:Mono (0)

Anonymous Coward | more than 9 years ago | (#10386789)

The debilitating disease is that of stupidity. Does anybody seriously think Microsoft won't fuck the mono project over for patent infringement if it gains marketshare. Microsoft patented the .NET API's, this isn't something Miguel has ever addressed, he just changes the subject and talks about EMCA standardization.

People who are counting on indefinate good faith from MSFT deserve everything they get!

Notebook or Handbook? (0)

Anonymous Coward | more than 9 years ago | (#10386719)

First it's called Mono: A Developer's Handbook, then it's called Mono: A Developer's Notebook.

What's next? Mono: A Developer's Tablet?

Re:Notebook or Handbook? (0)

Anonymous Coward | more than 9 years ago | (#10386751)

What's next? Mono: A Developer's Tablet?

It sure beats Mono: A Developer's Suppository.

This is a boffo follow-up to hugely successful... (1, Funny)

Anonymous Coward | more than 9 years ago | (#10386725)

Mono: An Incubator's Handbook

What, no VB? (1, Interesting)

Nom du Keyboard (633989) | more than 9 years ago | (#10386739)

If Mono doesn't support Visual Basic .NET, I'm not interested.

Even if VB.NET really is nothing more than VC++ in VB sheep's clothing.

Re:What, no VB? (0)

Swamii (594522) | more than 9 years ago | (#10386801)

Must...resist...urge...to...bite.... argghhh Mono Basic, their implementation of VB.NET, can be found here [go-mono.com].

Re:What, no VB? (2, Informative)

bendermannen (817161) | more than 9 years ago | (#10387005)

What the hell are you talking about? VB.NET has nothing to do with VC++. Neither C# or VB.NET compiles to object code which can be executed directly by the target computer. You should really read up on what youre talking about before posting... And that goes for those who gave you points as well.

Re:What, no VB? (1)

fitten (521191) | more than 9 years ago | (#10387146)

VB.NET is actually more like C# than the older (VB6) VBs. It looks almost like C# with global search and replace of keywords and the like.

Re:What, no VB? (1)

donbrock (705779) | more than 9 years ago | (#10387227)

If Mono doesn't support Visual Basic .NET, I'm not interested.

According to this article the next release of mono in March will implement a native Visual Basic (VB.Net) compiler and Windows Forms (WinForms)...whatever that is. http://www.vnunet.com/news/1158239

Mono vs .NET Framework (2, Interesting)

Nick of NSTime (597712) | more than 9 years ago | (#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 (1)

trendzetter (777091) | more than 9 years ago | (#10386916)

Yes. For me mono made me create my first linux desktop application. I could learn some coding at work and I am taking a course on .NET. It hasn't yet the fancy tools such as visual studio but you can use them if you really want.
It is also possible to buy this book and start writing your applications using monodevelop which offers alot of usefull features.

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

jblake (162981) | more than 9 years ago | (#10386931)

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 (5, Informative)

steve_deobald (729154) | more than 9 years ago | (#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.)

Re:Mono vs .NET Framework (1)

Oxy the moron (770724) | more than 9 years ago | (#10387010)

In the case of simplicity, Mono versus .Net isn't really the comparison point. The point of comparison is VS.Net versus MonoDevelop.

While MonoDevelop is definitely making good progress, there are multiple aspects of VS.Net (nice integrated designer, integrated debugging, etc.) that really enhance the development process. Until those are implemented in MonoDevelopment, MS.Net + VS.Net will be the simpler route.

Re:Mono vs .NET Framework (2, Informative)

jeif1k (809151) | more than 9 years ago | (#10387030)

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 integrated into Monodevelop, giving you a VisualStudio.NET-like experience developing applications for Mono and Gnome.

So, in short, yes, Mono "captures the simplicity of the .NET framework" and then some.

Re:Mono vs .NET Framework (0)

Anonymous Coward | more than 9 years ago | (#10387033)

So I can write code in C# on VS.NET 2003, and then just compile it on LINUX with mono and it will work? Even the Windows.Forms classes?

Sweet Spot? (4, Interesting)

Freedom Bug (86180) | more than 9 years ago | (#10386743)

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? (4, Interesting)

tcopeland (32225) | more than 9 years ago | (#10386896)

> 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? (2, Informative)

Swamii (594522) | more than 9 years ago | (#10387011)

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();

Between the Two (0)

Anonymous Coward | more than 9 years ago | (#10386946)

Lies scientific/engineering programming, game programming... just off the top of my head (these are the only types of pregramming I do).

As to interest, it's hard to argue that your examples are more interesting types of code.

pregramming????? (0)

Anonymous Coward | more than 9 years ago | (#10386972)

And I previewed too ...

there's a pun in there but I can't find it

Re:Sweet Spot? (3, Insightful)

j1bb3rj4bb3r (808677) | more than 9 years ago | (#10386980)

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 concerned with OO.
I work specifically on 'fast path' software that is in the data path, and while we absolutely must be concerned with performance, a good C++ compiler will generate perfectly acceptable code from a speed standpoint. Any tweaks can be done in assembler. The benefits in extensibility and good code design are usually worth it in the log run (and better designed code is generally less buggy and often faster)
So, the point is that it's primarily memory footprint that has kept embedded engineers from using C++ (or other OO) in the past, but as that restriction has lessened, more and more of them are using C++ and OO design principles (even in 'fast path' processing).
Therefore, I (and many of my collegues) would like a language that is more OO than C++ (which frankly is a hack between C and strict OO languages), but still provides the direct system and memory access that a language like C provides. Not saying C# is it by any means, but there is a sweet spot between #1 and #2, and I'm living in it ;).

Re:Sweet Spot? (5, Insightful)

jeif1k (809151) | more than 9 years ago | (#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.

It's not the language that counts... (2, Interesting)

Dante Shamest (813622) | more than 9 years ago | (#10386756)

An important part of any modern language is its class libraries. C# beats C++ only in the size of it's standard library. (Managed C++ doesn't count). If only the ANSI/ISO dudes would include a standard GUI library (even a very simple one) and stop spending so much time on generics and algorithms...

I thought... (3, Funny)

Rorschach1 (174480) | more than 9 years ago | (#10386800)

I once thought I was developing Mono for an entire year. Turns out I was just really bored.

Re:I thought... (0)

Anonymous Coward | more than 9 years ago | (#10386840)

ummmmm, shut up. You got that from Wayne's World.

Before anyone starts trolling... (5, Informative)

adolfojp (730818) | more than 9 years ago | (#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... (3, Informative)

Anonymous Coward | more than 9 years ago | (#10386925)

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..

Re:Before anyone starts trolling... (0)

Anonymous Coward | more than 9 years ago | (#10386986)

The reference Python implimentation _is_ a VM since it compiles to bytecode internally. Python will run faster on parrot. C# is a poor language choice without the support of the .NET libs which are patent encumbered as you correctly point out.

Otherwise I guess you're correct; I'll still never be installing a Microsoft CLR tho so it doesn't matter.

Re:Before anyone starts trolling... (0)

Anonymous Coward | more than 9 years ago | (#10387178)

Lets look at somne important facts first so we can have an eduated and informed discussion.

I want somne eduation to !

oops - have to enable /. headline filter (0, Troll)

Pupbear (222710) | more than 9 years ago | (#10386813)

So I wasn't paying that close attention, and saw the headline for this story and thought that it was a cookbook for biological weapons.

Why I think this is useful (0, Offtopic)

ewanrg (446949) | more than 9 years ago | (#10386851)

The applications that most get the attention of folks in my office run under both Windows and Linux, and the fact they do so make it easier to ease folks into thinking outside the Microsoft "box". While I'm not sure I'm looking forward to a version of Firefox or OpenOffice written in Mono, I can't say it would be a bad thing either.

In fact I think it would be "real" interesting to have someone write an app in Java, and another in C#, that can run in their respective environments on both Windows and Linux, and see where the sweet spot is.

Of course, I'm also the sort of person that thinks that imagining [blogspot.com] what Bill Gates' daughters will teach him about technology is fun too...

Cobol (1)

TheIronDuke (649926) | more than 9 years ago | (#10386853)

I want to use Object Oriented COBOL.

Talking up a particular .Net language is silly (0)

Anonymous Coward | more than 9 years ago | (#10386877)

All .Net languages compile to the same bytecodes and have the same abilities.

Developing Mono. (4, Funny)

holzp (87423) | more than 9 years ago | (#10386943)

Most slashdotters need instructions on the normal way to develop Mono.

Glaring Omission (0)

Anonymous Coward | more than 9 years ago | (#10387068)

There's not one word in that book about how you make a d@mn printout from your lovely Gtk# program!

Why bother? (1, Insightful)

laird (2705) | more than 9 years ago | (#10387121)

I'm sure the book is nicely written and all, but I'm still mystified by why anyone would care about C# or Mono. It all reminds me of when Intel announced the Itanium and scared half of the competing CPU manufacturers to kill off their own products. As a business strategy, it hardly matters that the Itanium has failed completely in the marketplace, since the competition largely committed suicide years ago, so Intel wins by default. Imaging how cool the Alpha, MIPS, etc., might have been by now if they'd continued active development...

So, back to Mono -- why on earth should anyone care that there's something that's almost Java, only without anywhere near as much industry support, and many years less maturity? Sure, MS is scary and all, but so was Intel... now, if C# were substantially better than Java, it would at least be technically interesting, but so far the best argument I've heard for using C# instead of Java is that MS is promoting it. I can see why that would be important in an MS-only shop, but why on earth would anyone interested in cross-platform or open software care about, much less promote, Mono? Is it some twisted attempt to take control of C# from MS?

Argh! (4, Informative)

be-fan (61476) | more than 9 years ago | (#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.

Here is somthing funny (2, Informative)

N8F8 (4562) | more than 9 years ago | (#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? (2, Interesting)

Animats (122034) | more than 9 years ago | (#10387235)

Can you use C# without .NET or some replacement for it? Is it possible to use it with POSIX alone? Or perhaps with OpenGL?
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...